Что обозначают горизонтальные дорожки в диаграммах bpmn
Нотация BPMN
Диаграмма, описанная в нотации BPMN, представляет собой алгоритм (сценарий) выполнения процесса, а также отображение того, как процесс взаимодействует с другими процессами с точки зрения обмена сообщениями (информацией, документами и другими функциональными объектами). Алгоритм выполнения процесса представляется на диаграмме с помощью объектов потока (событий, процессов, шлюзов), которые связываются между собой потоками управления, определяющими ход выполнения процесса. Подробнее об объектах, используемых на диаграмме процесса BPMN, описано в методике Проектирование системы управления в главе Нотация BPMN.
Палитра элементов окна диаграммы процесса в нотации BPMN
Описание назначения кнопок палитры элементов Окна диаграммы процесса в нотации BPMN приведено в статье Нотация BPMN.
Работа с объектами диаграммы процесса в нотации BPMN
Для всех объектов диаграммы можно выбрать другой объект из справочника с помощью пункта контекстного меню Сменить объект. Для процесса в этом случае будет создана ссылка на единицу деятельности выбранного типового процесса. На диаграмме процесса в нотации BPMN фигура «Ссылка на единицу деятельности» обозначается жирной линией, а сами ссылки на единицу деятельности в нотации BPMN называются процессами с типом «Вызов».
При переименовании оргединицы или функционального объекта на диаграмме BPMN новое название может совпасть с названием объекта, уже существующего в соответствующем справочнике. При этом дальнейшая работа программы аналогична ситуации, возникающей при переименовании события (см. Рис. 12).
Для добавления существующих объектов на диаграмму можно пользоваться механизмом Drag&Drop, то есть «перетаскивать» их из Навигатора или из Окна справочника.
При использовании на диаграмме дорожек добавляемая задача помещается на дорожку оргединицы, которая его выполняет. При этом автоматически создается связь единицы деятельности с оргединицей с типом «выполняет». Тип этой связи может быть изменён пользователем вручную в Окне свойств этой оргединицы или единицы деятельности на любой другой. При перемещении задачи из дорожки одной оргединицы на дорожку другой оргединицы в свойствах этой связи вместо оргединицы дорожки откуда переместили задачу, пропишется оргединица дорожки, куда переместили задачу, а тип связи останется неизменным. Если задачу вынести за пределы дорожек оргединиц, соответствующая связь будет удалена.
Работа с дорожками
В системе Business Studio в качестве исполнителя единицы деятельности может выступать как оргединица, так и функциональный объект (Программный продукт, База данных, Материальный объект или Прочее).
На диаграммах нотации BPMN исполнители показаны в виде дорожек.
Для добавления функциональных объектов на диаграмму в виде дорожек исполнителей, в выпадающем меню кнопок добавления объекта данного типа на палитре элементов окна диаграммы должен быть выбран тип фигуры «Дорожка» (уголок у таких кнопок закрашен красным цветом). Добавлять дорожки на диаграмму для таких объектов можно любым из следующих способов:
Оргединицы на диаграмму процесса в нотации BPMN добавляются перетаскиванием из иерархического справочника оргединиц, который показывается в Навигаторе. Подробнее о перетаскивании фигур на диаграмму см. Добавление фигур на диаграмму перетаскиванием.
Внимание! Задача считается помещенной в дорожку исполнителя по центральной точке фигуры (Рис. 3).
При увеличении ширины фигуры диаграммы, расположенной внутри дорожки исполнителя, ширина этой дорожки будет также пропорционально увеличиваться.
Для изменения ширины дорожки выделите её и подвиньте значок на боковой грани заголовка (подробнее о графической трансформации объектов на диаграмме см. Графическая трансформация фигур на диаграмме). Высоту поля заголовка дорожки также можно изменить, передвигая значок на верхней или нижней грани заголовка. При изменении высоты заголовка одной дорожки меняется высота заголовка всех других.
Для изменения ширины сразу всех дорожек диаграммы выделите группу дорожек и подвиньте значок на боковой грани контура группы.
При добавлении очередной дорожки может оказаться, что страница диаграммы не вмещает её (Рис. 4). Новая дорожка, тем не менее, будет добавлена на диаграмму. Для того чтобы на листе отображалось все содержимое, можно изменить масштаб диаграммы. Подробнее об изменении параметров страницы диаграммы см. Изменение параметров страницы диаграммы.
Работа с процессами
Процесс BPMN представляет собой действие или набор действий, выполняемых над исходным объектом (документом, материальным объектом и прочим) с целью получения заданного результата. Процессы BPMN подразделяются на задачи (простые действия, не имеющие дальнейшей декомпозиции) и подпроцессы (декомпозированные процессы), которые в свою очередь могут быть разных типов. Тип подпроцесса можно выбрать еще до декомпозиции процесса.
На диаграмме тип цикла для задачи или подпроцесса определяется при помощи подменю Тип цикла в контекстном меню, вызываемого от процесса (Рис. 6).
Для выбора типа процесса «Компенсация» в контекстном меню, вызываемом от процесса, можно установить флажок в пункте меню Компенсация (Рис. 7).
Работа с событиями
Событие представляет собой состояние, которое является существенным для целей управления бизнесом и оказывает влияние или контролирует дальнейшее развитие одной или более бизнес-процессов. События могут активизировать задачи (то есть привести к началу выполнения задачи), а могут быть результатом выполнения задачи.
На палитре элементов предусмотрены отдельные кнопки для добавления стартового события, промежуточного события-инициатора и конечного события. После добавления события на диаграмму первоначально выбранный тип события можно изменить при помощи подменю Тип события в контекстном меню, вызываемом от события (Рис. 8).
По умолчанию события добавляются на диаграмму с типом триггера «Неопределенное». На диаграмме тип триггера определяется при помощи подменю Тип триггера в контекстном меню, вызываемом от события (Рис. 9).
Для добавления граничного события необходимо сначала просто добавить на диаграмму промежуточное событие. Затем, удерживая левую клавишу мыши, необходимо добавленное событие присоединить к границе фигуры так, чтобы появился индикатор присоединения (Рис. 10).
После присоединения события к границе фигуры, тип события (граничное прерывающее, граничное непрерывающее) можно изменить при помощи подменю Тип события в контекстном меню, вызываемом от события (Рис. 11). Тип триггера можно сменить при помощи подменю Тип триггера в контекстном меню, вызываемом от события (см. Рис. 9).
В свойствах события можно задать «Параметры имитации», которые будут использоваться при проведении имитации (см. Имитационное моделирование).
В справочнике События ( Главное меню → Справочники → События ) от любого события можно выполнить «Отчет по событию», который содержит перечень процессов, на диаграммах которых событие является стартовым или конечным, и перечень процессов, порождающих событие или активизируемых событием.
Работа с шлюзами
Шлюзы представляют собой точки разветвления и слияния потоков управления процесса. Шлюзы могут быть различных типов. На палитре элементов Окна диаграммы предусмотрены отдельные кнопки для добавления эксклюзивного шлюза, параллельного шлюза и неэксклюзивного шлюза, а также кнопка для добавления шлюза с выбором его типа. После добавления шлюза любого типа на диаграмму его тип можно сменить при помощи подменю Тип шлюза в контекстном меню, вызываемом от шлюза (Рис. 12).
Работа с свернутыми пулами
Свернутый пул обозначает внешний (по отношению к текущей диаграмме) процесс или внешнюю ссылку. В качестве свернутого пула могут использоваться внешние процессы или объекты справочника «Внешние ссылки». Свернутый пул используется для указания взаимосвязей процесса:
Создание связей
На диаграмме процесса в нотации BPMN можно использовать 3 типа соединений элементов: потоки управления (соединяют элементы основного потока процесса: события, процессы, шлюзы), потоки сообщений (соединяют события и процессы основного потока процесса с внешними процессами и внешними ссылками, находящимися за рамками текущего процесса) и ассоциации (соединяют объекты данных с событиями и процессами основного потока, а также с внешними процессами и внешними ссылками).
Потоки управления могут быть условными потоками и потоками управления по умолчанию. Такие потоки могут исходить из процесса или эксклюзивного/неэксклюзивного шлюзов. Условный поток управления используется тогда, когда необходимо показать, что по рассматриваемому потоку будет происходить дальнейшее выполнение процесса только в том случае, если выполнится условие, указанное в названии потока. Поток управления по умолчанию используется тогда, когда необходимо показать, что по рассматриваемому потоку будет происходить дальнейшее выполнение процесса только в том случае, если не выполнилось ни одно из условий, заданных на условных потоках управления, исходящих из процесса или эксклюзивного/неэксклюзивного шлюза.
Тип потока управления, исходящего из процесса, можно сменить на условный поток или поток по умолчанию при помощи подменю Тип потока управления в контекстном меню, вызываемом от потока управления (Рис. 13). Тип условного потока управления, исходящего из эксклюзивного/неэксклюзивного шлюза, можно сменить на поток по умолчанию при помощи этого же подменю.
В справочниках типов связей ( Главное меню → Справочники → Типы связи ) можно создать собственные типы связей.
На диаграмме процесса в нотации BPMN можно показывать передачу объектов по потокам управления или потокам сообщений, связывающих 2 элемента.
В случае если объект данных передается между двумя последовательно соединенными процессами, то можно использовать тип связи «Ассоциация», которая присоединяется к потоку управления и строится в направлении от объекта данных к потоку управления, связывающему два процесса. После добавления ассоциации последовательно будет предложено выбрать типы связи: тип связи единицы деятельности с объектом данных и тип связи объекта данных с единицей деятельности. Подобно ассоциации, связанной с потоком управления, объекты данных можно присоединять ассоциацией к потокам сообщений. При этом также будет создано две связи: связь единицы деятельности с объектом данных и связь объекта данных с единицей деятельности. Выбрать тип соответствующей связи также будет предложено последовательно. Например, на Рис. 16 Объект данных 2 передается из Задачи 1 в Задачу 2. А Объект данных 1 передается из свернутого пула «Процесс 2» в Задачу 1.
Нотация BPMN
В нотации BPMN выделяют пять основных категорий элементов:
Перечисленные элементы помещаются на диаграмму в виде различных фигур перетаскиванием из справочника, либо при помощи кнопок палитры элементов окна диаграммы. Часть кнопок имеют закрашенный треугольник на иконке – у таких кнопок есть выпадающий список для выбора типа фигуры (см. Рис.1)
Описание назначения графических символов, используемых в нотации BPMN приведено в Таблице 1.
Для процессов BPMN (и для задач, и для подпроцессов) предусмотрено обозначение циклического выполнения. Для процесса BPMN можно задать следующие типы циклов:
— Стандартный цикл (используется, когда количество циклов заранее неизвестно. Процесс будет выполняться в цикле, пока верно некоторое условие);
— Многоэкземплярный параллельный цикл (используется, когда количество циклов известно заранее. При этом экземпляры процесса будут выполняться параллельно);
— Многоэкземплярный последовательный цикл (используется, когда количество циклов известно заранее. При этом экземпляры процесса будет выполняться последовательно).
Изменение типа задачи или подпроцесса, типа цикла или выбор для процесса типа «Компенсация» осуществляется при помощи подменю в контекстном меню, вызываемом от процесса на диаграмме. Подробнее об особенностях работы с процессами на диаграмме процесса в нотации BPMN см. Руководство пользователя в статье Процессы.
На Рис.6 изображено использование граничного непрерывающего события. Если при выполнении Процесса 1 возникнет Событие 2, то выполнение Процесса 1 продолжится. На текущей диаграмме дальнейшее выполнение процесса будет происходить по потоку, исходящему от граничного события, т.е. начнется выполнение Процесса 3. А также после выполнения Процесса 1 начнет выполняться Процесс 2
Подробнее об особенностях работы с событиями на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье События.
На Рис.8 параллельный шлюз используется для слияния потоков управления или синхронизации параллельных веток выполнения процесса. Выполнение Процесса 3 запустится только тогда, когда выполнится и Процесс 1, и Процесс 2.
Подробнее об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Эксклюзивный шлюз может использоваться и для слияния потоков управления. В данном случае шлюз просто пропускает через себя все потоки управления без синхронизации. На Рис.10 Процесс 3 будет выполнен дважды: после выполнения Процесса 1 и после выполнения Процесса 2.
Подробнее об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Показать ветвление потоков управления подобно неэксклюзивному шлюзу можно при помощи условных потоков управления (Рис.20).
Неэксклюзивный шлюз может использоваться для слияния потоков управления. В данном случае шлюз может использоваться для синхронизации. На Рис.12 Процесс 3 будет выполнен только тогда, когда выполнится и Процесс 1, и Процесс 2.
Подробнее об особенностях использования неэксклюзивного шлюза для слияния потоков управления при имитационном моделировании см. в методике Имитационное моделирование деятельности в статье Ветвление и слияние типа «ИЛИ» в нотации BPMN.
Об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Подробнее об особенностях использования комплексного шлюза для слияния потоков управления при имитационном моделировании см. в методике Имитационное моделирование деятельности в статье Ветвление и слияние типа «ИЛИ» в нотации BPMN.
Об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Существует 2 типа шлюзов по событиям, которые могут быть использованы в начале процесса:
— эксклюзивный шлюз по событиям (для запуска процесса) (Рис.15);
— параллельный шлюз по событиям (для запуска процесса) (Рис.16).
В случае, когда шлюз по событиям используется для запуска процесса, у него не должно быть входящих связей.
Эксклюзивный шлюз по событиям (для запуска процесса) аналогичен обычному эксклюзивному шлюзу по событиям: событие, идущее после шлюза и возникшее первым, определяет дальнейший ход выполнения процесса.
На Рис.15 выполнение процесса начнется с возникновения одного из событий, идущих после шлюза:
— если первым возникнет Событие 1, то дальнейшее выполнение процесса будет осуществляться только по потоку управления, исходящему из этого события, т.е. выполнится Процесс 1;
— если первым возникнет Событие 2, то дальнейшее выполнение процесса будет осуществляться только по потоку управления, исходящему из этого события, т.е. выполнится Процесс 2.
При использовании параллельного шлюза по событиям (для запуска процесса) выполнение процесса запускается по всем возникшим событиям, идущим после шлюза.
На Рис.16 Процесс 1 и Процесс 2 будут выполнены, если возникнут события, идущие перед этими процессами.
Подробнее об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Краткое описание BPMN с примером
О том, что такое BPMN, написано очень много. Но проблема в том, что почти вся информация, которую можно найти в Интернет, ориентирована на людей, которые уже ранее сталкивались с BPMN или с другим стандартом моделирования бизнес-процессов. Я же предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она появилась и оказалась столь востребованной, по крайней мере, за рубежом. Да и у нас в стране ей все больше и больше интересуются.
Также я хочу сразу обратить ваше внимание на то, что здесь я буду говорить именно о нотации BPMN, т.е. о языке моделирования бизнес-процессов. Я, конечно, постараюсь максимально просто описать основы BPMN так, чтобы они были понятны даже новичкам. Но также важно понимать, что здесь я буду говорить именно о языке, а не о методологии.
Методология моделирования бизнес-процессов — это понятие очень обширное, по сути, это та самая база, знания которой нужны для практического применения языков моделирования бизнес-процессов. О ней я буду говорить в будущих статьях и не раз. Почему я делаю на этом акцент? Многие люди (и я в свое время также) считают, что достаточно выучить язык бизнес-моделирования, и вы сумеете выстраивать бизнес-процессы. 
Практика показывает, что без базовых знаний здесь не обойтись. И всем, кто только планирует изучение моделирования, я настоятельно советую сначала ознакомиться с методологией, понять общие принципы бизнес-моделирования, получить определенные навыки бизнес-анализа. И только потом приступать к изучению BPMN или любого другого языка.
А для понимания причин появления BPMN и всех нюансов моделирования при помощи этой системы нотаций, понадобится также знание основных проблем, которые решает BPMN, что для работы использовали до появления BPMN, и с какими сложностями сталкивались. Ведь появление новых систем и нотаций невозможно без понимания определенной проблематики. И я считаю, что этот аспект очень важен для понимания сути вопроса, что же такое на самом деле BPMN.
Лично я познакомился впервые с BPMN около восьми лет назад, когда начал изучать систему Bizagi Modeler. Заинтересовался я этой системой по причине того, что давно уже понимал всю важность моделирования. До этого я лично пользовался IDEF0 и IDEF3, но там я сталкивался с определенными ограничениями. Дело в том, что IDEF0 несколько ограничен по числу возможностей. А IDEF3 мне лично показался излишне строгим и «сухим», в нем было сложно моделировать многие виды бизнес-процессов с участием программных продуктов.
В то время Bizagi был относительно простым модулем, в котором присутствовал удобный редактор для моделирования (рисования) бизнес процессов, но еще не было никаких инструментов для исполнения бизнес-процессов. Но даже тогда строгие правила BPMN, принятые в системе Bizagi, помогали избегать значительного числа ошибок, столь частых при обычном «рисовании» бизнес-процессов в графических редакторах или на бумаге.
В поисках оптимального решения для себя я изучал ARIS, инструменты 1С для бизнес-моделирования, различные системы моделирования бизнес-процессов, которые были придуманы различными бизнес-консультантами, как российскими, так и зарубежными. И, конечно же, познакомился с нотацией BPMN.
При первом знакомстве BPMN мне во многом понравился, идея была очень хорошей, а вот исполнение на тот момент с моей точки зрения еще было «сырым». И полноценно пользоваться BPMN я начал около 3 лет назад, после того, как задачи, которые я стал решать, усложнились настолько, что IDEF0 применять полноценно никак не получалось. И оказалось, что нотация развивалась, и теперь я активно пользуюсь BPMN в своей работе.
BPM: ОСНОВНЫЕ ПОНЯТИЯ
Для того чтобы разобраться, что такое BPMN, нужно понимать, что часть этой аббревиатуры «BPM» имеет две расшифровки — Business Process Modeling и Business Process Management. В первом случае – это непосредственно моделирование бизнес процесса, а во втором – управление бизнес-процессами, т.е. общая система, частью которой и является Business Process Modeling.
При этом моделирование бизнес-процессов – является основой и основной целью. При помощи моделирования мы можем описать любой бизнес процесс, а исполняться они могут в самых разных системах управления.
Есть и еще одно понятие, о котором стоит сразу упомянуть – это «BPMS», т.е. Business Process Modeling System. Этот термин описывает те самые системы управления, в которых производится моделирование, а также исполнение бизнес-процессов.
Можно сказать, что BPMN является частью двух важнейших составляющих:
ЯЗЫК ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ
Когда впервые сталкиваешься с моделированием бизнес-процессов, очень тяжело понять, с чего же тут начать, где искать основу для понимания того, как строятся бизнес-модели. И я также с этим в свое время столкнулся.
А основой здесь является наличие языка описания бизнес-процессов. И важно понимать, что это действительно язык, как и языки программирования или даже языки, на которых говорят люди, он также прост на базовом уровне и сложен, если начинать изучать нюансы. У этого языка есть свои правила, семантика, орфография, свои законы, которые нужно изучить и строго им следовать. С другой стороны, как и любой искусственный язык, предназначенный не для живого общения, а для строгого и однозначного описания каких-то действий и процессов, он в своей основе проще “живых” языков, а его правила — строго логичны.
Кроме того, в силу ограниченности задач, которые стоят перед этим языком, он гораздо более определен в терминологии. Но все же и здесь имеется очень много нюансов, каких-то сочетаний «слов», которые несут собственную смысловую нагрузку. И очень важно строго следовать правилам сочетания разных элементов языка и знать ограничения (что с чем сочетать недопустимо, как начинать описание, чем заканчивать и пр.).
И как любой технологический язык, описание бизнес-процессов имеет собственные специфические конструкции, понять которые без определенного уровня технологических знаний будет крайне затруднительно. А потому для изучения языка описания бизнес-процессов также важно, в первую очередь, понимать сами технологии, для описания которых он предназначен.
Например, для моделирования бизнес-процессов вам понадобится знание таких понятий, как «условия», «цикл», «декомпозиция» и т.д.
Важно понимать: BPMN не является языком описания IT-систем. Эта нотация предназначена для описания предметной области реального бизнеса. И здесь могут быть задействованы как программные системы, так и люди (сотрудники компании, заказчики, поставщики). Это самое главное отличие этой нотации от графических инструментов для описания программ.
НЕМНОГО ИСТОРИИ BPMN
Для большего понимания особенностей моделирования бизнес-процессов и структуры языка моделирования, я хочу немного рассказать об истории появления нотации BPMN. Разработка системы моделирования бизнес-процессов и спецификаций для нее (языка моделирования) ведется относительно давно.
Первая версия BPMN 1.0 была выпущена в мае 2004 года компанией Business Process Management Initiative. Эта версия обладала ограниченными возможностями и была, так сказать, «пробным вариантом», который нуждался в многочисленных доработках.
Следующая версия BPMN 1.1 выходит в январе 2008, и здесь разработкой и поддержкой занималась уже Object Management Group, организация, появившаяся в результате слияния BPMI с другой компанией-разработчиком программного обеспечения.
Еще один релиз появляется всего через год, версия BPMN 1.2 выходит в свет в январе 2009. Разработчик OMG остается прежним. Команда, которая занимается продуктом, после слияния практически не меняется.
В январе 2011 года компания OMG выпускает версию BPMN 2.0, а в декабре 2013 выходит последний на данный момент релиз – BPMN 2.0.2. Именно эта версия предлагается всем пользователям и сегодня, так как система получилась стабильной, возможности моделирования в ней очень широкие, а язык моделирования (набор обозначений) по большей части понятен всем бизнес-пользователям – как бизнесменам, бизнес-консультантам, так и техническим специалистам.
Из истории можно сделать вывод что период изменений в этом языке миновал, и можно спокойно изучать и использовать его на практике.
Сегодня BPMN – это один из наиболее распространенных методов описания бизнес-процессов, которые сегодня уже «понимают» как бизнес-пользователи, так и программные продукты, предназначенные для работы с бизнес-моделями. Т.е. этот язык описания является стандартным также и для создания исполняемых алгоритмов в сфере управления бизнесом.
Я особенно хочу подчеркнуть этот момент, так как и сам столкнулся поначалу с непониманием, зачем те или иные вещи усложнять? Ведь для описания бизнес-процессов, например, при GAP-анализе (анализ разрывов) или для представления заказчику бизнес-модели в какой-то упрощенной форме, всего многообразия элементов BPMN вам не нужно. Но когда начинается автоматизация, когда бизнес-модель становится не просто удобной схемой, а может экспортироваться в другие программные продукты в качестве исполняемых данных, все становится на свои места. Последняя версия BPMN действительно стабильна и все требования к языку обоснованы.
ИЗ ЧЕГО СОСТОИТ НОТАЦИЯ BPMN?
И здесь я хочу сделать небольшое отступление. Дело в том, что перевод терминов и понятий с английского языка на русский – занятие сложное. Найти наиболее точное слово обычно может специалист, но переводом занимается совсем другой человек, часто вообще не имеющий понятия о сути тех понятий, которые он переводит. В результате появляется множество неточностей, понятия усложняются, возникает путаница. Об особенностях перевода и сложностях применения терминов в сравнении с графикой я уже писал, например, в статье Знакомство с нотацией IDEF0 и пример использования (см. раздел “Несколько слов о преимуществах графики”).
Я в этой статье буду оперировать теми понятиями и терминами, которые использую сам на практике. И они не всегда будут совпадать с теми словами, которые вы встречали в Википедии или каких-то переведенных руководствах. Причина заключается именно в том, что я, как специалист, в некоторых случаях нашел для себя более точный перевод английского термина. И применение слова, которое выбрал для себя я, помогает понять суть процесса намного быстрее.
Конечно, я буду пояснять всю терминологию по мере необходимости. А потому думаю, что проблем с пониманием и терминами не возникнет. Но все же обратить внимание на этот момент, я считаю правильным.
Язык описания бизнес-процессов опирается на следующие базовые объекты:
Я же остановлюсь только на базовых элементах, без которых не обходится ни одна бизнес-модель. Для первого знакомства с BPMN и понимания основных принципов работы нотаций этого достаточно.
EVENT (СОБЫТИЕ)
Event – это то событие, которое произошло в описании процесса или хореографии (о ней я расскажу отдельно). Эти события могут быть начальными, конечными или промежуточными.
Например, опишем процесс получения заказа от клиента по телефону:
ACTIVITY (ДЕЙСТВИЯ)
Activity – это те действия (задачи), которые должны быть выполнены на определенном этапе бизнес-процесса. Их при моделировании обычно обозначают в виде прямоугольников, в которые вписывают суть действия.
Действия могут быть элементарными, т.е. неделимыми на какие-то более простые действия, так и не элементарными, т.е. такими, которые при детализации делятся на последовательность определенных более простых действий.
Обычно действия делят следующим образом:
GATEWAY (ШЛЮЗ, РАЗВИЛКА)
Gateway – это контрольный узел, который появляется в случае условного ветвления бизнес-процесса. Графически изображается в виде ромба.
Также шлюзы необходимы в случаях, когда порядок действий зависит от тех или иных факторов. Например, при работе с заказчиками шлюз появляется на этапе принятия клиентом решения о покупке – «да или нет». При положительном решении необходимо оформить покупку, при отрицательном – выяснить возможные причины отказа, провести работу с «отказом» и т.д.
FLOW (ПОТОК) И MESSAGE FLOWS (ПОТОК СООБЩЕНИЙ)
Поток Flow – это последовательность действий, обозначается как стрелка, и показывает, какое действие после какого необходимо совершить.
Message Flows – это пунктирные стрелки в бизнес-модели, которые показывают сообщения, которыми обмениваются участники бизнес-процесса. Например, если заказ переходит от клиента в обработку в отдел продаж, он сопровождается сообщением, которое содержит информацию об этом заказе. Также Message Flows могут связывать два отдельных пула в диаграмме.
Message Flows Association – еще один вид линий, в отличие от сообщений, которые являются пунктирными линиями, этот вариант отображается в виде последовательности не отрезков, а точек. Необходима для того, чтобы показывать артефакты (о них – ниже).
POOL (ПУЛ)
Пул – это объект описывающий какой-то один процесс на диаграмме. Он может быть не изображен на диаграмме, но он всегда есть. На одной диаграмме может быть несколько Пулов. Пул можно развернуть для просмотра деталей.
Пул может также содержать, так называемые, «дорожки». Они нужны для того, чтобы указать участников процессов, которые скрыты в пуле. Например, в процессе работы с клиентами участвует менеджер по продажам, руководитель отдела продаж, возможно, бухгалтер или кассир.
DATE OBJECT (ДАННЫЕ, ОБЪЕКТЫ ДАННЫХ)
Объекты данных – это элемент, который показывает, какие данные и документы нужны для того, чтобы какое-то действие запустилось, либо которые являются результатом выполненного действия. Объектом данных может быть сформированный заказ. Для менеджера это будет результат действий, а для склада, который получает заказ – началом действия (сбор товаров и отгрузка).
MESSAGE (СООБЩЕНИЕ)
Этот элемент необходим, чтобы показать коммуникацию между двумя участниками процесса. Это может быть Email, сообщения внутри системы совместной работы, переписка в каком-либо из мессенджеров, которыми пользуются участники процесса, коммуникации на сайте компании, sms-сообщения и т.д.
ARTEFACT (АРТЕФАКТЫ)
Под артефактами в BPMN понимают объекты, не являющиеся действиями и не связанные с действиями напрямую. Это могут быть любые документы, данные, информация, которая не влияет напрямую на исполнение процесса.
Выделяют два вида артефактов:
Text Annotation (текстовые аннотации) применяют для различных уточнений к диаграмме. Это могут быть комментарии, пояснения, другая информация, которая повысит читабельность диаграммы. Аннотации – это незакрытый прямоугольник, выполненный сплошной линией, от которого к объекту аннотации ведет линия, состоящая из точек.
ИСПОЛНЯЕМЫЕ И НЕИСПОЛНЯЕМЫЕ БИЗНЕС-ПРОЦЕССЫ
В бизнес-моделировании процессы можно условно разделить на два вида — исполняемые, которые действительно будут работать при помощи специального обеспечения, например, Bizagi, и неисполняемые, т.е.бизнес-модели, необходимые только для изучения и демонстрации вариантов работы предприятия.
В принципе, между их построением нет особой разницы, здесь важен исключительно желаемый результат. Либо бизнес-модель будет применяться только для облегчения взаимопонимания между заказчиком (руководителем) и консультантом (исполнителем). Либо эта нотация будет впоследствии использоваться в какой-либо программной среде для организации работы компании. В обычных руководствах вы этого разделения на две части не найдете. Но я лично считаю, что имеет смысл условно так делить бизнес-процессы, так как при различном желаемом результате потребуется различная глубина проработки деталей и выбор возможных инструментов для работы.
Исполняемые бизнес-процессы обязательно должны быть выстроены в строгом соответствие всем правилам нотации BPMN, так как в противном случае программное обеспечение не сможет работать корректно с составленной бизнес-моделью. Исполняемые процессы нужны, например, на предприятиях, где принят процессный подход к деятельности. Программное обеспечение позволяет вести контроль всех процессов в режиме реального времени, и на основе получаемых на каждом из этапов данных, руководитель компании и подразделений всегда смогут понимать, на каком этапе находится работа по тому или иному процессу. Подобный метод позволяет значительно повысить эффективность управления.
Неисполняемые бизнес-процессы нужны исключительно для демонстрации какой-либо бизнес-модели. Это может быть диаграмма, отображающая реальное положение дел на предприятии, может быть наглядной иллюстрацией к предложенным изменениям при реинжиниринге. В этом случае, конечно, можно использовать любые удобные инструменты, в том числе, традиционный для многих IDEF0. А соблюдение правил языка моделирование необходимо исключительно для достижения взаимопонимания.
Я рекомендую на начальном этапе работы с BPMN создавать неисполняемые бизнес-процессы. Это действительно очень удобная нотация для того, чтобы иллюстрировать свои идеи и предложения, демонстрировать «узкие места» в бизнесе, даже просто для себя разбираться в структуре работы той или иной компании очень удобно с использованием нотаций. Наглядная графика и строгие правила в этом очень помогают.
Исполняемый вариант требует глубоких знаний BPMN, а также внимательного отношения к каждой детали, так как вы, по сути, создаете программу (алгоритм) для компьютера, просто используете для этого не текстовый язык, а графические нотации. Это дело – для опытных специалистов.
ПОДХОДИТ ЛИ BPMN ДЛЯ МАЛОГО И СРЕДНЕГО БИЗНЕСА?
Нотации BPMN можно и даже нужно использовать при работе с малым и средним бизнесом. Возможно, что вы не будете реализовать бизнес-модель на уровне программного обеспечения, так как это всегда — дополнительные затраты, и в условиях малого бизнеса нет необходимости в подобных инструментах контроля и анализа работы.
Но, тем не менее, на уровне неисполняемых бизнес-процессов я очень активно используют именно BPMN. Дело в том, что при всей сложности вхождения (т.е изучения и умения работать с нотациями), уровень понимания BPMN — низкий, т.е. для чтения нотаций не требуется вообще никаких особых знаний и навыков. Графические нотации понимаются интуитивно. И я еще не встретил ни одного человека, для которого бы прочесть нотацию было бы сложно. Эта нотация создавалась специально для того, чтобы найти общий язык между аналитиком и обычными бизнесменами (управленцами).
В результате, как я и писал выше, при помощи BPMN вы экономите свое время и время заказчика (руководителя) и добиваетесь максимально высокого уровня взаимопонимания. Нотации не позволяют “двойного прочтения”, а потому очень помогают в работе.
МИНУСЫ И ВАЖНЫЕ ОСОБЕННОСТИ BPMN
О том, насколько удобна BPMN, я сказал уже много. Но для выбора любого инструмента важно также понимать и возможные минусы. О них я сейчас и расскажу:
ПРИМЕР ПРАКТИЧЕСКОГО ПРИМЕНЕНИЯ BPMN
Конечно же, без примера описание моделирования бизнес-процессов было бы неполным и не до конца понятным. Я решил в качестве примера взять процесс обеспечения заказов покупателей, так как этот этап работы присутствует практически в любом направлении бизнеса, а потому реализация этого процесса на практике будет понятна без дополнительных пояснений широкому кругу читателей.
Результатом этого процесса должно быть обеспечение покупателя необходимыми ему наименованиями товара.
Данный бизнес-процесс выполняется следующим образом:
BPMN позволяет при моделировании бизнес-процессов опускать на определенном уровне те или иные реальные процессы. Так, в нашем случае мы оставляем «за скобками» получение заказа и согласование перечня товаров и их стоимости с клиентом. Это можно будет детализировать в случае необходимости отдельно. Также в этом примере мы оставили «за скобками» процессы оплаты товары, отгрузки, оформления расходных документов и т.д. А сейчас у нас другая задача – описать сам процесс обеспечения покупателя необходимыми товарами.
Точкой входа служит получение заказа от покупателя. Точкой выхода – «резервирование товара».
Обратите внимание, что после получения заказа стрелка ведет к этапу-ромбу, т.е. условию:
При необходимости этот бизнес-процесс может быть детализирован, что также помогает увидеть, что и как работает (должно работать) для получения результата.
КАК РАЗРАБАТЫВАТЬ ДИАГРАММЫ BPMN НА ПРАКТИКЕ?
Здесь я хочу поделиться некоторыми советами о том, с чего начать и как производить разработку моделей бизнес-процессов. Мои советы основаны на знаниях особенностей бизнес-моделирования и личном практическом опыте.
Что еще хотелось бы посоветовать:
Еще статьи по данной теме:
Также в настоящее время я готовлю к публикации книгу и онлайн курс, в которой подробно опишу собственное видение процессного подхода к бизнесу, а также мой собственный практический опыт работы в сфере функционального и процессного моделирования. Все желающие могут подписаться на уведомление о выходе новой книги по и другие новости ссылке.