Пример моделирования бизнес процесса в bpmn

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

Введение

В настоящее время моделирование бизнес-процессов в нотации BPMN является одним из инструментов, используемых в компаниях для понимания процессов «Как есть», разработки мероприятий по их оптимизации/цифровизации, формирования регламентирующих документов. Многие компании используют для описания процессов современный программный продукт Business Studio 5.

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

1. уровень знаний и компетенций по использованию нотации BPMN, к сожалению, всё еще довольно низкий — при моделировании сотрудники допускают много формальных (нотационных) и содержательных ошибок, что делает схемы непригодными для анализа и оптимизации бизнес-процессов;
2. функциональные возможности программного продукта Business Studio используются не в полной мере;
3. в организациях отсутствует подробная и качественная методика формирования моделей бизнес-процессов, например в виде «Соглашения по моделированию».

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

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

Постановка задачи

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

Первое. Точка зрения – руководитель 1-2 уровня компании, заинтересованный в оптимизации и цифровизации бизнес-процесса в целом. Обратите внимание, что точка зрения, например, ИТ-специалиста, ответственного за внедрение какой-либо информационной системы (ERP, ЭДО, CRM и проч.) может существенно отличаться от точки зрения руководителя, то есть от «бизнесовой» точки зрения.

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

Итак, схема бизнес-процесса в нотации BPMN в Business Studio 5 должна содержать:

1. потоки информации (документов);
3. статусы информации (документов) с точки зрения их жизненного цикла и формы представления;
4. используемые информационные системы (программные продукты);
5. используемые для хранения информации (документов) ресурсы («хранилища данных»);
6. информацию во взаимодействии бизнес-процессов по входам/выходам.

Посмотрим, как можно решить указанную задачу средствами Business Studio 5. Разбирать метод будем на простом и наглядном примере.

Пример модели бизнес-процесса в нотации BPMN в Business Studio

На рис. 1 представлена простейшая схема подготовки, согласования и утверждения некоторого документа «Х». Это, можно сказать, «голый» поток работы (Work Flow). Есть ли компании, которые ТАК моделируют процессы? Как это ни странно, да, есть. Наблюдал в нескольких организациях. Отсутствие возвратов (после согласования/утверждения) и полное отсутствие информации/документов объясняют желанием «упростить» схему и сделать ее «наглядной» для бизнес-пользователей. При этом информацию «о действиях в случае отклонений» выносят в приложения к нормативному документу, а входы/выходы прописывают вручную прямо в самом проекте регламента, а не выгружают автоматически из Business Studio. Использование такого «ручного» труда, на мой взгляд, сродни покупке профессионального перфоратора, который потом не включают в розетку, а долбят дырки в стене вручную.

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

Что можно сделать с такой схемой? Прежде всего, отобразить реальный поток работы – возвраты после согласований.

Рис. 1. «Голый» поток работы.

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

Рис. 2. Поток работы с возвратами.

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

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

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

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

Моделирование информационных потоков на схемах в нотации BPMN в Business Studio

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

Для того, чтобы показать это движение, использована пунктирная стрелка типа «Association» (термин BPMN).

Рис. 3. Поток документов.

Если смотреть на схему непредвзято, с точки зрения здравого смысла, то можно задаться вопросом: «Дает ли наличие таких стрелок и значков «Документ “Х”» какую-то дополнительную аналитическую информацию?». Скорее «Нет», чем «Да». Но лишней работы по моделированию это добавляет точно. Возникает вопрос: «А может тогда лучше вообще не показывать эти документы»? Бизнес-аналитики некоторых компаний, которые моделируют движение документов на таком абстрактном уровне, постепенно вообще отказываются от визуализации документов на схемах.

Отмечу, что в проектах мы принципиально не используем справочник «Бумажные документы», только – «Электронные документы», чтобы не дублировать сущности. Так же не используем справочник «Информация». Почему? Любая информация в бизнесе, даже неструктурированное письмо по e-mail или сообщение по WhatsApp, может рассматриваться в качестве документа. Если в Business Studio одновременно использовать справочник «Электронные документы» и «Информация», то может возникнуть ненужная путаница.

С точки зрения анализа реального процесса «Как есть» схема рис. 3 опять неполна и не может быть эффективно использована. Что можно сделать?

На рис. 4 показаны статусы документов. Например, после задачи «Подготовить проект документа» Документ «Х» имеет статусы «Проект» и «Word». Они указывают на то, что документ создан в формате MS Word (статус – «Word») и готов для согласования (статус – «Проект»).

Рис. 4. Поток документов со статусами.

После задачи «Согласовать проект документа», Документ «Х» приобретает статусы «Несогласован» и «Word» или «Согласован» и 1С-ДО, то есть статусы определяются контекстно.

Как технически настроены статусы в Business Studio? Через свойства документа («Свойства объекта» по правой кнопке) можно найти «Статусы» и создать новый термин в справочнике «Термины», означающий нужный статус документа (информации). После этого можно вывести статус на показ, используя функционал Business Studio «Настроить показ параметров».

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

В справочнике «Термины» мы используем следующую группировку статусов (показаны примеры статусов):

1. По жизненному циклу документов:

   1. Проект
   2. Согласован
   3. Утвержден
   4. Подписан компанией
   5. Подписан клиентом
   6. …

2. По форме:

   1. Устно
   2. Бум.
   3. Excel
   4. Word
   5. e-mail
   6. Скан в pdf
   7. Скан скан-копии в pdf

3. Внутри ИС:

   1. 1C-ERP
   2. CRM
   3. Business Studio
   4. Контур.Диадок
   5. …

4. Формализован/неформализован:

   1. Неформ.
   2. Форма
   3. Шаблон

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

Моделирование ресурсов (хранилищ данных) на схемах в нотации BPMN в Business Studio

На рис. 5 показаны объекты типа «База данных» для того, чтобы показать, посредством какого ресурса (среды, хранилища) осуществляется переда документа от задачи к задаче.

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

Рис. 5. Поток документов с ресурсами.

Что такое база данных в современных условиях? Можно ли использовать, например, SQL Server без необходимой для доступа к данным прикладной программной оболочки? Конечно, нет. Поэтому мы используем в проектах справочник «Базы данных» в широком смысле в качестве ресурсов – мест хранения документов (информации), например:

1. Корпоративные ресурсы:

   1. 1С

      1. 1С-ERP
      2. 1С-ERP-CRM
      3. 1C-ДО

   2. Архивы электронные

      1. Архив Бухгалтерии
      2. Архив Юр.службы
      3. …

   3. Архивы бумажные

      1. Архив Бухгалтерии
      2. Архив Юр.службы
      3. …
   4. Outlook
   5. Сервер
   6. WhatsApp
   7. …

2. Персональные ресурсы:

   1. РМ сотрудника
   2. РС

3. Внешние ресурсы:

   1. ЭТП поставщика
   2. ЭДО
   3. …

На рис. 5 показано, что Документ «Х» передается от задачи «Подготовить проект документа» к задаче «Согласовать проект документа» посредством MS Outlook, то есть «временным прибежищем» для этого документа служит Outlook. Некоторые компании, кстати, умудряются до 80% всех рабочих документов хранить в Outlook, что является проблемой (путаница в версиях документов, долгий поиск, перегрузка сервера, риск потери важной информации и проч.).

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

Моделирование информационных систем на схемах в нотации BPMN в Business Studio

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

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

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

Информационные системы берутся из справочника Business Studio «Программные продукты», который может быть структурирован, например: так:

1. Офисное ПО:

   1. MS Office

      1. MS Word
      2. MS Excel
      3. MS Outlook
      4. …

2. Корпоративное ПО:

   1. 1C-ERP

      1. 1C-ERP-CRM
      2. 1C-ДО
      3. …
   2. Business Studio
   3. BI
   4. …

3. Специальное ПО:

   1. Контур.Диадок
   2. Контур.Фокус
   3. Telegram.Чат-бот
   4. ЭТП поставщика…

4. Сетевое и серверное ПО:

   1. …

Рис. 6. Информационные системы.

В версии Business Studio 5 нельзя настроить визуальный размер и цвет значков выбранного типа один раз для всей рабочей базы. Это приходится делать вручную на каждой схеме. Мы делаем значок программного обеспечения в виде небольшого четырехугольника и закрашиваем его в «фирменный цвет» соответствующий информационной системы, например, 1С – в желтый.

Информационные системы (программные продукты) связываются с задачами двумя различными видами входящих связей:

• «Поддерживает» — в случае, если ИС используется сотрудником при выполнении задачи;
• «Выполняет» — в случае, если задача выполняется целиком автоматически.

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

В чем разница между информационными системами (программными продуктами) и ресурсами? Почему недостаточно использовать что-то одно? На рис. 6 видно, что для подготовки документа используется MS Word, а передается документ через MS Outlook. То есть представление информационных систем и ресурсов на схеме бизнес-процесса не дублирует друг друга, как может показаться на первый взгляд. Эти два аспекта дополняют друг друга и делают модель аналитически полной.

Зачем одновременно показывать на схеме информационные системы и статусы документов? Ведь и так «всё понятно»? Не всё так просто… Например, документ может быть подготовлен в 1С, выгружен в MS Word и доработан вручную, а потом в виде скана в pdf отправлен клиенту через WhatsApp. В данном примере для выполнения задачи использовалось три программных продукта, но ресурсом (хранилищем), использованным для отправки документа, был WhatsApp. Ресурсами, используемыми для хранения файлов MS Word и pdf, могли быть «РС» (т.е. жесткий диск компьютера сотрудника) или сервер компании.

Моделирование межпроцессного взаимодействия по входам/выходам на схемах в нотации BPMN в Business Studio

Моделирование потоков документов (информации) будет не полным, если не показать взаимодействие между разными бизнес-процессами по входам/выходам.

В нотации BPMN в Business Studio 5 для решения этой задачи можно использовать следующую конструкцию – см. рис. 7. Мы связываем бизнес-процесс «Подготовить данные для проекта документа “Х”» (показан на схеме как свернутый пул) стрелкой типа «Message Flow» с задачей бизнес-процесса «Подготовить проект документа». Такая связь в нотации BPMN означает отправку и получение сообщения. По сути, это управляющее воздействие одного экземпляра процесса на другой экземпляр. Но в Business Studio мы сознательно идем на нарушение стандарта и интерпретируем такую связь просто – один бизнес-процесс поставляет на вход другого бизнес-процесса документы (информацию).

Далее к стрелке «Message Flow» привязывается конкретный документ. На рис. 7 – это «Данные для подготовки документа “Х”». Статус показывает, что это документ в формате MS Excel, а привязанная «База данных» показывает, что ресурсом (хранилищем) для этого документа служит файл-сервер компании.

Таким образом, рассматриваемый контекст нужно читать так: «Бизнес-процесс «Подготовить данные для проекта документа “Х”» когда-то (вполне возможно, что намного раньше, чем стартовал процесс «Подготовить, согласовать и утвердить документ») в процессе своего выполнения создал файл MS Excel и положил его на файл-сервер. Через какое-то время процесс «Подготовить, согласовать и утвердить документ» при выполнении задачи «Подготовить проект документа» обратился к файл-серверу и взял оттуда этот документ.

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

Рис. 7. Взаимодействие между бизнес-процессами по входам/выходам.

На рис. 8 представлен пример схемы бизнес-процесса, разработанной с использованием представленного в статье метода.

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

Рис. 8. Пример схемы бизнес-процесса.

Выводы

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

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

Однако, если вы хотите, чтобы ваши схемы бизнес-процессов «Как есть» в нотации BPMN в Business Studio 5 могли реально использоваться для анализа и принятия решений по оптимизации/цифровизации процессов, то представленный методический подход целесообразно использовать.

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

Удачи в проектировании подробных и практически полезных моделей бизнес-процессов в нотации BPMN в Business Studio!

www.bpm3.ru

Январь 2023 г.

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

Как повысить производительность на 88% без вложений в модернизацию оборудования?

Управление на высоких скоростях: процессный подход в гонке за лидерство в ритейле

Business Studio 4.0: новое пространство бизнес-моделирования

Глоссарий

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

BPMN 2.0. События начала 

У каждого процесса должно быть, как минимум, одно событие начала 

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

  

У каждого процесса должно быть, как минимум, одно событие начала. Если вы не можете определить событие начала, то есть два варианта: 

1. Границы процесса определены не верно
2. Это не процесс, а группа процессов, что, опять же, говорит о том, что процесс и его границы, определены не верно. 

Несколько событий начала 

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

• Получено задание руководителя на подготовку отчета 

• Последний рабочий день месяца

• Последний день перед отпуском 

 

Каждое из этих событий будет стартовать выполнение одного и того же процесса. 

Множественное событие начала 

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

Параллельное множественное событие начала 

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

Разные события начала 

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

 

Размещение событий начала в пулах 

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

 

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

 

Связь событий между уровнями декомпозиции 

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

 

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

 

Множественное событие начала процесса может быть декомпозировано на уровне ниже 

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

 

Событие начала в подпроцессе не должно иметь типа 

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

 

Правильное наименование события начала 

Одна из распространенных ошибок — называть событие начала наименованием входа, объекта, поступающего в процесс. Например — заявка клиента. Это неверно. Заявка клиента, это документ, объект. А вот событие начала, да и любое событие, должно отражать свершившийся факт законченного действия. Вместо “Заявка клиента”, правильно назвать “Получена заявка клиента”. В названии события обязательно должен быть указан объект и действие, событие, которое с объектом произошло. Наименование события должно иметь форму деепричастного оборота. 

 

Если событие начала инициировано ролью 

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

 

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

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

1 — Добавить номер, или наименование связанного процесса, в название события. 

 

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

 

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

 

4 — Использовать ссылку на процесс или событие окончания. 

 

BPMN 2.0. Промежуточные события 

Событие — условие развития процесса 

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

  

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

 

Событие, это всегда результат какого-то процесса или операции 

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

 

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

 

События определяют сценарии процесса 

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

 

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

 

Не прерывающие событие 

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

 

Несколько событий подряд 

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

 

Несколько условий, для развития процесса 

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

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

 

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

Событие, как условие времени 

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

 

События на границах операций / процессов 

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

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

 

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

 

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

 

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

 

BPMN 2.0. События окончания

Событие окончания — условие завершения процесса 

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

 

Несколько событий окончания 

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

Множественное событие окончания 

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

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

 

Событие окончания может быть событием начала другого процесса 

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

Расположение событий окончания 

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

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

 

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

 

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

 

Нет такого события окончания, как “Процесс завершен” 

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

BPMN 2.0. Все события

Событие, это завершенное действие, а не объект 

Еще раз повторю — событие, это завершенное действие, в названии которого есть объект и действие, которое выполнено с этим объектом. Не “Приказ”, а “Получен приказ”. 

Связь документов и событий

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

 

Парные события нужно называть одинаково 

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

 

Называйте события состояния так, чтобы было понятно, какое состояние оно отражает 

Событие типа Состояние, отражает изменение некого состояния. Например, “Превышен кредитный лимит”. Соответственно, называть такие события нужно, чтобы было понятно, какое состояние оно отражает. Нельзя назвать событие просто “Кредитный лимит”, потому что становится непонятно, что с этим лимитом произошло.

 

BPMN 2.0. Шлюзы 

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

 

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

 

То есть шлюзы бывают исходящие и включающие. Или, проще говоря — ветвления и объединения. 

Шлюз, это логическая конструкция 

Существует 3 логические конструкции, которые используются в шлюзах: 

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

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

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

 

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

 

Комплексный шлюз

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

1 — В кармане пачка сигарет, 

2 — И лампа не горит, И врут календари. 

 

В следующем примере тоже два варианта: 

1 — В кармане пачка сигарет И есть билет на самолет; 

2 — Группа крови на рукаве. Обе комбинации приводят к одному сценарию. 

 

Шлюз, это не принятие решения 

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

 

Условия развития событий

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

 

Ветвление без шлюза 

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

 

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

Наименование шлюза 

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

 

Шлюз без названия 

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

Ветвление, а затем объединение не имеет смысла 

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

 

Такие конструкции не имеют смысла. И вот почему: 

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

 

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

 

·      Если хотите показать, что нужно выполнить действия, но порядок и состав не важен, замените на процесс Ad Hoc. В процессе Ad hoc не важно в каком порядке и, даже, в каком составе будут выполнены операции. Вы можете добавить сахар, сливки, корицу в кофе в любом составе и порядке. 

 

Заменяйте сложны ветвления бизнес-правилами 

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

Пример сложного ветвления, лишь при трех условиях 

То же сложное ветвление, но представленное в виде бизнес-правила 

Суть объединяющего шлюза 

Суть в том, что объединяющий шлюз показывает — чтобы процесс мог идти дальше, должно быть выполнено несколько операций, или условий. Или должно быть выполнено несколько операций и выполнено несколько условий. Объединяющий шлюз также работает по логическим принципам: исключающее ИЛИ, ИЛИ, И. 

 

Комплексный шлюз. Объединение

Объединяющий шлюз И 

Наименование объединяющих шлюзов 

Нет необходимости называть объединяющие шлюзы. Можно давать текстовые аннотации к ним, там, где они логически не совсем очевидны. 

BPMN 2.0. Пулы / дорожки 

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

  

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

Название пула должно соответствовать роли 

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

Пулы, дорожки и организационная иерархия 

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

 

Иерархия пулов и дорожек 

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

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

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

 

Переход процесса от одного пула к другому 

Пулы могут соединяться между собой только информационными потоками. 

 

Информационные потоки между пулами 

Дорожки операции в дорожках соединяются рабочими потоками

Рабочий поток между дорожками   

Лучшая связь между элементами разным пулов выглядит как связь между операциями и событиями. То есть действие в одном пуле, порождает событие в другом пуле. Хотя может быть и прямая связь “операция — операция” 

 

Лучший способ отразить переход процесса между пулами  

Пулы могут обмениваться документами. 

 

Обмен документами между пулами

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

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

Связи документов с элементами BPMN 

В нотации BPMN, документ может быть связан с: 

• Операциями и процессами, через направленную ассоциацию 

• Событиями, через ненаправленную ассоциацию

• Пулами, через направленную ассоциацию

• Базами данных, через простое соединение 

 

Связи объектов данных с другими элементами 

Направление ассоциации имеет значение 

Если стрелка ассоциации идет от документа к операции, это означает, что документ используется для выполнения операции. Если стрелка ассоциации идет от операции к документу, это означает, что документ появляется в результате выполнения операции. 

 

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

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

 

Направленные ассоциации с базами данных 

Отражение состояний объекта данных 

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

 

Отражение состояния документа с помощью наименования 

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

Копии объектов данных 

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

 

М- оригинал. А — копия

Вывод — используйте копии объектов только тогда, когда вы хотите показать использование одного и того же объекта в разных местах. Это справедливо для объектов всех типов. Копии можно использовать и в рамках одной диаграммы, чтобы не “тянуть” длинные и неудобные для восприятия стрелки.

 

Копии можно использовать для оптимизации диаграммы 

Ссылки на процессы, которые являются источниками документов 

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

1 — Если ПО позволяет, то можно создать физическую ссылку на процесс. В Visual Paradigm для этого используется функция Trace. 

 

Связь документов и процессов-источников

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

 

Использование наименование документа, для отражения процесса-источника документа

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

 

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

Связь документа и базы данных 

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

Связи документов и баз данных

Базы данных для отражения ИТ системы 

Значок базы данных можно использовать для отражения взаимодействия операций и процессов с ИТ системами.

 

Использование значка БД в качестве ИТ системы 

Прикрепляйте документы к объектам данных 

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

 

BPMN 2.0. Операции / процессы 

Операция — элементарное действие, которое выполняется в процессе. Элементарное — действие, которое нельзя декомпозировать и раскрыть в качестве процесса. Процесс — совокупность операций и подпроцессов. 

Наименование операций

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

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

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

Используйте подпроцессы, для разделения процесса на этапы 

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

 

Разделение процесса на этапы, с помощью подпроцессов 

Используйте процедуры вместо цепочек операций

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

 

Сворачивайте последовательные операции в процедуры 

Заменяйте сложные участки с ветвлениями бизнес-правилами 

Вместо разветвленной цепочки условий, лучше использовать операции типа Бизнес-правило. Только не забудьте описать или прикрепить описание правила. Использование процедур и правил существенно упрощает моделирование, восприятие и использование модели. 

Цикличные операции / процессы 

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

 

Операция со стандартным циклом   

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

 

Множественный цикл

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

 

Преобразовывайте циклические участки процесса в подпроцессы. В данном примере подпроцесс имеет развернутый вид.   

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

 

Компенсация вместо циклической конструкции 

Ручная, автоматическая и пользовательская операция 

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

 

Ручная, пользовательская и автоматическая операция   

BPMN 2.0. Потоки 

Рабочий поток 

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

 

Рабочий поток

Поток работ отражает порядок выполнения операций и процессов 

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

 

Рабочий и информационный поток в диаграмме 

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

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

 

Правила наименования 

Давать наименование рабочему потоку по умолчанию не нужно Условные потоки нужно называть в соответствии с теми условиями, по которым они становятся активными. 

Располагайте потоки работ горизонтально 

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

Направление потоков всегда идет слева направо

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

Потоки сообщений используются для отображения коммуникаций между участниками процесса. 

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

 

Потоки сообщений между пулами 

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

Поэтому, документы нужно отображать отдельно.

 

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

Неочевидные информационное потоки должны иметь название. 

Очевидный информационный поток, это поток, который исходит из операции или процесса, в наименовании которого понятно, что и куда передается. К примеру, если информационный поток исходит из операции “Отправить отчет”, то такой поток является очевидным. Если поток идет из операции “Подготовка к инвентаризации”, то оно является неочевидным, потому что непонятно, что именно отправляется или получается с этим потоком 

BPMN 2.0. Композиция диаграмм 

Оставляйте достаточно свободного пространства 

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

 

Пространство между элементами диаграммы должно быть достаточным 

Выравнивание элементов диаграммы 

Все элементы диаграммы должны быть выровнены, относительно друг друга. По горизонтали и вертикали.

 

Выравнивание элементов диаграммы относительно друг друга 

Однотипные элементы должны иметь один размер 

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

 

Ограничьте количество элементов на диаграмме 

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

 

Диаграмма явно перегружена

  

Оптимально для восприятия

Сохраняйте основную ось процесса — поток по умолчанию 

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

 

Поток по умолчанию — центральная ось. Остальное, это ответвления от него 

Проверяйте грамматику и пунктуацию 

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

BPMN 2.0. Частные случаи 

Когда пул — черный ящик

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

 

Роль в процессе может быть представлена в виде пула — черного ящика   

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

Взаимодействие пользователя с ИТ системой

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

 

Взаимодействие пользователя и ИТ системы 

Сбор результатов параллельных потоков

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

 

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

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

BPMN – Business Process Management Notation – это система условных обозначений для построения схемы протекания бизнес-процессов (моделирования бизнес-процессов). Моделирование бизнес-процессов играет важнейшую роль для управления предприятием. Если в компании работают более 50 человек, то собственник уже не способен лично контролировать всё происходящее, поэтому для него становятся “тайной” многие взаимодействия сотрудников, особенности производства, обслуживания клиентов.

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

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

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

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

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

В основе любой схемы такого типа лежит событие. К событиям могут относиться:

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

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

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

Одним из вариантов ПО, с помощью которого можно проводить как моделирование, так и автоматизацию бизнес-процессов, является Comindware Business Application Platform – отечественная Low-code платформа для моделирования и управления BPMN-процессами и цифровой трансформации предприятия.

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

Купив платформу Comindware, вы сможете создать любое ИТ-решение для своего бизнеса. Например, систему управления взаимоотношениями с клиентами (CRM).

Создание практически любого решения для бизнеса, включая CRM, не обходится без создания бизнес-процессов. Среди важных возможностей платформы от Comindware – импорт бизнес-процессов, созданных в соответствии с нотацией BPMN 2.0, из других систем. Например: компанией уже было проведено моделирование бизнес-процессов с помощью системы BPM, использовавшейся ранее. Импорт бизнес-процессов позволяет не проделывать повторно работу, которая уже была выполнена, и избежать лишних сложностей при внедрении CRM-системы на базе Comindware Business Application Platform.

Для примера, один из процессов BPMN, созданный в системе CRM на платформе от Comindware, может выглядеть так:

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

Стоит также отметить, что данная платформа относится к типу Low-сode, что обеспечивает минимальное участие IT-отдела в создании и запуске в работу бизнес-процессов, а также позволяет бизнес-аналитикам вносить необходимые правки в процессы «на лету», своими силами.

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

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

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

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

Анатолий Белайчук, признанный эксперт в области BPM и автоматизации процессов. Имеет свыше 20 лет опыта руководящей работы и консалтинга в области управления бизнес-процессами. Является президентом Российского отделения Международной ассоциации BPM-профессионалов — ABPMP Russian Chapter, а также соавтором перевода спецификации нотации BPMN.

https://www.facebook.com/anatoly.belaychuk