Методология ARIS. Описание нотаций ARIS

бизнес модель нотация

Нотация ARIS eEPC

Нотация ARIS eEPC расшифровывается следующим образом: extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В табл. 1 приводятся основные используемые в рамках нотации объекты.

Таблица 1. Объекты нотации eEPC

Наименование	Описание	Графическое представление
	Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия
	Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций
Организационная единица	Объект, отражающий различные организационные звенья предприятия (например, управление или отдел)
Документ	Объект, отражающий реальные носители информации, например бумажный документ
Прикладная система	Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции
Кластер информации	Объект характеризует данные как набор сущностей и связей между ними. Используется для создания моделей данных
Стрелка связи между объектами	Объект описывает тип отношений между другими объектами, например активацию выполнения функции некоторым событием
Логическое «И»
Логическое «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
Логическое исключающее «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса

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

Рис. 1.

На рис. 1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:

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

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

На рис. 2 показано применение различных объектов ARIS при создании модели бизнес-процесса.

Рис. 2.

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

Из рис. 1 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC не может быть отражена визуально. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено одновременное выполнение двух задач. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе Microsoft Project.

Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Примеры моделей, сформированных с использованием ARIS eEPC, показаны на рис. 3 и 4.

Рис. 3.

Рис. 4. Описание процесса анализа и согласования заявки клиента

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

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

Функции в модели ARIS EPC запускаются событиями, например, «Счет поступил на согласование», и событиями оканчиваются, например, «Счет согласован» или «Счет не согласован». Если в результате исполнения функции имеется только один вариант дальнейшего выполнения бизнес-процесса, т.е. в результате формируется только одно событие, после которого идет следующая функция, событие между этими функциями может не рисоваться.

Модель бизнес-процесса нотации ARIS EPC обязательно начинается и заканчивается одним, или несколькими событиями или интерфейсами в другие модели бизнес-процессов. Для отражения интерфейсов используются специальные объекты «Интерфейс процесса» — тип объекта «Функция».

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

Модель EPC не может быть несвязной, т.е. расположение на модели, одного объекта, не связанного с остальными, является ошибкой.

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

На модели ARIS EPC указывается следующая информация:

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

Правила именования события в ARIS EPC

Имя события (Event) должно содержать существительное и описание изменения состояния в виде отглагольной формы. Пример: «Сделка исполнена».

Правила именования функции в ARIS EPC

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

Правила именования роли/должности в ARIS EPC

Наименование бизнес-роли (Person Type) должно соответствовать сути возлагаемых на исполнителя обязанностей. Как правило, наименование содержит фразу «Ответственный за …». Наименования должностей (Position) пишутся в соответствии со штатным расписанием.

Правила именования документов

Объект соответствует документу (Information Carrier) (в бумажном и/ или электронном виде). Для наименования документов (независимо от используемого символа) необходимо использовать их реальное название.

Правила именования информационных систем в ARIS EPC

Для наименования информационных систем (Application system type) следует использовать их устоявшиеся названия.

Правила именования интерфейса процесса

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

На рис. 2.30 представлена одна из важнейших нотаций ARIS - нотация ARIS VAD. Диаграмма цепочки процесса, добавляющего ценность, используется при описании бизнес-процессов организации на верхнем уровне. Как правило, консультанты, использующие ARIS, рекомендуют выделять шесть-восемь бизнес-процессов верхнего уровня и описывать их в нотации ARIS VAD. Затем выполняется декомпозиция полученных процессов верхнего уровня в нотации ARIS VAD или ARIS еЕРС. Рассмотрим объекты нотации ARIS VAD, представленные на рис. 2.30.

Основным объектом нотации ARIS VAD является Value-added chain - процесс или некоторая группа функций организации, которая служит для получения добавленной ценности. Объекты соединяются между собой пунктирной стрелкой, которая имеет тип is predecessor of («является предшественником»). Этот тип связи показывает, что один процесс - предшественник другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные связи. Поэтому термин is predecessor of, на наш взгляд, является неудачным.

Между процессами, приведенными на рис. 2.30, могут быть отображены потоки материальных ресурсов и информации, для описания которых можно воспользоваться объектами типа Cluster и Technical term, соответственно. Для описания инфраструктуры, необходимой для выполнения процесса, в данном примере выбраны типы объектов Product/Service и Information service. Выбор типов объектов для отображения реальных потоков является в достаточной степени условным. Очень важно в начале работ по моделированию процессов определиться, какие именно типы объектов будут использованы и какие объекты реального мира они будут отображать. Так, в случае примера, приведенного на рис. 2.30, можно было бы показать все потоки (информационные и материальные) при помощи объектов типа Technical term.

На рис. 2.30 показаны также объекты Organizational unit, отображающие подразделения, выполняющие соответствующие процессы.

Объекты соединяются между собой при помощи связей определенного типа (см. рис. 2.30). Например, информационный поток, отображаемый объектом Cluster, является входящим для первого процесса и связан с ним при помощи стрелки типа is input for («является входом для»). Другой пример - тип связи executes («исполняет») между объектами Value-added chain и Organizational unit. Тип связи is used by показывает, что Product/Service используется процессом и т.д. Таким образом, в методологии ARIS важнейшим требованием является корректный выбор и дальнейшее использование связей и объектов определенного типа.

На рис. 2.31 представлен пример модели верхнего уровня, выполненный в нотации ARIS VAD. Вы уже знакомы с этим процессов. Выше, на рис. 2.16, этот же процесс представлен в нотации IDEF0.

88____________________________ ВВ. Репин, В.Г. Елиферов

Глава 2 Выбор методологии описания бизнес-процессов________________________________ 89

Принципы построения диаграммы процесса верхнего уровня в нотации ARIS VAD существенно отличаются от нотации IDEF0. Так. в нотации ARIS VAD стрелки могут входить в любую сторону объекта Value-added chain. (Напомним, что в нотации IDEF0 каждая сторона объекта Activity (функция) имеет глубоки и смысл). На рис. 2.32 представлена ситуация, возможная в нотации ARIS VAD. когда на диаграмме процесса приводится множество обратных связей, которые понятны только аналитику, создавшему модель.

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

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

90 В.В. Репин, В.Г. Елиферов. Процессный подход к управлению

2.7.2. Нотация ARIS еЕРС - расширение нотации IDEF3

Нотация ARIS еЕРС (extended Event Driven Process Chain) - расширенная цепочка процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG, Германия, в частности, профессором Шеером. В табл. 2.2 приводятся основные объекты, используемые в рамках нотации.

Таблица 2,2 Основные объекты, используемые при построении диаграмм еЕРС

Помимо основных объектов, указанных в табл. 2.2, при построении диаграммы еЕРС могут быть использованы многие другие объекты. На практике применение большого числа объектов различных типов нецелесообразно, так как это значительно увеличивает размер модели и затрудняет ее прочтение.

Глава 2 Выбор методологии описания бизнес-процессов 91

Для понимания смысла нотации ARJS сЕРС рассмотрим основные используемые типы объектов и связей (рис. 2.34-2.38). На рис. 2.34 представлена простейшая модель ARIS еЕРС, описывающая фрагмент бизнес-процесса предприятия.

Из рис. 2.34 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» (activates) или инициирует выполнение Функции 1. Функция 1 «создает» (creates) Событие 2, за которым следует символ логического оператора «И», «запускающий» выполнение Функций 2 и 3.

Внимательный анализ нотации ARIS еЕРС показывает, что она практически не отличается от нотации IDEF3. Важнейшим отличием ARIS еЕРС является наличие объекта «событие» (event). Этот объект служит для отображения в модели возможных результатов выполнения функций, в зависимости от которых выполняется та или иная последующая ветвь процесса. Нотация ARIS еЕРС называется, очевидно, расширенной именно вследствие наличия в ней объекта «событие» (в IDEF3 такого объекта нет). На рис. 2.35 приводятся примеры применения символов логики и событий при построении моделей в нотации ARIS еЕРС.

При построении моделей в ARIS еЕРС необходимо соблюдать следующие правила:

1. Каждая функция должна быть инициирована событием и завершаться
событием;

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

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

На рис. 2.36 показано применение различных объектов нотации ARIS еЕРС при создании модели бизнес-процесса.

92____________________________ ВВ. Репин, В.Г. Елиферов. Процессный подход к управлению

Из рис. 2.35 и 2.36 видно, что бизнес-процесс в нотации ARIS еЕРС представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в ARIS еЕРС визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено вы-

Глава 2 Выбор методологии описания бизнес-процессов___________________________________ 93

полнение двух задач одновременно. Используемые при построении модели СИМ-ЮЛЫ логики позволяют отразить ветачение и слияние бизнес-процесса. Для получения информации о реальной длительности процессов и визуального отображения загруженности персонала в процессе можно использовать другие инструменты описания, например диаграммы Гантта в системе MS Project.

Рассмотрим примеры применения нотации ARIS еЕРС для описания бизнес-процессов. На рис. 2.37. представлен бизнес-процесс обработки заказа клиента. Этот же процесс изображен в нотации IDEF3 на рис. 2.23.

Процесс начинается с события «Поступил заказ клиента». Это событие инициирует функцию «Выполнить учет заказа в системе», которую выполняет менеджер Отдела сбыта. Для выполнения работы он использует «Систему учета заказов». Результат выполнения функции отображается событием «Учет заказа выполнен». После этого менеджер Отдела сбыта выполняет функцию «Выполнить анализ на соответствие номенклатуре». Результатом выполнения функции являются два альтернативных события «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического оператора - исключающее «ИЛИ».

Функция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: 1) заказ не соответствует номенклатуре и 2) производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического оператора «ИЛИ» и т.д.

Как видно из рис. 2.37, схема процесса в ARIS еЕРС отличается от схемы в IDEF3 наличием объектов: событий, документов, прикладных систем и должностей. Схема в ARIS eEPS визуально предстаатяется более информативной и воспринимается лучше, однако размер этой схемы существенно превышает размер схемы в IDEF3.

Рассмотренный выше процесс может быть представлен также в нотации ARIS PCD (Process Chain Diagram) - разновидности ARIS еЕРС. На рис. 2.38 показан бизнес-процесс обработки заявки клиента в нотации ARIS PCD. При описании этого процесса использованы все объекты, которые составляют процесс, показанный на рис. 2.37, но расположены они в виде столбцов таблицы. В первом столбце представлены события и некоторые символы логики, во втором - функции, в третьем - входящие и исходящие документы, в четвертом - виды прикладного программного обеспечения, в пятом - должности сотрудников, задействованных в процессе. Такое представление процесса является более «стандартным». Оно лучше подходит для целей документирования процессов. Однако представление в нотации ARIS PCD обладает существенным недостатком - его можно эффективно применять для простых (не более пяти-восьми функций), желательно линейных, процессов. Сложные процессы с разветвленной логикой отображать при помощи нотаций ARIS PCD неудобно, что наглядно видно на рис. 2.38.

94_________________________________ ВВ. Репин. В.Г. Елиферов. Процессный подход к управлению

Рис. 2.37. Пример модели процесса

Типовые задачи описания бизнес-процессов

Требования к описанию бизнес-процессов предприятий

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

какое программное обеспечение использовать в проекте (“ARIS лучше BPWin”, “ERWin лучше ARIS” и т.п.);
как моделировать процессы с использованием продукта?
как проводить анализ и выявлять проблемы при помощи продукта?
какую методологию использовать для описания процессов?

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

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

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

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

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

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

2. Описание нотации ARIS eEPC

Нотация ARIS eEPC расшифровывается следующим образом – extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В следующей таблице приводятся основные используемые в рамках нотации объекты.

Таблица 1

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

Рисунок 1.

На рисунке 1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 “активирует” или инициирует выполнение Функции 1. Функция 1 “создает” Событие 2, за которым следует символ логического И, “запускающий” выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:

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

Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала “Методы ARIS”, который устанавливается на компьютер одновременно с демо-версией продукта.

На рисунке 2 показано применение различных объектов ARIS при создании модели бизнес-процесса.

Рисунок 2.

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

Из рисунка 1 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.

Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Пример моделей, сформированных с использованием ARIS eEPC, показаны на рисунках 3-4.

Рисунок 3.

Рисунок 4.

3. Описание нотации IDEF0, IDEF3

Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур. Нотации IDEF0 и IDEF3 используют следующие объекты.

Нотация IDEF0

Нотация IDEF3

Таблица 2.

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

Таблица 3.

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

Бизнес-процесс, сформированный при помощи нотации IDEF0, показан на рисунке 5. (Этот процесс представлен в нотации ARIS eEPC на рисунке 3).

Рисунок 5.

На рисунке 6 показан бизнес-процесс, описанный при помощи нотации IDEF3. (Этот процесс представлен в нотации ARIS eEPC на рисунке 4.)

Рисунок 6.

В нотации IDEF3, так же как и в нотации ARIS eEPC, используются символы логики, отражающие ветвление процесса.

4. Сравнительный анализ нотаций ARIS и IDEF

Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице.

Таблица 4.

Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления – стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Work Flow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться “за кадром” на 30-90% (см. пример на следующем рисунке).

Рисунок 7. Недостатки описания бизнес-процесса в ARIS eEPC.

На рисунке 7 Функция 4 является контрольной и служит для проверки результатов выполнения работы, выполняемой функциями 2 и 3. Но данная модель не отвечает на вопросы:

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

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

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

5. Функциональные возможности продуктов ARIS и BPWin

Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPWin можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимуществ и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы BPWin позволяет решить эту задачу. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0 или IDEF3 BPWin. Сравнение функциональных возможностей систем приводится в следующей таблице.

Таблица 5.

Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. Вполне естественно, что в ARIS-е предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п. В BPWin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но с другой стороны ограничивает возможности по анализу объектов модели. В Model Mart так же предусмотрено администрирование базы данных.

Часто одним из недостатков BPWin сторонники ARIS-а называют ограничение по количеству объектов на диаграмме. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно реально использовать (критерий – обозримость), количество объектов в базе данных ARIS или модели BPWin составляет 150-300. Это означает, что при 8 объектах на одной диаграмме, общее количество диаграмм (листов) в модели составит 20-40. Базы данных ARIS Toolset (как и BPWin), содержащие более 500 объектов, фактически невозможно использовать. Следует подчеркнуть, что модель создается для выделения и анализа проблем, т.е. требуется детальное описание наиболее сложных, проблемных областей деятельности, а не тотальное описание всех процессов. Как ни странно, среди директоров компаний существует вера в то, что детальное описание процессов само по себе представляет ценность и может решить многие проблемы. Это далеко не так. Именно понимание того, что нужно описывать и какие аспекты функционирования реальной системы при этом отражать, определяет успех проекта по моделированию бизнес-процессов.

ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией – т.н. “Соглашениями по моделированию”. Разработка этих “Соглашений” само по себя является сложной, дорогой и требующей значительного времени (1-3 месяца) и квалифицированных специалистов задачей. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90%. В свою очередь, BPWin отличается простотой в использовании, и достаточной строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.). ARIS, безусловно, является более “тяжелым” инструментом, по сравнению с BPWin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.

6. Выводы

Рекомендации по применению систем в зависимости от типовых задач

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

Таблица 6.

Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (см. рисунок 8).

Рисунок 8.

Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человека в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPWin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.

В данном разделе мы рассмотрим методологию ARIS. В настоящее время на рынке инструментальных средств моделирования бизнес- процессов представлено одноименное ПО ARIS .
Методология ARIS включает в себя несколько различных нотаций для описания деятельности организации с различных точек зрения. В методологию интегрированы существующие стандарты и спецификации описания процессов и данных, например IDEF3, ERD, DFD, UML и т. д. Основная концепция ARIS по описанию организации показана на рис. 2.30.
Изображение на рис. 2.30 часто называют «домик ARIS». Подход методологии ARIS к описанию процессов основывается на рассмотрении деятельности организации с четырех точек зрения: взгляд на организационную структуру, взгляд на данные (потоки и структуру), взгляд на функции (функциональные иерархии), взгляд на контроль и управление (сводные модели бизнес-процессов).
Методология ARIS включает в себя большое количество различных нотаций, допускающих гибкое создание различных моделей

организации. К числу наиболее значимых и практически используемых нотаций ARIS относятся: нотация Value-added Chain Diagram (диаграмма цепочки процесса, добавляющего стоимость); нотации еЕРС, Extended Event-driven Process Chain (расширенная нотация цепочки процесса, управляемого событиями) и PCD (диаграмма цепочки процесса); нотация Organizational Chart (организационная диаграмма); нотация Function Tree (дерево функций); нотация Product Tree (дерево продуктов).
Рис. 2.30. Основные виды моделей в методологии ARIS

Сила методологии ARIS (с формальной точки зрения) заключается в ее комплексности, которая проявляется во взаимосвязи моделей, построенных в различных нотациях. Методология ARIS позволяет описывать деятельность организации с разных точек зрения, при этом полученные модели в определенной степени связаны между собой. Следует, однако, подчеркнуть, что основные преимущества такого комплексного подхода: требуют для своей реализации наличия инструментальной среды ARIS, дорогостоящей и достаточно сложной в использовании, хотя существует и бесплатная, упрощенная версия этого продукта под названием ARIS Express;
трудно реализуемы на практике, так как влекут большой расход ресурсов (человеческих, материальных и финансовых) в течение длительного времени. Нотация Value-added Chain Diagram (VAD)
На рис. 2.31 представлена одна из важнейших нотаций ARIS - нотация Value-added Chain Diagram. Диаграмма цепочки процесса, добавляющего стоимость, используется при описании бизнес-процессов организации на верхнем уровне. Как правило, консультанты, использующие ARIS, рекомендуют выделять шесть-восемь бизнес- процессов верхнего уровня и описывать их в нотации VAD. Затем проводится декомпозиция полученных процессов верхнего уровня, при этом используется либо нотация VAD, либо еЕРС. Рассмотрим основные объекты нотации VAD, представленные на рис. 2.31.
Основной объект нотации VAD - это Value Added Chain. Фактически это процесс или группа функций организации, которые служат для получения добавленной стоимости. Объекты соединяются между собой пунктирной стрелкой, имеющей тип is predecessor of («является предшественником»). Этот тип связи показывает, что один процесс - предшественник другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные связи. Поэтому термин is predecessor of, на наш взгляд, неудачный.
Между процессами, приведенными на рис. 2.31, могут быть отображены потоки материальных ресурсов и информации. Для их описания можно воспользоваться объектами типа Cluster (для описания информации) и Technical Term (для описания материальных потоков). Для описания инфраструктуры, необходимой для выполнения процесса, в данном примере выбраны типы объектов Product/Service и Information Service. Выбор типов объектов для отображения реальных потоков в достаточной степени условный. Очень важно в начале работ по моделированию процессов определить, какие именно типы объектов будут использованы и какие объекты реального мира они будут отображать. Так, в примере на рис. 2.31 можно было бы показать все потоки (информационные и материальные) при помощи объектов типа Technical Term.

Рис. 2.31. Модель в нотации Value-added Chain Diagram

На рис. 2.31 показаны также объекты Organizational Unit, отображающие организационные подразделения, выполняющие соответствующие процессы.
Объекты связываются между собой при помощи связей определенного типа (рис. 2.31). Например, информационный поток, отображаемый объектом Cluster, является входящим для первого процесса, и он связан с ним при помощи стрелки типа is input for («является входом для»). Другой пример - тип связи executes («исполняет») между объектами Value-added Chain и Organizational Unit. Тип связи is used by показывает, что Product/Service используется процессом и т. д. Таким образом, в методологии ARIS важнейшие требования - это корректный выбор и дальнейшее использование связей и объектов определенного типа.
На рис. 2.32 представлен пример модели верхнего уровня, выполненный в нотации ARIS VAD. Вы уже знакомы с этим процессом. На рис. 2.17 он приведен в нотации IDEF0.
Принципы построения диаграммы процесса верхнего уровня в VAD существенно отличаются от IDEF0: в VAD стрелки могут входить в любую сторону объекта Value-added Chain. (Напомним, что в IDEF0 каждая сторона объекта Activity (функция) имеет глубокий смысл.)

3
О
§
О
О

На рис. 2.33 представлена ситуация, возможная в нотации VAD, когда на диаграмме процесса приводится множество обратных связей, смысл которых понятен только создавшему модель аналитику.
Указанный недостаток VAD можно обойти, заранее оговорив возможность специального использования обратных связей, как, например, на рис. 2.34.
Рис. 2.33. Обратные связи в нотации Value-added Chain Diagram

Рис. 2.34. Пример реализации обратных связей в нотации Value added Chain Diagram

Отметим, что у специалистов по ARIS такой подход может вызвать критику, так как противоречит нотации. Но мы придерживаемся
той точки зрения, что это вполне допустимо, так как модели верхнего уровня в нотации VAD ARIS реально могут быть использованы лишь в качестве простейшего способа графического изображения цепочки процесса.
Заканчивая обзор нотации ARIS VAD, еще раз акцентируем внимание на том, что указанная нотация в большей степени носит иллюстративный характер и не предназначена для создания комплексных моделей процессов верхнего уровня организации. Нотация ARIS еЕРС - расширение нотации IDEF3
Нотация ARIS еЕРС (еЕРС - Extended Event Driven Process Chain - расширенная цепочка процесса, управляемого событиями) разработана специалистами немецкой компании IDS Scheer AG (Германия), в частности профессором Шеером. В табл. 2.3 приводятся основные используемые в рамках нотации объекты.
Помимо указанных в табл. 2.3 основных объектов, при постро ении диаграммы еЕРС могут быть использованы и многие другие. На практике применение большого числа объектов различных типов нецелесообразно, так как это значительно увеличивает размер модели и делает ее плохо читаемой.
Для понимания смысла нотации еЕРС рассмотрим основные используемые типы объектов и связей. На рис. 2.35 представлена простейшая модель еЕРС, описывающая фрагмент бизнес-процесса предприятия.
На рис. 2.35 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая событие 1 и функцию 1, активирует (activates) или инициирует выполнение функции 1. Функция 1 создает (creates) событие 2, за которым следует символ логического «И», запускающий выполнение функций 2 и 3.
Внимательный анализ нотации еЕРС показывает, что она практически не отличается от IDEF3. Важнейшее отличие еЕРС - наличие объекта «Событие» (Event). Этот объект служит для отображения в модели возможных результатов реализации функций, в зависимости от которых выполняется та или иная последующая
ветка процесса. Нотация еЕРС называется расширенной, очевидно, именно вследствие наличия в ней объекта «Событие» (в IDEF3 такого объекта нет). На рис. 2.36 приводятся примеры применения символов логики и событий при построении моделей в нотации еЕРС.
Табл. 2.3. Основные объекты, используемые в рамках нотации ARIS еЕРС

№	Наименова- . нив	Описание	¦Графическое представление
/>1	Функция	Объект «функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия		* "" Ч Function J
2	Событие	Объект «событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций
3	Организационная единица	Объект, отражающий различные организационные звенья предприятия (например, управление или отдел)		ija^^tionaUi^it
4	Документ	Объект, отражающий реальные носители информации, например бумажный документ		Document
5	Прикладная система	Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции	А	I ¦ yplication systjs J ? M	m
5	Прикладная система
6	Кластер информации	Объект характеризует данные как набор сущностей и связей между ними. Используется для создания моделей данных
7	Стрелка связи между объектами	Объект описывает тип отношений между другими объектами, например активацию выполнения функции некоторым событием	gt;
8	Логическое «И»		©
9	Логическое «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса	@
10	Логическое исключающее «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса	®

Рис. 2.35. Нотация ARIS еЕРС

Рис. 2.36. Применение логических операторов при построении моделей в еЕРС

При построении модели в ARIS еЕРС должны соблюдаться следующие правила: каждая функция инициируется и завершается событием; в каждую функцию не может входить более одной стрелки, запускающей выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.
Кроме этих, существуют и другие важные правила формирования моделей в ARIS.
На рис. 2.37 показано применение различных объектов нотации ARIS еЕРС при создании модели бизнес-процесса.

J activates
alt="" />

На рис. 2.36 и 2.37 видно, что бизнес-процесс в нотации еЕРС представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность осуществления процедур в еЕРС не может быть отражена визуально. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя возлагается выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов и визуального отображения загрузки персонала можно применять другие инструменты описания, например графики Ганта в системе MS Project.
Рассмотрим примеры использования нотации еЕРС для описания бизнес-процессов.

На рис. 2.38 представлен процесс обработки заказа клиента (он же изображен в нотации IDEF3 на рис. 2.24).
Процесс начинается с события «Поступил заказ клиента». Оно инициирует функцию «Выполнить учет заказа в системе», которую осуществляет менеджер отдела сбыта. Для работы он использует «Систему учета заказов». Результат выполнения функции отображается событием «Учет заказа выполнен».
После этого менеджер по сбыту реализует функцию «Выполнить анализ на соответствие номенклатуре». Результат - два альтернативных события: «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического исключающего «ИЛИ».
Функция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: если заказ не соответствует номенклатуре либо производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического «ИЛИ» и т. д.
Как видно из рис. 2.38, схема процесса в ARIS еЕРС отличается от схемы в IDEF3 наличием объектов: событий, документов, прикладных систем и должностей. Схема в ARIS визуально представляется более информативной и воспринимается лучше, однако ее размер существенно превышает схему в нотации IDEF3.
Рассмотренный выше процесс может быть представлен также в нотации ARIS PCD (Process Chain Diagram) - разновидности еЕРС. На рис. 2.39 представлен бизнес-процесс обработки заявки клиента в нотации PCD. При его описании использованы те же объекты, которые составляют процесс на рис. 2.38, но расположены они в виде таблицы. В первом столбце - события и некоторые символы логики, во втором - функции, в третьем - входящие и исходящие документы, в четвертом - виды прикладного программного обеспечения, в пятом - должности, задействованные в процессе. Такое представление процесса более распространено. Оно лучше подходит для документирования процессов.

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

Нотация ARIS Organizational Chart
Нотация Organizational Chart - одна из основных нотаций ARIS и предназначена для построения схем организационной структуры предприятия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения предприятия в виде иерархической структуры, как показано на рис. 2.40.
Рис. 2.40. Модель организационной структуры предприятия
alt="" />

Модель строится из объектов Organizational Unit, Position, Internal Person и т. д. Заложенные в нотацию виды связей позволяют отразить различные типы отношений между объектами организационной структуры. В представленном на рис. 2.40 примере «Предприятие» управляется «Директором», при этом используется тип связи is Organization Manager for. Иерархия подразделений строится при помощи связей is composed of. Также могут быть указаны должности - Position, фамилии занимающих их сотрудников - Internal person, тип связи - occupies. Кроме моделей иерархии подразделений, могут быть построены модели иерархии подчиненности в проектных командах, группах и т. д. Все отраженные в моделях объекты могут быть использованы в дальнейшем при построении моделей бизнес-процессов. При построении сложных иерархических
структур может быть использована декомпозиция, например структуру подразделения отражают на более детальной схеме. Нотация ARIS Function Tree
Эта нотация предназначена для формирования моделей дерева функций. Пример такой модели представлен на рис. 2.41. Все функции на этой диаграмме соединены связями. Чаще всего используются типы связей is execution-oriented superior и is process-oriented superior. Первый тип связи служит для построения дерева по функциональному признаку (описания функций подразделения). Второй тип связи используется при создании дерева функций, входящих в некоторый бизнес-процесс.
Рис. 2.41. Модель Function Tree (дерева функций)

Дерево функций может строиться по функциональному, процессному и продуктовому принципам. На практике часто используется первый принцип - создаются модели иерархии функций подразделения. Нотация ARIS Product Tree
На рис. 2.42 представлена нотация ARIS Product Tree. Она предназначена для создания моделей дерева продуктов. Модели такого типа могут использоваться для описания материальных входов и выходов процесса.

Рис. 2.42. Модель Product Tree (дерева продуктов)

Нотация ARIS Information Flow
Нотация Information Flow - аналог DFD и применяется при построении схем потоков данных или документов между функциями бизнес-процессов предприятия. Простота нотации ограничивает области ее полезного применения. Ее основные объекты - Function (используется также при построении моделей бизнес-процессов) и Information Flow - информационный поток, как показано на рис. 2.43.
Рис. 2.43. Нотация ARIS Information Flow (информационного потока)
информационный поток

При построении моделей бизнес-процессов сначала может быть построена модель еЕРС, а затем, с использованием определенных в процессе функций, - модель информационных потоков. Использование нескольких нотаций при создании моделей процессов в ARIS
При формировании моделей бизнес-процессов в ARIS, как правило, используется несколько типов нотаций. На рис. 2.44 представлена схема применения моделей, созданных в различных нотациях.

Рис. 2.44. Использование нотаций ARIS при создании моделей

Как правило, работа по описанию бизнес-процессов компании в ARIS начинается с создания модели организационной структуры. Одновременно (или позже) могут разрабатываться модели, описывающие структуру основных материальных и информационных входов и выходов. С использованием данных моделей создаются модели бизнес-процессов верхнего уровня в нотации VAD. После этого разрабатываются модели функций подразделений и другие вспомогательные модели (например, описание прикладных программных систем). Затем формируются модели процессов в нотации еЕРС. Модели еЕРС строятся на основе уже имеющихся описаний организационной структуры, функций подразделений, материалов, систем и т. д. Итог работы - комплект моделей, описывающих деятельность организации с различных точек зрения.
Особенность работы в полноценных программных продуктах для моделирования бизнес-процессов состоит в том, что программный продукт создает базу данных по объектам и их атрибутам. С одной
стороны, это позволяет рассматривать различные аспекты взаимодействия объектов модели, выбирая одну из нотаций (рис. 2.44). С другой стороны, «несущественная» ошибка при создании связей между объектами в одной нотации может существенно исказить вид диаграммы в другой нотации.