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

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

Можно отметить 3 самые популярные нотации: семейство IDEF, eEPC и BPMN 2.0. Я не буду рассказывать об истории возникновения, развития и правилах использования нотаций – все это можно прочитать в Википедии. Вместо этого представляю свой взгляд на их использование сугубо с практической точки зрения.

Популярные методологии моделирования бизнес процессов

Семейство IDEF

Ну всё-таки небольшое вступление будет. IDEF – это не одна нотация, а целое семейство. Различаются они по порядковым номерам – IDEF0, IDEF1, IDEF2 и т.д. Каждая нотация имеет свои особенности и используется для описания разных элементов бизнес-системы. Рассматривать будем семейство в целом.
Итак, IDEF. Первое что надо знать, IDEF является самой «старой» нотацией. Второе, она уже очень давно (десятилетия!) не развивается. Отсюда первый камень в огород. Семейство IDEF безнадежно, морально, функционально устарело.
Дальше. Использовать модели бизнес процессов, выполненных в IDEF, крайне сложно. Как для изучения, так и для анализа. Ниже представлен пример схемы бизнес процесса. Судите сами.

Нотация имеет ограничения по количеству отображаемых на схеме процессов – не больше 7. Отсюда возникает необходимость подстраивать описания под эти правила. Кроме того, существуют правила, которые сильно усложняют жизнь как «писателям» бизнес процессов, так и «читателям».
В совокупности это влечет за собой огромное количество тяжелых для восприятия, крайне запутанных схем. Но есть и плюс – вне зависимости от того, в какой программе вы составляете модель процесса в нотации IDEF, блок-схема будет ориентирована на лист формата А4 в альбомной ориентации. Т.е. распечатывать такие схемы удобно. На этом плюсы закончились)
О программном обеспечении. Да, существует огромное количество ПО, поддерживающего моделирование в этой нотации. В том числе и бесплатное. Но в большинстве своем оно тоже устарело и не позволяет решать актуальные на сегодняшний день задачи. В конце концов, нарисовать модель бизнес процесса можно в любом графическом редакторе. Начиная от элементарного Paint и заканчивая профессиональными инструментами, например, Microsoft Visio. Даже от руки на листе бумаги можно создать схему.
К слову, именно из потребности в автоматизации, т.е. в переводе моделей бизнес процессов в программу, и родились современные нотации. В том числе IDEF. Именно этим обусловлена строгость соблюдения правил моделирования. Машина может понять строгий графический язык, но не в состоянии понять текстовое описание.

Резюме – если вы встали перед выбором нотации для описания и моделирования бизнес процессов, ни в коем случае не останавливайтесь на IDEF.

Нотация eEPC

А вот это уже интересно. Само название нотации Событийная цепочка процессов (event driven process chain, «e» вначале означает extended, расширенное) говорит о том, что моделирование в данной нотации сосредоточено вокруг событий. А именно события и определяют развитие процесса.
В основе этой нотации лежит… Одна из нотаций семейства IDEF. А конкретно IDEF3. Впрочем, eEPC намного функциональнее и нагляднее.

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

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

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

Резюме – нотация eEPC является не самым плохим решением для описания и моделирования бизнес процессов.

Нотация BPMN 2.0

Скажу сразу, на мой взгляд, это лучшая нотация для описания и моделирования любых бизнес процессов.
BPMN (Business Process Model and Notation) – Нотация управления бизнес процессами. Вот так скромно и без прикрас назвал свое детище Институт управления бизнес процессами (BPI). Да, созданием и развитием BPMN занимается целый институт. Одно это говорит о том, что нотация является результатом серьезной, научно обоснованной работы. Более того, работа эта происходит постоянно, а в настоящее время нет ничего важнее постоянного развития инструментов управления. Впрочем, перейдем к сути.
BPMN – самая удобная, гибкая, наглядная, функциональная и вместе с тем простая нотация.
Существенным отличием является наличие понятия “дорожка”. Дорожка – это область в модели процесса, которая отображает все, что выполняет конкретный человек в данном процессе. Естественно, если процесс затрагивает разных людей, то посредством дорожек отображается их взаимодействие. И это крайне важно.

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

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

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

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

Есть еще возможности связки моделей BPMN и 1С. В итоге получается эффективная система управления процессами с возможностью отслеживания онлайн. Но об этом я буду рассказывать в другой раз в обзоре программ для моделирования и управления бизнес процессами.

Резюме – нотацию BPMN выбирает большинство профессионалов в управлении бизнес процессами. Она наиболее современная и активно развивающаяся. Я рекомендую работать именно с ней.

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

• Выбирайте ту нотацию, с которой у вас уже принято работать.
• Если не принято, выбирайте BPMN.
• Выбирайте ПО и соответственно ту нотацию, с которой оно работает.
• Не знаете с чего начать? Начинайте с 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 и возможность настройки внешнего вида схем под требования большинства имеющихся на рынке нотаций. Стройте модели бизнес-процессов так, как удобно именно вам!

Нотация моделирования бизнес-процессов 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

Нотация еЕРС (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

Одной из главных стадий при проектировании ИС является описание бизнес-процессов, для чего необходимо выбрать нотацию, в которой оно будет выполнено. На данный момент существует ряд наиболее распространенных языков графического описания бизнес-процессов: 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.

8.8. Методология BPMN

Модель и нотация бизнес-процессов (BPMN, Business Process Model and Notation) – методология моделирования, анализа и реорганизации бизнес-процессов. Разработана Business Process Management Initiative (BPMI), с 2005 г. поддерживается и развивается Object Management Group (OMG) . В отличие от других методологий бизнес-моделирования, имеющих статус «фирменного» () или «национального» () стандарта, BPMN получила «международный» статус – Международная организация по стандартизации опубликовала стандарт «ISO/IEC 19510:2013. Information technology - Object Management Group. Business Process Model and Notation».

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

По заявлению разработчиков стандарта BPMN, он вобрал в себя лучшие идеи, что имеются в следующих нотациях и методологиях моделирования:

o EDOC (Enterprise Distributed Object Computing, корпоративная распределенная обработка объектов) – Business Processes (бизнес-процессы);

EbXML (Electronic Business eXtensible Markup Language, расширяемый язык разметки для электронного бизнеса) BPSS (Business Process Specification Schema, схемы спецификации бизнес-процессов);

ADF (Activity-Decision Flow, поток «деятельность-результат») Diagram;

LOVEM (Line of Visibility Engineering Methodology, визуальная методология проектирования);

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

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

Элементы (символы) графической нотации BPMN по назначению объединены в категории:

Объекты потока (Flow Objects);

Данные (Data);

Зоны ответственности (Swimlanes);

Соединяющие элементы (Connecting Objects);

Артефакты (Artifacts).

В следующей таблице приведены символы нотации BPMN и их базовое изображение.

Таблица 8.3. Условные обозначения на BPMN-диаграммах

№ п/п	Символ	Наименование	Примечания
1. СИМВОЛЫ ОБЪЕКТОВ ПОТОКА
1.1		Событие (Event)	Факт (ситуация, набор условий или обстоятельств), который активирует или оказывает влияние на дальнейшее развитие одного или более процессов. Событие инициируют действия или являются их результатами. В отличие от функции, выполнение которой занимает определенный промежуток времени, событие относится к конкретной точке во времени.
1.2		Действие, деятельность (Activity)	Действие или набор действий, выполняемых исполнителем в ходе процесса. Помимо наименования действия вверху и внизу символа могут указываться имена участников.
1.3		Шлюз, логический оператор (Gateway)	Используется для обозначения слияния и/или ветвления потока событий и действий.
1.4		Обмен сообщениями (Conversation)	Описание действия, характеризующего обмен информацией между участниками (пулами) взаимодействия.
2. СИМВОЛЫ ДАННЫХ
2.1		Объект данных (Data Objects)	Товарно-материальные ценности (ТМЦ) или информация, используемые или получаемые в результате действий.
2.2		Хранилища данных (Data Stores)	База данных или ее фрагмент, содержащий информацию для выполнения действий.
2.3		Сообщение (Message)	Отражает факт передачи информации между участниками процесса.
3. СИМВОЛЫ ЗОНЫ ОТВЕТСТВЕННОСТИ
3.1		Пул, участник (Pool, Participant)	Структурное подразделение, которому поручено выполнение действия (фирма, организация, отдел, служба).
3.2		Дорожка (Lane)	Должность исполнителя или роль субъекта, которому поручено выполнение действия. Составная часть организационной единицы.
4. СИМВОЛЫ СОЕДИНЯЮЩИХ ЭЛЕМЕНТОВ (ЛИНИЙ)
4.1		Поток операций, поток управления (Sequence Flow)	Задает последовательность (до-после) возникновения событий и выполнения действий.
4.2		Поток сообщений (Message Flow)	Отражает информационный обмен между участниками процесса. Обычно соединяет действия и/или пулы двух участников процесса.
4.3		Ассоциация (Association)	Отражает связь между данными (артефактами) и объектами потока.
4.4		Ссылка на обмен сообщениями (Conversation Link)	Указывает на обмен сообщениями между участниками взаимодействия.
5. СИМВОЛЫ АРТЕФАКТОВ (СПЕЦИАЛЬНЫЕ СИМВОЛЫ)
5.1		Группа (Group)	Используется для группировки графических элементов, принадлежащих одной и той же категории.
5.2		Комментарий, текстовая аннотация (Text Annotation)	Примечание (дополнительная информация), связанная с отображенным элементом.

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

Ниже приводится описание специфики отображения символов и их семантическая интерпретация.

1. События.

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

Все события классифицируются по следующим признакам:

По времени наступления:

o стартовое событие – инициирует начало процесса (диаграммы). Из стартового события поток управления может только исходить, а поток сообщений - как входить, так и исходить. На диаграмме процесса, как правило, отображается только одно стартовое событие, но оно может отсутствовать или их может быть несколько при отображении процесса с пулами, дорожками или развернутыми подпроцессами. Контур события отображается одинарной тонкой линией;

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

o промежуточное событие – все остальные события, возникающие в ходе выполнения процесса. В промежуточное событие обязательно должен входить и выходить один поток. Исключение составляет граничные (Boundary) события, возникающие и обрабатываемые непосредственно либо в самом начале действия либо в его конце. Такие события отображаются на границе (контуре) действия и у них может быть только либо входящий либо исходящий поток. Контур события отображается двойной тонкой линией;

По возможности прерывания выполнения действия (подпроцесса):

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

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

По типу результата действия:

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

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

По причине возникновения (триггеру) – см. табл. 8.4:

Таблица 8.4. Условные обозначения событий на BPMN-диаграммах

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

Рис. 8.9. Пример использование различных типов событий по времени возникновения и результату действия

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

Рис. 8.10. Пример использование различных типов событий по возможности прерывания выполнения действия

2. Действие.

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

Различают три основных вида действий и их разновидности :

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

o - сервисная (Service). Задача предназначена для оказания услуги, которая может являться как веб-сервисом, так и автоматизированным приложением;

o - отправка сообщения (Send). Задача считается выполненной, если сообщение послано хотя бы один раз;

o - получение сообщения (Receive). Задача считается выполненной, если сообщение получено хотя бы один раз;

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

o - ручное исполнение (Manual). Характерная задача, выполняемая исполнителем без каких-либо средств автоматизации;

o - бизнес-правило (Business-Rule). Задача, технология выполнения которой зависит от текущих обстоятельств и выбирается на основе заданного бизнес-правила;

o - сценарий (Script). Задача, порядок выполнения операций которой описан на языке, распознаваемом исполнителем. Обычно используется для задач, выполняемых автоматическими средствами;

Подпроцесс (Sub-Process) – составное действие, включающее в себя другие действия, шлюзы, события и потоки операций. Части подпроцесса могут непосредственно отображены на диаграмме внутри символа действия или вынесены на отдельную диаграмму декомпозиции. Во втором случае на родительской диаграмме в центре нижнего края действия (подпроцесса) отображается символ + . Кроме стандартных подпроцессов, имеется еще две специфические его разновидности:

o - событийный подпроцесс (Event Sub-Process). Запускается каждый раз, когда происходит одно из стартовых событий. На диаграмме событийный подпроцесс не связан с другими действиями потоками операций. Контур подпроцесса отображается точками;

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

Вызов (Call). Позволяет включать в состав диаграммы повторно используемые задачи и подпроцессы. На диаграмме выделяется жирным контуром.

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

Цикл (Loop). Действие выполняется в цикле с пред- (while) или пост- (repeat-until) условием;

- ||| или ≡ - многоэкземплярность (Multi-Instance). Параллельное или последовательное выполнение нескольких экземпляров однотипных действий. При последовательном выполнении действие можно рассматривать как цикл с параметром (for);

Компенсация (Compensation). Действие выполняется взамен стандартного при невозможности его удачного завершения;

- ~ - настраиваемый подпроцесс (Ad-Hoc). Указывается только для подпроцессов. Конкретный состав и последовательность входящих в него действий определяется исполнителем в процессе его выполнения.

В общем случае для действия может быть указано несколько маркеров.

3. Шлюз.

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

- , – эксклюзивный (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). Аналогичен предыдущему, но возможна активация сразу нескольких маршрутов в случае срабатывания событий, с которыми они связаны. Возможно асинхронное выполнение маршрутов (связанных потоков операций и действий). Т.е. после активации и начала выполнения одного из маршрутов, другие маршруты тоже могут быть активированы и выполнены, пока не наступил момент завершения процесса (подпроцесса). Не имеет входящих потоков.

На рис. 8.11 показан пример диаграммы с двумя различными типами шлюзов (эксклюзивным и основанным на событиях).

Рис. 8.11. Пример использование различных типов шлюзов

4. Объект данных.

С помощью дополнительных маркеров на диаграмме может быть показана специфика использования и содержания данных:

- – входные данные (Data Inputs). Исходные ТМЦ или информация для выполнения действий. Отображается у верхнего края символа;

- – выходные данные (Data Outputs). Результат действия. Отображается у верхнего края символа;

- ||| – набор данных (Data Collection). Коллекция или массив однотипных данных. Отображается у нижнего края символа.

Связь между объектом данных и действиями отображается с помощью ассоциации.

5. Потоки операций.

В дополнение к стандартному изображению потока операций, на диаграмме могут быть указаны специфические потоки:

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

- – поток операций по умолчанию (Default Sequence Flow). Используется при ветвлении потоков. Может исходить из действия или шлюза. Не связан ни с каким логическим выражением. Поток по умолчанию активируется, если активация других потоков в соответствии с их логическими выражениями или событиями невозможна.

На рис. 8.12 показан пример диаграммы со специфическими потоками управления (условным и по умолчанию).

Рис. 8.12. Пример использование специфических потоков управления

Все многообразие процессов и способов взаимодействия между их участниками в BPMN поделено на типы (sub-model). Каждому из типов соответствует своя семантика и набор отображаемых элементов.

Таблица 8.5. Разновидности диаграмм (типы процессов) BPMN

Наименование диаграммы (процесса)			Назначение		Примерный вид
Диаграмма процесса (Process Diagram)	Частный (внутренний) бизнес-процесс (Private (internal) Business Process)	неисполняемый (Non-executable)	Процесс, выполняемый одним участником без указания на диаграмме других участников взаимодействия. Степень детализации (абстракции) участник процесса может быть произвольным (организация, отдел, сотрудник). Допускается использование на диаграмме пула, а внутри него дорожек, но потоки операций и сообщений не должны выходить за рамки пула.	Используется для высокоуровневого моделирования процесса. Отображен на диаграмме в общем виде, т.е. с такой степенью детализации, что его выполнение в реальных условиях по схеме, отображенной на диаграмме, как правило, невозможно из-за отсутствия описания возможных нюансов его исполнения. В частности, на диаграмме обычно отсутствуют шлюзы и условные выражения.
		исполняемый (Executable)		Используется для детализированного (обстоятельного) моделирования с описания всех возможных нюансов выполнения процесса.
	Публичный (открытый) процесс (Public Process)		Используется для отображения взаимодействия между частным процессом и другим процессом или участниками, отображенным в виде свернутых пулов.
Диаграмма хореографии (Choreography Diagram)			Используется для отображения частного процесса в виде действий, подразумевающих обмен сообщениями. Вверху и внизу символа действия указываются участники обмена сообщениями, с которыми непосредственно связаны отсылаемые/получаемые сообщения. Инициатор конкретного взаимодействия и его сообщение на диаграмме отображаются без заливки, принимающая сторона (обработчик запроса) и его сообщение (ответ) - с заливкой.
Диаграмма взаимодействия (Collaboration Diagram)	процессов (Process)		Используется для отображения состава и последовательности выполнения двух и более процессов в виде пулов с указанием взаимодействия между их составляющими через потоки сообщений.
	посредством обмена сообщениями (A view of Conversations)		Используется для отображения взаимодействия между участниками процесса через наборы потоков сообщений. Набор потоков сообщений представляется в виде символа обмена сообщениями, связанного ссылками с участниками информационного взаимодействия.

На следующих рисунках показаны примеры диаграмм разного типа из стандарта BPMN 2.0, построенные для одного и того же процесса.

Рис. 8.13. Диаграмма внутреннего процесса

Рис. 8.14. Диаграмма открытого процесса

Рис. 8.15. Диаграмма взаимодействия процессов

Рис. 8.16. Диаграмма хореографии

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

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

2. На диаграмме не должны присутствовать элементы без единой связи.

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

4. Каждый шлюз слияния должен обладать минимум двумя входящими связями, шлюз ветвления - минимум двумя исходящими.

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

Рис. 8.17. Примеры ветвления на альтернативные потоки по логическим выражениям

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

Рис. 8.18. Примеры ветвления на альтернативные потоки в зависимости от произошедших событий

7. Шлюз, разветвляющий ветки, и шлюз, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда шлюз ветвления «И», шлюз объединения – «ИЛИ».

Примеры допустимых и недопустимых ситуаций приведены на следующем рисунке.

а) допустимые ситуации

б) недопустимые ситуации

Рис. 8.19. Примеры допустимого и недопустимого использования шлюзов

8. Количество пересечений линий следует минимизировать. При этом считается, что пересекающиеся линии не имеют логической связи друг с другом. Другими словами, потоки в местах пересечений не меняют своего направления.

8.10. Примеры построения BPMN-диаграмм для расчета допускаемых скоростей

В качестве иллюстрации использования BPMN-диаграмм выбрана процедура расчета допускаемых скоростей. На диаграмме ей соответствует функция «Расчет допускаемых скоростей» (см. рис. 6.21), а на – процесс «Рассчитать допускаемые скорости» (см. рис. 6.24). Содержательное описание процедуры приведено в разделе .