Характеристика нотаций для моделирования бизнес процессов. Методология BPMN - Учебная и научная деятельность Анисимова Владимира Викторовича

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

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

Контекстная модель:

Название: Реализация готовой продукции со склада.

Цель: Увеличение продаж.

Точка зрения: Начальник отдела продаж.

Входные данные: копия накладной, копия договора, заказ.

Выходные данные: требование, счет, выписка из журнала, отчет, отказ от выполнения заказа.

Управление: номенклатура крепежных изделий, текущая цена крепежных изделий, устав предприятия, положение об отделе продаж.

Механизмы: сотрудник отдела продаж.

Контекстная модель представлена на рисунке 18.

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

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

Рис.19. Диаграмма декомпозиции

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

Основную функцию «Организация оплаты» можно декомпозировать на следующие действия: подсчет суммы оплаты, выставление счета, оплата счета. Основную функцию «Организация выдачи» декомпозируем так: выписка требования, сообщение на склад о подготовке товара, подготовка выписки для отдела договоров, изменение в журнале продаж. Основную функцию «Подготовка отчетов» декомпозируем на такие действия: анализ данных, выборка данных, печать отчетов. Соответствующие диаграммы представлены на рисунке 21, 22, 23.

Рис.20. Диаграмма декомпозиции A1

Рис.21. Диаграмма декомпозиции A2

Рис.22. Диаграмма декомпозиции A3

Рис.23. Диаграмма декомпозиции A4

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

⇐ Предыдущая567891011121314Следующая ⇒

Похожая информация:

Поиск на сайте:

Нотация ARIS Value-added Chain Diagram (ARIS VAD)

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

Модели AS-IS и ТО-ВЕ

Рассмотрим объекты нотации 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, при построении диаграм­мы еЕРС могут быть использованы многие другие объекты. На практике приме­нение большого числа объектов различных типов нецелесообразно, так как это значительно увеличивает размер модели и затрудняет ее прочтение.

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. Пример модели процесса

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

в нотации AR1S eEPC.

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

Рис. 2.38. Пример обработки

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

заявки и нотации AR1S PCD.

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

Нотация AR1S Organizational Chart

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

Модель строится из объектов Organizational unit, Position, Internal person и др.

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

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

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

Предыдущая78910111213141516171819202122Следующая

Модель AS-IS – это модель «как есть», т.е. модель уже существующего процесса/функции. Обследование процессов является обязательной частью любого проекта создания или развития системы. Построение функциональной модели AS-IS позволяет четко зафиксировать, какие процессы осуществляются на предприятии, какие информационные объекты используются при выполнении функций различного уровня детализации.
На основе модели AS-IS достигается консенсус между различными этапами процесса по тому, «кто что сделал» и что каждый этап добавляет в процесс. Функциональная модель AS-IS является отправной точкой для анализа потребностей предприятия , выявления проблем и “узких” мест и разработки проекта совершенствования деловых процессов. Модель AS-IS позволяет выяснить, «что и как мы делаем сейчас» перед тем, как определить то, «что и как будет делаться завтра». Анализ функциональной модели AS-IS позволяет понять, где находится проблемная ситуация, в чем будут состоять преимущества новых процессов и каким изменениям подвергнется существующая структура организации процесса. Исследование необходимости реструктуризации (выявление и ликвидация недостатков) в существующих процессах достигается за счет применения декомпозиции (анализа), производящаяся даже там, где функциональность на первый взгляд является очевидной.

Функциональная модель AS-IS

Так, например, признаками неэффективности существующих процессов могут быть:

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

При создании модели AS-IS неопытным аналитиком может возникать достаточно распространенная ошибка — это создание идеализированной модели, особенно в том случае, когда модель создается под влиянием знаний (точки зрения) руководителя. Обычно руководитель знаком с тем, как предполагается выполнение функции по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют требуемые функции. Поэтому могут создаваться модели, называемые SHOULD BE (как должно бы быть), и несущие ложную информацию и которую невозможно в дальнейшем использовать для анализа.

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

IDEF - это семейство методов моделирования, состоящее из 15 подходов описания бизнес процессов (от IDEF0 до IDEF14). Данная нотация применяется для построения функциональной модели системы . Несмотря на большое количество нотаций, входящих в эту методологию, наиболее часто применяемыми на практике являются IDEF0 и IDEF3, которые будут рассмотрены в рамках текущего анализа. Пример диаграммы IDEF0 отображающей функции и процедуры, а также потоки информации и материальных средств отображен на рис. 1.2.

Рисунок 1.2. Нотация IDEF0

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

Рисунок 1.3. Нотация IDEF3

При отслеживании потоков документации при использовании методологии IDEF возникает необходимость совместного использования нотации DFD.

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

Рисунок 1.4. Диаграмма языка UML

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

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

Рисунок 1.5. Диаграмма ARIS

Методология поддерживает четыре типа моделей, отражающих различные аспекты системы:

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

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

Таблица 1. 1. Сравнительная таблица нотаций описание бизнес-процессов

	Показатель
	Принцип построения диаграммы	Принцип иерархии		Временная последовательность выполнения процедур	Временная последовательность выполнения процедур
	Входящая информация	Стрелки сверху / слева			Используется отдельный объект
	Исходящая информация	Стрелка справа		В диаграмме активности нет - отображается в отдельной диаграмме	Используется отдельный объект
	Наглядность модели
	Возможность взаимосвязи функциональной и информационной модели
	Основная область применения методологий		Для построения модели бизнес-процессов		Для разработки основы ИС и моделирования БП

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

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

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

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

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

Разрабатываемая ИС удовлетворяет следующие требования:

• · справочный характер ИС - разрабатываемая система в диалоговом режиме предоставляет пользователям необходимую в процессе реализации проектов информацию (советы, извлеченные уроки, шаблоны документов и др.);
• · экспертный характер ИС - при заполнении системы начальными данными, в том числе определение показателей оценок методик и рангов проектов, применены опыт, мнения и советы ведущих экспертов Компании;
• · аналитический характер ИС - для реализации системы были проанализированы методики управления проектами и выбраны наиболее критичные (в рамках данного исследования) данные для включения в систему;
• · база знаний в ИС - при создании в системе нового проекта определение методики его ведения происходит посредствам семантических правил в режиме «вопрос-ответ», расчет и определение которых выполняется в соответствие с рангами методик по показателям (Приложение Б.);
• · база документов в ИС - в системе хранится ряд документов в библиотеках узла: проектные процедуры, шаблоны календарных планов, уставов и т.п.;
• · база данных в ИС - подход реализации узлов на порталах SharePoint можно представить как реляционную базу данных, в которой её таблицами являются списки SharePoint.

Системой управления реализуемых бизнес-процессов является платформа разработки ИС - MS SharePoint 2013.

Разработка информационной системы, описание бизнес-процессов и настройка системы на платформе SharePoint 2013 приведена в Главе 2.

Нотация моделирования бизнес-процессов BPMN (Business Process Modeling Notation) была впервые представлена публике еще в 2004 г. и описана консорциумом Object Management Group. В основе управления процессами в BPMN лежит идея, что сама стратегия управления опирается на три основные методологии: моделирования бизнес-процессов, анализа и оптимизации. В свою очередь, их поддерживает ряд инструментальных средств, служащих:

• для разработки стратегии, описания, анализа, документирования;
• информационной поддержки бизнес-процессов;
• поддержки потока работ (Workflow management).

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

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

• диаграммы активности UML;
• диаграмма потоков активностей и принятия решений ADF (activity decision flow);
• диаграмма событийных цепочек процесса ЕРС (event-driven process chain);
• нотация функционального моделирования IDEF (Icam DEFinition for functional modeling);
• другие модели (UMLEDOC Business Processes, RosettaNet, LOVeM).

В 2010 г. была опубликована версия BPMN 2.0, созданная при сотрудничестве многих исследовательских групп, в том числе консорциума OMG, Института Хассо Платтнера (Hasso Plattner Institut, Потсдам, Германия), университета Гумбольдта (Берлин, Германия), университетской инициативы Signavio.

В 2013 г. версия BPMN 2.0.1 была принята как международный стандарт IS0/1 ЕС 19510:2013 Информационные технологии. Модель и нотация процесса менеджмента объекта в групповом бизнесе.

Основные понятия и группы объектов в BPMN приведены в табл. 4.6.

Таблица 4.6

Основные понятия и группы объектов в BPMN

объектов	Описание
Действия	При помощи объектов Действия описываются задачи (бизнес-правила, сценарии, задачи-сервисы, задачи отправки сообщений и др.). Задачи затем детализируются, в том числе за счет маркеров действий (сценариев действий) и определения потоков (порядка и условий выполнения действий)
	События в BPMN, как и в некоторых других нотациях, относятся к категориям начальных, промежуточных и завершающих. К событиям относятся: отправка и получение сообщений, таймеры, ошибки, сигналы, остановы и другие виды событий. По сути, событие является индикатором происшествия, требующего дальнейшего участия пользователя, что возможно организовать, НЕ прерывая процесса (в отличие от предыдущих версий нотации)
Логические операторы	Логические операторы определяют порядок наступления событий процесса при ветвлении, слиянии или синхронизации
	Стандартные объекты данных (сообщения, хранилища, коллекции объектов), которые могут использоваться различными действиями
Хореография	Понятие, впервые появившееся именно во второй версии нотации BPMN. Его основная идея в отражении задач взаимодействия (обмена сообщения) между участниками (двумя и более)
Диалоги и взаимодействия	Определение характера информационных взаимодействий: один-к- одному либо один-ко-многим. Отличие от хореографии - в выделении нескольких пулов действий (swimlanes ) и детальном описании каждого из них (пример таких пулов приведен на рис. 4.17)
	Благодаря группе объектов Роли определяются: распределение обязанностей участников процесса; информационные потоки между ними; порядок обмена сообщениями

Нотация еЕРС (Extended Event-driven Process Chain, расширенная событийная цепочка процессов) предполагает описание алгоритма действий, выполняемых отдельными организационными единицами, что позволяет сформировать общий сценарий процесса как последовательность отдельных шагов.

Рис. 4.17.

Основными объектами диаграммы еЕРС являются элементы, приведенные в табл. 4.7.

Таблица 4.7

Объекты и нотация диаграмм еЕРС

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

еЕРС нс случайна названа «расширенной» диаграммой - на практике в модели такого вида могут также включаться другие объекты, например:

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

Между всеми объектами в обязательном порядке определяются связи, например, «создает» (документ), «распределяет» (задание между сотрудниками), «использует» (информационную систему 1C), «выполняет» (функцию выполняет менеджер), «принимает решение», «обеспечивает», «является владельцем» и многие другие.

Пример

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

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

Графическое описание

Рис. 4.18.

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

Архитектура интегрированных программных систем ARIS - инструментальная система моделирования бизнеса, разработанная компанией IDS Scheer AG и ныне принадлежащая Software AG.

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

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

Рис. 4.19.

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

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

Для каждого из представлений программный продукт ARIS предусматривает различные виды диаграмм:

• организационная диаграмма;
• диаграмма данных ERM;
• диаграммы BPMN 2.0;
• процессный ландшафт (цепочка добавленной стоимости VACD);
• системный ландшафт (диаграмма компонентов);
• иерархическая диаграмма активностей (whiteboard );
• диаграмма бизнес-процессов ЕРС;
• диаграмма ИТ-инфраструктуры (сети);
• диаграмма общего вида.

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

Расширения ARIS

Таблица 4.8

Дополнительные инструменты	Предоставляемые возможности
Процессная аналитика	Визуализация проблем производительности
	Получение отчетов/оповещений о достижении критических отметок показателей процессов
	Мониторинг данных, процессов и их ключевых индикаторов (например, функционально-стоимостной анализ затрат)
Управление	Управление бизнес-операциями, рисками и требованиями, контроль исключений
Управление политиками и соответствием требованиям регуляторов	Формирование карт политик в бизнес-контексте с разграничением зон ответственности
	Сочетание политик управления требованиями, рисками и процессами
	Ведение журнала аудита с возможностью формирования сложных отчетов (в том числе по контрольным панелям)
Управление взаимодействием: создание рабо- чей платформы коллаборации	Организация общих обсуждений процессов/приложений/данных
	Представление моделей процессов в формате web-страниц
	Публикация моделей процессов в интранет-сети компании
	Возможность для специалистов компании предложить свои улучшения в процессах
Симуляция	Возможность «прогона» (симуляции) моделей BPMN 2.0 и ЕРС для выявления различий моделей As-Is и То-Ве
	Получение статистики и сводной информации по результатам симуляции моделей в режиме реального времени
	Возможность проведения сценарного анализа «Что, если» для определения степени зависимости результата и показателей процессов от определенных факторов и групп факторов
Моделирование бизнес-правил	Возможность определения логики бизнес-правил и связывания сформированных с их помощью структурированных моделей с электронными таблицами (например, для анализа стоимости процесса)
Управление оптимизацией	Интеграция информации о структуре и значениях ключевых показателей эффективности процессов, моделях бизнес-процессов, информации о центрах затрат для поддержки принятия стратегических решений

Процессным подходом к организации бизнеса мир занимается уже давно и достаточно эффективно, и стандарт Business Process Model and Notation (BPMN, нотация) является процедурой продуманной с правильным описанием бизнес-процессов. Компании постоянно совершенствуют разные специализации данного стандарта и тем самым добиваются весьма существенного повышения всех качественных показателей своей работы. Нотация BPMN понятна не только для экспертов той предметной области, в которой она создавалась, её логическими выкладками может оперировать любой работник.

Моделирование и стандартизация

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

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

Специалисты

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

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

Символы (элементы) BPMN

Поддерживает и развивает BPMN организация OMG. Это не мем интернетных завсегдатаев, обозначающий "о майн гот", а весьма знаменитая фирма Object Management Group, в которой участвуют более восьмисот компаний, разрабатывающих стандарты, подобные BPMN-нотации. Всеми полезными изменениями в новых версиях мы обязаны разработчикам OMG. Именно эта организация выбрала ключевым направлением продвижение нотации UML BPMN, с помощью которой моделируются объектно-ориентированные системы. А потому при разработке диаграмм помимо концепций и понятий (поток управления, действие, объект данных и тому подобное) в BPMN много понятий, характерных для подхода объектно-ориентированного: сообщение, обмен и поток сообщений.

Символы графической нотации разобраны по назначению и объединяются в категории. Objects - объекты потока, Data - данные, Swimlanes - зоны ответственности, Connecting Objects - соединяющие объекты, Artifacts - артефакты. Поток управления, объект данных и символы объектов потока дополнительно разделяются на подгруппы по семантическому признаку, чтобы отобразить специфику происходящих событий, особенности ветвления потоков, выполнение действий и так далее. Указывают специфику за счёт дополнительных графических изображений - маркеры, иконки, помещённые внутри главного символа. Также символы событий бывают с разным видом контура и фоновым цветом.

События по времени

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

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

События: прерывание подпроцесса и тип результата

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

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

Действия

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

Task - задача. Элементарное действие, то есть неделимое. Разновидность или специфика задачи отображается маркером или иконкой в верхнем углу слева на символе действия. Задача может быть Service (сервисная), для оказания услуги, являющейся автоматизированным приложением или веб-сервисом. Send - отправка сообщения. Если хотя бы единожды сообщение отправлено, задача может считаться выполненной. Receive - получение сообщения (тот же принцип: если единожды получено сообщение, задача выполнена). Задача User - пользователя, считается характерной, выполняется исполнителем при помощи программного обеспечения и содействии других сотрудников. Задача, требующая ручного исполнения, - Manual, которая исполняется без помощи автоматизации. Business-Rule - бизнес-правило, по технологии выполнение этой задачи зависит от обстоятельств, выбрать способ помогает заданность бизнес-правила. Script - сценарий, где выполнение операций строго по порядку, описанному на распознаваемом исполнителем языке. Обычно этот вид задач выполняется автоматическими средствами.

Подпроцессы

Sub-Process - подпроцесс. Он включает в себя шлюзы в нотации BPMN, потоки операций, события и много других действий. Таким образом, подпроцесс является составным действием, части которого непосредственно отображаются внутри символа на диаграмме или же выносятся на отдельную декомпозиционную диаграмму. В последнем случае на главной диаграмме в центре подпроцесса (нижний край действия) должен отображаться знак +. Есть стандартные подпроцессы, но их недостаточно, поэтому и появились две его специфические разновидности. Это Event Sub-Process - событийный подпроцесс, который запускается всегда при появлении стартового события. Диаграмма показывает его никак не связанным с остальными действиями и потоками операций. Контур такого подпроцесса изображён точками.

Вторая разновидность - Transaction (транзакция), это состоящее из разных операций действие с удачным завершением, то есть получением положительного результата. Получить конкретный результат можно только при условии удачного завершения абсолютно всех составляющих. Если же возникают проблемы по ходу выполнения подпроцесса, результаты всех предыдущих операций будут отменены (отмена события). Такими помехами могут стать невозможность выполнения той или иной операции или некорректное выполнение её. Чтобы не отменять предыдущие события, можно попробовать неудавшуюся операцию компенсировать (компенсация события). Контур такого подпроцесса отображён двойной сплошной линией. Для включения в диаграмму всех задач или подпроцессов, используемых повторно, существует Call - вызов, который на диаграмме обозначен жирным контуром.

Шлюзы

Шлюзы в нотации BPMN предназначены для того, чтобы указывать специфику потока операций и их пропуска по параллельным или альтернативным ветвям. Шлюз может обходиться без исходящих или входящих потоков, но всегда имеет как минимум два собственных либо входящих потока, либо исходящих. Маркер внутри его символа задаёт тип шлюза. Это может быть Exclusive, XOR - эксклюзивный с исключающим "или", предназначенный для разделения потока на альтернативные маршруты. По ходу выполнения процесса активирован может быть только один из предлагаемых маршрутов. Условия пропуска содержатся рядом с обозначающей линией. Inclusive, OR - неэксклюзивный с логическим "или" шлюз, предназначенный для разделения потока на маршруты, где активируется каждый, если соблюдено условие истинности логического выражения, связанного с ним. В этом процессе можно выполнять несколько маршрутов, но если хоть в одном отсутствует истинность, то выбор невозможен.

Аналог неэксклюзивного шлюза - Complex (комплексный). Отличие в том, что определяющее активизацию того или иного потока операций выражение только одно. Parallel, AND - параллельный с логическим "и" шлюз нужен для ветвления или слияния параллельно выполняемых операций. Exclusive Event-Based - шлюз эксклюзивный, но основанный на событиях, разделяющих поток операций на альтернативные маршруты. Exclusive Event-Based Gateway to start a Process - тоже эксклюзивный шлюз, события, на которых он основан, запускают весь процесс. Это начальный символ процесса или подпроцесса, входящих потоков не имеет. Таким же образом работает и Parallel Event-Based Gateway to start a Process - шлюз параллельный, также основанный на запускающих процесс событиях. Однако при его помощи можно активировать несколько процессов одновременно, если события, связанные с ними, сработают. Входящих потоков, естественно, не имеет. На картинках ясно видна нотация BPMN в примерах построения диаграмм с двумя видами шлюзов.

Данные и потоки

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

Стандартное изображение потока операций может быть дополнено в диаграмме указанием специфических потоков. Conditional Sequence Flow - обозначение условного потока операций при ветвлении его. Отображён исходящим из действия (если нет желания использовать в диаграмме шлюз). Default Sequence Flow - поток операций, совершающийся по умолчанию, чаще всего исходит из шлюза или действия, с логическими выражениями не связан.

Примеры и выводы

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

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

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

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

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

Ниже приведён пример системы бизнес-моделирования, которая на бумаге поддерживает нотацию ARIS eEPC, но, на самом деле, ответственность закрепляется в карточке на функцию, а графические блоки используются «для красоты».

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

Процессы верхнего уровня

Самые распространённые нотации для построения процессов верхнего уровня на сегодняшний день это IDEF0 (методология функционального моделирования) и ARIS VAD (цепочка создания ценности).

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

В чём же отличие нашей схемы от IDEF0? В первую очередь в том, что в IDEF0 есть требования к тому к какой стороне блока какая стрелка должна подходить:

• стрелка входа приходит всегда в левую кромку активности
• стрелка управления - в верхнюю кромку
• стрелка механизма - нижняя кромка
• стрелка выхода - правая кромка

Является ли это важным отличием, которое даёт преимущества данной нотации перед нашим подходом? С нашей точки зрения – нет, но при желании, вы можете привести схему взаимодействий в Fox Manager в чёткое соответствие с требованиями этой нотации (сверху – оригинальная схема в IDEF0, снизу – её аналог в Fox Manager).

Как видите, при желании, вы можете моделировать схемы IDEF0 и в Fox Manager.

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

Что касается нотации ARIS VAD – то тут всё ещё проще: достаточно выстроить процессы по цепочке создания ценности и при желании показать ответственных и взаимодействия.

На картинке приведён пример такой схемы в нашей программе (сверху – оригинальная диаграмма ARIS VAD, снизу – её аналог в Fox Manager). Конечно, можно придраться в форме блоков, стрелок или подсветке, но в целом, не возникает сомнений, что в нашей программе, при желании, можно строить диаграммы в соответствии с требованиями нотации ARIS VAD.

Процессы нижнего уровня

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

Существует множество нотаций для моделирования бизнес-процессов нижнего уровня: Basic Flowchart, Cross Functional Flowchart, EPC и другие. Большинство из них имеют незначительные отличия друг от друга.

Например, если в программе Fox Manager на диаграмме свернуть блоки ответственных, документов и ресурсов, то мы получим аналог нотации Basic Flowchart (справа – оригинальный процесс, слева – аналог в Fox Manager).

Если же все блоки на диаграмме развернуть – то мы получим аналог процесса в нотации EPC . Самое замечательное то, что при использовании нотации Fox Manager блоки можно сворачивать и разворачивать динамически, и при этом не нужно создавать новую версию процесса в другой нотации. На картинке справа изображен оригинальный процесс, а слева – аналог в Fox Manager.

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

Поддержка нотации Cross Functional Flowchart была добавлена в программу в одном из наших бесплатных обновлений . Данная нотация отличается от уже рассмотренных выше нотаций тем, что на ней можно показывать ответственных дорожками, а не рядом с блоком. К сожалению, у этого способа есть свои недостатки, когда ответственных очень много – то процесс становится ненаглядным и трудночитаемым. Также возникают проблемы, когда необходимо распределить ответственность за функцию сразу двум и более должностям. Ниже приведён пример такого процесса в Fox Manager.

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

Конечно, наверное, можно сократить набор элементов этой нотации до необходимого минимума и попытаться приспособить её для целей регламентации, но при этом мы потеряем её главное преимущество – возможность исполнения процессов BPM-движком. При этом, если оставить только 5-10 необходимых блоков, то, скорее всего, внешний вид таких процессов будет очень походить на уже рассмотренные нами нотации.

Вывод

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

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

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

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

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

Но мы отдаём себе отчёт в том, что некоторые бизнес-аналитики не доверяют новым разработкам и предпочитают пользоваться старыми, знакомыми им нотациями. Цель данной статьи – показать гибкость программы Fox Manager и возможность настройки внешнего вида схем под требования большинства имеющихся на рынке нотаций. Стройте модели бизнес-процессов так, как удобно именно вам!