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

Нотация 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. Описание процесса анализа и согласования заявки клиента

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

Во многих современных системах класса Business Process Management (BPMS) для описания «исполняемых» процессов применяется спецификация BPMN (версия 1, 2). Эта спецификация является, вероятно, лучшей для целей формализации автоматизируемых процессов. Однако для описания и регламентации процессов, исполняемых людьми, она является слишком сложной так же, как и некоторые другие нотации, появившиеся ранее.

В статье рассмотрены проблемы выбора нотаций, адекватных задаче описания и регламентации процессов, исполняемых людьми. Выполнено сравнение нотации ARIS eEPC, «простой блок-схемы » в MS Visio и «Процедуры» Business Studio.

Делаются выводы о целесообразности выбора нотации для комплексного описания и регламентации процессов компании.

Введение

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

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

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

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

При такой постановке задачи придется, скорее всего, использовать несколько нотаций: BPMN, некоторую нотацию типа Work Flow и, возможно, UML. Использовать какую-то одну нотацию и один инструмент моделирования для эффективного решения этих разнородных задач на практике вряд ли получится.

Нотация BPMN является наиболее удобной (в ряду существующих в настоящее время) для описания «автоматически исполняемых» процессов. Но она не удобна для создания относительно простых схем в регламентирующих документах для сотрудников по следующим причинам:

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

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

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

Нотация ARIS eEPC

Нотация ARIS eEPC была одной из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотации типа Work Flow (поток работ). Особенностями нотации является наличие элементов типа «событие» и наличие операторов логики: «и», «неисключающее или», «исключающее или» (см. Рис. 1).

Рис. 1. Схема процесса в нотации ARIS eEPC

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

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

Возникает вопрос: а за что, собственно, боролись? Типичная схема в ARIS eEPC:

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

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

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

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

«Простая блок-схема »

Нотация «простая блок-схема » реализована в популярном офисном продукте MS Visio. На Рис. 2. показаны элементы этой нотации и фрагмент соответствующей схемы. В полном объеме рассматриваемая нотация применяется редко.

Вообще, в MS Visio представлено несколько нотаций типа «блок-схема» , которые являются достаточно сложными. Очевидно, по этой причине они не нашли широкого применения, хотя и были включены в набор нотаций, поставляемых с системой.

Нотация «простая блок-схема » в своем самом простом и часто используемом на практике варианте, содержит всего несколько элементов:

Процесс;
Решение;
Ручная операции (реже);
Документ;
Данные;
Стрелка (для отображения связей между объектами схемы).

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

Рис. 2. Нотация «Простая блок-схема » в MS Visio

Рассмотрим некоторые особенности применения «Простой блок-схемы », в частности применение стрелок. На практике, сотрудники компании, формирующие схемы при помощи «Простой блок-схемы » придерживаются двух подходов:

Не именуют стрелки вообще;
Стараются присваивать стрелкам, связывающие элементы схемы, простые и понятные названия;

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

Нотация «Простая блок-схема » при использовании в компаниях часто подвергается различным вариациям:

Изменяется смысл элемента «решение»;
По-разному используют стрелки связей (именуют или не именуют и т. п.);
По-разному используют стрелки связей в сочетании с объектом «документ»;
Прочее.

Интересно, что нотация «простая блок-схема » в том или ином виде часто используется специалистами по менеджменту качества при описании процессов СМК.

Рис. 3. Пример схемы в нотации «Простая блок-схема »

Преимуществами нотации «Простая блок-схема » (с сокращенным до минимума количество элементов) являются:

Простота формирования графических схем процессов;
Интуитивная понятность схем сотрудникам (даже без специального обучения);
Минимальная потребность в обучении сотрудников;
Наличие доступных инструментов для описания процессов (MS Visio, MS Word).

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

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

В целом, масштабное использование в компании нотации «Простая блок-схема » без современного средства моделирования представляется весьма неэффективным.

«Процедура» Business Studio

На Рис. 4 представлена схема, сформированная в нотации «Процедура» среды моделирования процессов Business Studio (Россия). В рассматриваемой нотации используются следующие условные обозначения:

Процесс;
Решение;
Событие;
Стрелка предшествования (как в классических нотациях класса Work Flow);
Стрелка потока объектов;
Сноска;
Внешняя ссылка.

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

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

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

Рис. 4. Схема процесса в нотации «Процедура» Business Studio

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

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

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

В целом, схема процесса в нотации «Процедура» при кажущейся простоте является весьма информативной и удобной для описания. Можно сформулировать следующие преимущества этой нотации (в случае ее использования в Business Studio):

Представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);
Быстрота создания графических схем для целей регламентации;
Возможность повышения информативности схем процессов за счет гибкого использования событий и именованных стрелок (одновременно с возможностью привязки документов к стрелкам и последующей выгрузки информации в регламентирующих документах);
Схемы процессов просты и понятны всем сотрудникам даже без специального обучения;
Простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны — обучение можно проводить силами сотрудников отдела орг. развития);
Схемы процессов являются кросс-функциональными, что удобно для описания «сквозных» процессов компании;
Можно выгружать и редактировать схемы в MS Visio (при необходимости).

Среда моделирования Business Studio позволяет достаточно быстро создавать процессную модель компании. Информация о процессах может быть выгружена из системы в виде регламентирующих документов в требуемом формате. Заметим, что в Business Studio есть возможность описывать процессы в нотации ARIS eEPC, нотации IDEF0 и нотации «Процесс» (см. руководство по системе).

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

Таблица 1. Информация о процессе, представленном на Рис. 4

Рис. 5. Пример схемы в нотации «Процедура» в Business Studio

Выводы

В целом, нотация «Процедура» в версии, реализованной в среде моделирования Business Studio, является более удобной и понятной сотрудникам, чем нотация ARIS eEPC. Она позволяет быстро описывать и регламентировать процессы компании.

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

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

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

В. Репин, С. Маклаков

Анализ деятельности предприятий и реорганизация бизнес-процессов - чрезвычайно сложная задача, требующая методической и инструментальной поддержки. В последнее время среди бизнес-аналитиков все большую популярность приобретают CASE-средства BPwin (Computer Associates) и ARIS Toolset (ARIS). В настоящей статье дается краткий сравнительный анализ этих средств и рекомендации по их использованию.

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

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

каких результатов с точки зрения улучшения деятельности организации можно добиться, используя технологииописания и реорганизации бизнес-процессов;
какое программное обеспечение использовать в проекте («ARIS лучше BPwin?», «ERwin лучше ARIS?» и т.п.);
как моделировать процессы с использованием продукта «Х»;
как проводить анализ и выявлять проблемы при помощи продукта «Х»;
какую методологию использовать для описания процессов;
что делать дальше с полученными моделями бизнес-процессов.

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

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

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

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

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

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

Нотация ARIS eEPC

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

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

Рис. 1. Пример модели в нотации eEPC

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

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

Рис. 2. Пример применения объектов ARIS для описания бизнес-процессов

Рис. 3. Описание процесса обслуживания клиента процесса

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

Нотация ARIS Organizational Chart

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

Рис. 5. Модель организационной структуры предприятия

Модель строится из объектов «Organizational unit», «Position», «Internal person» и др. Заложенные в нотацию виды связей позволяют отразить различные виды отношений между объектами организационной структуры. В представленном на рис. 5 примере «Предприятие» управляется «Директором», при этом используется тип связи «is Organization Manager for». Иерархия подразделений строится при помощи связей типа «is composed of». Кроме того, могут быть указаны должности - «Position» и фамилии реальных сотрудников, их занимающих: «Internal person», а также тип связи «occupies».

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

Нотация ARIS Information Flow

Нотация Information Flow является аналогом нотации DFD (см. ниже) и используется при построении схем потоков данных или документов между функциями бизнес-процессов предприятия, как показано на рис. 6.

Рис. 6. Фрагмент диаграммы ARIS Information Flow

Простота нотации ограничивает области ее полезного применения. Основными объектами нотации являются «Function» (используется также при построении моделей бизнес-процессов) и «Information Flow» - информационный поток (рис. 7).

Рис. 7. Нотация ARIS Information Flow

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

Нотации, поддерживаемые BPwin 4.0

Описание нотаций IDEF0 и IDEF3

Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. IDEF0 получила чрезвычайно широкое распространение и является, в частности, стандартом в таких международных организациях, как НАТО и МВФ. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Workflow), для которых важно отразить логическую последовательность выполнения процедур. Объекты нотаций IDEF0 и IDEF3 показаны в табл. 2 и 3.

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

	Наименование	Описание
Нотация IDEF0
1	Работа (Activity)	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Изображается прямоугольником. Имя работы должно отображать процесс, действие. Для того чтобы работа могла быть смоделирована, должно пройти какое-то время от начала до окончания работы и должны быть затрачены какие-то ресурсы
2	Стрелка входа	Стрелка рисуется входящей в работу слева и описывает входящие документы, информацию, материальные ресурсы, необходимые для выполнения функции и изменяемые работой
3	Стрелка выхода	Стрелка рисуется исходящей из работы справа и описывает результаты выполнения работы - исходящие документы, информацию, материальные ресурсы. В нотации IDEF0 каждая процедура должна обязательно иметь не менее одной стрелки выхода
4	Стрелка управления	Стрелка рисуется входящей в работу сверху и описывает управляющее воздействие, например распоряжение, нормативный документ и т.д. В нотации IDEF0 каждая процедура должна обязательно иметь не менее одной стрелки управления
5	Стрелка механизма	Стрелка рисуется входящей в работу снизу и описывает так называемые механизмы, то есть ресурсы, необходимые для выполнения процедуры, но не изменяющие в процессе ее выполнения свое состояние. Примеры: сотрудник, станок и т.д.
6	Стрелка вызова	Стрелка рисуется исходящей из работы вниз и является ссылкой на другую модель работы. В BPwin такая стрелка используется для слияния и расщепления моделей

Таблица 3. Объекты нотации IDEF3

	Наименование	Описание
Нотация DFD
1	Работа	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Изображается прямоугольником. Имя работы должно отображать процесс, действие
2	Объект ссылки (Referent)	Объект, используемый 1) для описания ссылок на другие диаграммы; 2) ссылок на другие работы; 3) ссылок на объекты; 4) для пояснения логики ветвления стрелок на перекрестках; 5) различных комментариев к функциям и перекресткам
3	Перекрестки	Логические операторы (5 типов - синхронное и асинхронное «И», синхронное и асинхронное «ИЛИ», исключающее «ИЛИ»), определяющие взаимосвязь между функциями в рамках процесса. Позволяют описать ветвление процесса
4	Стрелки	Три типа стрелок, позволяющих описать последовательность выполнения процессов, а также потоки информации и объектов

Семантика построения моделей IDEF0 и IDEF3 предполагает соблюдение четких правил. Полное описание стандартов IDEF можно найти на сайте http://www.idef.com/ .

Пример описания бизнес-процесса в нотации IDEF0 показан на рис. 8 (соответствует процессу, показанному на рис. 3).

Рис. 8. Пример описания бизнес-процесса в нотации IDEF0

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

На рис. 9 показан пример описания бизнес-процесса в нотации IDEF3 (соответствует процессу, показанному на рис. 4).

Рис. 9. Пример описания бизнес-процесса в нотации IDEF3

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

Описание нотации DFD

Нотация DFD предназначена для описания информационных потоков в обследуемой организации. Объекты нотации DFD показаны в табл. 4. Наличие объектов «хранилище данных» и двунаправленных стрелок позволяет наиболее эффективно описать документооборот и требования к информационной системе.

Таблица 4. Объекты нотации DFD

	Наименование	Описание
Нотация DFD
1	Работа (Activity)	Объект служит для описания функций по обработке информации, выполняемых подразделениями/ сотрудниками предприятия
2	Объект ссылки	Объект ссылки моделирует объект, воздействующий на систему извне
3	Хранилище данных	Хранилище данных моделирует место хранения информации - архив, база данных, репозитарий и т.д.
4	Стрелка	Стрелка показывает потоки информации, движение документов, перемещающихся вместе как один пакет. Стрелка может быть двунаправленной, то есть показывает поток информации по данному маршруту в обе стороны

На рис. 10 показан пример диаграммы DFD.

Рис. 10. Пример описания документооборота в нотации DFD

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

Организационные диаграммы (Organizational Chart) в BPwin 4.0

Организационные диаграммы BPwin (рис. 11) являются аналогом организационных диаграмм ARIs и так же, как и в ARIS, предназначены для описания иерархии подчинения в организациях.

Рис. 11. Пример организационной диаграммы в BPwin

Для создания организационной диаграммы в BPwin необходимо предварительно в словарях внести следующую информацию.
Изображения (bitmaps), если на организационной диаграмме предполагается использовать иконки.
Группы ролей - могут соответствовать структурным подразделением. В примере на рис. 10 показаны группы ролей «Дирекция», «Бухгалтерия» и «Цех № 1».
Роли - могут соответствовать должности. В примере на рис. 10 показаны роли «Ген. директор», «Бухгалтер», «Технолог» и др.
Ресурсы - могут соответствовать фамилии конкретной персоны.

После создания словаря BPwin позволяет с помощью диалогов-гидов создать иерархию подчинения, включающую группы ролей, роли и ресурсы. В диаграммах IDEF0, IDEF3 и DFD каждой работе может быть назначен исполнитель-ресурс из словаря ресурсов. Роли и ресурсы могут быть также использованы при создании диаграммы Swim Lane - разновидности диаграммы IDEF3, на которой в виде отдельных полос показываются зоны ответственности служащих предприятия при выполнении технологических операций.

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

Таблица 5. Объекты нотаций ARIS, IDEF0 и IDEF3

	Критерии сравнения
1	Принцип построения диаграммы/логика процесса		Принцип доминирования (см. стандарт IDEF0)	Временная последовательность выполнения процедур
2	Описание процедуры процесса	Объект на диаграмме	Объект на диаграмме	Объект на диаграмме
3	Входящий документ
4	Входящая информация		Стрелка входа, стрелка управления	Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
5	Исходящий документ	Используется отдельный объект для описания («документ»)	Стрелка выхода	Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
6	Исходящая информация	Используется отдельный объект для описания («кластер», «технический термин»)	Стрелка выхода	Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
7	Исполнитель процедуры	Используется отдельный объект для описания («позиция», «организационная единица»)	Стрелка механизма
8	Используемое оборудование	Используется отдельный объект для описания	Стрелка механизма	Нет (может быть отражен в модели только привязкой объекта ссылки)
9	Управление процедурой	Нет. Может быть отражено только символами логики и событий (последовательность выполнения процедур) и/или указанием входящих документов	Стрелка управления	Только временная последовательность выполнения процедур и логика процесса
10	Контроль выполнения процедуры	Нет. Может быть отражен указанием входящих документов	Стрелка управления	Нет (может быть отражен в модели только привязкой объекта ссылки).
11	Обратная связь по управлению/контролю		Стрелка управления	Нет
12	Обратная связь по входу	Нет. Может быть отражена только символами логики (последовательность выполнения процедур)	Стрелка входа	Нет

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

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

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

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

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

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

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

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

Таблица 6. Сравнение функциональных возможностей ARIS Toolset 5.0 и BPwin 4.0

	Возможности/ Инструментальная среда	ARIS Toolset 5.0	BPwin 4.0
1	Поддерживаемый стандарт	(частично - DFD, ERM, UML)	IDEF0, IDEF3, DFD
2	Система хранения данных модели	Объектная база данных	Модели хранятся в файлах. Возможно создание репозитария на основе реляционной СУБД с помощью ModelMart
3	Ограничение на размер базы данных		Нет. Размер базы данных ограничивается вычислительными ресурсами
4	Возможность групповой работы	Есть. Используется ARIS Server	Есть. Используется ModelMart
5	Ограничение на количество объектов на диаграмме	Нет	Для DFD и IDEF3 - нет. Для IDEF0 ограничено рекомендациями нотации
6	Возможность декомпозиции	Неограниченная декомпозиция. Возможна декомпозиция на различные типы моделей	Неограниченная декомпозиция. Возможен переход на другую нотацию в процессе декомпозиции
7	Формат представления моделей	Не регламентируется	Стандартный бланк (каркас) IDEF с возможностью его отключения
8	Удобство работы по созданию моделей	Сложная панель управления, есть выравнивание объектов, есть undo	Простая панель управления, нет выравнивания объектов, нет undo
9	UDP - свойства объектов, определяемые пользователем	Большое, но ограниченное количество свойств; количество типов ограничено	Количество UDP не ограничено. Количество типов ограничено (18)
10	Возможность анализа стоимости процессов	Есть. Возможность использовать ARIS ABC	Упрощенный ABC - анализ стоимости по частоте использования в процессе. Возможность экспорта в Easy ABC
11	Генерация отчетов	Создание отчетов на основе стандартных и настраиваемых пользователем макросов Visual Basic	RPTwin, возможность визуальной настройки отчетов, включая расчет по формулам с использованием UDP
12	Сложность разработки нестандартных отчетов	Сложно	Просто
13	Экспорт отчетов		Реализован экспорт отчетов в MS Office, текстовый файл, RTF, HTML
14	Связь с моделью данных	Возможность построения ERD-диаграмм, для экспорта необходимо дополнительное программное обеспечение	Реализована связь с моделью данных ERwin. Каждой стрелке может быть поставлен в соответствие набор сущностей и атрибутов
15	Описание доступа к данным	Нет	Для каждой работы могут быть описаны права на использование данных. Объект модели данных может быть создан непосредственно в среде BPwin
16	Описание сопутствующей документации	Есть, поддержка OLE	С помощью UDP типа command с каждой стрелкой связывается любой документ, который может быть загружен с помощью Windows - приложения. Запуск приложения проводится непосредственно из среды BPwin

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

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

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

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

Таблица 7. Оценка применимости ARIS Toolset 5.0 и BPwin 4.0 для задач моделирования бизнес-процессов

Задача/Инструментальная среда	ARIS Toolset 5.0
Разовый проект по описанию бизнес-процессов, например: описание одного бизнес-процесса с точки зрения контроля и управления; описание функциональных возможностей новой системы управления на верхнем уровне	3	5
Длительный (непрерывный) проект по описанию деятельности компании с различных точек зрения (организационная структура, структура документов, большой объем базы данных процессов и т.д.)	5	4
Разработка системы автоматизации: описание функциональных возможностей системы; создание логической модели данных; связь модели процессов и модели данных; создание физической модели данных; генерация кода приложения.	3 3 - -	5 BPwin + ERwin + Paradigm Plus

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

Рис. 13. Оценка эффективности ARIS Toolset и BPwin

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

Интернет-сайт www.finexpert.ru
Интернет-сайт
Интернет-сайт www.idef.com
С.В.Маклаков. BPwin и ERwin. CASE-средства разработки информационных систем. Москва: Диалог-МИФИ, 2000, 256с.
Д.А. Марка, К. МакГоуэн Методология структурного анализа и проектирования. Москва, 1993.
«Методы ARIS». Файл pdf, более 1000 стр. Поставляется вместе с демо-версией системы ARIS Toolset.
Август-Вильгельм Шеер. Бизнес-процессы: основные понятия, теории, методы. Москва: Просветитель, 1999.

В данном разделе мы рассмотрим методологию 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). С другой стороны, «несущественная» ошибка при создании связей между объектами в одной нотации может существенно исказить вид диаграммы в другой нотации.

Всякая вещь есть форма проявления беспредельного разнообразия.
Козьма Прутков

Введение в нотацию eEPC

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

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

Целью данной статьи является не рассмотрение всевозможных нотаций (я сознательно не называю их названий), а остановиться на подробном описании той нотации, которую выбрал я для своих проектов в процессе длительного поиска наиболее оптимального варианта.
Если кому-то интересно узнать, какие еще бывают нотации и для чего они используются, я планирую сделать это в другой статье, которая будет называться «Поговорим о нотациях», но это пока в планах.
Пора начать наше повествование об очень интересной, простой и практичной нотации eEPC (в переводе: расширенное описание событийной цепочки процессов). В ее дословном переводе раскрывается и основное предназначение: описание цепочки бизнес-процессов. Главная «фишка» нотации в ее принципе «событийности», который мы рассмотрим подробно.
Какие преимущества имеет нотация eEPC:

Во-первых, это не совсем нотация в чистом виде. Т.е. если в некоторых нотациях существует жесткий набор элементов и правил их использования (иначе все запутается), то принцип eEPC позволяет добавлять собственные элементы. Как это обеспечивается? Конечно, существует определенный «стержень», вокруг которого все строится, т.е. набор четких правил, по которым строится схема и по которым она потом читается. Кроме этого Вы может добавить свой элемент, включить правила его использования в собственный корпоративный стандарт (чтобы исключить самодеятельность, которая может запутать схему и усложнить ее читаемость) и все! Это очень важный момент. Кроме этого, в своем корпоративном стандарте можно задать и любые другие ограничения и правила
eEPC содержит элементы логики. Это позволяет строить схемы с условиями, что необходимо для описания деятельности («если договор согласован, то …., иначе …»)
Простота элементов позволяет рисовать диаграммы как в программных продуктах, так и любым другим способом, хоть на бумаге, Вы не запутаетесь.
eEPC настолько легка в обучении и восприятии, что может использоваться в реальной деятельности, а не только пылиться в шкафу. На обучение правилам потребуется около 2-х часов (при наличии желания обучаемого).

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

Главный «стержень» нотации eEPC

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

Вот такие два простых элемента составляют основу правил описания бизнес процессов в нотации eEPC. Думаю, надо сказать пару слов об используемых цветах. Если Вы сталкивались с описание процессов в других нотациях, как правило они были черно-белые. И это правильно, явной зависимости содержания от цвета быть не должно, т.к. схема может быть нарисована карандашом на бумаге, распечатана на черно-белом принтере и пр. В данном случае (в нтации eEPC) так исторически сложилось, что элементы имеют определенные цвета. Не сказать, чтобы это было обязательно, но привычка вырабатывается, да и восприятие в электронном виде лучше – сразу видно что есть что. Эти цвета можно рассматривать как рекомендацию. Почему они такие? Точно не уверен, но мне кажется от того, что компания ARIS, когда сделала в своем продукте поддержку нотации eEPC, дала им такие цвета, они и «прижились». Кстати, иногда эту нотацию еще называют «ARIS», «ARIS EPC», что является не совсем верным, т.к. компания ARIS не изобретала эту нотацию, а сделала ее поддержку в своей программе моделирования бизнес-процессов. В общем, рекомендую использовать цвета. Главное, чтобы сама форма элементов не была одинаковой (т.е. отличаться лишь цветом), т.к. в черно-белом варианте это может вызвать путаницу. Существуют и другие правила, которые позволяют придать «стройность» диаграмме eEPC, мы будем о них говорить.
Итак, есть событие, есть функция. Как они связаны?
Мы видим, что событие1 привело к необходимости выполнять некую функцию, которая завершилась событием2 . Если применительно к примеру с телефонным звонком, то будет так:

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

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

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

Все остальные элементы являются вспомогательными, и практически не регламентированы требованиями самой eEPC. Однако, нет никаких препятствий для того, чтобы добавить свои собственные элементы. Главное, зафиксировать это во внутреннем стандарте, чтобы было единое понимание, как они выглядят и зачем применяются. Такое расширение не нарушает требований, если не нарушается связка событие-функция-событие, и предназначено лишь для улучшения восприятия информации или адаптации правил описания в какой-либо отраслевой специфике. Я добавил свой набор элементов, о которых расскажу ниже.
Еще требуется выяснить, как рассмотренные элементы должны располагаться. Все эти элементы так или иначе должны быть связаны с функцией. Это общее правило: с событием не связывается ни один элемент, кроме функции. Т.е. все эти элементы должны быть связаны стрелочками с функцией. Что касается стрелок и их направлений: принято считать, что если нет направления передачи информации, то вместо стрелки отображается просто линия. Если информация входит (поступает на вход), то направление стрелки от объекта к функции, если выходит, то наоборот.
Еще пару слов о месте нахождения этих элементов на схеме и можно перерисовать нашу схему, уточнив выполнение функции обработки звонка. Жестких требований по расположению элементов нет, но принято их отображать на всех схемах одинаково (для однообразия и стройности схемы). Для унификации вешнего вида графических схем бизнес-процессов такие правила надо закрепить во внутреннем стандарте и следовать им. Чуть позже и приведу некоторые рекомендации по этому поводу.
Теперь перерисуем нашу схему:

Мы видим, что оператор выполняет обработку входящего звонка, действуя в соответствии с правилами обработки входящих звонков и использует для этого программу «CRM». Ни входящих, ни исходящих документов при этом не используется.
Как я уже упоминал, одной из сильных сторон нотации являются элементы логики. Одновременно это и один из самых сложных для понимания моментов. Поэтому, сначала я приведу пример, а потом мы отдельно будем разбираться с элементами логики.
Пусть в нашем примере будет так: в случае заинтересованности клиента дальнейшую работу с ним проводит менеджер по продажам и выставляет коммерческое предложение, которое отправляет по почте с использованием почтового клиента «MS Outlook». Если заинтересованности нет, то обработка звонка завершена. В реальной жизни хорошо бы использовать и правила завершения звонка, но это я так, к слову, пока это упростим. Вот что получится:

Элементы логики в схемах нотации eEPC

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

И . Когда произойдут два или более события одновременно;
ИЛИ . Когда могут произойти одно ли несколько событий, но как минимум одно должно произойти обязательно;
ИСКЛЮЧАЮЩЕЕ ИЛИ . Либо одно, либо другое. Т.е. два варианта одновременно невозможны.

Вот как одни выглядят:

Как видите, существует два варианта графического представления элементов логики. Они ничем не отличаются, совершенно альтернативные. Я привел их оба, т.к. на практике в различных источниках можно увидеть оба варианта. Какой из них использовать, решать Вам. Мне больше нравится первый.
Теперь необходимо разобраться с применением элементов логики. Сначала рассмотрим встречающиеся варианты, затем перейдем к примеру. Разберем каждый элемент в отдельности.
Логический элемент «И».

Когда для выполнения функции требуется одновременное выполнение нескольких событий:

Пример: Если закрыт отчетный период (событие 1) и наступил срок подачи отчета руководителю (событие 2), сотрудник готовит ежемесячный отчет.

Соединение элементов, если при выполнении функции, возникает несколько событий:

Пример: Завершена некоторая работа с заказчиком. Одновременно зафиксировано два события: взаиморасчеты сверены (событие 1), акт подписан (событие 2).

На практике такое применение встречается не часто. Как правило, если в одной функции объединено много действий.

Соединение элементов, если при выполнении нескольких функций, возникает событие:

Пример: Кладовщик собрал заказ (функция 1), оператор выписал документы (функция 2), товар готов к отгрузке (событие).

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

Пример : Поступила партия товара (событие). Одновременно начинается отгрузка ранее заказанного клиентами товара и размещение оставшегося на складе.

Логический элемент «ИЛИ».
Соединение элементов, если одно из событий может вызвать выполнение функции:

Пример : Поступила заявка по телефону (событие 1) или поступление заявки по электронной почте (событие 2) приведет к необходимости ее обрабатывать.
Соединение элементов, если одна функция может вызвать как минимум одно событие:

Пример: Подготовлен и отправлен товар счет для отправки клиенту. Счет мог быть отправлен по почте (событие 1), по факсу (событие 2).

Соединение элементов, когда выполнение нескольких функций вызовет событие:

Пример: Оказана услуга (функция 1) или продан товар (функция 2), возникла задолженность у клиента (событие 1).

Логический элемент «ИСКЛЮЧАЮЩЕЕ ИЛИ».

Соединение элементов, когда для выполнения функции необходимо одно и только одно из событий:

Пример: Клиент приехал в магазин лично (событие 1) или совершил заказ через интернет (событие 2). Необходимо выполнить отгрузку товара (функция 1).

Соединение элементов, если в результате выполнения функции происходит максимум одно из событий:

Пример: Решение либо принято либо нет.

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

Пример : Доставка товара осуществлена (событие 1) либо собственным транспортом (Функция 1), либо транспортной компанией (функция 2)

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

Попробуйте применить элементы логики на практике. Если будут трудности, напишите мне, постараюсь помочь.

Расширение нотации собственными элементами

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

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

Соглашения о правилах размещения фигур на схеме

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

Последовательность событий и функций располагают сверху вниз (лучше) или слева направо (если не хватает места);
Элементы, обозначающие исполнителей, располагаются справа от функций;
Входящие документы слева вверху от функций; направление стрелки от документов к функции;
Исходящие документы слева внизу от функций; направление стрелки от функции к документам;
Элемент «Информация» располагается внизу справа от функции. Если места недостаточно, допускается произвольное расположение, как можно ближе к функции;
Элемент «Приложение» располагается вверху справа от функций. (если для этого используется файловые хранилища, не являющиеся отчетами, то отображаются аналогично). Связь без стрелки.
Элементы «База данных» и «Картотека» располагаются произвольно;
Элемент «Материальный поток» располагается слева от сопровождающих его документов с привязкой к документу линией без стрелки;
Элемент «Кластер» в случае использования в сочетании с фигурой «Документ» для обозначения документа в электронном виде располагается слева от соответствующего документа.

Например: Расчетчик заработной платы рассчитывает заработную плату на основании предоставленных ему документов «Бригадный наряд». При этом он руководствуется документом «Положение о заработной плате», расчет производит в программе «1С: ЗиК». Результатом расчета является документ «Ведомость».

Идентификация элементов на диаграмме

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

Отображение обратной связи

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

Для отображения обратной связи по управлению используется принцип «прямого включения» в процесс дополнительной функции управления с последующим ветвлением (используется логический элемент «Исключающие ИЛИ»). Например:

Текстовое описание процессов

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

Бизнес-процесс:	Обработка входящего контакта	04.ВК
Функции процесса:
Наименование	Описание	Номер на схеме
Обработка входящего звонка	При поступлении входящего звонка оператор обрабатывает звонок в соответствии с правилам обработки входящих звонков. Выявляет интерес клиента, предоставляет информацию об услугах	04.ВК.01
Формирование коммерческого предложения	При наличии интереса клиента, оператор передает контакт менеджеру по продажам. Менеджер по продажам готовит коммерческое предложение и отправляет клиенту по электронной почте	04.ВК.02
Показатели процесса:
Наименование	Способ оценки / измерения
Количество отказов	Статистика по базе данных

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