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

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.

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

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