Your business - Information portal
Are you here: » »

Business modeling tools. Modeling business processes - an overview of notations. From simulation to automation

  • Obtaining a holistic picture of the life of the organization, coordinating different points of view on the constantly developing and changing business.
  • Ensuring mutual understanding at all levels of the organization, bridging the gap between the managing and performing parties.
  • Ensuring the reduction of production costs and the improvement of quality and service levels.

In the process of business modeling, there is a transition from the concept of “what” should be done to the concept of “how” should be done. The output of the simulation should be a document that gives the development team a clear understanding of the scope of the project, as well as the customer's software and hardware. The received data is reflected in the project specification, which may include the following sections:

  • description of the main data entities of the application;
  • a formal description of the application specification;
  • business logic and business rules;
  • functional requirements;
  • non-functional requirements;
  • application form/page templates;
  • glossary or list of abbreviations;
  • help charts.

Business modeling tools and their evolution

To create business models, information systems design tools and their corresponding description languages ​​are used (the most famous among them is UML - Unified Modeling Language). With the help of such languages, graphical models and diagrams are built that demonstrate the structure of the organization's business processes, the organization of interaction between people and the necessary changes to improve the performance of the organization as a whole. Business modeling tools are in constant development. Initially, with the help of such tools, it was possible to describe only the business functions (work) of the company and the movement of data in the process of their implementation. Moreover, if the same business function was used to perform different types of work, it was difficult to understand whether the same business function or a different one was meant. The inability to explicitly define the hierarchy of business processes (for example, "value chain", "business process", "sub-process", "work", "function") created problems when using such descriptions. The descriptions themselves were just a collection of pictures. Later, tools began to appear that made it possible to describe the organization not only from the side of business functions, but also from other sides. Thus, it became possible to create separate diagrams that reflect the organizational structure of the company, data flows in the organization, the sequence of business functions that make up a single business process, with the ability to use logic symbols, etc. Due to the ever-increasing requirements for business modeling tools, it has become more and more diagrams appeared to describe various aspects of the organization's activities, which made the creation of a model more and more complicated. In this regard, the next important stage in the development of business modeling tools is associated with the idea of ​​using a single repository (storage) of objects and the idea of ​​possible reuse of objects in different diagrams. Whatever tool is chosen, it is required to ensure the interaction of local information systems with each other. To date, the most modern and at the same time generally accepted standard for organizing business process management is BPEL (Business Process Execution Language). Based on this product, you can create a single integration platform for all your applications. After modeling processes in one of the modeling tools, special translators are used to bring the model to the BPEL standard.

Examples of business modeling and its results

  • Cost reduction. The business model will give an idea of ​​where you can avoid unnecessary costs and how to optimize the use of resources. Based on the business model, a functional cost analysis is carried out to calculate the cost of a product or service, and a budget management system is built that allows you to control the costs of the enterprise.
  • Improving efficiency. The ability to reduce the cost of adaptation and training of staff. Regulatory documentation based on the prepared business model corresponds to the current state of affairs of the organization, distributes responsibilities, builds a hierarchical system of career growth.
  • Expanding the sphere of influence, increasing the network, organizing branches. The presence of a business model will reduce costs and make it possible to describe the structure of the arrangement of new branches of the enterprise.
  • Adequacy of investment. With the help of business modeling, it is possible to determine the amount of capital investments with a sufficient degree of accuracy, reduce risks and financial losses at the start-up stage of a new project.
  • Implementation of EDMS. The business model of an enterprise standardizes the composition of enterprise documents and establishes routes for the movement of documents.
  • Automation and implementation of systems of class ERP, SCM, CRM or other software. Based on the business model, it is possible to formulate better requirements for the system and choose the solution that is optimal in terms of cost and functionality.
  • Certification of the quality management system. Development business models enterprise allows you to significantly reduce the time and costs for the development, implementation and certification of a quality management system and get a set required documents for successful certification, reduce the cost of maintaining a quality management system.

Features of business modeling

Creation, implementation and support of a business model is an expensive investment project. And like any project, the creation of a business model must be preceded by an analysis of the feasibility and feasibility of its implementation. Large projects require powerful business modeling tools with well-developed functionality: with the ability to store information in a single repository, collaborate on a modeling project and check the created model for integrity, semi-automatic diagram generation, integration with other software, analysis and model documentation - while in small projects, for cost reasons, it would be wiser to use less functional tools. To analyze the activity, develop the existing structure, it is necessary to initially build an adequate business model. That is, initially the theory, and only after - its implementation.

Solutions

Today there are a large number of software products that are designed to describe the architecture of an organization. According to the reports of the analytical company Gartner, the following companies can be attributed to the leaders of this segment.

Now, after a general clarification of the general functional tasks solved by the means under consideration, one should also compare the possibilities that these tools provide.

In further analysis, only the characteristics of the programs ARIS ToolSet (hereinafter, ARIS), BP-Win - Erwin (hereinafter, BP-Win) and ORG-Master (hereinafter, ORG-Master) will be considered. The Rational Rose program - as the most focused on building purely software, rather than organizational systems, in order to simplify the presentation, we will exclude from consideration, especially since the UML methodology underlying it is now implemented in ARIS).

Functionality of business systems modeling tools

When comparing various business system modeling tools, it is advisable to consider their features according to the following groups of functionality:

  • tools for building models of business systems;
  • model analysis tools;
  • means of optimizing the simulated systems according to their models;
  • support for libraries of standard models;
  • registration of regulations and documentation;
  • support for the development of database models and software tools;
  • integration with other software products (CASE tools, ERP systems, application programs).
  • the general organization of business processes and the procedure for interaction between organizational units (performers),
  • distribution of responsibility for the implementation of individual functions and the expenditure of system resources,
  • loading organizational units, performers and instrumental resources in the system,
  • the main time and cost parameters of the simulated system,
  • requirements for resource support of processes occurring in the system.

Analysis general organization of business processes and the order of interaction of organizational units in the system is carried out directly when studying the built models of business processes. Qualitative analysis also reveals roles, which, under certain conditions, can be excluded from the process. Wherein visibility of the model and the ability to trace the relationships existing in the system takes on paramount importance.

Notes related to the visibility of models are given below. But it should also be noted here that an important requirement for the model is the possibility of its analysis before its complete construction. Indeed, if it is possible to identify interrelations (as well as their absence) in the system only after building its complete model, then this turns out to be very inconvenient at the initial stages of work, when information about the features of the processes occurring in the system may still be partially absent or be inaccurate.

Here, ORG-Master is in a winning position, since the business process model in it is not built directly in the form of an IDEF diagram. This diagram can be automatically generated after creating and filling in the classifiers forming the model (business functions, organizational links, resources, etc.) and setting all the necessary projections (relationships by resources, performers, tools, regulations, and the actual relationships between business operations). Thus, even before a complete (or partial) business process model is obtained, the main relationships that determine the modeled process are already identified and can be analyzed.

In contrast to this approach, business process models in ARIS and BP-Win are built directly, and the existing relationships of process components must be prepared for analysis, as a result of appropriate procedures.

So, for example, after building a business process model in BP-Win, using ERwin, a separate data model is built, in which links are established between the system components (data model entities according to the methodology). Then these models are connected by means of a mechanism essentially similar to the projection construction mechanism used in ORG-Master (see Appendix 1. Model components of the ORG-Master software and methodological complex).

With this in mind, the second of the considered possibilities for analyzing the model: analysis distribution of responsibility for the implementation of individual functions and the expenditure of system resources, is automatically implemented in the process of building a business process model in the ORG-Master system. Indeed, projections of the type Organizational links - Functions and Functions - Resources, specified when building business process models in ORG-Master, directly show those responsible for a particular area of ​​work or resource (and allow you to analyze any combination of them). In addition, ORG-Master allows you to export matrix projections to MS Excel, where organizational analysis charts are formed on their basis.

In ARIS and BP-Win, for this purpose, it is necessary either to manually trace all the links in business process diagrams (and data models in BP-Win), or to specifically build the appropriate lists or reports.

Question about loading artists and instrumental resources in the system, as well as obtaining estimates for the main time parameters of the simulated system, can be decided on the basis of quantitative data on the complexity (or simply the duration) of the functions they implement. To solve this problem, it is necessary to enter such data into the system in one way or another, as well as provide means for obtaining summary estimates. Support for the IDEF3 methodology (in BP-Win), the ABC methods in ARIS and BP-Win, and the simulation tools in ARIS (and partially in BP-Win) provide for some processing of these estimates. As for the original data itself, they are set by the user, who, therefore, is responsible for the final result.

However, obtaining sufficiently representative estimates using statistical (simulation/event) modeling (and, even more so, using ABC methods when considering time as a resource) for loading system components is difficult due to the following factors.

Modern approaches to the analysis of any process ( workflow) proceed from dividing the time of its implementation by, in fact, the period of execution of operations and the time of transmission of their results. At the same time, in office processes or service delivery processes, actual work takes on average about 10% of the time, and the rest of the time is spent either on physical movement the result of the task (requiring the signing of the text of the contract that needs to be washed again) and waiting in line until the next performer has time to continue the process. Therefore, methods based on a simple summation of the time of operations at the present time, as a rule, do not give an accurate idea of ​​the time parameters of the process.

More adequate results can be obtained by simulating the behavior of the system. However, for service delay times, one has to either take very approximate assumptions about the law of their distribution in time, or carry out rather expensive and time-consuming timing procedures and subsequent statistical processing. At the same time, the reliability of the results obtained will not be too high, or it will require significant additional costs. Therefore, it seems reasonable approach that: “the cost of modeling to obtain any information should not exceed the value (cost) of the results of its use. In addition, one should always keep in mind the Pareto law, from which, in relation to the problem under consideration, it follows that 20% of modeling efforts provide 80% of the effect.

Therefore, from our point of view, before moving to complex and time-consuming and resource-consuming modeling methods associated with quantitative estimates of time and cost parameters, it is worth focusing on obtaining the effect from the implementation of more obvious business modeling results. Quantitative optimization should be carried out taking into account measurements and analysis of actual processes.

ORG-Master has a functional analogue of the ABC-analysis tools - the Budgeting Wizard, which generates a simple budgeting system. One of the results of this system is a quantitative assessment of the costs of implementing business processes ( operating budgets), which is at least comparable in value to the data obtained using ABC-costing support tools.

In addition, the ORG-Master family also includes the Time-Master software package, one of whose components, which provides process control (workflow), allows you to accumulate statistics in the course of their execution, which provides estimates for the time parameters of processes necessary for analysis.

  • Business systems optimization tools (business processes), in addition to the possibilities of analyzing models, provide: a management tool.
  • generation of a number of alternatives;
  • planning;
  • choosing the best course of action;
  • allocation of resources;
  • setting priorities.

As a rule, the implementation of the listed functions is associated with the use of special rather complex or cumbersome algorithms for solving optimization problems. A number of possibilities of this kind are incorporated in the ARIS system. However, their implementation, in general, does not seem appropriate until the stage of fine-tuning the business process after achieving the results of its restructuring by simpler methods.

Support for libraries of generic models allows you to use previously created developments in the process of building new models. This possibility is provided in all three considered tools. In particular, ORG-Master supports both complete reference business models of enterprises obtained as a result of real projects carried out on Russian enterprises, and "library" classifiers that describe the typical organization of individual aspects of activity.

Decor, in accordance with the built models, company regulations seems to be a very important feature that ensures the integrity and consistency of the documentary description of the business system. The importance of this component for business modeling tools can be understood by looking at regulations as a tool for managing a company. Indeed, if a company works stably, it means that its business processes are well-established and amenable to almost formal regulation. The internal culture, which must be present in such a company, will allow, if necessary, to quickly rebuild the system or business process parameters by changing the work regulations of the relevant departments and performers.

The presence of documents-regulations for all aspects of the company's activities is one of the basic provisions of the concept of regular, systemic management. According to her, in a well-organized business, about 80% of managerial decisions are made according to predetermined procedures, and only the rest, related to non-standard situations and various innovations, rely on the creativity and heroism of employees.

The organization of the activities of an enterprise (company), aimed at achieving certain goals, is regulated at the present level by the following standard set of basic organizational documents:

  • position on the organizational and functional structure, reflecting the composition of businesses and functions supported in the company, and their distribution within the company;
  • provisions on company policies (accounting, investment, etc.);
  • regulations on the organization of the main business and management subsystems of the company, containing a detailed description of the functions in the areas of activity;
  • documented procedures - descriptions of business processes in a form that allows both to present the process to an outside observer, and to be guided by this document to the executors of the process operations;
  • and finally the traditional "subdivision regulations", and " job descriptions» personnel with lists of functional duties, types of responsibility, rights and powers of employees.

In addition, it should be possible to create special reporting forms for creating documents in various functional areas: Terms of Reference for an enterprise management information system, Quality Manual (see, for example, Appendix 3) and other special documents according to the ISO9000 standard, etc.

All information that allows generating these documents must be contained in the form of an integral and consistent system in the complete business model of the enterprise (company). Moreover, many of the documents created should correspond as much as possible to generally accepted Russian standards (Obviously, the ARIS and BP-Win systems meet the last requirement to the least extent).

In the ORG-Master environment, such provisions and instructions are generated automatically as text forms for describing procedures, represented by the corresponding classifiers and relations-projections of connections between them. Graphic forms (various digraphs and process diagrams) serve as a good complement to these documents.

In the ARIS environment, job descriptions and process descriptions are based on process event diagrams and, in principle, various text documents can be built by analyzing process models and organization structures. Although, to a greater extent, the picture is reversed here - the system is focused mainly on the creation of graphics, and the function of creating regulatory documents is clearly auxiliary and, as a result, not developed.

In BP-Win, the direct possibility of obtaining various regulations is not stipulated.

In a relationship project documentation two sides can be considered: a description of business processes and a description of an information system for supporting business processes for its subsequent development. The first of them is almost equally provided in each of the considered environments by the possibility of building various reporting forms based on the built business process models.

In terms of documentation for the development of an information system, the most traditional features are provided by the BP-Win / ERwin environment, which, in fact, was created for this.

The capabilities of ARIS are approximately the same: in the first versions of the data model, they were described according to the entity-relationship scheme, in later versions, in the UML language. However, the ARISToolset tool provides more advanced information systems development functions.

The capabilities of ORG-Master allow you to fully represent the data structures necessary for organizing information support for the modeled business processes using your own universal tools - classifiers and projections. There are no formalisms such as ER diagrams, although in recent versions it is possible to visualize in the DFD standard. In addition, it became possible to reflect the interaction between functional blocks on IDEF0 diagrams not only using the direct transfer of documents and files, but also through shared databases!

Support for the development of database models and software tools usually refers to the capabilities of CASE-type tools or related tools for setting up enterprise management information systems (for example, ERP-class systems). Such support may provide the following functionality:

  • analysis and design of the architecture of information management systems,
  • database and file design,
  • programming (program code generation),
  • maintenance and reengineering,
  • project management.

Questions analysis and design of information systems architecture, usually culminate in the definition of system requirements and related specifications. This stage, with a systematic approach to design, should directly rely on models of business systems and, in fact, detail them. Therefore, all the above arguments are valid here, covering the construction, analysis and optimization of system models, as well as the design of regulations and documentation.

Database and file design(conceptual and internal levels), transformation of data models, description of file formats in the considered tools is most fully supported only in BP-Win (ERwin), since this environment is specially designed for solving such problems.

In the ARIS environment, this possibility is provided in the ARIS Toolset package at the level of the project specification and the definition of database parameters.

The approach developed in the ORG-Master environment assumes (although not necessarily) that information systems that already have databases can be used in the modeled business systems. In this case, they do not need to be redesigned unless the system in use is to be replaced. However, in the absence of information systems, ORG-Master creates the basis for the conceptual data model and data file structures. This basis is represented by descriptions of the composition and relationship of information objects and documents used in business process models.

Generation of program codes for application or system tools ARIS and ORG-Master systems are not provided, since they are business system design tools, not software. To a certain extent, this feature is implemented only in BP-Win.

Maintenance and reengineering. These functions are usually implemented by means of documenting, analyzing programs, restructuring and reengineering them. The remarks made above regarding the means of documentation are fully applicable in this consideration.

Functions project management creation of databases and software tools are specific to the development of software products. In this form they are implemented in BP-Win. Project management in the ORG-Master family fully supports the Time-Master software package. (Although, strictly speaking, these functions are not mandatory for the class of tools in question).

Integration with other software products involves expanding the scope of the tool in question and can be carried out both as part of the development of a family of compatible software tools (like Platinum Technologies) or with software tools other developers (third party software).

Integration with “third party” software products is performed for one of the following purposes:

  • using the functionality of the integrated product to expand the scope of its product,
  • providing the opportunity to include your product in a third party product,
  • providing a more or less universal interface for your product if the specific third party is not known in advance.

From the point of view of functional orientation, integration with:

  • CASE means,
  • ERP systems,
  • application programs.

ARIS has interfaces with some CASE tools and is also a model building tool for direct customization of such enterprise management systems, primarily SAP R/3. As noted above, the system relies on its own notation to represent business processes, so it uses built-in simulation tools and a tool cost analysis, the results of which, however, can be exported to MS Excel formats.

The ORG-Master and BP-Win systems support the IDEF0 notation to describe the represented business processes. In principle, this is a kind of link both between these tools and for communication with other software products using this methodology. However, without considering here the issues of the “age” of the IDEF0 notation, it should be noted that the internal representation of data in each system is different, and the standard interface of the type of “sockets” or classes for the IDEF0 system is not specified. However, there is a standardized file format for representing IDEF diagrams. Therefore, although the descriptions made with its help are not very convenient for both humans and computers, it is possible to use them as a means of exchanging models if there are appropriate converters of this format. Such a converter is provided in the following versions of ORG-Master.

BP-Win supports methodologies IDEF0, DFD and IDEF3 and integrates with the following software products (mostly from the same manufacturer):

  • ERwin data modeling tool (Platinum Technology),
  • ModelMart project management and storage system (Platinum Technology),
  • a specialized report generator based on the RPTwin model (Platinum Technology),
  • simulation system BPSimulator (System Modeling Corporation),
  • EasyABC cost analysis tool (ABC Technologies).

(*Platinum Technology - part of Computer Associates since 1999)

ORG-Master is initially positioned as an organizational class system focused on solving the problems of modeling and designing business processes and structures and supporting organizational decision making. It provides the ability to integrate with its own developer packages ("BIG-SPB Software"), focused on solving various functional tasks. In the ORG-Master system, if necessary, simple executive information systems are automatically created in the MS Office environment:

  • Budgeting system (which is a simple system of management accounting, profitability and solvency management of the enterprise).
  • Marketing system (accumulating operational quantitative information about the enterprise market, as well as integrating with its own CRM system for supporting customer relations).

The introduction of these applications into the activities of the enterprise allows you to quickly master modern control techniques, which greatly facilitates the transition to more complex executive systems.

It is possible (and was tested in projects) to interface data via exchange files within the framework of building integrated information systems with executive and analytical programs of partner firms: 1C, AiT:Soft, Intalev, Comteh +, INEK, etc., as well as with integrated control systems enterprise resources (for example, IPS production).

The new version also provides mechanisms for exporting business process descriptions to the Time-Master software package, which combines the properties of Project Management, WorkFlow and Personal Information System systems and is built on Internet / Intranet technologies.

Section Summary:

The main functional capabilities of the compared tools are presented in Table 2, where the assessments of the degree of implementation of functions or properties are indicated on a five-point scale.

As can be seen from Table 2, direct summation of the estimates gives a spread of about ±4%. Such a scatter lies within the error of the estimates themselves. Moreover, the means themselves, which differ in their functional orientation, received close estimates due to the fact that the different strengths and weaknesses of different means compensate each other in direct calculation.

However, during the discussion of functionality, it was emphasized that, directly for solving business engineering problems, individual groups of functionality have different meanings. This fact is reflected by the coefficients recorded in the “Weight” column of Table 2. Taking this factor into account, it can be seen that the overall assessment of the ORG-Master complex is slightly superior to ARIS.

But again, this may be the result of different preferences and priorities in the intended use of the product. For example, due to a lower assessment of the significance of existing tools for quantitative analysis of models (simulation and event modeling), as well as optimization tools, which, however, are poorly represented in all the systems under consideration. At the same time, the properties of self-documenting models or the universality of the representation of various aspects of modeling are highly appreciated.

In general, when evaluating and choosing a modeling tool, it is recommended to independently decide which of the system tools are most important in solving a specific problem of its application and, accordingly, put down “weights”.

Additionally, reference Appendix 2 provides an overview of formalization standards and tools for constructing and/or analyzing certain models that are used in the systems under consideration.

Business Process Modeling is an effective tool for finding ways to optimize the company's activities, allowing you to determine how the company works as a whole and how activities are organized at each workplace. The methodology (notation) for creating a model (description) of a business process is understood as a set of ways in which real world objects and relationships between them are represented in the form of a model. Each object and links is characterized by a number of parameters or attributes that reflect certain characteristics of a real object (object number, name, description, execution time (for functions), cost, etc.).

The description of business processes is carried out for the purpose of their further analysis and reorganization. The purpose of the reorganization may be to introduce an information system, reduce costs, improve the quality of customer service, create job and work instructions, etc., and a detailed description of the processes in itself is of no value.

Reengineering business processes (eng. Business process reengineering) is a fundamental rethinking and radical redesign of business processes to achieve maximum efficiency of production, economic and financial and economic activities, formalized by the appropriate organizational and administrative and normative documents. Business engineering consists of modeling business processes (development of the "as is" model, its analysis, development of the "how to" model) and the development and implementation of a transition plan to the "as needed" state.

The basis of many modern methodologies for modeling business processes was the SADT methodology (Structured Analysis and Design Technique - a method of structural analysis and design), the IDEF family of standards (Icam DEFinition, where Icam is Integrated Computer-Aided Manufacturing) and algorithmic languages.

The main types of methodologies for modeling and analyzing business processes:

Business Process Modeling ( business process modeling). The most widely used methodology for describing business processes is the IDEF0 standard. Models in IDEF0 notation are intended for a high-level description of a company's business in a functional aspect.

Description of workflows ( Work Flow Modeling). The IDEF3 standard is intended to describe workflows and is close to algorithmic methods for constructing flowcharts.

Description of data streams ( Data Flow Modeling). DFD notation ( Data Flow Diagramming), allows you to reflect the sequence of work performed during the process, and the flows of information circulating between these works.

other methodologies.


In relation to obtaining the added value of a product or service, the following classes of processes can be distinguished:

Core business processes (e.g. marketing, manufacturing, supply, and service maintenance products).

Supporting business processes do not add value to the product, but increase its value (for example, financial support for operations, staffing, legal support, administration, security, supply of components, repairs and Maintenance etc.).

Business processes management.

Business model is a formalized (graphical, tabular, textual, symbolic) description of business processes. The main area of ​​application of business models is business process reengineering.

The goals of business process modeling are usually formulated as follows:

Provide an understanding of the structure of the organization and the dynamics of the processes taking place in it;

To provide an understanding of the current problems of the organization and the possibilities of their solution;

Make sure that customers, users and developers share the same understanding of the goals and objectives of the organization;

Create a base for the formation of requirements for software that automates the organization's business processes (software requirements are formed on the basis of a business model).

An important element of the business process model are business rules or domain rules. Typical business rules are corporate policy and state laws. Business rules are usually formulated in a special document and can be reflected in models.

Decomposition in a general sense, this is a method that allows you to replace the solution of one large problem with the solution of a series of smaller problems, splitting an object into its component parts according to an established criterion. In practice, decomposition is used to refine business models.

Stages of business process description:

Determining the purpose of the description.

Description of the environment, definition of inputs and outputs of the business process, construction of IDEF0 diagrams.

Description of the functional structure (process actions), construction of IDEF3 diagrams.

Description of flows (material, informational, financial) of the process, construction of DFD-diagrams.

Building organizational structure process (departments, participants, responsible).

IDEF0

The model consists of diagrams, text fragments and a glossary with links to each other. Diagrams are the main components of the model, all functions and interfaces are presented as blocks and arcs.

The connection point of the arc with the block determines the interface type:

Control information enters the block from the top.

The input information is included in the block on the left.

The results exit the block on the right.

The mechanism (human or automated system) that performs the operation enters the unit from below.

Each component of the model can be decomposed (deciphered in more detail) in another diagram. It is recommended to stop modeling when the level of detail of the model satisfies its purpose. The total number of levels in the model should not exceed 5-6.

Diagramming begins with the representation of the entire system in the form of a single block and arcs depicting interfaces with functions outside the system. Then the block that represents the system as a single module is detailed in another diagram using several blocks connected by interface arcs. Each detailed diagram is a block decomposition from the diagram of the previous level. At each decomposition step, the diagram of the previous level is called the parent diagram for the more detailed diagram.

Such diagrams do not explicitly indicate either sequence or time. The method has a number of disadvantages: the complexity of perception (a large number of arcs in the diagrams and a large number of decomposition levels), the difficulty of linking several processes.

IDEF3

This method is designed to simulate sequence of actions and interdependencies between them within processes. IDEF3 models can be used to drill down IDEF0 functional blocks that do not have decomposition diagrams.

IDEF3 diagrams display action in the form of a rectangle. Actions are named using verbs or verbal nouns, and each action is assigned a unique identification number (the action number is usually preceded by the number of its parent, eg 1.1.).

All links in IDEF3 are unidirectional and are organized from left to right.

Types of IDEF3 links:

Temporal precedence, simple arrow. The source activity must complete before the end activity can begin.

Object flow, double-tipped arrow. The output of the original action is the input of the final action. The source activity must complete before the end activity can begin. The names of streaming links must clearly identify the object that is transmitted with their help.

Fuzzy Relationship, dotted arrow.

The completion of one action may initiate the start of the execution of several other actions at once, or vice versa, a certain action may require the completion of several other actions before starting its execution (process branching).

Process branching is reflected using special blocks:

- "And", block with sign &.

- "XOR" ("one of"), block with X sign.

- "OR", a block with the sign O.

If the actions "AND", "OR" must be performed synchronously, this is indicated by two double vertical lines inside the block, asynchronously - one.
The IDEF3 method allows you to decompose an activity multiple times, which ensures that alternative process flows are documented in a single model.

DFD

The purpose of this presentation is to show how each process transforms their input data on the weekend. It can reflect not only information, but also material flows. Also, as in other models, decomposition is supported.

The main components of data flow diagrams are:

External entities (material object or individual, which are the source or receiver of information, for example, customers, personnel, suppliers, customers, warehouse);

Systems and subsystems (for example, a subsystem for working with individuals);

Processes (transformation of input data streams into output ones in accordance with a certain algorithm; physically, this can be, for example, a subdivision of an organization (department) that processes input documents and issues reports, a program, a hardware-implemented logical device, etc.);

Data storage devices (abstract devices for storing information);

Data flows (arrows on the diagram).

It is necessary to place on each diagram from 3 (less does not make sense) to 7 (more - not perceived) processes, without cluttering the diagrams with details that are insignificant at this level.

The first step in building a DFD hierarchy is to build context diagrams. Typically, when designing relatively simple systems, a single context diagram with a star topology is built, in the center of which is the so-called main process, connected to receivers and sources of information. For complex systems (ten or more external entities, distributed nature and multifunctionality of the system), a hierarchy of context diagrams is built. At the same time, the top-level context diagram contains not a single main process, but a set of subsystems connected by data flows.

Each process on a DFD can be detailed using a DFD or (if the process is elementary) a specification. Specifications are descriptions of algorithms for tasks performed by processes. Specification languages ​​can range from structured natural language or pseudocode to visual modeling languages.

In business process modeling, data flow diagrams (DFDs) are used to build "AS-IS" and "AS-TO-BE" models, thus reflecting an organization's existing and proposed business process structure.

ARIS

Currently, there is a tendency to integrate a variety of modeling methods, manifested in the form of the creation of integrated modeling tools. One of these tools is a software product called ARIS (Architecture of Integrated Information Systems), developed by the German company IDS Scheer.

ARIS supports four types of models (and many types of models in each type), reflecting different aspects of the system under study:

Organizational models that represent the structure of the system - the hierarchy of organizational units, positions and specific individuals, the links between them, as well as the territorial binding of structural units;

Functional models containing a hierarchy of goals facing the management apparatus, with a set of function trees necessary to achieve the goals;

Information models reflecting the structure of the information necessary for the implementation of the entire set of system functions;

Management models representing a comprehensive view of the implementation of business processes within the system.

To build the listed types of models, both ARIS's own modeling methods and various well-known modeling methods and languages, in particular, UML, are used. The modeling process can be started with any of the model types.

The main business model of ARIS is eEPC (extended Event-driven Process Chain, extended event-driven process chain model). The ARIS eEPC notation is an extension of the IDEF3 notation. A business process in eEPC notation is a flow of sequentially performed work (procedures, functions) arranged in the order in which they are performed. The actual duration of the procedures in eEPC is not visually reflected.

To obtain information about the actual duration of processes, it is necessary to use other description tools, for example, MS Project.

Models in ARIS are diagrams whose elements are various objects- "functions", "events", "structural divisions", "documents", etc. Between objects of certain types can be set connections certain types ("performs", "makes a decision", "should be promptly informed about the results", etc.). Each object corresponds to a specific set of attributes that allow you to enter Additional information about a specific object.

The main objects of the eEPC notation are:

Function. Serves to describe the functions (procedures, work) performed by departments / employees of the enterprise. Every function must be initiated by an event and must end with an event; Each function cannot enter more than one arrow, "starting" the execution of the function, and exit more than one arrow, describing the completion of the function.

Event. Used to describe real events that affect the execution of functions.

Organizational unit. For example, management or department.

Document. Reflects real media, such as paper documents.

Application system.

information cluster. Characterizes a set of entities and relationships between them.

Communication between objects. The type of relationship between objects, for example, the activation of the execution of a function by some event.

Boolean operator. The "AND", "OR" or exclusive "OR" operator allows you to describe the branching of the process.

If, when creating a model in eEPC, you specify only the sequence of procedures, not caring about the reflection of control documents and information, the resulting models will be of low value in terms of analysis and further use.

An object DBMS is used to store models in ARIS, and a new database is created for each project. Various database administration functions are provided, such as access control. The database is a hierarchical storage of models.

The work on creating a model should be regulated by strict and voluminous modeling conventions (standards), ARIS supports a mechanism of methodological filters that allow the user to use only a certain set of schemes and objects. The development of such agreements requires considerable time and highly qualified specialists. If a project using ARIS is started without detailed elaboration of such agreements, then the probability of creating business process models that do not answer the questions posed is very high.

Business process modeling has become a classic work of many business analysts as part of the optimization of business processes and the standardization of the activities of Russian companies. There are many notations that are used in certain cases. This article is devoted to an overview of business process modeling notations.

VAD (value added chain diagram)

The VAD notation proposed by Michael Porter in his work on corporate strategy focuses on modeling business processes that "create value" in the form of services or products for the customer. A business process model built in VAD notation provides a general, non-detailed view of business processes.

Using the VAD notation, you can describe the list and the relationship of business processes at the top level, since this notation allows you to display all the company's business processes on one model. In the VAD notation, you can use relationships that show the relationship of business processes relative to each other, while the flow of the process in this notation in the vast majority of cases is directed from left to right.

There are a lot of VAD notation options implemented in various tools, each with its own character set, but they all look about the same - a set of business processes often interconnected by “predecessor-follower” links.

For example, the extension of this notation in the ARIS toolkit allows you to show performers, risks, documents, data, and much more on the business process model.

In addition to modeling an organization's business process map, VAD notation allows you to model end-to-end business processes during their initial definition. But you need to understand that VAD is not designed to simulate logical conditions in the process, and therefore it is well accepted by management. In practice, after modeling business processes at the top level in the VAD notation, more detailed modeling of business processes in other notations follows, which we will discuss in more detail below.

The VAD notation model can be drawn in many tools such as MS Visio and many other business process modeling tools.

Business process modeling - EPC (event-driven process chain)

The EPC notation was developed by Professor August Wilhelm Scheer within the framework of the ARIS toolkit methodology. With the help, a business process is modeled as a list of process steps triggered by events. The notation is convenient for the subsequent regulation of the business process, as well as for analyzing the information flow of the business process (incoming/outgoing documents).

freedom EPC notation allows you to describe additional objects within the framework of business process modeling, such as operational risks, control procedures, screen forms, information systems, indicators, and much more.

Within the framework of the EPC notation, the process is modeled “top-down”, and the order in which the steps/functions/actions/operations of the business process are performed is determined through a system of events and logical conditions. As events in the EPC notation, the beginning and completion of process steps are considered, as well as external events that require a response from the organization.

The business process model consists of sequences "event-function-event" and logical operators "AND", "OR", "exclusive OR" that display solutions, condition checking, parallelization and convergence of the flows of the modeled business process.

There are many options for EPC notation, in the format of columns, rows, as well as with different lists of objects used, however, all these options are available only in the ARIS toolkit, while in other tools, for example, MS Visio or Business Studio, only EPC business process modeling is available. in classic format.

Modeling a business process in EPC notation allows you to subsequently obtain a text or tabular business process regulation, since a correctly drawn EPC model can be converted into a sequence of ordinary language sentences, which becomes the basis for the regulation. That is why this notation is considered the most convenient for modeling business processes for the purpose of subsequent analysis and regulation.

Modeling business— processes– BPMN (Business Process Model and Notation 2.0)

The BPMN notation was created by the Object Management Group (OMG) and is intended for modeling business processes with a view to their subsequent automation. The BPMN notation is used for detailed modeling of a business process, and the number of objects in this notation exceeds 100, which allows you to describe all the nuances of the behavior of business processes so that the information system can convert the created model into executable code.

The openness of the BPMN notation and support by most business process modeling and automation tools have made this notation a leader in business process modeling.

In BPMN notation, in addition to business process steps, you can model start, intermediate and final process events, information flows and message flows. Among the features of the notation, one can single out the default use of the Swim Lane modeling style (swimming lanes), when the performer is shown as a vertical or horizontal strip resembling lanes in a swimming pool, and it is on this track that the actions / operations performed by this performer are located.

Streamlining a business process in the Swim Lane format makes the transfer of responsibility and workflow between process participants visual, but at the same time, it makes modeling difficult in the case of several co-executors in one operation.

Models drawn in BPMN notation are often difficult to assemble into a coherent hierarchy, since the methodology was originally created to automate "end-to-end" business processes.

BPMN notation requires a certain amount of experience, which often limits the number of creators of these models to systems and business analysts. Representatives of business units rarely model business processes in BPMN notation.

Despite the graphical differences, the BPMN and EPC notations are very similar to each other, and in the ARIS toolkit they can already be converted to each other, albeit with certain methodological limitations.

Business Process Modeling - Flow Charting

The name of the notation is Flow Charting, it is easiest to translate as flowcharts. This notation originally appeared in the ANSI standard in 1970, and contains a very simple set of characters.

Over the years of the existence of the Flow Charting notation, many variants of flowcharts have been drawn containing symbols for solving various problems, for example, for describing material flows, roles and works, equipment, for analyzing the inputs and outputs of functions.

In fact, flowcharts were the forerunners of modern business process modeling notations, and have been taught in most educational institutions as part of information technology disciplines up to the present.

The Flow Charting notation does not have a rigid standard, which allows you to model business processes from different points of view, adding certain objects to the model as needed. In this way, this notation is very similar to EPC, but has even more freedom in terms of application. The freedom to use Flow Charting and support for most inexpensive and even free business process modeling tools has made this notation applicable in many companies.

Among the shortcomings of Flow Charting, one can single out the absence of a typical list of objects and attributes, which is the reverse side of the "freedom" of this notation. This allows you to model the same business process in this notation in such a way that the models will be seriously different from each other.

Despite the fact that business process models in the Flow Charting notation can be found quite often, most likely it will become a thing of the past, giving way to more “strict notations”

Modeling business— processes– IDEF (Integrated Definition Language)

IDEF notation appeared in the 70s as a US government standard focusing on the inputs, outputs, mechanisms and controls of a business process and linking the processes of an organization into a hierarchy. The key element of this notation is the function, while all other objects and interactions are modeled using relationships.

The notation uses a very simple set of symbols: process rectangles and arrows depicting inputs, outputs, controls and mechanisms, this notation is distinguished by a “built-in” numbering system for business process steps, which allows you to trace the relationships between parent and child processes.

Given the history of this standard and its fairly widespread use, it is implemented in many modeling tools, but still this notation can be attributed to the outgoing generation, since it has fewer and fewer supporters, and business representatives often treat these "microcircuits" with skepticism.

UML (unified Modeling Languages)

The Unified Modeling Language (UML) is a set of notations and modeling techniques designed to describe requirements for information systems, however, among the UML notations there is also a specialized notation designed specifically for modeling business processes. UML is supported by the Object Management Group (OMG), which has made this methodology quite common among IT professionals.

This notation is very similar to EPC and BPMN, the only difference is in the display of logical statements and events, and although there are many books on UML notation and it is supported by many modeling tools, UML Activiti Diagram is used mainly for systems analysis and design, and only a minor number of companies use UML to model business processes

VSM (value Stream Mapping)

The name of the VSM notation can be translated into Russian as mapping the customer value stream. The original name of this notation in the Toyota Corporation, where it is believed to have come up with it, is the Material and Information Flow Map.

The VSM notation was developed as part of the lean manufacturing methodology, and uses a set of specific symbols to display resource and time cost elements for business process performance analysis in Lean 6Sigma projects. A value stream map depicts the physical environment and the flow of materials and products in a manufacturing process and is used to tie resource and time inputs to a process and thus provide insight into productivity.

The purpose of this notation is to involve its participants in the analysis of the business process in order to encourage them to independently search for optimization opportunities. As a rule, VSM models are drawn in projects on Flip Chart and do not require serious business process modeling tools, because decisions are made on its basis, and the model itself does not become the basis for either the regulation or the IT solution.

The main thing when creating a model in VSM notation is filling in temporary attributes by process, to search for "bottlenecks" and places of excessive storage of stocks.

This notation has a limited circle of followers, and among the broad masses of business analysts it will not be widespread in the near future due to the specificity of the tasks solved with its help. But at the same time, many business process modeling tools, such as ARIS, have already developed extensions to support business process modeling in this notation.

SIPOC

The abbreviation SIPOC means: Supplier (supplier), Input (input), Process (process), Output (output), Customer (consumer). This is a process documentation template adopted in the Six Sigma methodology, in fact, it is not even a model notation, but a table format that allows you to describe a business process at the top level. The SIPOC model is most effectively applied when defining business process boundaries, interacting parties, and process inputs/outputs.

There is no notation for SIPOC, because it is a simple table with appropriate headers that allows you to structure the selected business process for further analysis and optimization.

The usefulness of SIPOC, unlike other diagrams, lies in the possibility of using it by employees of business units, since it does not contain complex logic and many objects, like EPC or BPMN notations.

Business Process Modeling - Conclusions

So, I looked at some business process modeling notations that can be found on Russian market(They are described in more detail in the BPM CBOK chapter on business process modeling). Which of the notations to choose for use is an open question, for example, for modeling the business processes of an organization at the top level, I use the VAD notation, for the primary modeling of a business process selected for optimization, it is easier to use SIPOC or VAD. To create detailed models of business processes - a simplified BPMN for modeling cross-functional interaction or EPC for detailed modeling in order to formalize the information flow and the set of objects associated with a business process. Well, if you need to automate a business process in a BPMS system, then you can’t do without BPMN notation.

Business Process Modeling is one of the methods to improve the quality and efficiency of the organization. This method is based on the description of the process through various elements (actions, data, events, materials, etc.) inherent in the process. As a rule, business process modeling describes the logical relationship of all elements of the process from its inception to completion within the organization. In more complex situations, modeling may involve processes or systems external to the organization.

Business process modeling allows you to understand the work and analyze the organization. This is achieved due to the fact that models can be compiled for various aspects and levels of management. In large organizations, business process modeling is more detailed and multifaceted than in small ones, which is associated with a large number of cross-functional relationships.

Typically, various computer tools and software are used to model business processes. This makes it easier to manage models, track changes in them, and reduce analysis time.

Goals of business process modeling

The ultimate goal of business process modeling is to improve performance. To do this, the analysis focuses on adding value to the results of the process and reducing the cost and time to complete the activities.

Business process modeling has several goals:

  • First, this is the purpose of describing processes. Through simulation, it is possible to trace what happens in processes from start to finish. Modeling allows you to get an "outside" view of the processes and identify improvements that will increase their efficiency.
  • secondly, the rationing of processes. Business process modeling sets the rules for the execution of processes, i.e. how they should be done. If the rules, guidelines or requirements established in the models are followed, then the desired performance of the processes can be achieved.
  • thirdly, the establishment of interrelations in processes. Business process modeling establishes a clear relationship between processes and the requirements they must fulfill.

Stages of business process modeling

Modeling business processes, as a rule, includes the implementation of several successive stages. Because the ultimate goal of modeling is to improve processes, it covers both the “design” part of the work and the work on the implementation of process models.

The composition of the stages, which includes the modeling of business processes, is as follows:

  • identifying processes and building the initial model "as is". In order to improve the process, it is necessary to understand how it works at the moment. At this stage, the boundaries of the process are defined, its key elements are identified, and data on the operation of the process is collected. As a result, the initial process model "as is" is created. This model does not always adequately reflect the operation of the process, so the model of this stage can be called the “first draft” or the initial “as is” model.
  • revision, analysis and refinement of the original model. At this stage, contradictions and duplication of actions in the process are identified, the limitations of the process, the relationship of the process are determined, and the need to change the process is established. As a result, the final version of the model "as is" is formed.
  • development of the “how it should be” model. After analyzing the existing situation, it is necessary to determine the desired state of the process. This desired state is represented in the “as it should be” model. Such a model shows how the process should look like in the future, including any necessary improvements. During this stage of business process modeling, such models are developed.
  • testing and applying the “as it should be” model. This stage of modeling is associated with the introduction of the developed model into the practice of the organization. The business process model is tested and the necessary changes are made to it.
  • improving the "as it should be" model. Business process modeling is not limited to creating a “how it should be” model. Each of the processes continues to change and improve along the way, so process models should be regularly reviewed and improved. This stage of modeling is associated with continuous improvement of processes and improvement of the business process model.

Types of business process modeling

Modeling business processes can have a different focus. It depends on what problems it is supposed to solve with its help. Accounting for absolutely all influences on the process can significantly complicate the model and lead to redundancy in the description of the process. To avoid this, business process modeling is divided by type. The type of simulation is selected depending on the characteristics of the process under study.

For the purposes of process improvement, the following types of modeling are used:

  • functional modeling. This type of modeling implies the description of processes in the form of interconnected, clearly structured functions. At the same time, a strict temporal sequence of functions, in the form in which it exists in real processes, is not necessary.
  • Object Modeling- implies the description of processes as a set of interacting objects - i.e. production units. An object is any object that is transformed during the execution of processes.
  • Simulation- with this type of business process modeling, it is meant to model the behavior of processes in various external and internal conditions with an analysis of the dynamic characteristics of processes and an analysis of the distribution of resources.

The division of modeling by type is performed to simplify the work and focus on certain characteristics of the process. In this case, for the same process can be applied different kinds modeling. This allows you to work with one type of model independently of others.

Principles of business process modeling

Business process modeling is based on a number of principles that make it possible to create adequate process models. Their observance makes it possible to describe a set of process state parameters in such a way that within one model the components are closely interconnected, while individual models remain sufficiently independent of each other.

The main principles of business process modeling are as follows:

  • Decomposition principle– each process can be represented by a set of hierarchically arranged elements. In accordance with this principle, the process must be detailed into its constituent elements.
  • Focus Principle– to develop a model, it is necessary to abstract from many process parameters and focus on key aspects. For each model, these aspects may be different.
  • Documentation principle– the elements included in the process must be formalized and fixed in the model. Different designations must be used for different process elements. Fixing elements in the model depends on the type of modeling and the chosen methods.
  • Consistency principle- all elements included in the process model must have an unambiguous interpretation and not contradict each other.
  • The principle of completeness and sufficiency- before including this or that element in the model, it is necessary to evaluate its impact on the process. If the element is not essential for the execution of the process, then its inclusion in the model is not advisable, because it can only complicate the business process model.

Methods for modeling business processes

Today, there are a fairly large number of methods for modeling business processes. These methods belong to different types of modeling and allow you to focus on different aspects. They contain both graphical and textual tools, through which you can visualize the main components of the process and give precise definitions of the parameters and relationships of elements.

Business process modeling is performed using the following methods:

  • Flow Chart Diagram (workflow diagram) is a graphical process representation method in which operations, data, process equipment, etc. are depicted with special symbols. The method is used to display a logical sequence of process actions. The main advantage of the method is its flexibility. The process can be represented in many ways.
  • Data Flow Diagram (data flow diagram). A data flow diagram or DFD is used to show the transfer of information (data) from one operation of a process to another. DFD describes the relationship of operations through information and data. This method is the basis of the structural analysis of processes, since allows you to decompose the process into logical levels. Each process can be broken down into sub-processes at a higher level of detail. The use of DFD allows you to reflect only the flow of information, but not the flow of materials. A data flow diagram shows how information enters and exits a process, what actions change information, where information is stored in a process, and so on.
  • Role Activity Diagram (diagram of roles). It is used to model a process in terms of individual roles, groups of roles, and the interaction of roles in a process. A role is an abstract process element that performs an organizational function. The role diagram shows the degree of "responsibility" for the process and its operations, as well as the interaction of roles.
  • IDEF (Integrated Definition for Function Modeling) is a whole set of methods for describing various aspects of business processes (IDEF0, IDEF1, IDEF1X, IDEF2, IDEF3, IDEF4, IDEF5). These methods are based on the SADT (Structured Analysis and Design Technique) methodology. The IDEF0 and IDEF3 methods are most often used to model business processes.
  • IDEF0 - allows you to create a process function model. The IDEF0 diagram shows the main process functions, inputs, outputs, control actions and devices related to the main functions. The process can be decomposed into a lower level.
  • IDEF3 - this method allows you to create a "behavioral" process model. IDEF3 consists of two kinds of models. The first view represents the description of the workflow. The second is a description of the transition states of objects.
  • Colored Petri Nets– this method represents the process model in the form of a graph, where the vertices are the actions of the process, and the arcs are the events, due to which the process transitions from one state to another. Petri nets are used to dynamically model the behavior of a process.
  • Unified Modeling Language (UML) - is an object-oriented process modeling method. It consists of 9 different diagrams, each of which allows you to model different static or dynamic aspects of the process.

Most of these methods are implemented in software. It allows you to support business processes or analyze them. Examples of such software are various CASE process modeling tools.

Heading: Start business
Share