Business modeling. Basic approaches

In this article I want to talk about the basic principles of business modeling, about the approaches that are used in this area, and on the basis of which modeling languages ​​and notations are created.



I already wrote about modeling using IDEF0 (Introduction to IDEF0 notation and usage example), about the organization of warehouse operations and working with clients from lead to transaction (CRM implementation. From lead registration to closing a deal. Case and explanation), about Bizagi system ( Bizagi. Description. Example). And everywhere I used to clarify examples and practical solutions of business process notation.



On the one hand, the use of schemes for clarity when describing business models does not raise any questions. It is really very convenient. On the other hand, many businessmen and even my colleagues are wondering why we need special notations and rules for developing business processes, because in any graphical editor (visio) or using other handy tools you can simply draw an intuitive pattern.

')

I want to talk about why standardization is so important, and also about when a particular approach is applied.

Basic approaches

Today there are many different tools for developing business models, they use different modeling languages, both standard and some of their own development. But all of them can be combined according to the principle of work in three main approaches:

• Functional;
• Process;
• Mental (using mental maps).

In fact, of course, there are other approaches, many of them as well as modeling languages. But they are mostly hybrid solutions that combine the listed approaches. In addition, it is the process and functional models that have already become standards, at least in the west. And with us they are becoming more common. I want to talk about these main areas in more detail.

Functional modeling

Functional modeling considers business as a function (lat. Functio - performance, execution) or in other words “black box”. In the functional model, the function does not have a time sequence, but only an entry point and an exit point. Functional modeling helps to consider a business model from a performance point of view, i.e. in modeling, we proceed from what we have at the input, and what we want to get at the output.



For example, a company is developing some kind of CRM system for its business. In the case of the application of a functional approach to modeling, the environment itself chosen for work suggests where to start. The entry point is “incoming customer interest or lead”, the exit point is the desired result: “buying and receiving a loyal client”, “getting a regular client”, “getting maximum information about a potential client”, etc.



Thus, in the functional model, the entry point and the desired result are initially known, and the sequence of actions is the object of development. At the same time, the use of functional models as “black boxes” allows to detail each stage as needed. And all the work in modeling is aimed at finding the optimal solution to achieve the goal.



You can also use functional models to demonstrate your ideas and solutions. It is also very convenient, because in the process of the demonstration you can move from the general to the detail, divide and decompose functions as needed. But you will decompose functions with this, and, dividing one function into several, you will not receive a description of the process.



Some confuse the process description and the functional model. For example, in the Business Studio system, a function is called a process, although this is not entirely true. Still, the description of functions and the process approach are somewhat different things. And I personally believe that functional modeling is optimally implemented in IDEFO notation. I myself use it for this type of work, and I also recommend it to everyone.



You can learn more about how to work with IDEFO by reading my article on communication with IDEF0 notation and an example of its use.

Process Modeling (Business Process Modeling)

I will talk about process modeling in terms of BPMN notation, as one of the most common standards for process modeling. At the same time, I fully agree that there are many modeling languages ​​and various systems. And everyone can use what is more convenient for him. But nevertheless BPMN is already the established standard of process modeling, and therefore I take it as the basis in the description.



The process from the point of view of a business model is a sequence of some events and actions that have a beginning and an end.



This is the main difference between process modeling and functional modeling. Functional modeling considers the business model in terms of input and output (available resources and the desired result). A process is based on a sequence of actions within certain limits, in the case of BPMN it will be the beginning and end of the event.



All processes can be broken down (detailed) into subprocesses up to detailing at the task level, i.e. actions which further detailing is impossible. A process is a sequence of actions that must be performed in order to get a certain result. It should be noted that in the business model as a process, the result may not be explicit in contrast to the functional model.



The fundamental difference between process modeling and functional modeling is that in process modeling, the focus is not on what we want to get, but on what needs to be done to get the result, i.e. not the outcome of a particular activity, but the sequence of actions.



For example, in BPWIN or Business Studio, in the process of detailing each function, there is a transition from a functional approach to a process approach. Those. in general, we consider the model from the point of view of the possibilities and the desired result, and when we turn to solutions for each function, an explicitly process approach is already practiced here, i.e. step by step algorithm of actions to achieve the result.



Imagine that in the functional model there is a “black box” - the function “Accept order”. And when decomposing, we already consider it not as a function, but as a process, and a sequence of actions when accepting an order - this is already a process approach.



There is another very important difference. The functional model cannot be used in the implementation of any system, only for design. And the process approach allows creating executable models, i.e. descriptions of the sequence of actions that we can later translate into some kind of environment for creating an enterprise collaboration system based on the process approach.

Mental approach (mental maps)

When creating mental models, a specialist approaches modeling not as a process or set of functions, but as there is no set of related concepts. For clarity, I will give an example - the mental map of the concept of “procurement procedure” (see figure).



This approach is used primarily for yourself. Drawing a scheme in free form helps to structure your knowledge, so to say, “sort through” the received information in free form. Also, such mental maps help to find a solution, which later, as needed, will be implemented within the framework of strict rules of the process or functional approach.



You can use mental maps and to demonstrate to clients: the existing situation, and solutions to the problem. Mental maps will help to visually demonstrate what methods can be used, to show various ideas in visual form.



The advantages of using such mental cards are obvious:

• No need to know any special languages;
• There are no strict frameworks and restrictions when creating a scheme;
• The mental map is intuitive in most cases;
• Creating such schemes is simple.

The downside is the lack of a well-established approach and standardized methodology. If in the functional and process notation there is some variation, but still it is limited to the strict limits of the modeling languages, the mental maps are created in an arbitrary form. And even specialized programs for their creation also almost do not limit the person in the process of modeling. Those. some rules may be introduced within a specific software product, but there is no standard.



As a result, to understand the model and the ideas embedded in it requires the presence and comments of its developer (analyst).



Of course, there are very simple maps that are intuitively read and without additional comments. But in the absence of standards, there is always the possibility that even in this case, the author had something else in mind, or somewhere he did not sufficiently elaborate his scheme. Those. There is a possibility of different readings. And business is not a philosophy. With all the speculation and variety of approaches to the description of business processes, it is very important unambiguous decisions.

Methodology and languages ​​of business modeling

Very often, even in professional literature, confusion arises when people confuse concepts of the methodology for analyzing business performance and describing business modeling languages.



Methodology is a system of principles and standards for describing business models and their subsequent analysis. While business modeling language is nothing more than a tool for developing business models.



This suggests a comparison with programming in general and using a specific programming language. Programming includes the construction of the algorithm, the choice of a suitable programming language, and the implementation of the program’s algorithm within a given language. And, for example, C ++ programming is already a limitation by certain limits, since a clearly limited circle of tasks can be solved using the means of a specific language, and, at the same time, even if the problem can be solved using C ++, it is not necessary that this language will be optimal in a particular case. In general, the difference between the concept of "programming" and "programming within a particular language," I think most understand, even without such explanations.

Difference of languages ​​for developing business models in systems design languages

There is a whole family of system design languages ​​that are externally similar to business modeling languages, for example, Ares Studios, a whole family of UML languages, and others that are used to design IT systems.



The main difference between these languages ​​from the development languages ​​of business processes lies in their purpose. If design languages ​​of IT-systems consider business processes from the point of view of their automation, implementation in IT-systems, then business modeling languages ​​consider the sequence of actions from the point of view of business, including the work of both IT-systems and employees, movement of goods etc.



Accordingly, there are no elements in the systems design languages ​​that will help to fully describe the actions of departments, employees, the interaction between them, work with suppliers, communication with customers, and so on. Tools of this group of languages ​​will help to automate business processes that are amenable to automation. And everything else will be left "behind the scenes", for example, as some kind of "functions" without decoding.



At the same time, the languages ​​of development of business processes cover as much as possible exactly the work of business as such, but these or other nuances of automation and algorithmization of systems in them are not always possible to describe with a sufficient degree of detail.

Benefits of developing business models

And yet, why use business modeling languages ​​that impose strict restrictions, require you to adhere to rigidly defined rules when modeling? After all, you can always “draw a diagram” in a graphic editor or even on paper using a mental approach, while learning modeling languages ​​will not be required at all.



In fact, standards and rules are a huge plus:

1. Modeling languages ​​help to convey information in the best possible way. Standardization increases the simplicity of perception.
2. The speed of model development increases significantly. Languages ​​contain all the necessary tools and graphic blocks in finished form. You do not have to “draw” or invent your own terminology. The toolkit is ready, and work within it is significantly accelerated. Of course, the language needs to be learned. But to study once is much faster than every time to invent and explain your own set of symbols.
3. The number of possible errors decreases. The elements of the system themselves will already “prompt” a list of possible and necessary actions. And in the case of creating executable models or non-executable, but within the strict framework of the rules, you can always check the work of the business model in the executable environment and debug as in programming.

Application of business models in practice

Personally, I think that business modeling should be used to solve any problems associated with identifying problems and bottlenecks, with optimization and modernization of business, etc. As a business consultant, I almost always build models of the company or its departments when working with my clients. This gives a clear understanding of all stages of work and allows you to avoid "white spots" in this matter.



In addition, visual schemes of business models help me in the process of interaction with customers. My projects are often complicated, and plain text or oral speech is not enough to understand, while using visual business models reduces the client's time spent reading and understanding my sentences, and virtually eliminates the problems of mutual understanding on this issue. And if several years ago I was still confused with clients, now the option of describing “in words” without visual and convenient schemes is rarely practiced.



And in the case of the automation of any stage of work or the creation of an automated business management system based on a project-oriented approach, a high-quality business model, made in a particular modeling language, will become a ready-made guide for technical specialists.



Convenience, versatility, simplicity of perception - these are the reasons for which from verbal descriptions in the business sphere are increasingly moving to business modeling. And the use of ready-made languages ​​allows you to work with models quickly, avoid mistakes, and also make any changes without any problems.



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 .