Графическое представление бизнес процессов

Роман Исаев

Партнёр ГК «Современные технологии управления»

Руководитель проектов, бизнес-тренер, сертифицированный специалист Business Studio

Автор 11 книг и более 60 публикаций в научно-практических журналах

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

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

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

  • CFFC (Cross Functional Flow Chart. Кросс-функциональная модель, или «диаграмма дорожек») — см.  Рис. 1. По мнению многих экспертов, она наиболее проста для разработки и чтения. Данная нотация интуитивно понятна сотрудникам и имеет очень широкое распространение. Но есть два недостатка: ограничение по количеству «дорожек» (субъектов — исполнителей бизнес-процесса) на листе А4, недостаточный набор фигур для отображения всех необходимых сущностей и атрибутов (например, отсутствие фигур «базы данных» и «программный продукт»).

Рис. 1. Нотация «Cross Functional Flow Chart» — модель процедуры «Оформление и выдача кредита»

  • EPC (Event driven Process Chain. Цепочка процесса, управляемая событиями) — см. Рис. 2. Содержит большой набор фигур для отображения всех основных сущностей и атрибутов на моделях бизнес-процессов. Имеет хорошую визуализацию и цветовое оформление.

Рис. 2. Нотация «EPC» — модель процедуры «Разработка / модификация продукта банка»

  • BPMN (Business Process Model Notation. Модель и нотация бизнес-процесса) — см. Рис. 3. Является наиболее сложной и многофункциональной нотацией. Есть организации, которые полностью описывают все свои бизнес-процессы в BPMN и имеют более 200 моделей в формате А4 с постоянной актуализацией.

Рис. 3. Нотация «BPMN» — модель процедуры «Прием сотрудников на работу»

  • Basic Flow Chart и IDEF0. Оисание этих двух нотаций не входит в задачу данной статьи.

Разработку графических моделей необходимо выполнять с помощью программных продуктов бизнес-моделирования (например, Business Studio или Microsoft Visio). Каждый программный продукт поддерживает разный набор нотаций. Подробное описание всех нотаций утверждается в документе «Соглашение по бизнес-моделированию». Для бизнес-аналитиков (методологов) это единые договорённости по разработке, а для сотрудников организации — памятка по правильному чтению (интерпретации) графических моделей.

Форматы описания бизнес-процессов по их оформлению (формализации)

Рассмотрим 3 основных формата.

  1. Текстовый формат. Для сложных бизнес-процессов это обычно несколько текстовых регламентов с общим объёмом более 100 страниц А4. У этого формата есть немало минусов и недостатков, тем не менее, он является самым распространённым на сегодняшний день.
  2. Табличный формат  — более формализованный (структурированный) и компактный. Бизнес-процесс представляется в виде таблицы со следующими столбцами: функции (действия), вход, источник входа, выход, потребитель выхода, требования к срокам, комментарии и др.
  3. Графический формат. В России уже известны организации (в первую очередь банки — см.  [1]), которые имеют все свои процессные регламенты в графическом формате (т. е. они состоят только из моделей). Такая практика с каждым годом получает всё более широкое распространение. На наш взгляд, все организации, которые ориентированы на долгосрочное и эффективное ведение бизнеса в условиях конкурентной среды, перейдут к графическому описанию бизнес-процессов.
    Однако следует отметить, что специализированные методики и правила (например, методику анализа финансового состояния клиента, правила юридической проверки клиента) не нужно описывать в виде моделей. Это технически сделать очень сложно и нецелесообразно. Поэтому подобные методики следует применять в качестве текстовых приложений к графическим моделям бизнес-процессов.

Есть ещё и четвёртый формат, редко встречающийся в организациях, но запоминающийся. Это описание бизнес-процесса в формате презентационных слайдов (например, MS Power Point), состоящих из «живых» картинок (Clipart), фотографий и текстовых пояснений. Данному формату нельзя придать юридическую силу (официально утвердить), но, как это ни странно, бизнес-процессы в течение многих лет работают на основе этого формата описания. Работают с ошибками, операционными рисками и проблемами, но руководители не понимают этого или не хотят менять подход.

Во многих организациях (особенно среднего и небольшого размера) бизнес-процессы, к сожалению, вообще не описаны. Нет ни моделей, ни регламентов, ни каких-либо официальных материалов. Есть только виртуальные знания и договорённости, которые находятся «в головах» сотрудников и руководителей организации. Подробные рекомендации и примеры того, как описать бизнес-процессы с минимальными инвестициями и рисками, рассмотрены в [2].

Почему важно именно графическое описание бизнес-процессов

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

  • Визуализировать (представить наглядно) логику бизнес-процесса. Например, для коллективного обсуждения и анализа.
  • Быстро и точно выявить ошибки и операционные риски в бизнес-процессах. Также очень удобно на моделях отметить те места, в которых могут реализоваться операционные риски, и заранее принять необходимые меры.
  • Найти «узкие места» и причины неэффективности в бизнес-процессе.
  • Полноценно применить методы оптимизации, разработать модели «как надо» («TO-BE» или версию 2.0). Большое количество методов оптимизации основано на использовании графических моделей.
  • Провести имитационное моделирование (Simulation) и функционально-стоимостный анализ (ФСА) бизнес-процесса с помощью программных продуктов бизнес-моделирования.
  • Объяснить порядок выполнения бизнес-процесса сотрудникам, быстро вспомнить или понять основные моменты и детали. В некоторых организациях графические модели наиболее важных и сложных процедур постоянно находятся на рабочих столах сотрудников.
  • Отследить все взаимосвязи с другими бизнес-процессами и объектами в компании, что особенно актуально для крупных и территориально разделённых организаций.
  • Организовать качественный контроль бизнес-процесса (в том числе процедуры внутреннего аудита). Отметим, что в банках инициатором описания бизнес-процессов иногда выступает служба внутреннего контроля.
  • Построить комплексную электронную бизнес-модель организации (например, основанную на бизнес-процессах [3]). Именно системный подход, т. е. разработка системы взаимосвязанных моделей по всем областям работы и управления в организации, позволяет добиться максимальных результатов.
  • Обеспечить синхронизацию одинаковых объектов в разных бизнес-процессах. Например, если бизнес-аналитик изменил название должности (субъекта) в организационной структуре, то на моделях всех бизнес-процессов, в которых участвует данная должность (как исполнитель), должны автоматически измениться названия соответствующих фигур. При текстовом описании бизнес-процессов синхронизацию и актуализацию регламентов приходится выполнять вручную, поэтому при больших объёмах информации часто возникают неточности и даже противоречия.
  • Автоматически сгенерировать текстовые и табличные регламенты с помощью программных продуктов бизнес-моделирования (например, Business Studio).

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

Источники информации

  1. Исаев Р.А. Секреты успешных банков. Бизнес-процессы и технологии. — М.: Инфра-М, 2017.
  2. Исаев Р. А. Описание и оптимизация бизнес-процессов с минимальными инвестициями и рисками.
  3. Комплексная типовая бизнес-модель банка (финансовой организации).

Опубликовано по материалам:
Журнал «Банковское дело» № 12/2017

Январь 2018 г.

Рекомендуемые материалы по тематике

Комплексная бизнес-модель банка: новые решения и практика

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

Опыт и технология внедрения комплексной типовой бизнес-модели банка

Алфавит нотации и примеры бизнес-процессов
Алфавит нотации и примеры бизнес-процессов

Введение

В этой статье мы рассмотрим, что представляет собой нотация бизнес-моделирования BPMN и как её использовать для описания бизнес-процессов.

Главное назначение и практическое применение

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

BPMN позволяет описать бизнес-логику выполнения действий в виде наглядной диаграммы, а также запустить отрисованный бизнес-процесс на исполнение. Для этого используются специализированные системы BPMS (Business Process Management System), поддерживающие эту нотацию.

BPMS-системы могут автоматически перевести схему бизнес-процесса в исполняемый код и создать веб-приложение, которое будет обрабатывать данные, введённые пользователями и сторонними сервисами. Это соответствует концепции Low Code/No Code (создание программного обеспечения без разработки кода) и отлично подходит для автоматизации офисных процессов.

Технически такая возможность реализуется за счёт перевода BPMN-диаграмм в документы формата BPEL (Business Process Execution Language). BPEL-документы представляют собой инструкции исполнения бизнес-процессов для веб-сервисов.

Таким образом, BPMN используется в следующих случаях:

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

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

Краткая история появления нотации

BPMN считается довольно молодой нотацией: её 1-я версия вышла в 2009 году под эгидой профессионального консорциума OMG. Сегодня эта нотация является стандартом де-факто в ИТ-сфере и используется для описания бизнес-процессов. Текущая версия BPMN 2.0 вышла в 2011 году и используется до сих пор. В 2014 году в дополнение к BPMN группа OMG выпустила нотацию описания бизнес-правил и принятия решений (Decision Model and Notation, DMN).

DMN упрощает построение BPMN-диаграмм в случаях сложной бизнес-логики и многоуровневых её ветвлениях.

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

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

Уровни моделирования

В зависимости от целей построения BPMN-диаграмм, различают 3 уровня моделирования:

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

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

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

Алфавит нотации

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

Поток управления — это последовательность шагов бизнес-процесса, в которой он исполняется.

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

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

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

События

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

Триггер определяет тип и смысл события. Например, триггер в виде конверта означает, что пришли какие-то данные, причём совсем не обязательно в виде сообщения электронной почты. Триггер в виде часов связан со временем. Если событие имеет триггер, значит, поток управления двинется дальше только тогда, когда сработает триггер этого события. Например, получены данные, наступил определённый временной интервал и так далее.

Таблица базовых элементов BPMN

Таблица базовых элементов BPMN

Подробнее весь набор событий, их визуализация и смысл приведены в Приложении А.

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

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

Эфемерной сущностью BPMN, которая показывает смысл концепции потока, называют токен. Подобно потоку воды токен «бежит» от стартового события диаграммы к финишному, разделяясь на несколько экземпляров с помощью логических операторов. Последовательность и вариативность выполнения действий называется бизнес-логикой и показывается с помощью логических операторов или развилок, шлюзов. Например, на диаграмме ниже представлено 2 логических оператора: исключающее ИЛИ (XOR) и включающее ИЛИ (OR).

Процесс утреннего пробуждения

Пример процесса утреннего пробуждения

Пример процесса утреннего пробуждения

Как можно видеть на диаграмме, после стартового события выполняется первое действие («Проверить время звонка»). Следующий за ним логический оператор исключающего ИЛИ, подобно шлюзу, пропускает дальше поток управления только по одной ветке: «да» или «нет». Причём ветка «нет» здесь помечена как поток по умолчанию, который выполнится, если все остальные условия не будут верны.

После выполнения действия оператор включающего ИЛИ (OR) пропускает поток на действие «Выпить кофе» или на действие «Узнать новости» или по обоим веткам. Исключения здесь нет, ручеёк потока управления распараллеливается на две ветки, чтобы потом объединиться снова в одну и один раз выполнить действие «приготовиться к делам». После выполнения этого действия процесс заканчивается конечным событием.

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

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

Диаграмма BPMN может содержать один или несколько пулов, каждый из которых может содержать одну или несколько дорожек.

Процесс утоления голода

В следующем примере процесс «утоления голода» состоит из двух дорожек («Ребёнок» и «Мама»), общение между которыми выполняется через поток управления.

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

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

Стартовым событием является простое событие «Возникло чувство голода» на дорожке Ребёнок, а конечным — простое событие «Чувство голода удовлетворено» на этой же самой дорожке.

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

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

Типы событий

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

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

Также некоторые события могут быть прерывающими и не прерывающими.

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

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

Прерывающие события с разным типом

Прерывающие события с разным типом

События могут располагаться в потоке управления между действиями процесса или на границе действия — в этом случае они считаются граничными.

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

Граничные прерывающие и непрерывающие события

Граничные прерывающие и непрерывающие события

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

Примеры прерывающих и непрерывающих граничных событий с типом «сообщение»

Примеры прерывающих и непрерывающих граничных событий с типом «сообщение»

Типы действий

Подобно событиям, действия в BPMN также могут быть разных типов:

  • Выполняемые вручную без использования какого-либо ПО, например, съесть пиццу.

  • Выполняемые пользователем с помощью ПО, к примеру, заказать пиццу.

  • Выполняемые скриптом или сервисом, например, изменить статус заказа пиццы.

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

Более подробно про типы действий, их смысл и графические обозначения рассказано в Приложении Б.

Логические операторы

Поскольку BPMN показывает логику выполнения бизнес-процесса, в диаграммах используются логические операторы, которые также называются развилками или шлюзами. Изначально их всего три: OR, XOR и AND.

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

Пример исключающего ИЛИ

Пример исключающего ИЛИ

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

Наконец, логическое И (AND) означает активацию всех входящих или исходящих в этот оператор потоков управления, реализуя логическое умножение переменных, т. е. операцию конъюнкции.

Пример логического И

Пример логического И

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

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

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

Пример использования эксклюзивного шлюза по событиям

Пример использования эксклюзивного шлюза по событиям

Все остальные шлюзы, которые есть в BPMN, приведены в Приложении В.

Артефакты

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

Вы можете найти полный перечень артефактов в Приложении Г.

Правила построения диаграмм

Рассмотрим пример бизнес-процесса обработки заявки:

Пример бизнес-процесса обработки заявки

Пример бизнес-процесса обработки заявки

Стартовым событием в нашем процессе является поступление заявки от клиента. Обратите внимание, что клиент на диаграмме показан в виде свернутого пула: мы не видим никаких действий в пуле клиента, потому что для рассматриваемого процесса он представляет собой чёрный ящик, от которого приходят и уходят потоки сообщений, без подробностей обработки.

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

Обозначение действий по областям ответственности разных ролей

Обозначение действий по областям ответственности разных ролей

После действия «Направить клиенту коммерческое предложение (КП)» на диаграмме используется логический оператор ИЛИ (событийный XOR), после которого возможен один из двух вариантов:

1. Если прошло 5 дней, что показано событием с триггером таймер, и ответа от клиента нет, заявке присваивается статус «Отказ» в CRM-системе и наступает финишное событие «Заявка закрыта».

2. Если же ответ от клиента получен и 5 дней ещё не прошло, процесс движется дальше в зависимости от данных в этом ответе.

Таким образом либо заявке присваивается статус «Отказ» или выполняется свернутая задача «Сформировать проект договора», детали которой показаны на отдельной диаграмме.

В результате этой задачи создаётся документ «Проект договора» и наступает финишное событие «Заявка успешно обработана».

Поток по умолчанию

Если в диаграмме используются операторы обычного XOR, проверяющего условия по данным, и OR (неисключающего ИЛИ) рекомендуется помечать поток по умолчанию, который активируется, если другие условия не сработали. Поток по умолчанию допустимо не подписывать, если подписаны остальные потоки и диаграмма остаётся понятной. В примере ниже «‎Нецелевой» — поток по умолчанию.

Пример обозначения потока по умолчанию

Пример обозначения потока по умолчанию

Альтернативный способ показать условия

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

Пример условия зашитого в поток управления

Пример условия зашитого в поток управления

Задачи и события

Говоря про вариативность BPMN, следует отметить небольшое различие между событиями-сообщениями и задачами-сообщениями. По сути это одно и тоже, но к задачам-сообщениям можно прикреплять обработчики событий (например, таймер) и модификаторы (например, цикл по объектам), а к самим событиям — нет.

Ниже показан пример диаграммы с задачами по отправке и получению сообщения:

Пример этой же диаграммы с событиями получения и отправки сообщений:

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

Рекомендации по использованию BPMN

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

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

  • Использовать только пользовательские и ручные задачи — без сценариев, сервисов и бизнес-правил, отправки и получения сообщений.

  • Использовать только свернутые подпроцессы, раскрывая их детали на отдельной диаграмме.

  • Использовать только XOR и AND, без событийных шлюзов и OR, так как разница между исключающим и не исключающим ИЛИ понятна не всем пользователям.

  • Использовать события с типом простое, таймер, сообщение и останов.

Для упрощения восприятия диаграммы стоит придерживаться правил наименования:

  • Внешних контрагентов показывать как закрытые, они же — свёрнутые пулы (пулы, в которых нет действий).

  • Называть закрытые пулы ролями или бизнес-единицами, а открытые — процессами.

  • Называть дорожки также, как роль, должность или структурное подразделение.

  • Называть действия (задачи) в стиле Глагол-Существительное, например, «‎Проверить счёт», «Подтвердить заявку», «Оформить договор».

  • Называть события как свершившийся факт в прошедшем времени, к примеру, «Поступила заявка», «Прошло 3 дня».

  • Подписывать исходящие из XOR стрелки, например, «Да» и «Нет», а также отмечать поток по умолчанию.

Также рекомендуется:

  • Показывать успешное и неуспешное завершение процесса разными финишными событиями.

  • Не выводить поток управления за пределы подпроцесса.

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

Наконец, при разработке любой диаграммы нужно помнить о главном правиле аналитика: независимо от нотации, ваша схема должна быть МАКСИМАЛЬНО простой и понятной читателю БЕЗ знания тонкостей процессного моделирования!

В целом алгоритм разработки BPMN-диаграммы можно представить как набор следующих 7 шагов:

  1. Определить границы процесса, т. е. стартовое и конечное события, участников и полезный результат.

  2. Описать «счастливый» путь (happy path), который ведёт к созданию полезного результата (продукта).

  3. Добавить условия и альтернативные потоки.

  4. Добавить неуспешные завершения.

  5. Добавить артефакты (объекты и хранилища данных).

  6. Раскрыть на новых связанных диаграммах свёрнутые подпроцессы.

  7. Добавить промежуточные событийные потоки к внешним пулам.

Пример построения диаграммы по текстовому описанию

Рассмотрим пример процессов работы с клиентской заявкой, представленной двумя пулами: «Обработка заявки» и «Заключение договора».

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

Процесс начинается с момента, когда клиент оставил заявку на сайте (то есть поступление заявки является триггером процесса, его стартовым событием). На основании заявки, в которой указаны подробности заказа, менеджер формирует коммерческое предложение (КП). Далее менеджер озвучивает КП по телефону или направляет на email, или же делает и то, и другое — в зависимости от пожеланий клиента и указанных в заявке контактных данных.

Узнав подробности коммерческого предложения, клиент принимает решение о продолжении сотрудничества или отказе от него. Если клиент не согласился на условия КП, на этом процесс работы с ним заканчивается, а заявке присваивается статус «Отказ».

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

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

Пример построения диаграммы по текстовому описанию

Пример построения диаграммы по текстовому описанию

Инструменты для разработки бизнес-процессов в нотации BPMN

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

  • ШТОРМ — веб-редактор от команды Дениса Котова, пожалуй, главного евангелиста BPMN в России, с автопроверкой диаграмм и возможностями командной работы в одном пространстве;

  • Online BPMN — простой и удобный веб-редактор, поддерживает интеграцию с BPMS-системой;

  • Cavemo — веб-редактор, аналогичный предыдущему, имеет офлайн-версию

  • простые веб-«рисовалки‎» Lucidchart, Draw.io, Visual Paradigm

Также алфавит нотации BPMN поддерживается и в MS Visio, ARIS Express и других редакторах диаграмм общего назначения.

Заключение

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

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


Анна Вичугова

Бизнес-аналитик, CBAP, к.т.н., тренер Systems.Education,
основатель и тренер Школы прикладного бизнес-анализа

  • Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)

  • Сертифицированный бизнес-аналитик (IIBA CBAP, 2020)

  • Сертифицированный специалист Business Studio и СЭД Directum

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19, 34, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

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

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

Основные понятия

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

Это широко известная во всем мире концепция, созданная на основе сочетания управления бизнесом с использованием определенных методов и инструментов. Итак, BPM включает в себя технологии и направлен на выявление, анализ и оптимизацию процессов в организациях.

BPM, BPMN и BPMS

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

BPM — это способ визуализации бизнес-операций, выходящий за рамки функциональных структур компании.

Он включает в себя всю работу, необходимую для предоставления продукта или услуги, всегда оставляя клиенту самую важную часть процесса.

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

BPMS — это инструмент, который может стать отличным решением для тех, кто хочет ускорить и облегчить деятельность компании.

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

Таким образом, мы можем определить BPMS (Business Process Management Suite) как инструмент, который позволяет в автоматическом режиме:

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

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

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

  • электронные формы;
  • определение бизнес-правил;
  • интеграция с другими системами и различные отчеты.

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

Хороший инструмент BPMS — это полная система, которая объединяет различные корпоративные решения на одной платформе. Следовательно, управление может быть намного более эффективным, а связь между различными областями становится более централизованной и видимой.

Хороший инструмент BPMS

Платформа BPMS может выполнять разные функции, такие как:

  • Графическое моделирование среды.
  • Репозиторий процессов.
  • Оркестровка процессов.
  • Управление контентом (ECM).
  • Управление человеческим взаимодействием.
  • Связь с внешними системами.
  • Мониторинг анализа данных для поддержки бизнес-аналитики (аналитика).
  • Управление правилами и др.

BPM, BPMN, BPMS — в чем отличия

В то время как BPM — это предмет или философия управления, которую можно применить к бизнесу, BPMN — это официальная стандартная нотация, которая используется во всем мире.

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

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

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

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

BPMN — это моделирование процессов в BPMS, которое используется для автоматизации процессов и делает их понятными для всех вовлеченных людей. Можно даже применить обозначение на любом этапе BPM , чтобы поддержать цикл непрерывного улучшения. Другими словами, вы можете использовать BPMN в BPMS, когда хотите:

  • Автоматизируйте процессы с минимальной помощью ИТ-профессионала
  • Моделируйте процессы от начала до конца
  • Измените процесс после выявления узких мест
  • Добавить новые бизнес-правила и т. Д.

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

Нотация описания бизнес-процессов

BPMN в настоящее время является наиболее широко используемой нотацией для моделирования процессов, используемым бизнес-аналитиками, а также руководителями — владельцами процессов.

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

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

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

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

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

На практике основными формами использования являются:

  • Более или менее полная процессная модель организации.
  • Описание конкретных процессов для нужд бизнес-анализа.
  • Использование языка как инструмента программирования для автоматизации операций.

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

Основные элементы:

  • Действия (также называемые действиями или задачами).
  • События.
  • Шлюзы (часто называемые процессом принятия решений, в результате упрощенного представления шлюзов как преемников точек принятия решений на блок-схемах).
  • Компенсация (для многих пользователей это технический элемент, который играет незаменимую роль в тот момент, когда вы хотите подготовить процесс не только к стандартному курсу, но и в ситуациях, когда в процессе происходит что-то непредвиденное и с этим нужно что-то делать. ).
  • Потоки.
  • Блоки (часто переводятся как пулы).
  • Полосы.

Помимо элементов, BPMN также определяет типы схем:

  • Описание процесса.
  • Описание хореографии.
  • Описание сотрудничества.

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

Зачем нужна регламентация бизнес-процессов?

Большинство компаний в настоящее время являются вертикальными и разделены на отделы, такие как логистика, маркетинг, финансы и т. д., в соответствии с областями знаний профессионалов. Это естественный эффект открытия нового бизнеса.

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

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

Язык BPMN

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

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

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

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

  • Контролировать процессов от начала до конца.
  • Определить конкретные узкие места.
  • Расставить приоритеты в процессах в соответствии с их потребностями.
  • Увеличивать масштаб с помощью автоматизированного программного обеспечения.
  • Установить цели и KPI.
  • Установить стандарты качества.
  • Создавайть отчеты, графики и расширенные данные в режиме реального времени.
  • Подключать рабочий процесс в разных отделах и системах.
  • Ускорить принятие решений.
  • Создать прототипы и опробовать решения (время выхода на рынок).

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

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

Какие проблемы возникают, если процессы не регламентированы

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

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

Немного истории

BPMN является производной от синтеза множества нотаций бизнес-моделирования. Изначально опубликованная Business Process Management Initiative (BPMI) в 2004 году, BPMN теперь поддерживается OMG после слияния двух организаций в 2005 году. Документ спецификации BPMN был выпущен OMG в феврале 2006 года. Версия 2.0 BPMN была разработана в 2010 году, а фактическая версия спецификации была выпущена в декабре 2013 года. Последняя версия (BPMN 2.0.2) была официально опубликована ISO в качестве стандарта издания 2013 года: ISO / IEC 19510.

Из чего состоит нотация: основные графические элементы

В BPMN процессы описываются с помощью диаграмм с рядом графических элементов. Такое визуальное представление позволяет пользователям легко понять логику процесса.

Схема бизнес процесса BPMNБизнес процесс в нотации BPMNНотаций моделирования процессов (BPMN 2.0, uml, EEPC, Aris);

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

Событие (Event)

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

Действие (Activity)

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

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

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

Развилка (Gateway)

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

Поток (Flow)

Поток — это элементы, которые соединяются друг с другом для формирования бизнес-процессов. Элементы потока — это основные элементы, определяющие поведение процесса. Существует три типа элементов потока: события, действия и шлюзы.

Поток сообщений (Message Flows)

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

Пул (Pool)

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

Внутри бассейна есть элементы потока. Они представляют собой работы, которые пул должен выполнять в моделируемом процессе.

Объекты данных (Date object)

Данные — это в основном информация, необходимая или производимая при выполнении бизнес-процесса. Существует четыре типа данных: объекты данных, входные данные, выходные данные и хранилища данных.

Сообщение (Message)

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

Артефакты (Artefact)

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

Бонусом все объекты BPMN 2.0 на одной картинке:

постер BPMN

Постер BPMN 2.0 (кликабельно)

Бизнес-процессы

Знание того, как работает бизнес, — это первый и самый важный шаг в улучшении бизнес-процессов. Модель и нотация бизнес-процессов (BPMN) обеспечивает:

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

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

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

Исполняемые

Процессы, которые можно смоделировать при помощи BPMN. Цель таких процессов внедрение или улучшение автоматизации.

Не исполняемые

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

Большинство компаний в настоящее время являются вертикальными и разделены на отделы, такие как логистика, маркетинг, финансы и т. д., В соответствии с областями знаний профессионалов. Это естественный эффект открытия нового бизнеса.

Строение бизнеса

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

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

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

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

Таким образом, использование bpmn подходит любой компании.

Подходит ли bpmn для малого и среднего бизнеса

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

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

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

Преимущества

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

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

BPMN простой в освоениия, но достаточно мощный, чтобы описать потенциальные сложности бизнес-процесса.

Минусы стандарта

  1. Неэффективное управление и потеря доходов. Преимущества BPMN могут быть достигнуты только при его правильной реализации. Если не работать с методологиями, может произойти потеря доходов и ресурсов.
  2. Меньше инноваций. BPMN должна в полной мере использовать современные технологии и персонал. Но большинство предприятий, внедряющих BPM, не в состоянии максимально эффективно использовать современные технологии и рабочую силу. Видно, что BPM тормозит инновации.
  3. Отсутствие общения. Общение действительно важно в любой сфере бизнеса. Благодаря внедрению BPMN становится меньше общения между сотрудниками, работающими в разных секторах. Это связано с методом BPM разделения процессов и рабочих процессов.

Особенности

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

Как разрабатывать диаграммы

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

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

Диаграммы бизнес-процессов

Обратите внимание на следующие рекомендации по построению диаграмм:

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

Поддерживаются два типа процессов: простые и бизнес-процессы.

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

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

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

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

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

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

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

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

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

Пример практического применения

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

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

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

Затем эта задача исправляется и выполняется с большим вниманием.

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

#статьи

  • 7 дек 2022

  • 0

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

Иллюстрация: Оля Ежак для SKillbox Media

Ксеня Шестак

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

Бизнес-аналитик с опытом работы более четырёх лет, магистр в области информационной бизнес-аналитики. Сейчас участвует в проектах, связанных с нефтедобычей, геологоразведкой, логистикой. Принимала участие во внедрении «1С:ERP» как основной бизнес-аналитик. Проверяющий куратор курсов Skillbox «Профессия Бизнес-аналитик», «Профессия Операционный менеджер».

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

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

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

В статье для Skillbox Media расскажем:

  • что такое бизнес-процессы и для чего ими управлять;
  • какие есть способы описания бизнес-процессов;
  • что такое нотация BPMN и в чём её главные преимущества;
  • из каких элементов состоит BPMN;
  • как построить модель бизнес-процесса с помощью BPMN пошагово;
  • как применяют нотацию BPMN в бизнес-аналитике;
  • как узнать больше об управлении бизнес-процессами.

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

К ним можно причислить, например, обработку заказов в интернет-магазине, доставку товаров клиенту, подготовку договоров.

Чтобы всё работало, процессами нужно управлять. От гибкости и управляемости бизнес-процессов зависит, насколько успешным будет бизнес. Есть разные подходы к управлению — все они включают три основных элемента:

  • анализ бизнес-процессов;
  • выявление проблем;
  • оптимизация бизнес-процессов.

Инфографика: Майя Мальгина для Skillbox Media

В Skillbox Media есть статья, где подробно рассказано об управлении бизнес-процессами.

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

Три самых распространённых способа описания бизнес-процессов:

  • Текстовый — подготовка письменных инструкций, регламентов, стандартов и других нормативных документов.
  • Табличный — описание процессов в формате таблиц.
  • Схематичный — графическое изображение процессов.

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

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

Нотации описывают:

  • какие обозначения использовать в описании процессов и как их читать;
  • как отображать последовательность действий и отношения внутри них;
  • какие элементы нужно обязательно учесть.

Есть несколько вариантов нотаций — их выбирают в зависимости от типов бизнес-процессов и потребностей бизнеса. Вот некоторые примеры нотаций:

  • Блок-схема — используют для описания алгоритмов, статусов и ролей процесса.
  • EPC — используют для описания событий бизнес-процессов.
  • IDEF0 — используют для описания логических отношений между этапами процесса.
  • ARIS — используют для описания одновременно всех бизнес-процессов компании и её архитектуры.
  • BPMN — используют для подробной детализации действий в бизнес-процессах.

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

BPMN — аббревиатура от Business Process Model and Notation. Это система условных обозначений и их описания для моделирования бизнес-процессов.

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

Первая версия BPMN создана в 2004 году рабочей группой IBM. В 2010 году — дополнена и выпущена под названием BPMN 2.0. В неё добавили новые типы событий и диаграмм, устранили ошибки первой версии.

Вот главные преимущества нотации BPMN перед другими нотациями:

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

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

Ниже на иллюстрации приведён пример процесса — поиска и приёма на работу нового сотрудника.

Фрагмент описания бизнес-процесса в нотации BPMN
Скриншот: личный архив Анны Солодовниковой

Разберём основные элементы нотации. Их будет достаточно для большинства схем.

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

Изображение: Skillbox Media

Примеры задач в иллюстрации выше — «Заявка на подбор нового сотрудника», «Проведение собеседования». Часто задачи формулируют через глагол: «Провести собеседование», «Подобрать сотрудника».

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

Изображение: Skillbox Media

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

В нашем примере стартовые события — «Потребность в расширении штата» и «Текущий сотрудник написал заявление на увольнение».

Шлюзы. Показывают слияния потоков управления в рамках процесса. Среди них выделяют:

  • Параллельный шлюз — означает, что два процесса исполняются одновременно. Читается как «И».

    В нашем примере параллельный шлюз — «Проведение собеседования» и «Проведение собеседования, заполнение листа оценки кандидата».

Изображение: Skillbox Media
  • Эксклюзивный шлюз — используют, чтобы обозначить ветвление потока управления на несколько альтернативных потоков, когда процесс зависит от выполнения условия. Читается как «ИЛИ».

    В этом случае процесс идёт чётко по одному из потоков.

Изображение: Skillbox Media
  • Неэксклюзивный шлюз — применяют, чтобы показать ветвление потока управления на несколько других, когда процесс зависит от выполнения условий. Читается как «И/ИЛИ».

    В этом случае процесс может пойти по двум потокам одновременно, а может — только по одному из них. Такой шлюз используется редко.

Изображение: Skillbox Media

Объект данных. Показывает, какие объекты сопровождают выполнение процесса. Например, бумажный документ, электронный документ, информацию и так далее.

В нашем примере объекты данных — «Заявка на подбор», «Лист оценки кандидата», «Предложение о работе».

Изображение: Skillbox Media

Потоки. Это стрелки, которые показывают движение по процессам и порядок их выполнения. Есть несколько видов потоков:

  • Поток управления — показывает, в каком порядке выполняется процесс. Эти стрелки связывают между собой задачи, события и шлюзы.

    Пример — связь между задачами «Поиск подходящих кандидатов» и «Отправка релевантных резюме». Это две задачи, которые последовательно идут друг за другом.

Изображение: Skillbox Media
  • Поток сообщений — показывает передачу сообщений или объектов из одного процесса в другой. В нашем примере так показана связь между подготовкой заявки на подбор сотрудника и принятием этой заявки в работу.

Изображение: Skillbox Media
  • Ассоциация — показывает связи объектов данных и баз данных с процессами.

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

Изображение: Skillbox Media

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

Например, в нашей иллюстрации дорожки соответствуют кандидату, HR-менеджеру, руководителю отдела.

Изображение: Skillbox Media

Полный список элементов, которые используют в нотации, можно посмотреть здесь.

Существует много инструментов для разработки процессов в BPMN. Мы рекомендуем бесплатный онлайн-сервис Diagrams.net. В нём можно создавать схемы, модели, диаграммы и обмениваться ими в браузере.

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

Вот пошаговый план того, как построить бизнес-процессы в нотации BPMN:

1. Изучите процесс: для чего он нужен и какие задачи решает.

2. Определите, является он основным, вспомогательным или процессом управления.

Основной процесс — приносящий прибыль или влияющий на прибыль компании. Например, производство или продажи. Таким процессам нужно уделять особое внимание.

Вспомогательный процесс — процесс, который не генерирует доход, но обеспечивает качественное выполнение основных процессов. Например, бухгалтерский учёт.

Процесс управления — процесс, влияющий на существование и развитие компании. Например, управление командами компании.

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

4. Выявите всех участников процесса: должности, роли, отделы, в некоторых случаях — Ф. И. О. ответственных сотрудников. Но в схемах процесса лучше избегать построения дорожек, завязанных на Ф. И. О., — иначе нужно будет постоянно следить за актуальностью данных.

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

6. Отметьте все внутренние события бизнес-процесса. Дополнительные детали можно при необходимости уточнить у владельцев процесса.

7. Если в процессе важно отразить внутренние действия систем, попросите участников процесса наглядно показать, что они делают и какой результат получают. Продемонстрируйте это на схеме.

Задачи бизнес-аналитика, для которых требуется BPMN, делят на два этапа:

  • Построение схем «как есть» (as is) — описание текущей последовательности работ бизнес-процесса.
  • Построение схем «как будет» (to be) — описание целевого процесса с фиксацией требуемых изменений: этапов модернизации, автоматизации.

Разберём на примере. Допустим, в компании N было 70 сотрудников, которые работали в одном офисе. Всю необходимую документацию они распечатывали, подписывали от руки и самостоятельно относили получателю — например, бухгалтеру, отделу кадров или секретарю.

Потом компания выросла в 2,5 раза, появились удалённые сотрудники. Руководство приняло решение внедрить систему электронного документооборота (СЭД). Перед внедрением такой системы бизнес-аналитику потребуется выполнить три основные задачи:

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

Что даёт описание текущего процесса и моделирование целевого процесса документооборота? Снизится риск упустить ключевые функции СЭД и получить на выходе систему, которая не будет решать задачи компании.

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

  • Бизнес-процессы — все операции, которые помогают решать задачи бизнеса и получать доход. Чтобы всё работало по плану, процессами нужно управлять: описывать их, анализировать и оптимизировать.
  • Эффективнее всего описывать бизнес-процессы графически — в виде интуитивно понятных схем. Для этого используют различные нотации — системы условных обозначений. Они нужны для того, чтобы любой человек понимал, что изображено на схеме.
  • Одна из универсальных и самых наглядных нотаций — нотация BPMN (Business Process Model and Notation). Она в графическом виде отражает последовательность работ бизнес-процессов и логику их выполнения.
  • Если вы только начали разбираться в управлении бизнес-процессами — прочитайте статью Skillbox Media «Большой гайд по управлению бизнес-процессами: главное, что должен знать каждый менеджер».
  • В этой статье отдельно разбирали вопрос моделирования бизнес-процессов, в этой — процесс их автоматизации.
  • Также в Skillbox есть курс «Профессия Бизнес-аналитик». На нём учат собирать данные о финансах компании и бизнес-процессах, проводить продуктовые интервью и определять стратегии развития, оптимизировать процессы.

Другие материалы Skillbox Media для менеджеров

Научитесь: Профессия Бизнес-аналитик
Узнать больше

Print Friendly, PDF & Email

BPMN (Business Process Model and Notation — нотация и модель бизнес процессов) разработана компанией Business Process Management Initiative и поддерживается Object Management Group после слияния организаций в 2005 г. Последняя версия 2.0 вышла в 2012 г. В 2013 году BPMN утверждена в качестве международного стандарта ISO/IEC 19510.

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

Бизнес-процессы

Существует множество определений бизнес-процессов. Например Википедия дает такое определение:

Бизнес-процесс — это совокупность взаимосвязанных мероприятий или работ, направленных на создание определённого продукта или услуги для потребителей. Управленческая концепция BPM рассматривает бизнес-процессы как важные ресурсы предприятия, и предполагает управление ими как одну из ключевых организационных систем.

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

Еще одним определением процесса (бизнес-процесса) будет:

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

Входы и выходы — это информационные и материальные потоки.
Прежде чем описывать процесс в виде графической схемы, очень важно определить его контекст

Запомните принцип:

процесс может:

• получать входы от других процессов;
• передавать выходы другим процессам

Процесс НЕ может:

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

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

Бизнес-процесс состоит из операций и действий. Дадим определение этим понятиям.

Операция — это единица работы, выполняемая непрерывно, на одном рабочем месте, над одним обрабатываемым объектом. До начала выполнения операции объект имеет определенное начальное состояние. В результате выполнения операции состояние предсказуемо изменяется. Таким образом, операция описывает работу, приводящую к требуемому изменению состояния обрабатываемого изделия.

Операция состоит из действий или набора действий, производимых над обрабатываемым объектом. Действие есть акт взаимодействия оператора с обрабатываемым изделием, в котором достигается определенная, заранее определенная, цель.

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

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

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

И давайте рассмотрим следующую схему:

Зеленый круг — стартовое событие, которое указывает на начало того или иного процесса;

Красный круг — конечное событие, которое указывает на точку завершения процесса;

Ромб — графический элемент шлюза, используется для изображения ветвления;

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

Детальней об всех этих элементах будет рассказано подробней чуть ниже.

Область применения нотации BPMN

Нотация BPMN предназначена для описания:

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

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

• Функциональную (структурную) декомпозицию работ;
• Организационную структуру предприятия;
• Модель данных;
• Бизнес правила,
• Бизнес стратегию компании

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

Основные элементы нотации

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

1.Элементы управления;
2. Соединительные элементы;
3. Артефакты;
4. Данные.
5. Зоны ответственности

Зоны ответственности

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

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

Если пул показывает детали процесса: операции, логические операторы, события и потоки управления, его называют «белый» ящик. Напротив, пул, который не показывает деталей процесса, называют «черный» ящик.

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

Например, «Начальник отдела продаж» — это должность, а «Инициатор договора» — роль. Недопустимо называть дорожки по фамилии исполнителя.
Дорожки на схемах BPMN принято располагать горизонтально, хотя вертикальное расположение также допустимо.

События

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

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

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

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

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

В BPMN разные события изображаются по разному.

Операции и логические операторы

Операция обозначает единицу работы, в результате которой изменяется состояние объекта управления, например, «Согласовать заявку», «Вынести решение» и т.д.

Логический оператор изображают работу, которая не изменяет объект, но маршрутизирует его в соответствии с некоторым правилом. Например, если величина запрошенного кредита превышает 50000 гривен, то его согласует старший менеджер.

Соединительные элементы

C помощью событий, операций и логистических операторов можно составить схему процесса

Операции процесса на схеме соединены стрелками. Эти стрелки имеют тип «Sequence flow» — они показывают последовательность выполнения операций во времени. Можно сказать, что они управляют «потоком операций» — Work Flow.

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

Поток операций (управления) (Sequence Flow) Поток операций служит для отображения того порядка, в котором организованы действия Процесса или условия Хореографии.
Поток сообщений (Message Flow) Поток сообщений служит для отображения обмена сообщениями между двумя участниками, готовыми эти сообщения отсылать и принимать. На диаграмме взаимодействия BPMN два отдельно взятых Пула представляют собой двух участников Процесса (бизнес-сущности или бизнес-роли).
Ассоциация (Association) Ассоциация служит для установления связи между информацией или Артефактами (объектами, не относящимися к Элементам потока) и элементами потока. Текстовые объекты, а также графические объекты, не относящиеся к элементам потока, могут соотноситься с элементами потока. При необходимости Ассоциация может указывать направление потока (например, потока данных).

Данные

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

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

Хранилища данных изображают внешние по отношению к процессу системы хранения, например, СУБД.

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

Артефакты

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

Графическое изображение Группы

Группы – это способ логически объединить на схеме несколько операций процесса. Чаще всего группирование операций используется для того, чтобы скрыть излишние детали процесса. Группы могут пересекать несколько дорожек и даже пулов.

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

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

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

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

Субклассы нотации BPMN

Полный набор графических элементов в нотации BPMN 2.0 содержит 116 графических элементов, для упрощения работы с ними их можно разделить на несколько групп (взято из книги Федорова И.Г. «Моделирование бизнес-процессов в нотации BPMN 2.0»)

Основной набор включает 7 элементов, достаточен для разработки концептуальной (не исполняемой) модели процесса.

Подмножество описательных элементов (+17) достаточно для построения исполняемой модели;
Подмножество аналитических элементов (+29) Наконец, полный набор (+50) позволяет создавать любые типы диаграмм.

Логика процесса

Логика процесса описывается с помощью шлюзов (условий), которые могут быть нескольких типов (в BPMN выделяют 7 типов) .

Эксклюзивный шлюз

Эксклюзивный шлюз (XOR, «Исключающее ИЛИ») используется для ветвления потока управления на несколько альтернативных потоков, когда выполнение процесса зависит от выполнения некоторого условия.

Исключающие Шлюзы включаются в состав бизнес-процесса для разделения Потока операций на несколько альтернативных маршрутов. Для процесса с исключающим  типом Шлюза может быть выбран лишь один из предложенных маршрутов (поэтому определяется как Шлюз «ИЛИ»).

Параллельный шлюз (AND, «И») используется для обозначения слияния/ветвления потоков управления в рамках процесса.

Пример использования параллельного шлюза при ветвлении/разделении потоков
Пример использования параллельного шлюза при слиянии потоков

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

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

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

Эксклюзивный шлюз по событиям (XOR, «Исключающее ИЛИ») используется для ветвления потока управления на несколько альтернативных потоков, когда дальнейшее выполнение процесса зависит от возникновения некоторого события-обработчика, следующего после шлюза.

Пример построения процесса с помощью BPMN

Ниже представлена схема процесса «Подача заявления на отпуск сотрудником». Это наверное  вариант самой встречаемой схемы, которой будет достаточно для построения 90% схем и она досточно понятна даже стороннему наблюдателю.

BPMN 2.0 Метамодель и нотация бизнес-процессов (сводная информация)

АННА Вичугова

Как начать моделировать бизнес-процессы в BPMN

Алфавит нотации и примеры бизнес-процессов

В этой статье мы рассмотрим, что представляет собой нотация бизнес-моделирования BPMN и как её использовать для описания бизнес-процессов.

Главное назначение и практическое применение

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

BPMN позволяет описать бизнес-логику выполнения действий в виде наглядной диаграммы, а также запустить отрисованный бизнес-процесс на исполнение. Для этого используются специализированные системы BPMS (Business Process Modelling System), поддерживающие эту нотацию.

BPMS-системы могут автоматически перевести схему бизнес-процесса в исполняемый код и создать веб-приложение, которое будет обрабатывать данные, введённые пользователями и сторонними сервисами. Это соответствует концепции Low Code/No Code (создание программного обеспечения без разработки кода) и отлично подходит для автоматизации офисных процессов.

Технически такая возможность реализуется за счёт перевода BPMN-диаграмм в документы формата BPEL (Business Process Execution Language). BPEL-документы представляют собой инструкции исполнения бизнес-процессов для веб-сервисов.

Таким образом, BPMN используется в следующих случаях:

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

Воркшоп «BPMN для людей:

основы самой популярной нотации

для описания бизнес-процессов»

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

Краткая история появления нотации

BPMN считается довольно молодой нотацией: её 1-я версия вышла в 2009 году под эгидой профессионального консорциума OMG. Сегодня эта нотация является стандартом де-факто в ИТ-сфере и используется для описания бизнес-процессов. Текущая версия BPMN 2.0 вышла в 2011 году и используется до сих пор. В 2014 году в дополнение к BPMN группа OMG выпустила нотацию описания бизнес-правил и принятия решений (Decision Model and Notation, DMN).

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

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

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

В зависимости от целей построения BPMN-диаграмм, различают 3 уровня моделирования:

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

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

Поток управления — это последовательность шагов бизнес-процесса, в которой он исполняется.

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

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

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

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

Триггер определяет тип и смысл события. Например, триггер в виде конверта означает, что пришли какие-то данные, причём совсем не обязательно в виде сообщения электронной почты. Триггер в виде часов связан со временем. Если событие имеет триггер, значит, поток управления двинется дальше только тогда, когда сработает триггер этого события. Например, получены данные, наступил определённый временной интервал и так далее.

Таблица базовых элементов BPMN

Подробнее весь набор событий, их визуализация и смысл приведены в Приложении А.

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

Эфемерной сущностью BPMN, которая показывает смысл концепции потока, называют токен. Подобно потоку воды токен «бежит» от стартового события диаграммы к финишному, разделяясь на несколько экземпляров с помощью логических операторов. Последовательность и вариативность выполнения действий называется бизнес-логикой и показывается с помощью логических операторов или развилок, шлюзов. Например, на диаграмме ниже представлено 2 логических оператора: исключающее ИЛИ (XOR) и включающее ИЛИ (OR).

Процесс утреннего пробуждения

Пример процесса утреннего пробуждения

Как можно видеть на диаграмме, после стартового события выполняется первое действие («Проверить время звонка»). Следующий за ним логический оператор исключающего ИЛИ, подобно шлюзу, пропускает дальше поток управления только по одной ветке: «да» или «нет». Причём ветка «нет» здесь помечена как поток по умолчанию, который выполнится, если все остальные условия не будут верны.

После выполнения действия оператор включающего ИЛИ (OR) пропускает поток на действие «Выпить кофе» или на действие «Узнать новости» или по обоим веткам. Исключения здесь нет, ручеёк потока управления распараллеливается на две ветки, чтобы потом объединиться снова в одну и один раз выполнить действие «приготовиться к делам». После выполнения этого действия процесс заканчивается конечным событием.

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

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

Диаграмма BPMN может содержать один или несколько пулов, каждый из которых может содержать одну или несколько дорожек.

В следующем примере процесс «утоления голода» состоит из двух дорожек («Ребёнок» и «Мама»), общение между которыми выполняется через поток управления.

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

Стартовым событием является простое событие «Возникло чувство голода» на дорожке Ребёнок, а конечным — простое событие «Чувство голода удовлетворено» на этой же самой дорожке.

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

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

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

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

Также некоторые события могут быть прерывающими и не прерывающими.

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

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

Пребывающие события с разным типом

События могут располагаться в потоке управления между действиями процесса или на границе действия — в этом случае они считаются граничными.

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

Граничные прерывающие и непрерывающие события

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

Примеры прерывающих и непрерывающих граничных событий с типом «сообщение»

Подобно событиям, действия в BPMN также могут быть разных типов:

  • Выполняемые вручную без использования какого-либо ПО, например, съесть пиццу
  • Выполняемые пользователем с помощью ПО, к примеру, заказать пиццу
  • Выполняемые скриптом или сервисом, например, изменить статус заказа пиццы

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

Поскольку BPMN показывает логику выполнения бизнес-процесса, в диаграммах используются логические операторы, которые также называются развилками или шлюзами. Изначально их всего три: OR, XOR и AND.

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

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

Наконец, логическое И (AND) означает активацию всех входящих или исходящих в этот оператор потоков управления, реализуя логическое умножение переменных, т. е. операцию конъюнкции.

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

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

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

Пример использования эксклюзивного шлюза по событиям

Все остальные шлюзы, которые есть в BPMN, приведены в Приложении В.

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

Правила построения диаграмм

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

Пример бизнес-процесса обработки заявки

Стартовым событием в нашем процессе является поступление заявки от клиента. Обратите внимание, что клиент на диаграмме показан в виде свернутого пула: мы не видим никаких действий в пуле клиента, потому что для рассматриваемого процесса он представляет собой чёрный ящик, от которого приходят и уходят потоки сообщений, без подробностей обработки.

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

Обозначение действий по областям ответственности разных ролей

После действия «Направить клиенту коммерческое предложение (КП)» на диаграмме используется логический оператор ИЛИ (событийный XOR), после которого возможен один из двух вариантов:

1. Если прошло 5 дней, что показано событием с триггером таймер, и ответа от клиента нет, заявке присваивается статус «Отказ» в CRM-системе и наступает финишное событие «Заявка закрыта».

2. Если же ответ от клиента получен и 5 дней ещё не прошло, процесс движется дальше в зависимости от данных в этом ответе.

Таким образом либо заявке присваивается статус «Отказ» или выполняется свернутая задача «Сформировать проект договора», детали которой показаны на отдельной диаграмме.

В результате этой задачи создаётся документ «Проект договора» и наступает финишное событие «Заявка успешно обработана».

Если в диаграмме используются операторы обычного XOR, проверяющего условия по данным, и OR (неисключающего ИЛИ) рекомендуется помечать поток по умолчанию, который активируется, если другие условия не сработали. Поток по умолчанию допустимо не подписывать, если подписаны остальные потоки и диаграмма остаётся понятной. В примере ниже «‎Нецелевой»‎ — поток по умолчанию.

Пример обозначения потока по умолчанию

Альтернативный способ показать условия

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

Пример условия зашитого в поток управления

Говоря про вариативность BPMN, следует отметить небольшое различие между событиями-сообщениями и задачами-сообщениями. По сути это одно и тоже, но к задачам-сообщениям можно прикреплять обработчики событий (например, таймер) и модификаторы (например, цикл по объектам), а к самим событиям — нет.

Ниже показан пример диаграммы с задачами по отправке и получению сообщения.

Пример этой же диаграммы с событиями получения и отправки сообщений.

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

Рекомендации по использованию BPMN

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

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

  • Использовать только пользовательские и ручные задачи — без сценариев, сервисов и бизнес-правил, отправки и получения сообщений
  • Использовать только свернутые подпроцессы, раскрывая их детали на отдельной диаграмме
  • Использовать только XOR и AND, без событийных шлюзов и OR, так как разница между исключающим и не исключающим ИЛИ понятна не всем пользователям
  • Использовать события с типом простое, таймер, сообщение и останов

Для упрощения восприятия диаграммы стоит придерживаться правил наименования:

  • Внешних контрагентов показывать как закрытые, они же — свёрнутые пулы (пулы, в которых нет действий)
  • Называть закрытые пулы ролями или бизнес-единицами, а открытые — процессами
  • Называть дорожки также, как роль, должность или структурное подразделение
  • Называть действия (задачи) в стиле Глагол-Существительное, например, «‎Проверить счёт», «Подтвердить заявку», «Оформить договор»
  • Называть события как свершившийся факт в прошедшем времени, к примеру, «Поступила заявка», «Прошло 3 дня»
  • Подписывать исходящие из XOR стрелки, например, «Да» и «Нет», а также отмечать поток по умолчанию
  • Показывать успешное и неуспешное завершение процесса разными финишными событиями
  • Не выводить поток управления за пределы подпроцесса
  • Взаимодействие между разными пулами показывать через поток сообщений (пунктирной стрелкой), который не может присоединяться к шлюзам, в отличие от потока управления

Наконец, при разработке любой диаграммы нужно помнить о главном правиле аналитика: независимо от нотации, ваша схема должна быть МАКСИМАЛЬНО простой и понятной читателю БЕЗ знания тонкостей процессного моделирования!

В целом алгоритм разработки BPMN-диаграммы можно представить как набор следующих 7 шагов:

  1. Определить границы процесса, т. е. стартовое и конечное события, участников и полезный результат
  2. Описать «счастливый» путь (happy path), который ведёт к созданию полезного результата (продукта)
  3. Добавить условия и альтернативные потоки
  4. Добавить неуспешные завершения
  5. Добавить артефакты (объекты и хранилища данных)
  6. Раскрыть на новых связанных диаграммах свёрнутые подпроцессы
  7. Добавить промежуточные событийные потоки к внешним пулам

Пример построения диаграммы по текстовому описанию

Рассмотрим пример процессов работы с клиентской заявкой, представленной двумя пулами: «Обработка заявки» и «Заключение договора».

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

Процесс начинается с момента, когда клиент оставил заявку на сайте (то есть поступление заявки является триггером процесса, его стартовым событием). На основании заявки, в которой указаны подробности заказа, менеджер формирует коммерческое предложение (КП). Далее менеджер озвучивает КП по телефону или направляет на email, или же делает и то, и другое — в зависимости от пожеланий клиента и указанных в заявке контактных данных.

Узнав подробности коммерческого предложения, клиент принимает решение о продолжении сотрудничества или отказе от него. Если клиент не согласился на условия КП, на этом процесс работы с ним заканчивается, а заявке присваивается статус «Отказ».

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

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

Пример построения диаграммы по текстовому описанию

Инструменты для разработки бизнес-процессов в нотации BPMN

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

  • ШТОРМ — веб-редактор от команды Дениса Котова, пожалуй, главного евангелиста BPMN в России, с автопроверкой диаграмм и возможностями командной работы в одном пространстве;
  • Online BPMN — простой и удобный веб-редактор, поддерживает интеграцию с BPMS-системой;
  • Cavemo — веб-редактор, аналогичный предыдущему, имеет офлайн-версию
  • простые веб-«рисовалки‎» Lucidchart, Draw.io, Visual Paradigm

Также алфавит нотации BPMN поддерживается и в MS Visio, ARIS Express и других редакторах диаграмм общего назначения.

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

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

Воркшоп «BPMN для людей:

основы самой популярной нотации

для описания бизнес-процессов»

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

Анна Вичугова

  • Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)
  • Сертифицированный бизнес-аналитик (CBAP 2020, международная сертификация IIBA)
  • Сертифицированный специалист Business Studio (2010, 2012, 2013, 2018)
  • Сертифицированный специалист и администратор СЭД Directum (2011)

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19.***, 34.***, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

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

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

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

Сегодня в мире наиболее популярны 3 нотации:

  • IDEF0.
  • EPC.
  • BPMN.

Когда возникли нотации?

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

Вторая, EPC (Event-driven Process Chain), появилась на 10 лет позднее. Её название (“цепочка событийных процессов”) даёт понять, что фокус сделан именно на событие.

Нотация BPMN – часть концепции BPM (управления бизнес-процессами). Впервые она возникла в 2004 году (версия 1.0) и несколько раз модернизировалась в 2008, 2009, 2011 и 2013 годах. Самая последняя версия – BPMN 2.0.2.

Рассмотрим особенности каждой из нотаций и их отличия.

 виды нотаций бизнес-процессов

Нотация IDEF0

Она позволяет создать модель, которая будет отражать:

  • Структуру системы.
  • Функции.
  • Потоки ресурсов, информации.

Модель IDEF0 разворачивается одновременно слева направо и сверху вниз, по диагонали. Объекты, расположенные левее / выше, доминируют над теми, которые находятся правее / ниже. Доминирующие объекты могут включать в себя зависимые: например, доставка заказа – это элемент, входящий в состав более масштабного процесса управления заказами. Также доминирующие объекты могут являться предшествующими этапами для зависимых: получение заявки – согласование заявки.

Графические элементы:

  • Прямоугольники – действия или этапы.
  • Стрелки – ресурсы, исполнители, необходимые для совершения действия или прохождения этапа.

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

Ещё один минус: с помощью IDEF0 лучше всего описываются модели, где бизнес-процесс представляет собой одну цепочку, без развилок. Если на пути он встречает множественные “или”, работать с IDEF0 становится очень сложно.

Нотация EPC

Она использует значительно больше элементов – разноцветных фигур.

  • Розовые фигуры – события.
  • Зелёные – функции (действия).
  • Жёлтые — исполнители.
  • Серые – ресурсы.
  • Оранжевые – информационные системы.

Модель разворачивается сверху вниз, более высокие элементы предшествуют более низким.

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

Чтобы выстроить схему, сначала определяются стартовое / финальное событие, затем – промежуточные события, необходимые для них исполнители, ресурсы.

Достоинство EPC – простота для восприятия. Разноцветные элементы делают модель более “живой”, приятной для глаз, а это немаловажно, если требуется нарисовать схему для сотрудников или провести презентацию.

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

Главный недостаток EPC в том, что её структурной единицей является событие, поэтому приходится создавать события для любых, даже самых незначительных этапов. EPC справедливо критикуют и за обилие тавтологических элементов: задача “определить исполнителей” – событие “исполнители определены”, задача “согласовать договор” – событие “договор согласован”. Если схема длинная и сложная, такие элементы её перегружают, как и многочисленные стрелки от “исполнителей” к “”событиям”, особенно если один исполнитель отвечает за множество событий, или на одно событие назначено несколько сотрудников.

Нотация BPMN

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

Основные элементы BPMN:

  • Задача (прямоугольник).
  • Событие (круг).
  • Шлюз, развилка (ромб).
  • Поток, ход (стрелка).
  • Базы данных, документы.
  • Сноски.
  • Пулы.

Базовая нотация BPMN включает не более 10 типов значков и помогает описать алгоритм в такой форме, которая будет понятна бизнес-пользователю, не прошедшему специального обучения. Расширенная BPMN содержит около 100 значков и позволяет сделать регламент машиночитаемым, причём не допуская разночтений.

Главное преимущество BPMN – она лучше всего подходит, если нужно описать именно бизнес-процесс, сделав его понятным даже для рядовых сотрудников. Сегодня BPMN пользуется популярностью: большинство вендоров, предлагающих системы BPM, предусматривают работу c BPMN: схему, созданную с её помощью, можно сделать исполняемой, подключив возможности информационной системы.

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

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

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

Понравилась статья? Поделить с друзьями:
  • Греется ли коробка передач во время работы
  • Гренада торговый центр люберцы часы работы
  • Гриль фактори адмирала трибуца часы работы
  • Гринвей что за компания независимые отзывы
  • Грингор ювелирная компания санкт петербург