Интегрированная модель бизнес-процессов

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

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

Модели и перспективы

Ряд исследований предлагают рассматривать модель бизнес-процесса как согласованное представление нескольких перспектив [1]. Архитектура CIMOSA выделяет четыре перспективы: функциональную, информационную, ресурсную, организационную [2]. Модель Захмана включает шесть перспектив, а интегрированная модель информационных систем ARIS оперирует четырьмя, причем три (информационная, организационная и функциональная) рассматриваются как основные, а выбор четвертой перспективы определяется целью моделирования. Для описания информационной системы используется ресурсное представление, а для моделирования бизнеса примеряется перспектива управления [3]. Будем придерживаться формулировки, предложенной Кертисом, — модель бизнес-процесса включает четыре перспективы [4]:

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

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

Функциональная перспектива

Функциональная модель — это каталог функций, иерархически организованный справочник работ, в котором перечислены все действия, выполняемые субъектами [5]. Считается, что, имея «полный» набор функций, можно скомпоновать ИТ-систему, применяя повторно используемые компоненты. Функциональная модель лежит в основе справочных (референтных) моделей, которые строятся путем функциональной композиции, поскольку этот способ является наиболее естественным для анализа системы.

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

Аспекты поведенческой перспективы

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

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

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

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

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

Аспекты организационной перспективы

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

Рассмотрим отдельные аспекты организационной перспективы.

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

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

Поскольку роль есть способ группировки участников процесса, следует рассмотреть виды департаментализации сотрудников с точки зрения теории менеджмента. Структура организации определяется как совокупность способов, посредством которых процесс труда разделяется на отдельные рабочие задачи и осуществляется координация действий по решению этих задач [7]. Для разделения работы на задание используется структурирование сотрудников, например группирование по рабочим процессам позволяет отобрать всех исполнителей, участвующих в конкретном процессе. Здесь может возникнуть путаница, связанная с группировкой по функциям. Дело в том, что в функционально ориентированной компании группировка по функциям используется для структурирования организационных подразделений, что дает аналитикам повод привязывать функцию к организационной единице или трактовать ее как должность. Однако в процессной компании работа осуществляется кросс-функционально, пересекая границы подразделений и должностей — например, работник и его руководитель могут выполнять одну работу, соответственно, располагаются в одной роли, хотя работают в разных должностях. Поэтому группировка по функциям должна рассматриваться как один из способов объединения участников, которым поручено исполнение определенной работы. Для различения работников и их руководителей следует использовать критерий группировки по лимиту ответственности.

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

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

Аспект назначения исполнителя. После того как потенциальные исполнители задания отобраны, следует выбрать одного актуального исполнителя, которому и будет поручена работа. Для этого обычно используются следующие стратегии:

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

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

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

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

Информационная перспектива

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

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

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

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

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

Интегрированная модель бизнес-процесса

Рис. 1. Связь перспектив в модели ARIS

В интегрированной модели ARIS связь отдельных перспектив реализуется через сущность «функция» (рис. 1). Под функцией понимается работа, выполняемая субъектом (человеком или структурным подразделением) над объектом. Если моделируется производственный процесс, то объектом называется изделие, а если бизнес-процесс — то информационный объект. Функция преобразует объект, меняет его состояние, что фиксируется в событии. Таким образом, функция является связующим звеном между организационной моделью (описывает субъектов действия) и моделью данных (описывает объект труда). Ресурсы — индивидуальный исполнитель, должность или организационная единица — привязываются к функции, это обозначает, что они могут выступить в качестве исполнителя этой функции. В свою очередь, к функции привязывается документ или объект данных, это означает, что данный объект изменяется соответствующей функцией. Такой способ связи имеет ряд недостатков — в частности, отображая индивидуального исполнителя или должность на функцию, мы привязываем модель к конкретному предприятию. Поскольку права доступа ресурса к объекту отображаются через функцию, то все субъекты, имеющие право выполнить функцию, получают одинаковый доступ к данным, которыми оперирует эта функция.

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

Рис. 2. Связь между перспективами интегрированной модели

***

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

Литература

1. Axenath B., Kindler E., Rubin V. The Aspects of Business Processes; Technical Report tr-ri-05-256, Computer Science Department of the University of Paderborn, April 2005.
2. Vernadat F. Enterprise Integration: On Business Process and Enterprise Activity Modeling. In: Concurrent Engineering: Research and Applications, 1996.
3. Scheer A.W. Architecture of integrated Information Systems. 1992.
4. Curtis B., Kellner M., Over J. Process Modeling. 1992.
5. Owen J. Business Function Modelling eBook. Integrated Modelling Method. http://integrated-modeling-method.com/imm-bpm-business-process-modeling-store/business-function-modeling-ebook.
6. Тельнов Ю.Ф., Федоров И.Г.: Системный анализ справочных моделей бизнес-процессов; Экономика, статистика, информатика. Вестник УМО, 2, 2012.
7. Минцберг Г. Структура в кулаке: создание эффективной организации, 2004.
    

Игорь Федоров (IFedorov@mesi.ru) — профессор Московского государственного университета экономики, статистики и информатики (Москва).