Функциональная модель бизнес процесса это

Моделирование бизнеса. Основные подходы

В этой статье я хочу поговорить об основных принципах моделирования бизнеса, о тех подходах, которые применяются в этой сфере, и на основе которых создаются языки моделирования и нотации.

Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.

С одной стороны, применение схем для наглядности при описании моделей бизнеса в ни у кого не вызывает вопросов. Это действительно очень удобно. С другой стороны, многие бизнесмены и даже мои коллеги недоумевают, зачем нужны специальные нотации и правила для разработки бизнес-процессов, ведь можно в любом графическом редакторе (visio) или при помощи других удобных инструментов просто нарисовать интуитивно понятную схему.

О том, почему так важна стандартизация, а также о том, в каком случае применяется тот или иной подход, я и хочу поговорить.

Основные подходы

Сегодня существует множество различных инструментов для разработки бизнес-моделей, они используют различные языки моделирования, как стандартные, так и какие-то собственные разработки. Но все их можно объединить по принципу работы в три основных подхода:

• Функциональный;
• Процессный;
• Ментальный (с применением ментальных карт).

На самом деле, конечно, существуют и другие подходы, их много так же, как и языков моделирования. Но они большей частью являются гибридными решениями, объединяющих перечисленные подходы. Кроме того, именно процессная и функциональная модели уже стали стандартами, по крайней мере, на западе. И у нас они получают все большее распространение. Об этих основных направлениях я и хочу поговорить подробнее.

Функциональное моделирование

Функциональное моделирование рассматривает бизнес как функцию (лат. functio — совершение, исполнение) или иными словами «черный ящик». В функциональной модели функция не имеет временной последовательности, а только точку входа и точку выхода. Функциональное моделирование помогает рассматривать бизнес-модель с с точки зрения результативности, т.е. при моделировании мы исходим из того, что имеем на входе, и того, что желаем получить на выходе.

Например, компания разрабатывает какую-то CRM-систему для своего бизнеса. В случае применения функционального подхода к моделированию уже сама выбранная среда для работы подсказывает, с чего начинать. Точка входа – «входящий интерес клиента или лид», точка выхода – желаемый результат: «покупка и получение лояльного клиента», «получение постоянного клиента», «получение максимум информации о потенциальном клиенте» и т.д.

Таким образом, в функциональной модели изначально известны точка входа и желаемый результат, а последовательность действий и является объектом разработки. При этом использование функциональных моделей как «черных ящиков» позволяет детализировать каждый этап по мере необходимости. А вся работа при моделировании направлена на поиск оптимального решения для достижения цели.

Функциональные модели вы можете также использовать для демонстрации своих идей и вариантов решений. Это также очень удобно, ведь в процессе демонстрации вы можете двигаться от общего к деталя, по мере необходимости разделять и декомпозировать функции. Но декомпозировать вы будете при этом именно функции, и, разделяя одну функцию на несколько, вы не получите описание процесса.

Некоторые путают описание процесса и функциональную модель. Например, в системе Business Studio функцию называют процессом, хоть это и не совсем верно. Все же описание функций и процессный подход – несколько разные вещи. И я лично считаю, что функциональное моделирование оптимально реализовано в нотации IDEFO. Сам я для такого варианта работы использую именно ее, и всем также рекомендую.

Правила работы с IDEFO вы можете подробнее изучить, прочитав мою статью накомство с нотацией IDEF0 и пример использования.

Процессное моделирование (моделирование бизнес процессов)

О процессном моделировании я буду рассказывать с точки зрения нотации BPMN, как одного из наиболее распространенных стандартов процессного моделирования. При этом я полностью согласен, что существует множество языков моделирования и различных систем. И каждый может пользоваться тем, что ему удобнее. Но все же BPMN — это уже сложившийся стандарт процессного моделирования, а потому его я и беру за основу в описании.

Процесс с точки зрения бизнес-модели — это последовательность каких-то событий и действий, которые имеют начало и конец.

В этом кроется основное отличие процессного моделирования от функционального. Функциональное моделирование рассматривает бизнес-модель с точки зрения входа и выхода (имеющихся ресурсов и желаемого результата). А процессное основано на последовательности действий в определенных границах, в случае BPMN это будут начало и конец события.

Все процессы могут разбиваться (детализироваться) на подпроцессы вплоть до детализации на уровне задач, т.е. действий, дальнейшая детализация которых невозможна. Процесс – это некая последовательность действий, которую необходимо выполнить, чтобы получить определенный результат. Необходимо отметить что в модели бизнеса как процесса результат может и не быть явным в отличии от функциональной модели.

Принципиальное отличие процессного моделирования от функционального заключается в том, что при процессном моделировании основное внимание уделяется не тому, что мы хотим получить, а тому, что нужно сделать для получения результата, т.е. не итогам той или иной деятельности, а самой последовательности действий.

Например, в BPWIN или Business Studio в процессе детализации каждой функции происходит переход от функционального подхода к процессному. Т.е. в общем, мы рассматриваем модель с точки зрения – возможностей и желаемого результата, а когда переходим к решениям для каждой функции, здесь уже практикуется явно процессный подход, т.е. пошаговый алгоритм действий для достижения результата.

Представьте себе что в функциональной модели есть «черный ящик» — функция «Принять заказ». А при декомпозировании мы уже рассматриваем ее не как функцию, а как процесс, и последовательность действий при приеме заказа – это уже процессный подход.

Есть и еще одно очень важное отличие. Функциональную модель невозможно использовать при реализации какой-то либо системы, только для проектирования. А процессный подход позволяет создавать исполняемые модели, т.е. описания последовательности действий, которые мы можем в дальнейшем перевести в какую-то среду для создания системы совместной работы предприятия, основанной на процессном подходе.

Ментальный подход (ментальные карты)

При создании ментальных моделей специалист подходит к моделированию не как к процессу или набору функций, а как к некому набору связанных между собой понятий. Для наглядности я приведу пример — ментальная карта понятия “Процедура снабжения” (см. рисунок).

Такой вариант подхода применяется, прежде всего, для себя. Рисование схемы в свободной форме помогает структурировать свои знания, так сказать, “разложить по полочкам” в свободной форме полученную информацию. Также подобные ментальные карты помогают найти решение, которое уже позже, по мере необходимости, будет воплощаться в рамках строгих правил процессного или функционального подхода.

Можно применять ментальные карты и для демонстрации клиентам: и существующей ситуации, и вариантов решения поставленной задачи. Ментальные карты помогут наглядно продемонстрировать, какие методы могут быть использованы, показать в наглядной форме различные идеи.

Плюсы применения таких ментальных карт очевидны:

• Не нужно знать какие-то специальные языки;
• Нет строгих рамок и ограничений при создании схемы;
• Ментальная карта в большинстве случаев интуитивно понятна;
• Создавать такие схемы просто.

Минусом подхода является отсутствие устоявшегося подхода и стандартизированной методологии. Если в нотациях функциональных и процессных имеется некоторая вариативность, но все же она ограничена строгими рамками языков моделирования, то ментальные карты создаются в произвольной форме. И даже специализированные программы для их создания также почти не ограничивают человека в процессе моделирования. Т.е. какие-то правила могут вводиться в рамках определенного программного продукта, но стандарта не существует.

В результате для понимания модели и заложенных в ней идей требуется присутствие и комментарии ее разработчика (аналитика).

Конечно, существуют очень простые карты, которые интуитивно читаются и без дополнительных комментариев. Но при отсутствии стандартов всегда есть вероятность, что даже в этом случае автор что-то другое имел в виду или где-то недостаточно детализировал свою схему. Т.е. существует вероятность разного прочтения. А бизнес — это не философия. При всей умозрительности и разнообразии подходов к описанию бизнес-процессов, здесь очень важны однозначные решения.

Методология и языки бизнес-моделирования

Очень часто даже в профессиональной литературе возникает путаница, когда люди смешивают понятия методологии анализа работы бизнеса и описания языков бизнес-моделирования.

Методология — это система принципов и стандартов описания бизнес моделей и их последующего анализа. В то время как язык бизнес-моделирования – это не более чем инструмент для разработки моделей бизнеса.

Здесь напрашивается сравнение с программированием вообще и применением конкретного языка программирования. Программирование включает в себя и построение алгоритма, и выбор подходящего языка программирования, и реализацию алгоритма программы в рамках того или иного языка. А, например, программирование на языке Си++ – это уже заведомо ограничение определенными рамками, так как средствами определенного языка можно решить только четко ограниченный круг задач, и, одновременно, даже если задачу можно решить средствами Си++ совсем не обязательно, что именно этот язык будет в конкретном случае оптимальным. В общем, разницу между понятием «программирование» и «программированием в рамках определенного языка», я думаю, большинство понимают даже без таких пояснений.

Отличие языков разработки бизнес-моделей в от языков проектирования систем

Существует целое семейство языков проектирования систем, которые внешне схожи с языками бизнес-моделирования, например, это Ares Studios, целое семейство языков UML и другие, которые используются для проектирования IT-систем.

Основное различие этих языков от языков разработки бизнес-процессов лежит в их предназначении. Если языки проектирования IT-систем рассматривают бизнес-процессы с точки зрения возможности их автоматизации, воплощении в IT-системах, то языки бизнес-моделирования рассматривают последовательность действий именно с точки зрения бизнеса, включая работу как IT-систем, так и сотрудников, движения товаров и т.д.

Соответственно, в языках проектирования систем нет элементов, которые помогут полноценно описать действия подразделений, сотрудников, взаимодействие между ними, работу с поставщиками, общение с клиентами и так далее. Инструменты этой группы языков помогут именно автоматизировать процессы бизнеса, которые поддаются автоматизации. А все остальное будет оставлено «за кадром», например, как некие «функции» без расшифровки.

В то же время языки разработки бизнес-процессов охватывают максимально именно работу бизнеса как такового, а вот те или иные нюансы автоматизации и алгоритмизации систем в них описать далеко не всегда возможно с достаточной степенью детализации.

Преимущества разработки моделей бизнеса

И все же, зачем применять языки бизнес-моделирования, которые налагают строгие ограничения, требуют придерживаться жестко заданных правил при моделировании? Ведь всегда можно «нарисовать схему» в графическом редакторе или даже на бумаге, используя ментальный подход, при этом изучение языков моделирования вообще не потребуется.

На самом деле, стандарты и правила – это огромный плюс:

1. Языки моделирования помогают максимально качественно передать информацию. Стандартизация повышает простоту восприятия.
2. Скорость разработки моделей значительно увеличивается. Языки содержат все необходимые инструменты и графические блоки в готовом виде. Вам не придется «рисовать» или придумывать свою терминологию. Инструментарий уже готов, и работа в его рамках значительно ускоряется. Конечно, язык нужно выучить. Но один раз изучить – это намного быстрее, чем каждый раз придумывать и пояснять собственный набор обозначений.
3. Снижается число возможных ошибок. Сами элементы системы уже будут «подсказывать» перечень возможных и необходимых действий. А в случае создания исполняемых моделей или неисполняемых, но в строгих рамках правил, всегда можно проверить работу бизнес-модели в исполняемой среде и провести отладку, как при программировании.

Применение моделей бизнеса на практике

Лично я считаю, что бизнес-моделирование стоит применять при решении любых задач, связанных с выявлением проблем и «узких мест», с оптимизацией и модернизацией бизнеса и т.д. Как бизнес-консультант я практически всегда строю модели работы компании или ее подразделений при работе со своими клиентами. Это дает четкое понимание всех этапов работы и позволяет избежать «белых пятен» в этом вопросе.

Кроме того, наглядные схемы бизнес-моделей помогают мне в процессе взаимодействия с клиентами. Проекты у меня часто бывают сложными, и обычного текста или устной речи бывает недостаточно для понимания, в то время как использование наглядных бизнес-моделей снижает затраты времени клиента на чтение и понимание моих предложений, и практически исключает проблемы взаимопонимания в этом вопросе. И если несколько лет назад я еще сталкивался с недоумением со стороны клиентов, то сейчас вариант описания «на словах» без наглядных и удобных схем практикуется крайне редко.

А в случае автоматизации какого-либо этапа работы или создания автоматизированной системы управления бизнесом на основе проектно-ориентированного подхода качественная бизнес-модель, выполненная в том или ином языке моделирования, станет готовым руководством для технических специалистов.

Удобство, универсальность, простота восприятия – это те причины, по которым от словесных описаний в бизнес-сфере все больше переходят к бизнес-моделированию. А применение готовых языков позволяет работать с моделями быстро, избегать ошибок, и также без проблем вносить любые изменения.

Также в настоящее время я готовлю к публикации книгу и онлайн курс, в которой подробно опишу собственное видение процессного подхода к бизнесу, а также мой собственный практический опыт работы в сфере функционального и процессного моделирования. Все желающие могут подписаться на уведомление о выходе новой книги по и другие новости ссылке.

In systems engineering, software engineering, and computer science, a function model or functional model is a structured representation of the functions (activities, actions, processes, operations) within the modeled system or subject area.^[1]

A function model, similar with the activity model or process model, is a graphical representation of an enterprise’s function within a defined scope. The purposes of the function model are to describe the functions and processes, assist with discovery of information needs, help identify opportunities, and establish a basis for determining product and service costs.^[2]

History[edit]

The function model in the field of systems engineering and software engineering originates in the 1950s and 1960s, but the origin of functional modelling of organizational activity goes back to the late 19th century.

In the late 19th century the first diagrams appeared that pictured business activities, actions, processes, or operations, and in the first half of the 20th century the first structured methods for documenting business process activities emerged. One of those methods was the flow process chart, introduced by Frank Gilbreth to members of American Society of Mechanical Engineers (ASME) in 1921 with the presentation, entitled “Process Charts—First Steps in Finding the One Best Way”.^[3] Gilbreth’s tools quickly found their way into industrial engineering curricula.

The emergence of the field of systems engineering can be traced back to Bell Telephone Laboratories in the 1940s.^[4] The need to identify and manipulate the properties of a system as a whole, which in complex engineering projects may greatly differ from the sum of the parts’ properties, motivated various industries to apply the discipline.^[5] One of the first to define the function model in this field was the British engineer William Gosling. In his book The design of engineering systems (1962, p. 25) he stated:

A functional model must thus achieve two aims in order to be of use. It must furnish a throughput description mechanics capable of completely defining the first and last throughput states, and perhaps some of the intervening states. It must also offer some means by which any input, correctly described in terms of this mechanics, can be used to generate an output which is an equally correct description of the output which the actual system would have given for the input concerned. It may also be noted that there are two other things which a functional model may do, but which are not necessary to all functional models. Thus such a system may, but need not, describe the system throughputs other than at the input and output, and it may also contain a description of the operation which each element carries out on the throughput, but once again this is not.^[6]

One of the first well defined function models, was the functional flow block diagram (FFBD) developed by the defense-related TRW Incorporated in the 1950s.^[7] In the 1960s it was exploited by the NASA to visualize the time sequence of events in a space systems and flight missions.^[8] It is further widely used in classical systems engineering to show the order of execution of system functions.^[9]

Functional modeling topics[edit]

Functional perspective[edit]

In systems engineering and software engineering a function model is created with a functional modeling perspective. The functional perspective is one of the perspectives possible in business process modelling, other perspectives are for example behavioural, organisational or informational.^[10]

A functional modeling perspective concentrates on describing the dynamic process. The main concept in this modeling perspective is the process, this could be a function, transformation, activity, action, task etc. A well-known example of a modeling language employing this perspective is data flow diagrams.

The perspective uses four symbols to describe a process, these being:

• Process: Illustrates transformation from input to output.
• Store: Data-collection or some sort of material.
• Flow: Movement of data or material in the process.
• External Entity: External to the modeled system, but interacts with it.

Now, with these symbols, a process can be represented as a network of these symbols. This decomposed process is a DFD, data flow diagram.

In Dynamic Enterprise Modeling a division is made in the Control model, Function Model, Process model and Organizational model.

Functional decomposition[edit]

Functional decomposition refers broadly to the process of resolving a functional relationship into its constituent parts in such a way that the original function can be reconstructed from those parts by function composition. In general, this process of decomposition is undertaken either for the purpose of gaining insight into the identity of the constituent components, or for the purpose of obtaining a compressed representation of the global function, a task which is feasible only when the constituent processes possess a certain level of modularity.

Functional decomposition has a prominent role in computer programming, where a major goal is to modularize processes to the greatest extent possible. For example, a library management system may be broken up into an inventory module, a patron information module, and a fee assessment module. In the early decades of computer programming, this was manifested as the «art of subroutining,» as it was called by some prominent practitioners.

Functional decomposition of engineering systems is a method for analyzing engineered systems. The basic idea is to try to divide a system in such a way that each block of the block diagram can be described without an «and» or «or» in the description.

This exercise forces each part of the system to have a pure function. When a system is composed of pure functions, they can be reused, or replaced. A usual side effect is that the interfaces between blocks become simple and generic. Since the interfaces usually become simple, it is easier to replace a pure function with a related, similar function.

Functional modeling methods[edit]

The functional approach is extended in multiple diagrammic techniques and modeling notations. This section gives an overview of the important techniques in chronological order.

Function block diagram[edit]

A functional block diagram is a block diagram, that describes the functions and interrelationships of a system. The functional block diagram can picture:^[11]

• Functions of a system pictured by blocks
• Input of a block pictured with lines, and
• Relationships between 9 functions
• Functional sequences and paths for matter and or signals^[12]

The block diagram can use additional schematic symbols to show particular properties.

Specific function block diagram are the classic functional flow block diagram, and the Function Block Diagram (FBD) used in the design of programmable logic controllers.

Functional flow block diagram[edit]

The functional flow block diagram (FFBD) is a multi-tier, time-sequenced, step-by-step flow diagram of the system’s functional flow.^[14]
The diagram is developed in the 1950s and widely used in classical systems engineering. The functional flow block diagram is also referred to as Functional Flow Diagram, functional block diagram, and functional flow.^[15]

Functional flow block diagrams (FFBD) usually define the detailed, step-by-step operational and support sequences for systems, but they are also used effectively to define processes in developing and producing systems. The software development processes also use FFBDs extensively. In the system context, the functional flow steps may include combinations of hardware, software, personnel, facilities, and/or procedures.

In the FFBD method, the functions are organized and depicted by their logical order of execution. Each function is shown with respect to its logical relationship to the execution and completion of other functions. A node labeled with the function name depicts each function. Arrows from left to right show the order of execution of the functions. Logic symbols represent sequential or parallel execution of functions.^[16]

HIPO and oPO[edit]

HIPO for hierarchical input process output is a popular 1970s systems analysis design aid and documentation technique^[17] for representing the modules of a system as a hierarchy and for documenting each module.^[18]

It was used to develop requirements, construct the design, and support implementation of an expert system to demonstrate automated rendezvous. Verification was then conducted systematically because of the method of design and implementation.^[19]

The overall design of the system is documented using HIPO charts or structure charts. The structure chart is similar in appearance to an organizational chart, but has been modified to show additional detail. Structure charts can be used to display several types of information, but are used most commonly to diagram either data structures or code structures.^[18]

N² Chart[edit]

The N² Chart is a diagram in the shape of a matrix, representing functional or physical interfaces between system elements. It is used to systematically identify, define, tabulate, design, and analyze functional and physical interfaces. It applies to system interfaces and hardware and/or software interfaces.^[14]

The N² diagram has been used extensively to develop data interfaces, primarily in the software areas. However, it can also be used to develop hardware interfaces. The basic N² chart is shown in Figure 2. The system functions are placed on the diagonal; the remainder of the squares in the N × N matrix represent the interface inputs and outputs.
^[20]

Structured Analysis and Design Technique[edit]

Structured Analysis and Design Technique (SADT) is a software engineering methodology for describing systems as a hierarchy of functions, a diagrammatic notation for constructing a sketch for a software application. It offers building blocks to represent entities and activities, and a variety of arrows to relate boxes. These boxes and arrows have an associated informal semantics.^[21] SADT can be used as a functional analysis tool of a given process, using successive levels of details. The SADT method allows to define user needs for IT developments, which is used in industrial Information Systems, but also to explain and to present an activity’s manufacturing processes, procedures.^[22]

The SADT supplies a specific functional view of any enterprise by describing the functions and their relationships in a company. These functions fulfill the objectives of a company, such as sales, order planning, product design, part manufacturing, and human resource management. The SADT can depict simple functional relationships and can reflect data and control flow relationships between different functions. The IDEF0 formalism is based on SADT, developed by Douglas T. Ross in 1985.^[23]

IDEF0[edit]

IDEF0 is a function modeling methodology for describing manufacturing functions, which offers a functional modeling language for the analysis, development, re-engineering, and integration of information systems; business processes; or software engineering analysis.^[24] It is part of the IDEF family of modeling languages in the field of software engineering, and is built on the functional modeling language building SADT.

The IDEF0 Functional Modeling method is designed to model the decisions, actions, and activities of an organization or system.^[25] It was derived from the established graphic modeling language structured analysis and design technique (SADT) developed by Douglas T. Ross and SofTech, Inc. In its original form, IDEF0 includes both a definition of a graphical modeling language (syntax and semantics) and a description of a comprehensive methodology for developing models.^[1] The US Air Force commissioned the SADT developers to develop a function model method for analyzing and communicating the functional perspective of a system. IDEF0 should assist in organizing system analysis and promote effective communication between the analyst and the customer through simplified graphical devices.^[25]

Axiomatic design[edit]

Axiomatic design is a top down hierarchical functional decomposition process used as a solution synthesis framework for the analysis, development, re-engineering, and integration of products, information systems, business processes or software engineering solutions.^[26] Its structure is suited mathematically to analyze coupling between functions in order to optimize the architectural robustness of potential functional solution models.

[edit]

In the field of systems and software engineering numerous specific function and functional models and close related models have been defined. Here only a few general types will be explained.

Business function model[edit]

A Business Function Model (BFM) is a general description or category of operations performed routinely to carry out an organization’s mission. They «provide a conceptual structure for the identification of general business functions».^[27] It can show the critical business processes in the context of the business area functions. The processes in the business function model must be consistent with the processes in the value chain models. Processes are a group of related business activities performed to produce an end product or to provide a service. Unlike business functions that are performed on a continual basis, processes are characterized by the fact that they have a specific beginning and an end point marked by the delivery of a desired output. The figure on the right depicts the relationship between the business processes, business functions, and the business area’s business reference model.^[28]

Business Process Model and Notation[edit]

Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes in a workflow. BPMN was developed by Business Process Management Initiative (BPMI), and is currently maintained by the Object Management Group since the two organizations merged in 2005. The current version of BPMN is 2.0.^[29]

The Business Process Model and Notation (BPMN) specification provides a graphical notation for specifying business processes in a Business Process Diagram (BPD).^[30] The objective of BPMN is to support business process management for both technical users and business users by providing a notation that is intuitive to business users yet able to represent complex process semantics. The BPMN specification also provides a mapping between the graphics of the notation to the underlying constructs of execution languages, particularly BPEL4WS.^[31]

Business reference model[edit]

A Business reference model is a reference model, concentrating on the functional and organizational aspects of the core business of an enterprise, service organization or government agency. In enterprise engineering a business reference model is part of an Enterprise Architecture Framework or Architecture Framework, which defines how to organize the structure and views associated with an Enterprise Architecture.

A reference model in general is a model of something that embodies the basic goal or idea of something and can then be looked at as a reference for various purposes. A business reference model is a means to describe the business operations of an organization, independent of the organizational structure that perform them. Other types of business reference model can also depict the relationship between the business processes, business functions, and the business area’s business reference model. These reference model can be constructed in layers, and offer a foundation for the analysis of service components, technology, data, and performance.

Operator function model[edit]

The Operator Function Model (OFM) is proposed as an alternative to traditional task analysis techniques used by human factors engineers. An operator function model attempts to represent in mathematical form how an operator might decompose a complex system into simpler parts and coordinate control actions and system configurations so that acceptable overall system performance is achieved. The model represents basic issues of knowledge representation, information flow, and decision making in complex systems. Miller (1985) suggests that the network structure can be thought of as a possible representation of an operator’s internal model of the system plus a control structure which specifies how the model is used to solve the decision problems that comprise operator control functions.^[32]

See also[edit]

• Bus Functional Model
• Business process modeling
• Data and information visualization
• Data model
• Enterprise modeling
• Functional Software Architecture
• Polynomial function model
• Rational function model
• Scientific modeling
• Unified Modeling Language
• View model

References[edit]

 This article incorporates public domain material from the National Institute of Standards and Technology.

 This article incorporates public domain material from Operator Function Model (OFM). Federal Aviation Administration.

Для того чтобы сузить до разумных пределов творческую свободу проектировщика, требуются метастандарты проектирования бизнес-процессов, которые можно сформулировать в виде установочных концепций. Предлагаемые в статье семантические правила моделирования акцентированы на повышении адекватности оценок эффективности системы бизнес-процессов, получаемых средствами функционально-стоимостного анализа или имитационного моделирования. Также статья содержит предложения, которые могут пригодиться руководителям и аналитикам при создании внутренних положений предприятия, уточняющих и конкретизирующих фирменные инструкции ко многим CASE-средствам.

!!! Полезный материал! Сборник статей по целевому управлению. Скачать >

Чтобы приготовить блюдо, недостаточно знать его ингредиенты и их пропорции; необходимо еще овладеть навыками изготовления продукта. Объективно, современные методики организационного проектирования предлагают лишь описание ингредиентов и весьма приближенное описание технологий получения продукта, оставляя широкое поле для творчества. И это, наверное, правильно. Ведь субъективные интерпретации и детализации этих методик могут быть не менее ценными, чем сами методики.

Многообразие возможных точек зрения на принципы моделирования и содержание понятия «бизнес-процесс», с которым сталкивается проектировщик, с одной стороны, активизирует его, а с другой, существенно осложняет решение проектной задачи в заданные сроки. В [1] отстаивается точка зрения, что проектировщику следует активизировать свою креативность в максимально узких рамках. Творческую свободу проектировщика ограничивают:

1. стандарт проектирования бизнес-процессов;
2. отраслевые стандарты бизнес-процессов;
3. ранее принятые стандарты проектирования бизнес-процессов предприятия;
4. установочные концепции.

Примером стандартов проектирования бизнес-процессов может служить семейство стандартов IDEF (Госдепартамент и BBC США), RUP (компания Rational Software), Catalysis (компания Computer Associates). Отраслевыми стандартами являются модели, разрабатываемые государственными и международными общественными организациями (рекомендации ISA, APICS, ISO, TM Forum и др.). Стандарты предприятия обычно составляют подмножество стандартов (1) и (2), обогащенное процедурными правилами разработки и согласования моделей бизнес-процессов, принятых на предприятии.

Какими бы ни были жесткими нормативные ограничения, всегда найдется неопределенная ими область творчества для постановщика задачи и ее исполнителя, а также возможности интерпретации этих ограничений. Дополняющие и не противоречащие нормативным ограничениям согласованные точки зрения постановщика и исполнителя на моделируемый объект и способы его описания назовем установочными концепциями. Ими могут быть:

• цели моделирования (реинжиниринг бизнес-процессов, автоматизация бизнес-процессов и внедрения информационных систем, системные исследования бизнес-процессов и др.);
• интерпретация стандартов (1-3) как заказчиком проектных работ, так и самим проектировщиком;
• принципы формирования словаря проекта и соглашения об основных понятиях, неопределенные стандартами (1-3) или нуждающиеся в уточнении.

Апробированные установочные концепции могут являться основой для разработки предложений по совершенствованию стандартов предприятия.

Не станем ограничиваться рассмотрением одной из целей моделирования, а попытаемся сосредоточиться на аспектах моделирования бизнес-процессов, имеющих общую значимость. Исходный контекст статьи – это абстрактный проект, целью которого является разработка модели бизнес-процессов, а предмет обсуждения – задача «настройки» ограничений (3-4) на этот проект. Фактически речь идет о процессе приспособления стандарта (tailoring process) и точек зрения проектировщика, который, как правило, содержит огромные возможности для привнесения субъективных решений, как по воле проектировщика, так и по воле заказчика. Поэтому необходимы дополнительные методические рекомендации, которые сузили бы область творческого «произвола» при модификации стандартов проектирования бизнес-процессов.

Рассмотрим рекомендации по конкретизации языков моделирования бизнес-процессов в контексте методологии IDEF0. Данный выбор не является принципиальным, а лишь отражает субъективные пристрастия автора. При этом следует иметь в виду, что предлагаемые принципы формирования рекомендаций и логику их применения легко распространить на отличные от IDEF0 методики проектирования бизнес-процессов с учетом трех аспектов моделирования бизнес-процессов: функционального моделирования, моделирования событий и ресурсов и унификаций описания бизнес-процессов.

Функциональная модель бизнес-процессов

Любой стандарт проектирования бизнес-процессов базируется на исходных понятиях – смысловых примитивах. Так, стандарт IDEF0 использует понятие «Работа» (Activity) для обозначения действия, а также обозначения интерфейсов «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), которые составляют графическую конструкцию (A), изображенную на рис. 1.

Рис. 1.

К сожалению, в IDEF0 эти примитивы определяются в общем виде, поэтому пользователи стандарта обычно прибегают к интерпретациям примитивов. Например, только на первый взгляд конструкция из рис. 1 выглядит логичной, а формирование дополнительных концептуальных установок – ненужным. Как правило, у начинающего пользователя возникает недоумение, куда ему необходимо отнести понятие «Распоряжение»: к интерфейсу «Управление» или к интерфейсу «Вход»? Или куда отнести понятие «расходные материалы» при моделировании работы канцелярии: к «Входу» или «Механизму»? Дальше – больше. Стандарт IDEF0 исполнителей «Работ» (одушевленных и неодушевленных) относит к интерфейсу «Механизм». На уровне бытового сознания это не вызывает вопросов, однако, если вдуматься в суть понятия «исполнение», то становится ясным, что исполнитель «Работ» является активатором «Работ», составляющих данную «Работу» и приводящих к ее исполнению. Между тем, активатором «Работ» согласно IDEF0 является «Вход».

Подобных логико-лингвистических противоречий в интерпретациях профессиональные пользователи стандарта IDEF0 могут привести много. Приведенные примеры говорят о том, что проектировщику так или иначе придется «заузить» стандарт IDEF0, если для него важна непротиворечивость модели и собственных представлений о моделируемом объекте.

!!! Полезный материал! Сборник статей по целевому управлению. Скачать >

Для практического удобства можно предложить иную, зауженную интерпретацию исходных примитивов стандарта IDEF0 (графическая конструкция (Б) на рис. 1). Сформулируем основную идею предлагаемой рекомендации по конкретизации языков моделирования бизнес-процессов.

Все «Работы» принадлежат одному классу – обладают одинаковым набором свойств и поведением.

Все связи между «Работами» принадлежат классу «Ресурс». Например, электронное издание «Налогового кодекса РФ» является реализацией (или экземпляром) общедоступного информационного ресурса, а уборщица Иванова И.И. является экземпляром ресурса «Уборщица офиса 202».

На IDEF0-диаграмах изображаются классы объектов. Однако проектировщик всегда отталкивается от знания только некоторых общих свойств конкретных реализаций (экземпляров) этих классов. Назовем такое множество свойств «точкой зрения на экземпляр класса». Эту посылку можно использовать для однозначной «привязки» ресурсов к трем возможным входам бизнес-процессов. Для этого на множестве ресурсов вводится классификация, основанная на различиях «точек зрения на экземпляры ресурсов».

1. Признак изменчивости экземпляров ресурсов при исполнении «Работы»:

• ресурсы, подлежащие трансформации в другие виды ресурсов;
• нетрансформируемые ресурсы.

Нетрансформируемые ресурсы могут быть неизнашиваемыми или изнашиваемыми (устаревающими). Так, значительная часть информационных ресурсов в электронной форме являются неизнашиваемыми (библиотека нормативных документов организации и др.). Примером изнашиваемых ресурсов могут служить вспомогательные инструменты, персонал. Описанные признаки относятся к экземплярам ресурсов, а не к самим ресурсам: понятия как абстрактные классы не изнашиваются.

2. Признак блокировки экземпляра ресурса «Работой», исключающий возможность использования экземпляра ресурса другими «Работами»:

• ресурсы, которые не могут блокироваться “Работами” (ресурсы общего пользования);
• блокируемые ресурсы (например, уборщица Иванова И.И.)

Правила разводки ресурсов, классифицируемых по описанным признакам, по интерфейсам, заданным стандартом IDEF0, иллюстрируются на примере “Общая модель бизнес-процессов (В)” (рис. 1). Предлагаемая интерпретация смыслового содержания интерфейсов IDEF0-стандарта не только полностью соответствует требованиям этого стандарта, но и лишена возможных логико-лингвистических противоречий, свойственных ряду других интерпретаций.

События и ресурсы

Важнейший компонент моделирования бизнес-процессов – оценка материальных, стоимостных и временных ресурсов, необходимых для исполнения всего множества процессов. В современных инструментах проектирования, поддерживающих IDEF0, для этих целей используется функционально-стоимостной анализ, а расчеты производятся методом непосредственной имитации исполнения «Работ». Можно встретить мнение, что одним из недостатков IDEF0-моделей, в которых по тем или иным причинам не определяются моменты активации работ, является ошибка функционально-стоимостного анализа, вызванная фактором нарушения последовательности «Работ». Эта ошибка считается допустимой для приближенных расчетов. Для более точных расчетов предлагается использовать иные инструменты; так, в BPwin наличествует возможность экспорта данных в систему EasyABC. Однако это слишком дорогое решение для такой простой задачи. Что мешает нам более четко определить моменты активации «Работ» на IDEF0-диаграммах?

Считается, что основным отличием стандартов, нацеленных на функциональное или процессное моделирование, являются их возможности по описанию событий и последовательности исполнения «Работ» во времени. В известном руководстве [4] пользователям стандартов IDEF0 и IDEF3 настойчиво навязывается идея о различном их назначении, говорится об отличиях интерпретации стрелок в IDEF0 и в моделях потока работ [5]. Покажем, что это утверждение далеко от действительности.

В качестве базовой посылки примем положение о том, «что не запрещено стандартом, то разрешено». Покажем, что IDEF0 не запрещает изображать события и определять последовательность «Работ» с помощью стрелок. Будем исходить из того, что в IDEF0 активаторами работ определены стрелки [5]. К сожалению, сущность такой активации в стандарте не поясняется. Логично предположить, что активация – это принуждение к исполнению «Работы» или, как минимум, изменение состояния «Работы», которое тоже можно толковать как начало исполнения. При этом активация может толковаться широко. Например, отсутствие информации на входе «Работы» тоже может рассматриваться как активация.

Однако в стандарте, как это ни странно, синтаксически не различаются «Работы», находящиеся на различных уровнях декомпозиции. Различия же между ними существенны. Согласно положению стандарта о том, что активаторами «Работ» являются стрелки, а на нижнем уровне декомпозиции бизнес-процессов стрелки описывают последовательность исполнения «Работ» [5], можно утверждать, что каждая «Работа» на нижнем уровне декомпозиции модели активируется только при активации всех ее входов. К сожалению, из текста стандарта не следует, что считать условиями активации «Работы» более высокого уровня. Стандарт рекомендует проектировщику, по возможности, не задумываться над этой проблемой, однако не настаивает на этом определенно [5].Читатель стандарта может в этом самостоятельно убедиться, если не вырывать фразы из контекста.

!!! Полезный материал! Сборник статей по целевому управлению. Скачать >

Существует еще аспект времени, который стандартом замалчивается, – момент завершения «Работы». Без его знания функционально-стоимостной анализ, основанный на моделировании, не будет завершен. Можно прятать голову в песок и не определять условие активации «Работы», но момент ее завершения мы видеть обязаны. К счастью, ответ на вопрос о моменте завершения «Работы» тривиален: «Работа» не может быть завершена, пока все ее входы не будут активированы. Теперь и нематематику должно быть ясным, что известные условия активации «Работ» на диаграммах нижнего уровня и известные условия окончания «Работ» на верхних уровнях позволяют однозначно восстановить информацию об условиях активации «Работ» на всех уровнях. Иначе говоря, условия активации «Работ» в IDEF0 являются предопределенными.

Рассмотрим теперь один из возможных вариантов конкретизации описания событий в IDEF0.

Моделирование организаций невозможно без учета происходящих в ней причинно-следственных связей или событий. Стандарт IDEF0 в явном виде не позволяет отображать события на схемах, поэтому инструментарий ARIS с возможностью изображать графический примитив «Событие» часто приводит в восторг некоторых разработчиков программных продуктов, вовлеченных по тем или иным причинам в организационное проектирование. У автора существуют серьезные сомнения в необходимости использования примитива «Событие» для целей моделирования событий (но не моделирования событий самого по себе).

Это обусловлено тем, что мы имеет дело не с самими событиями, а с информацией о явлениях, воспринимаемой как событие. Информация о явлении – это информационный ресурс. Бизнес-процессы обмениваются друг с другом только ресурсами и ничем иным, поэтому ясно, что класс «Событие» является вырожденным, и в «жизни» бизнес-процессов существует только один подкласс событий – «Поступление Ресурса», а сами «События» различаются видом ресурса. Например, нормативные документы, которые в соответствии с рекомендациями IDEF0 рассматриваются как «Управление», являются неизнашиваемым информационным ресурсом общего пользования. Другими словами, стрелки на IDEF0-диаграммах соответствуют «Событиям», а включение примитива «Событие» в любой стандарт проектирования бизнес-процессов ничем не оправдано и является избыточным – по крайней мере, если придерживаться ресурсной концепции управления организацией. Этот же вывод распространяется и на объекты, называемые «перекрестками» в стандарте IDEF3.

Итак, сформулируем еще одну установочную концепцию.

1. Исполнение «Работы» безусловно инициируется событием «Поступление Ресурса». Это соответствует классическим представлениям о том, что любое воздействие влечет реакцию. Не бывает воздействий без рефлексии на него. Поэтому поступление любого ресурса является управляющим воздействием.

2. Необходимым (но не достаточным) условием завершения «Работы» является свершение полного набора событий «Поступление Ресурса», связанных с интерфейсами «Работы».

Приведенная установочная концепция делает изобразительные свойства стандарта IDEF0 не только достаточными для описания ситуаций и условий исполнения «Работ» при моделировании организации, но и более выразительными, простыми и эффективными.

Об унификации описания бизнес-процессов

В качестве первой установочной концепции озвучивалась идея о принадлежности «Работ» одному классу объектов, обладающих одинаковым набором свойств и поведением. Для чего это нужно? Прежде всего, для того чтобы различные «Работы» могли общаться друг с другом на одном языке. Только в этом случае бизнес-процесс может быть открытой системой. О необходимости придерживаться идеологии открытых систем при проектировании модели бизнес-процессов как необходимом условии реализации принципа последовательных модернизаций писалось не раз [1, 2]. Только открытым системам свойственен низкий уровень издержек при сопровождении и доработках.

На моделирование бизнес-процессов, согласно методологии IDEF и первым ее интерпретациям, был ориентирован стандарт IDEF3. Основным его отличием от стандарта функционального моделирования IDEF0 была возможность задавать последовательность «Работ» с помощью дуг и условия на последовательность исполнения «Работ» с помощью логики «перекрестков» (синхронные и асинхронные ИИЛИ, исключающее ИЛИ). Предполагалось, что проектировщик, не вдаваясь в описание логики взаимодействия «Работ», разработает функциональную IDEF0-модель до определенного уровня декомпозиции «Работ», а затем на нижних уровнях перейдет на моделирование бизнес-процессов в соответствии со стандартом IDEF3, отображая уже логику взаимодействия «Работ». Поскольку уровень декомпозиции IDEF0-модели, на котором осуществляется переход на стандарт IDEF3, определяется проектировщиком субъективно, то говорить о какой-либо универсальности представлений бизнес-процессов при таком подходе не приходится.

Как было показано, предлагаемая конкретизация положений IDEF0 в части описания событий и, следовательно, логики, не уступает по функциональности стандарту IDEF3. Так, в рамках ресурсной концепции управления организацией дуги в стандарте IDEF0 также могут показывать последовательность исполнения «Работ», а условия исполнения «Работ» задаются событиями «Поступление Ресурса». Возможно, это явилось одной из причин, почему в популярном инструментарии BPwin диаграммы, поддерживающие стандарт IDEF0, называются Business Process Diagram. Одно можно сказать точно: одновременное использование стандартов IDEF0 и IDEF3 в рамках одного проектного процесса никак не способствует однозначному пониманию понятия «бизнес-процесс» в системе стандартов IDEF.

Что такое «Работа», интуитивно ясно. Сложнее обстоит дело с бизнес-процессом, описываемым «Работами». В статье [3] собрано 10 различных определений бизнес-процесса и показано, насколько сложен логико-лингвистический анализ определений бизнес-процесса на смысловую непротиворечивость; там же приводится авторское определение. Для большей наглядности дадим определение бизнес-процесса, используя графическую нотацию IDEF0 и рекомендации по адаптации языка, сформулированные ранее. При разработке общей модели автором использовались установочные концепции, заимствованные из модели взаимодействия открытых систем, методических материалов ассоциаций документарной электросвязи и телекоммуникационного сообщества.

1. На вход бизнес-процесса поступают с выходов процессов-контрагентов ресурсы, которые преобразуются в бизнес-процессе в другие виды ресурсов, поставляемые контрагентам.

2. Все бизнес-процессы в организации объединены одной задачей – оказанием услуг друг другу на основе анализа запросов о поставке услуг. В частности, услугой может быть изготовление и поставка продукта.

3. Оказание услуг друг другу бизнес-процессы осуществляют согласно единой процедуре.

Рис. 2.

На Рис. 2 представлена универсальная IDEF0-модель бизнес-процесса, показывающая сущность интерфейсов «Работы»; как правило, проектировщики бизнес-процессов при их моделировании ее не раскрывают. Особенность этого графического определения – его акцентирование на интерфейсах бизнес-процессов, описываемых в виде отдельных «Работ». Часто осознание необходимости интерфейсов приходит к проектировщику с запозданием, вынуждая его переделывать модель или возлагать функции интерфейсов рассматриваемого бизнес-процесса на его контрагенты. В этом случае желательно «принудительно» создавать сначала промежуточную IDEF0-диаграмму, на которой изображены «Работы»: входные и выходные интерфейсы бизнес-процесса и «Работа», отражающая сущность бизнес-процесса (ею обычно ограничивается неопытный проектировщик). Этого можно не делать только в случае, если проектировщиком осознанно отсутствие необходимости разрабатывать интерфейсы бизнес-процессов. Структура предложенной модели бизнес-процессов соответствует современным представлениям о структуре систем, в том числе и систем управления.

Перечисленные концепции довольно жестко ограничивают множество возможных способов унификации бизнес-процессов. Один из них представляет бизнес-процессы в виде триады «Работ»: «Анализ реакции внешней среды», «Моделирование», «Воздействие на внешнюю среду». Данная идея изложена в [1] и основана на предположении, что организация – это система процессов «рефлексии». Важнейшим элементом является «Моделирование». Выбор этого термина диктуется точкой зрения автора на то, что бизнес-процессы обмениваются друг с другом не объектами «реального» мира, а представлениями о них. Такая точка зрения позволяет адекватно переходить к задаче оценки стоимости услуг или продуктов.

Моделирование – «Работа», отвечающая за непосредственное преобразование поставляемых бизнес-процессом «Ресурсов» и формирование новых «Ресурсов», поставляемых другим бизнес-процессом. Другой важнейшей функцией этой «Работы» является планирование (или программирование) поставок «Ресурсов» другим бизнес-процессом. План поставок строится для рассматриваемого бизнес-процесса с использованием модели его внешней среды (скажем, на основе заявок на поставку ресурсов). Входным интерфейсом бизнес-процесса является «Анализ реакции внешней среды» (т.е. «Работа», обеспечивающая на основе модели внешней среды и правил наблюдения «фильтрацию» поступающих «Ресурсов» и формирование необходимых спецификаций «Ресурсов», требуемых для исполнения «Моделирования»). Выходным интерфейсом бизнес-процесса является «Воздействие на внешнюю среду» (т.е. «Работа», осуществляющая поставку «Ресурсов» контрагентам на основе плана поставок, а также направляющая отчеты о поставках «Моделированию»).

Заключение

Механическое следование требованиям стандарта IDEF0 приводит, как правило, к игнорированию интерфейсов бизнес-процессов или к неполноте их описания. Беда не в том, что большая часть логики бизнес-процессов оказывается упущенной (ее можно восстановить позже), а в том, что логика операций, которые должны принадлежать одному из бизнес-процессов, часто возлагается проектировщиком на другие бизнес-процессы. Тем самым еще больше разрушается структурная однородность и универсальность представления бизнес-процессов. Следствием же является усложнение сопровождения модели на ее жизненном цикле и плохая масштабируемость модели (уникальность, неприспособленность к тиражированию и т.п.). Следование предложенному в статье способу унификации описания бизнес-процессов позволяет избежать подобных неприятностей.

Насколько предложенный подход к унификации описания бизнес-процессов будет полезен конкретному проектировщику, сильно зависит от его личных пристрастий, опыта реализованных проектов и иных обстоятельств. Большое значение имеет и область применения разрабатываемой модели. Так, для описания документооборота возможно, целесообразнее использовать Swim Lane – диаграммы, строящиеся в Bpwin на основе IFEF3-диаграмм, или сразу начинать проектирование с DFD-диаграмм. Предложенные «рецепты» являются выжимками приобретенного автором опыта при разработке процессных моделей нескольких организаций, для которого широта IDEF0 стандарта стала источником проектного «шума». Сущность приведенных рекомендаций выражается в направленном сужении стандартов организационного проектирования с целью «погружения» проектировщика в мир строгих абстракций, предлагаемых системной идеологией и общей теорией управления. Данные рекомендации окажутся полезными директорам информационных служб при постановке задач системным аналитикам и определении требований к стандартам разработки информационных систем.

!!! Полезный материал! Сборник статей по целевому управлению. Скачать >

Литература

1. С. Рубцов, Какой CASE-инструмент нанесет наименьший вред организации? // Директор информационной службы, 2002, – 1.
2. С. Рубцов, Взаимодействие открытых систем – старая концепция для новых идей. // Новые рынки, 2001, – 4.
3. С. Рубцов, Уточнение понятия ‘бизнес-процесс’. Менеджмент в России и за рубежом, 2001, – 6.
4. R. J. Mayer, C. P. Menzel, M. K. Painter, P. S. deWitte, et al. Information Integration For Concurrent Engineering (IICE). IDEF3 Process Description Capture Method Report. – Wright-Patterson Air Force Base, Ohio: Air Force Materiel Command, 1995.
5. National Institute of Standards and Technology. Integration Definition For Function Modeling (IDEF0). – Washington: Draft Federal Information, 1993.

Автор: Сергей Рубцов

Функциональные модели (алгоритмы) описания бизнес-процессов. Преимущества и недостатки

---

---

Вычисление основной дактилоскопической формулы Вычислением основной дактоформулы обычно занимается следователь. Для этого все десять пальцев разбиваются на пять пар…

Расчетные и графические задания Равновесный объем — это объем, определяемый равенством спроса и предложения…

Кардиналистский и ординалистский подходы Кардиналистский (количественный подход) к анализу полезности основан на представлении о возможности измерения различных благ в условных единицах полезности…

Обзор компонентов Multisim Компоненты – это основа любой схемы, это все элементы, из которых она состоит. Multisim оперирует с двумя категориями…

Измерение следующих дефектов: ползун, выщербина, неравномерный прокат, равномерный прокат, кольцевая выработка, откол обода колеса, тонкий гребень, протёртость средней части оси Величину проката определяют с помощью вертикального движка 2 сухаря 3 шаблона 1 по кругу катания… Неисправности автосцепки, с которыми запрещается постановка вагонов в поезд. Причины саморасцепов ЗАПРЕЩАЕТСЯ: постановка в поезда и следование в них вагонов, у которых автосцепное устройство имеет хотя бы одну из следующих неисправностей: — трещину в корпусе автосцепки, излом деталей механизма… Понятие метода в психологии. Классификация методов психологии и их характеристика Метод – это путь, способ познания, посредством которого познается предмет науки (С…

Иллюстрация: Andrea Piacquadio / Pexels / Colowgee для Skillbox Media

Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.

Дипломированный специалист по автоматизации бизнес-процессов. Девять лет опыта в бизнесе и консалтинге. Смоделировал более тысячи процессов для торговых и промышленных предприятий. Основатель OkoCRM.

---

Фото: личный архив Александра Завьялова

Ни один процесс нельзя улучшить, предварительно не описав его. Это касается не только бизнес-процессов больших компаний, но и алгоритмов работы ИП или самозанятых. Прежде чем оптимизировать бизнес-процессы, важно зафиксировать, как они работают, — то есть смоделировать.

О базовых терминах и идеях в области бизнес-процессов мы рассказали в большом гайде. В этой статье разберём подробнее:

• что такое моделирование бизнес-процессов и нотации для моделирования;
• какие есть подходы к моделированию и кто этим обычно занимается;
• как изображают бизнес-процессы;
• как самостоятельно описать бизнес-процессы.

---

Бизнес-процессы — любые операции внутри компании, которые помогают решать бизнес-задачи и зарабатывать. Моделирование бизнес-процессов — описание этих операций и документирование требований к ним.

Ответственные за моделирование разбираются в процессах компании и описывают, кто, что и как делает. Изучают каждую операцию и разбивают её на этапы. Сначала описывают всё это текстом, затем превращают описание в схему.

В профессиональном моделировании бизнес-процессов часто используют нотации. Нотация — это набор правил для графического описания бизнес-моделей. Нотации описывают:

• какие иконки использовать в моделировании и как их читать;
• как отображать последовательность действий в процессе и отношения внутри него;
• какие элементы обязательно нужно включить.

Нотации нужны для того, чтобы любой человек понимал, что изображено на схеме. Даже если пользователь видит её впервые, он должен разобраться.

Специалисты придумали много вариантов нотаций. Их делят на две основные категории:

• Структурные. Они показывают элементы процесса и взаимосвязи между ними. Это нотации стандарта IDEF: IDEF0, IDEF1x, IDEF4, IDEF5.
• Динамические. Они показывают логику выполнения процессов, последовательность и варианты их использования. Это нотации DFD, EPC, BPMN.

Ниже, когда мы будем говорить о подходах к моделированию, расскажем о двух вариантах нотаций — IDEF0 и BPMN.

С получившейся моделью бизнес-процесса работают дальше. Двигают элементы так, чтобы корректировать продолжительность цикла, влиять на качество результата или снижать себестоимость. Это называется оптимизацией бизнес-процесса — подробнее о ней говорили в статье. Но прежде чем оптимизировать и улучшать, важно провести качественное моделирование.

В моделировании бизнес-процессов есть три основных подхода: функциональный, процессный и ментальный. В следующих разделах разберём их подробнее.

Иногда можно встретить и другие подходы, но обычно это гибридные решения, собранные из основных. Каждый из трёх подходов предполагает, что процессы нужно визуализировать — рисовать их в виде схем. Различия подходов — в принципах визуализации.

При этом подходе описывают результаты, которые нужно получить, и ресурсы, которые при этом будут задействованы, без учёта последовательности действий.

У модели есть точки входа и выхода: то, что имеем на старте, и то, что хотим получить. Внутри — промежуточные результаты, ресурсы и факторы, которые влияют на процесс.

Задача функционального подхода — показать, какие факторы нужно учесть и какие ресурсы задействовать, чтобы процесс состоялся. Подробного описания действий в этом случае не будет, но появится общее представление о процессе.

Я использую этот подход, чтобы оценить результативность бизнес-процесса, а также для того, чтобы показать свои идеи и варианты решений: от общего к деталям.

На мой взгляд, функциональный подход понятнее всего реализован в нотации IDEF0. Она рассматривает процесс как совокупность логически связанных между собой работ. Нотация показывает, как объекты подчинены друг другу внутри процесса.

Разберём на примере. Пусть это будет изготовление рекламного ролика.

Процесс изготовления рекламного ролика — основной блок с процессами. Я называю его «чёрный ящик». У него есть три входа и один выход:

1. Сверху — вход для информации о контроле и ограничениях. Это данные, которые определяют условия для реализации процесса. Например, при разработке ролика нас будет ограничивать законодательство и стайлбук заказчика. А ещё мы будем опираться на перечень услуг клиента — чтобы в рекламе были корректные данные.

2. Слева — вход для основной информации. На её основе будет создан результат. В примере с роликом, чтобы получить эту информацию, для заказчика проводят брифинг.

О том, как составить бриф для клиента в рекламе и digital, писали в статье.

3. Снизу — вход для механизма, который будет осуществлять функцию. В примере с роликом это CRM, где хранятся данные о заказчике, и сотрудники телеканала, которые будут снимать ролик.

4. Справа — выходы. Это результаты, которые мы получим: заключим договор, снимем ролик и предложим сотрудничать на постоянной основе.

Вот как функция будет выглядеть в виде диаграммы.

В итоге из нескольких таких диаграмм можно собрать одну большую. Важно соблюдать правила расположения данных — сверху, слева и снизу, — чтобы связи между ними сохранялись.

Для неподготовленного управленца это самый понятный подход. Его используют, когда уже определены границы процесса — начало и конец события.

При процессном подходе описывают не результат, а действия, которые необходимо совершить для достижения результата. Процесс можно детализировать сколько угодно — вплоть до операций каждого сотрудника. Получается блок-схема.

Я сторонник процессного подхода. В результате него получаются более прикладные модели, которые понятны и руководителю компании, и исполнителям. Функциональный же подход больше полезен для общего проектирования процессов — и далёк от их практической реализации.

Например, в функциональном подходе «Обработка заявки» — только один из элементов входа. В центре внимания — результат, то есть заключение сделки. В процессном подходе «Обработка заявки» — большой алгоритм. Он подробно описывает действия всей команды.

У процессного подхода есть свои нотации. Стандартом считается BPMN — базовый набор условных обозначений. Его используют для изображения бизнес-процесса в виде блок-схемы.

Нотация BPMN есть в каждом конструкторе для моделирования, но пользоваться ей не обязательно. Гораздо важнее, чтобы схема процесса была читаемой и понятной для руководителя и исполнителей.

Для примера нарисовали блок-схему обработки заявки в учебном центре. Она не соответствует канонам BPMN, но всё равно наглядна и понятна.

Это вариант моделирования «для себя». Его используют, чтобы структурировать общие представления о бизнес-процессе, но не раскладывать его на этапы и не составлять алгоритмов.

При ментальном подходе на процесс смотрят не как на последовательность результатов или действий, а как на набор связанных друг с другом понятий. Обычно их собирают на интеллект-карте: в центре «чёрный ящик» с процессом, на орбите — связанные с ним идеи и элементы. Жёстких рамок и нотаций нет — карты рисуют в произвольной форме.

Такая визуализация помогает найти решение, как сделать процесс эффективнее. Дальше это решение воплощают на основе процессного подхода: забирают в основную модель главные элементы, а ненужные отбрасывают.

Ниже дан пример ментальной карты процесса снабжения предприятия. На карте собраны понятия, которые связаны между собой внутри процесса. Но по этапам они не распределены.

Обычно моделированием бизнес-процессов занимаются внутренние сотрудники компании или подрядчики. Выбор исполнителя зависит от размеров бизнеса и целей моделирования.

Например, если нужно построить воронку продаж для CRM и при этом нет цели улучшать процессы, можно строить модель можно своими силами. Когда цель моделирования в том, чтобы оптимизировать процессы, лучше обратиться к аналитикам. Для оптимизации нужно глубоко разобраться в процессах и ещё и думать над тем, как их доработать. Потребуется опыт и знание инструментов.

Рассмотрим, кто может заниматься моделированием процессов.

Собственник и сотрудники. В небольших компаниях лучше, чтобы процессы моделировал собственник: он знает свой бизнес и сможет подробно его описать. Самих процессов в таких компаниях немного, а сложная детализация обычно не нужна.

В компаниях покрупнее собственнику лучше привлекать к моделированию помощников: собрать команду из руководителей отделов и проработать основные процессы вместе. Например, процессы в отделе продаж лучше разбирать со старшим менеджером, а процессы в цехе — с главным инженером.

Подрядчики. В среднем и крупном бизнесе моделировать бизнес-процессы внутренними силами точно не получится — количество и объём всех процессов уже не укладываются в голове собственника.

В этом случае моделированием занимается экспертная группа. В неё входят приглашённые бизнес-аналитики и специалисты, участвующие в моделируемых процессах.

Моделирование как отдельную услугу заказывают редко. Чаще это один из этапов внедрения систем автоматизации — CRM, ECM или ERP. Это работает по такой схеме:

• Команда внедрения — подрядчик — приходит на территорию заказчика.
• Она описывает процессы, проводит аудит и составляет аналитический отчёт с вариантами оптимизации.
• Заказчик утверждает отчёт.
• Подрядчик внедряет систему автоматизации с уже оптимизированными процессами.

Чаще всего бизнес-процессы моделируют графически, в виде карт и схем, как мы показывали выше. Иногда описывают текстом — в виде пошаговой инструкции с уточнениями, кто и что делает. Также используют таблицы: в строках пишут действия, а в столбцах — исполнителей и этапы.

На мой взгляд, графическое моделирование — наиболее удобное и наглядное. Изобразить бизнес-процессы можно двумя способами: в специальных программах для моделирования и в обычных графических редакторах.

В специальных программах. Это способ для профессионалов в моделировании.

Специальный софт удобен тем, что шаблоны нотаций уже вшиты в него, — не нужно изучать правила иллюстрирования дополнительно. Но придётся разбираться в функциональности программ.

Вот четыре конструктора, которые я использовал в своей практике для моделирования процессов:

• Microsoft Visio 2010 — векторный графический редактор для создания разных видов схем: блок-схем, схем технологических процессов, моделей бизнес-процессов, планов зданий и этажей, трёхмерных карт и так далее. Платный.
• Bizagi Process Modeler — программа для моделирования процессов по нотации BPMN с возможностью совместной работы. Бесплатная.
• ARIS Express — программа для моделирования бизнес-процессов и оргструктуры с нотациями eEPC или BPMN. Бесплатная.
• Business Studio — система, в которой можно описать, оптимизировать и регламентировать бизнес-процессы предприятия. Платная.

Как правило, у всех платных конструкторов есть демоверсии, которых хватает, чтобы смоделировать простой процесс. Но повторюсь, специальное ПО — вариант для профессионалов. Не нужно тратить на него время, если вы не планируете моделировать бизнес-процессы постоянно.

В графических редакторах. Этот способ подойдёт для новичков, которые только знакомятся с моделированием бизнес-процессов. Проще всего взять обычный графический редактор — например, Microsoft Paint, Figma или Adobe Photoshop — и самостоятельно нарисовать интуитивно понятную схему процесса.

Также для изображения бизнес-процессов используют сервисы для создания ментальных карт. На мой взгляд, самые удачные из них — XMind, Diagrams и MindManager.

При выборе сервиса главное, чтобы пользователю было удобно пользоваться им и чтобы было понятно, что получается в итоге. Стандартизация и каноны при этом не так важны. На первых порах для внутреннего использования этот вариант самый доступный.

Покажем, как описать и смоделировать бизнес-процесс, на примере обработки заявки учебного центра. Использовать конструкторы не будем — все модели из примера построим в графическом редакторе.

1. Задаём точки входа и выхода. Вход — первое событие в процессе, выход — результат. Так обозначают границы, чтобы потом наполнить процесс действиями. Нужно определить:

• Когда начинается процесс. В нашем примере это момент получения заявки от клиента. Если компания использует CRM, точкой входа будет попадание заявки в систему.
• Когда процесс закончится. Это момент успешной реализации сделки: клиент оплатил счёт, а продавец и логист организовали доставку.

Можно придумать несколько вариантов точек входа и выхода — для разных вариантов развития события.

2. Описываем элементы. При составлении схемы перед глазами нужно держать основную информацию о процессе, чтобы ничего не забыть. Для этого в любом файле подробно описываем:

• зачем нужен процесс;
• из каких шагов и действий он состоит;
• кто исполнители;
• есть ли ограничения по срокам — сколько времени должен занимать весь процесс и его отдельные шаги;
• какие события сопровождают действия исполнителей — например, обмен документами, информацией, денежные переводы;
• какого результата нужно достичь — например, нужны подготовленные документы или оплата по счёту;
• перечень ресурсов — что исполнителю нужно для реализации процесса;
• показатели эффективности — по каким параметрам отслеживать, достигнута цель процесса или нет;
• детали и особенности отдельных этапов.

Здесь лежит шаблон текстового описания процесса.

3. Выделяем основные этапы процесса. На основе описанного в предыдущем пункте процесса составляем блок-схему. В графическом редакторе рисуем каркас — основные этапы в пределах границ входа и выхода.

4. Добавляем детали. Наполняем каркас «мясом» — основными событиями по процессу и действиями исполнителя по алгоритму.

5. Задаём роли. В процессе может быть несколько исполнительских ролей. Их может выполнять один или несколько сотрудников. Обычно роли обезличены, без уточнения фамилий, — только должности.

6. Наполняем схему ресурсами. Отмечаем на схеме источники ресурсов, которые будут использовать в бизнес-процессе. Например, какие документы кто кому и на каком этапе отправит, какие базы и системы для этого будет использовать.

В нашей «ручной» схеме — это просто дополнительные элементы в алгоритме. Если для моделирования используется специальный софт, к схеме можно прикрепить ссылки.

Блок-схема готова. Если таких схем несколько, их процессы можно связать друг с другом на одной карте.

Схемы и алгоритмы нужны, чтобы сделать процессы эффективнее и полезнее для бизнеса. Кроме этого, с готовыми моделями бизнес-процессов проще проводить автоматизацию. Об автоматизации бизнес-процессов расскажем в следующей статье.

• Бизнес-процессы — любые операции внутри компании, которые помогают решать бизнес-задачи и зарабатывать. Моделирование бизнес-процессов — описание существующих в компании процессов и документирование требований к ним.
• В моделировании бизнес-процессов есть три основных подхода: функциональный, процессный и ментальный. Самый понятный подход для неподготовленного человека — процессный. Он даёт подробный алгоритм действий для сотрудников и глубокую детализацию операций.
• Моделировать процессы можно своими силами — если бизнес небольшой и несложный. Если в дальнейшем нужно оптимизировать процессы, лучше привлечь консультантов.
• Бизнес-процессы обычно описывают графически — в виде карт и интуитивно понятных схем. Так с ними проще работать.
• Смоделировать процесс можно самому: разобрать внутреннюю кухню компании, описать в тексте все алгоритмы и на основе этого построить схему в графическом редакторе.

Другие материалы Skillbox Media для менеджеров

Эффективный руководитель

Вы научитесь разрабатывать стратегию, ставить цели, создавать бизнес‑процессы и комфортный климат в команде. Найдёте точки роста в своей компании, сможете претендовать на повышение или масштабировать бизнес.

Узнать про курс

SADT
—
методология
(Structured
Analysis
and
Design
Technics)
получила столь ши­рокое распространение
благодаря тому, что ориентирована на
комплексное представление структуры
материальных, информационных, финансовых
и управленческих потоков, ото­бражение
организационной структуры [3]. В силу
этого, SADT
— методология в большей сте­пени
нацелена на реорганизацию всей системы
управления, чем другие методологии
функционального моделирования, основанные
на использовании диаграмм потоков
дан­ных, главная цель которых
проектирование информационных процессов.

Функциональная
модель бизнес-процессов состоит из
диаграмм, фрагментов тек­стов и
глоссария, имеющих ссылки друг на друга.
Диаграммы — главные компоненты мо­дели,
которые отображают последовательности
взаимосвязанных через общие объекты
функций (операций, действий, работ —
activity)
бизнес-процесса.

Достоинство
функциональной модели заключается в
графической простоте, в ко­торой
используются всего два конструктивных
элемента:

• функциональный блок — описание функции,
  операции, действия, работы;

• интерфейсная дуга, связывающая
  два функциональных блока — описание
  объекта, потока
  объектов.

Функциональная
модель начинается с построения общего
описания процесса, ко­торое
представляется в диаграмме нулевого
уровня или контекстной диаграмме
(рис. 3.).
На
этом уровне весь процесс рассматривается
как один функциональный блок со всеми
связанными обрабатываемыми и управляющими
объектами. На этой диаграмме также
отражается
цель структурного анализа (например,
сокращение длительности выполнения
процесса,
или сокращение издержек, или повышение
качества обслуживания и т.д.) и точка
зрения, с позиции которой рассматривается
модель (дирекция, отдел информатиза­ции,
экономический отдел и т.д.).

Рис.3. Контекстная диаграмма

Диаграммы
следующих уровней детализируют функции
процесса каждого преды­дущего
уровня (рис. 4.). Так, функциональный блок
А0 декомпозируется на совокуп­ность
взаимосвязанных подфункций Al,
А2, A3, …. В свою очередь, каждый
функцио­нальный
блок 1-го уровня может быть декомпозирован
на совокупность подфункций, на­пример
А2 на А21, А22, А23, А24 … и так дальше, пока
на последнем уровне не получатся
элементарные действия. На каждом уровне
рекомендуется размещать не более 6
функцио­нальных блоков. Число уровней
декомпозиции не ограниченно. Обычно
для структурного анализа
бизнес-процессов достаточно 2-3
уровней декомпозиции, последующие
уровни декомпозиции
требуются для алгоритмизации информационных
процессов и разработки инструкций для
исполнителей бизнес-процессов.

Рис.4. Декомпозиция функции А0

Для
каждого функционального блока определяются
интерфейсные
дуги
различных
типов
(стрелки), которые отражают потоки
объектов.
Объекты
могут быть различной природы: материальные,
финансовые, информационные. По характеру
использования объектов в функциональных
блоках различают: входные (input)
объекты слева от блока, выходные
(output)
объекты справа от блока, управляющие
(control)
объекты сверху от блока
и механизмы (mechanize)
снизу от блока. Объекты
обозначаются метками на стрел­ках,
которые обязательны.

Входные
объекты преобразуются
в функциональных блоках в выходные. При
этом выходной
объект
—
это новый созданный объект или
преобразованный старый объект. В
последнем случае новое качество объекта,
как правило, обозначается прилагательным,
например,
принятый заказ, отложенный заказ,
удаленный заказ, выполненный заказ и
т.д.

Управляющие
объекты
соответствуют
нормативным актам (законодательным
ак­там, инструкциям, планам, приказам),
на основе которых выполняются процессы.
Кроме того,
управляющие объекты рассматриваются
как ограничения, обстоятельства, условия
вы­полнения
процесса, например номенклатуры-ценники,
списки клиентов и поставщиков, со­стояние
запасов, состояние расчетного счета,
наличие производственных мощностей и
т.д.

Управляющие
объекты должны обязательно отражаться
в функциональной модели, а
входные объекты не обязательно.
В последнем случае какой-либо управляющий
объект одновременно
является и входным, например, заказ, на
основе которого выполняется ра­бота,
преобразуется внутри функционального
блока в готовый продукт.

Механизмы
—
это объекты, которые исполняют процессы
(исполнители). К меха­низмам
относят структурные подразделения
предприятия, персонал, автоматизированные
рабочие места, оборудование.

Объекты
могут выступать в различных блоках в
разных ролях, например, когда выходной
объект одного блока является входным
объектом, или управляющим объектом, или
механизмом для другого функционального
блока. Объекты, которые выступают толь­ко
в одной роли, обозначаются метками, с
которыми связаны пограничные дуги. При
этом объекты,
передаваемые в детальную диаграмму из
вышестоящих диаграмм, обозначаются
ICOM
метками :

I1,I2,I3,
….
— входные объекты;

01, 02, 03, … — выходные объекты;

Cl,
C2,
СЗ, ….
— управляющие объекты;

М1,М2, МЗ, ….- механизмы.

Объекты,
с которыми связаны пограничные дуги,
могут быть локальными на данном уровне
диаграммы. Такие объекты связываются
с функциональными блоками внешними
тун­нельными
дугами, имеющими скобки на внешней
стороне стрелки от блока.

Объекты,
которые используются во всех функциональных
блоках на детальной диаграмме, обозначаются
внутренними туннельными дугами, имеющими
скоб­ки на внутренней от блока стороне
стрелки, и не передаются в качестве ICOM
— метки на детальный
уровень.