Нотация bpmn ошибки

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

В 2018 году я провёл 10 часов таких разборов. Я пересмотрел все записи и выписал топ-25 ошибок, которые встречались и способы их лечения.

Ошибки в BPMN бывают трех видов:

1. Ошибки формальные — когда диаграмма не соответствует BPMN.
2. Ошибки стиля — когда схема формально правильная, но читать или модифицировать её неудобно. Стилевые предпочтения у всех свои.
3. Ошибки логики — это когда схема правильная, стиль соблюден, но есть проблемы в сути того, что нарисовано.

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

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

Для тех, кто торопится

Я разработал бесплатный облачный сервис для рисования и обсуждения диаграмм с коллегами, который сам проверяет 80% ошибок. Он очень экономит время и делает обсуждение удобным. Регистрируйтесь!

25. НЕ BPMN (Формальная ошибка BPMN)

В диаграмме использованы символы, которых нет в BPMN. Это символы из Archimate, UML, IDEF и других нотаций.

24-23. Пулы вместо дорожек. Дорожки вместо пулов (стилевая ошибка BPMN)

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

А дорожки, наоборот, показывают участников описываемого процесса:

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

22. Гонка сигналов (Логическая ошибка BPMN)

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

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

Вылечить можно так:

Старайтесь избегать таких ситуаций по логике бизнес-процесса.

21. Возврат главного потока назад или вниз (Стилевая ошибка BPMN)

Авторы пытаются вписать процесс змейкой в формат А4.

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

20. Обслуживание “главного” (Логическая ошибка BPMN)

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

С точки зрения бизнес-процесса “главный” такой же участник, который должен сделать свою часть работы:

19. Всё завершения в одно завершающее событие (Стилевая ошибка BPMN)

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

Разумнее нарисовать схему так:

18. Переход в межпроцессное взаимодействие там, где это не нужно. (Стилевая ошибка BPMN )

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

Такое отображение только усложняет схему и не отличается от такого:

17. Одна задача для множественной обработки (Логическая ошибка BPMN)

В BPMN есть элементы, показывают итерирование по набору сущностей.

Аналитики делают задачу, в названии которой пишут массовую операцию:

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

16. Инструкция, а не процесс (Логическая ошибка BPMN)

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

Такие задачи можно рисовать одним кубиком:

15. Страх “сложных” символов (Стилевая ошибка BPMN )

Достигнув определённого понимания инструментов и почувствовав в нём уверенность, авторы начинают решать все задачи имеющимися инструментами.

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

14. Использование conditional flow (стилевая ошибка BPMN )

BPMN позволяет на потоки управления навешивать условия.

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

13. Одна развилка для сборка и разведения токенов (стилевая ошибка BPMN)

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

Лечится просто:

12. Сверху вниз (стилевая ошибка BPMN)

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

В BPMN схемы моделируются слева направо. Некоторые редакторы, например https://bpmn.io/ не дают размещать пулы или дорожки вертикально.

11. Передать информацию, получить информацию (логическая ошибка BPMN)

Для отображения факта передачи информации не надо ставить задачи:

Сам поток управления и означает факт передачи информации.

Нужно рисовать вот так:

10. Текст вместо символов (стилевая ошибка BPMN)

Много комментариев, которые можно выразить символами BPMN.

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

9. Неверное использование бизнес-правил (стилевая ошибка BPMN)

Символ бизнес-правил напоминает таблицу, поэтому люди вставляют его туда, где предполагается работа с таблицами:

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

8. Разный уровень задач на процессе (логическая ошибка BPMN )

Это ситуация, когда на одной схеме задачи совершенно разного операционного уровня:

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

7.Техника, а не бизнес-процесс (логическая ошибка BPMN)

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

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

6. Много стрелок в\из квадратиков (стилевая ошибка BPMN)

Когда вы вставляете много стрелок в квадратик, вы можете сконфузить читателя  — легко подумать, что 2 стрелки должны прийти вместе:

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

5. Не сходятся токены (формальная ошибка BPMN )

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

Развилка №2 никогда не пропустит процесс дальше, т.к. ждёт 3 токена на вход (потому что 3 входящих потока), но И/ИЛИ развилка между Task 2 и Task 3 запустит токен только по одному из потоков. Исправляется тем, что мы добавляем исключающую развилку, который “соберёт” токены, перед тем, как их вставить в развилку №2.

4. Перепутаны потоки (формальная ошибка BPMN )

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

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

3. Элементы ничем не заканчиваются (стилистическая ошибка BPMN )

BPMN формально разрешает брошенные элементы:

Но это просто отвратительно — у читателя сразу масса вопросов. Где завершение? Забыли нарисовать? Почему есть начало, но нет завершения?

Старайтесь чтобы из задачи всегда был выход.

2. Задачи на клиента (стилистическая ошибка BPMN)

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

Это довольно сильно меняет наш процесс, мы полагаемся только на свои силы и на те вещи, на которые можем влиять:

1. События используются c ошибками(формальная ошибка в BPMN)

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

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

В этот пост все события уже не поместятся, ждите следующий.

Заключение

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

Напишите в комментарии — какие еще сложности у вас возникают при моделировании в BPMN?  О каких ошибках я забыл?

Если на собеседовании вас спрашивают «Имеете ли вы опыт моделирования бизнес-процессов», то в неявном виде вас спрашивают об опыте использования нотации BPMN. Мне могут возразить, что есть и другие нотации, например UML Activity diagram или старый-добрый IDEF0. Но на сегодняшний день место лидера за BPMN.

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

В интернете есть целый ряд статей, посвященных рассмотрению ошибок, которые чаще всего допускают при создании диаграмм в нотации BPMN (ссылка 1, ссылка 2, ссылка 3, …). Отталкиваясь от них и от своего десятилетного опыта я написал эту статью.

Ошибки в BPMN-диаграммах бывают трех видов:

• Ошибки формальные – диаграмма не соответствует нотации BPMN.

• Ошибки стиля – диаграмма формально верная, но читать или модифицировать ее неудобно. Стилевые предпочтения у всех свои.

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

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

1. Не BPMN

В диаграмме использованы элементы, отсутствующие в BPMN. Это символы UML, IDEF и других нотаций. Или это самодельные, придуманные автором символы. Самый просто способ убедиться в том, что вы используете корректные элементы — обратиться к постеру BPMN elements

2. Пулы (Pool) та дорожки (Lane)

Во-первых, пулов и дорожек на диаграмме может не быть. Однако их наличие упрощает понимание диаграммы.

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

Дорожки позволяют нам показать участников описываемого процесса – кто какую задачу в рамках процесса выполняет. Если вдаваться в детали, то дорожки – элемент чисто визуальный. Исполнителя/исполнителей для каждой задачи указывают в ее свойствах. Вот как это выглядит в Bizagi:

Можно увидеть, что здесь есть возможность указать участников и указать их вовлеченность в выполнение задачи по RACI-матрице.

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

Итак,

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

• процессы или внешних контрагентов моделируем пулами;

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

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

3. Глагол в названии
Название задачи должно содержать глагол: «Создать заявку», «Отправить запрос». Некоторые вместо этого пишут «Создание заявки», или еще хуже «Заявка». Это ошибка в стиле.

4. Подробное описание процесса, о котором мы ничего не знаем

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

5. «Долгая-долгая история»

Если процесс содержит много шагов, то диаграмма начинает напоминать детскую игру «змейка»:

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

Для разрешения этой ситуации есть 2 варианта:

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

2. Или использовать промежуточное событие «Ссылка» (Link):

6. «Потерянное письмо»

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

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

Теперь давайте рассмотрим пример диаграммы:

Если Task 2 будет завершен раньше, чем Task 1, то отправленное Process 2 сообщение потеряется, потому что Process 1 начинает его ожидать только после завершения Task 1. А до этого момента «почтальона» никто не встречает. Для исправления этой ситуации мы можем изменить диаграмму следующим образом:

Здесь мы письмо начинаем ждать сразу после отправки со стороны Process 1.

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

7. «У всех свой путь, своя цель, но всех нас ждет один конец.»
С высказыванием Карлоса Кастанеды можно соглашаться, можно нет. Но очень редко у процесса возможен только один вариант завершения, как показано на диаграмме:

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

8. «Конец-делу венец» или завершение без описания.

All’s Well That Ends Well или «Все хорошо, что хорошо заканчивается». Не оставляйте финальное событие без подписи. Особенно эта подпись необходима, когда завершающих событий у нас несколько, как на последнем рисунке в пункте 7. Укажите, какой результат мы получили, когда дошли до этого красного кружка. Это упростит восприятие диаграммы читателем, а engine зафиксирует в протоколе, чем закончился экземпляр процесса.

9. «и швец, и жнец, и на дуде игрец»

Часто в диаграммах можно увидеть, что одна развилка (gateway) используется одновременно и для сведения, и для разветвления потоков:

Практики и теоретики рекомендуют использовать одну развилку либо для сведения, либо для разветвления. Меняем диаграмму следующим образом:

10. «Смешались в кучу кони, люди»

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

мы можем перейти к следующей, используя специальный тип задачи «Business Rule Task»:

Продолжение следует…

Расписание тренингов по бизнес-анализу и анализу данных от Art of Business Analysis

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

Введение

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

Для выполнения этой задачи нужны: эффективная система управления проектом, методология, инструмент (система моделирования) и человеческие ресурсы, адекватные по численности и подготовке. Если инструмент можно легко купить, то с методологией и ресурсами всё не так просто. Качество управления проектом сильно зависит от конкретного руководителя.

Методология комплексного описания процессов организации с использованием конкретного инструмента — это не просто описание нотации моделирования в части используемых значков. Это более сложный объект для разработки. Отмечу, что Методология в целом не является предметом этой статьи (будет рассмотрена позже). Методология комплексного описания процессов должна быть подробно описана в «Соглашении по моделированию» компании.

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

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

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

Исходные данные для анализа

Исходные данные для анализа таковы. В ряде компаний (нефтедобыча, производство, ритейл и проч.) проводилось обучение временных рабочих групп (ВРГ) численностью 25–30 человек. Некоторые участники когда-то занимались «описанием» процессов при помощи «диаграмм с ромбиками» (в Business Studio — это нотация «Процедура») или сталкивались с нотацией eEPC. Но большинство специалистов созданием графических схем не занимались.

Обучение проводилось в течение 2 дней на основе методического пособия «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» (В. В. Репин, 2018 год). В первый день слушателей последовательно знакомили с основами нотации BPMN. Они выполняли ряд связанных между собой заданий, моделируя процесс в среде Business Studio и двигаясь от простого к сложному.

Во второй день рассматривались более сложные примеры и выполнялось комплексное задание на описание группы связанных между собой процессов. Это задание выполнялось в небольших рабочих группах по 2–3 человека. После описания процессов группы выполняли анализ качества моделей на основе чек-листа. Проводился разбор ошибок.

Далее сотрудники, прошедшие обучение, включались во временные рабочие группы по описанию процессов. ВРГ разрабатывали графические схемы процессов. Выполнялся анализ качества этих схем и разбор ошибок (дистанционно или на рабочих сессиях).

Требования и правила моделирования устанавливались в «Соглашении по моделированию» компании.

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

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

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

Типовые ошибки моделирования, допускаемые начинающими

Проблема мышки

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

Оборванные входы-выходы

Следующая проблема — это оборванные входы-выходы. У неопытных и довольно безответственных рисовальщиков документы появляются «из воздуха», «зависают» на выходе операций процесса и никуда не попадают. Часто начинающие вообще не показывают на схеме потоки документов/информации.

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

Обсуждая входы/выходы можно отметить два аспекта. Технически на схеме в нотации BPMN в среде Business Studio можно показывать взаимодействие между разными процессами при помощи стрелки типа massage flow, связывая конкретную операцию процесса со свернутым пулом (другой процесс). Для последующей возможности вывода информации о входах/выходах в отчеты к этой стрелке должен быть привязан конкретный документ. Часто неопытные пользователи забывают это делать. Но сама по себе стрелка massage flow без привязанного к ней документа с точки зрения комплексной модели в Business Studio не несет конкретной информации.

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

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

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

На мой взгляд, наличие потока документов на схеме процесса в нотации BPMN в Business Studio необходимо и практически полезно для целей анализа, регламентации и автоматизации.

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

Рис. 1. Оборванные и отсутствующие входы-выходы (фрагмент схемы).

Некорректная логика процесса

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

Рис. 2. Пример логической ошибки (фрагмент схемы процесса). Нет входов/выходов.

Непонимание межпроцессного взаимодействия

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

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

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

• отправляют сообщение в другой процесс (свернутый пул на схеме в Business Studio), который не должен запускаться (инициироваться) — с ним просто есть взаимодействие по входам-выходам (причем, чаще всего, опосредованное — через базу данных или файл-сервер компании);
• отправляют сообщение в свернутый пул под названием «Все процессы», «Поставщик» или, что хуже всего, «Отдел такой-то…» (в Business Studio можно создать свернутый пул из так называемой «Внешней ссылки»);
• отправляют сообщение в процесс, который находится в дереве на 2–3 уровня выше описываемого и сформирован в нотации IDEF0 — отправка «на деревню дедушке»;
• показав отправку сообщения на схеме описываемого процесса, не открывают другой процесс и не дают себе труд продумать, куда попадает отправленное сообщение и как оно повлияет на выполнение другого процесса.

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

Рис. 3. Некорректное использование событий отправки/получения сообщений (фрагмент схемы). Нет входов/выходов.

Использование таймеров

Событие-таймер используется как по ходу процесса, так и в виде граничного события. Как пример типичной ошибки начинающих приведу следующую формулировку события-таймера: «Не позднее 2-го числа месяца». Когда должен сработать таймер — непонятно. Другой пример — «Ежедневно» (см. рис. 4).

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

Рис. 4. Некорректное использование события-таймера (фрагмент схемы).
Нет входов/выходов.

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

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

Процесс в процессе (рекурсия)

Довольно часто можно наблюдать такую картину. Берем для анализа процесс под ‘каким-то названием. Начинаем смотреть его детальную схему в BPMN. Видим кучу действий с бумажками (служебки, распоряжения, отчеты, поручения и проч.). Где-то среди всей этой волокиты видим операцию, название которой в точности повторяет название процесса в целом. И это называется описать процесс! Проблема в том, что работу, реально добавляющую ценность, обкладывают бумажками и «закапывают» на нижний уровень, описание которого проектом не предусмотрено. Эту ошибку допускают очень многие, даже довольно опытные сотрудники и бизнес-аналитики! Кстати, наличие таких моделей, как правило, означает, что модель вышестоящего уровня архитектурно плохо выстроена.

Красота схемы

Здесь все печально. Только 10–15% сотрудников стремятся сделать схемы красивыми. Для остальных это третьестепенная задача. Но некрасивую схему не хочется брать в руки, а тем более анализировать. Визуальная красота схемы — залог ее проработанности, что снижает трудоемкость последующих согласований и внесения изменений.

Накопление опыта и исправление ошибок

По ходу выполнения проекта сотрудники накапливают опыт моделирования процессов. Степень проработки и качество моделей процессов становятся существенно выше. При интенсивной работе ВРГ (2–3 модели процессов в неделю), через 1–1,5 месяца можно говорить о приемлемом уровне качества описания моделей процессов.

Хотел бы отметить, что для освоения навыков моделирования процессов на операционном уровне (в нотации BPMN) очень полезно показать сотрудникам имитацию выполнения процесса в Business Studio. Еще лучше, если после этого они сами попробуют запустить на имитацию отрисованный ими процесс, причем сначала пошагово, чтобы почувствовать себя той самой «мышкой» (токеном). Это упражнение дает хорошее понимание сути моделирования процессов Work Flow.

Выводы

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

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

• «мышка» или идеология исполняемых процессов;
• информационное взаимодействие внутри процесса и между процессами («стыковка по входам/выходам»);
• корректное использование событий отправки-получения сообщений и синхронизация процессов между собой по событиям;
• соблюдение уровней при описании межпроцессного взаимодействия (процесс BPMN может отправить сообщение только в процесс BPMN);
• корректное использование событий-таймеров;
• четкое отслеживание множественных объектов для обработки;
• визуальная наглядность схемы («Красота схемы»).

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

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

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

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

Опубликовано по материалам портала http://www.finexpert.ru/

Опубликовано по материалам:
http://finexpert.ru/view/modelirovanie_biznes_protsessov_v_notatsii_BPMN_nachinayushchimi_tipovye_oshibki/941

Ноябрь 2018 г.

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

Графическое описание процедур БП

Глоссарий. Должностная инструкция

О настоящем и будущем процессного управления в России — интервью Владимира Репина в рамках проекта «Управление из первых рук»

Оптимизация процессов снабжения в ПАО «Распадская угольная компания»

Или ментальные «ловушки», которые мешают аналитикам использовать нотации.

От системного аналитика требуют знание нотации BPMN (Business Process Model and Notation). А действительно ли ей пользуются на практике? Если нет, то почему?

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

В этой статье вы узнаете:

Результаты опроса

На вопросы отвечали 45 системных аналитиков четырёх уровней.

86,7% из них считает, что BPMN-нотации необходимы системному аналитику.

Но при этом в работе их использует меньше половины.

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

Почему такое расхождение? Почему аналитики, которые считают нотации необходимыми, их не применяют?

Три самых популярных ответа:

• В схему никто, кроме рисующего не смотрит.

• Разное толкование обозначений. 

• Не знаю с чего начать.

Остальные ответы про 200 с лишним элементов, сложность нотаций, их декомпозицию, а ещё отсутствие опыта в «рисовании», можно отнести к этим трём пунктам.

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

№1. «Не знаю с чего начать» — показываем на практике

Давайте попробуем закрыть проблему «Не знаю с чего начать» и начнём с основных элементов.

BPMN позволяет аналитику, product owner (PO) и разработчику общаться на одном языке с помощью условных обозначений, который приняты в нотации. 

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

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

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

Вернёмся назад в прошлое, на несколько дней раньше. В нашей истории аналитик описал требования в формате текста:

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

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

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

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

Вернёмся к нашим «дорожным знакам». Представьте, что BPMN — это язык, а элементы это слова. У «слов» есть обозначения и значения. Вот несколько основных элементов нотаций.

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

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

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

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

Gateway — Шлюз. Элемент показывает ветвление, слияние процесса. Шлюз — это узел, который «ветвит» процесс, поэтому изображается ромбом. Например, когда пользователь выбирает депозит и видит его, то может перейти на следующий процесс — совершить какие-то действия с депозитами. Если они не показываются, то это уже другой процесс.

Flow — Поток. Связывает элементы процесса: события, процессы, шлюзы. Обозначается стрелкой.

Data — Данные. Это могу быть объекты данных, базы данных. Например, сервис сформировал список депозитов и отправил их для отображения на сайте пользователю.

Элементов нотации гораздо больше, но для начала хватит базовых.

Как построить диаграмму за 5 шагов

Давайте построим диаграмму для нашей задачи по списку депозитов вместе с аналитиком.

1️⃣ Выделяем участников процесса (lanes).

Это может быть Пользователь, Сайт, Сервис.

2️⃣ Находим события начала (start) и окончания (end) процесса.

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

3️⃣ Укажем действия участников внутри lanes.

• Пользователь открывает страницу сайта.

• Сайт отправляет запрос на получение информации.

• Сервис собирает данные для ответа. Если есть депозиты, сайт показывает виджет. 

• Дальше проверяет все ли депозиты доступны. Если не все, то подсвечивает их визуально для пользователя.

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

4️⃣ Нарисуем потоки данных (flow) и укажем сами данные (data).

В нашей схеме будет поток управления и данные со списком депозитов.

5️⃣ Обозначим на схеме шлюзы (gateway). 

Будет 2 ветвления:

• Есть ли депозиты?

• Есть ли среди депозитов недоступные?

Получили вот такую диаграмму.

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

Инструменты. Для рисования я использовала инструмент storm.Bpmn2.ru, потому что он мне удобен (скачать файл можно по ссылке). В нём есть основные элементы, проверка диаграммы, возможность скачать *.jpg, *.bpmn. Но, по результатам моего опроса, он не самый популярный.

Большинство аналитиков применяют draw.io, Visio и Camunda Modeller.

Есть еще и другие, которые могут быть удобнее лично вам, но они оказались не такими популярными, например, drawio, Bpmn.io, Camunda Modeler или Chor-js (demo).

№ 2. «В схему никто, кроме рисующего не смотрит»

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

Большинство — 78,6% — всё же заглядывают в схему в документах аналитиков.

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

№ 3. «Разное толкование схем»

Для проверки этой проблемы я провела опрос внутри команды. Всё те же 14 человек попросила выбрать понятную им схему в BPMN и UML Sequence.

Примечание. Как нарисовать UML Sequence описано в статье «Plantuml в работе системного аналитика. Пиши uml диаграммы текстом, чтобы сэкономить время»

Как выглядела схема в опросе (в двух вариантах).

Здесь мнения разделились.

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

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

По моему опыту, проблема не в толковании, а в недоинформированности об элементах схем и в сложности самих схем.

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

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

Как презентовать BPMN команде?

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

Примечание. Есть ещё вариант, чтобы разработчик посмотрел схему, нужно сделать так, чтобы она ему стала нужна для разработки кода. Например, о таком варианте рассказывал Дмитрий Жезлов на митапе Backend Stories (Java) в докладе «Zeebe для Банка в 2021 году».

А что в итоге?

Я верю, что после прочтения статьи у вас не возникнут три основные проблемы:

• В схему никто, кроме рисующего не смотрит.

• Разное толкование обозначений. 

• Не знаю с чего начать.

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

Единственная трудность возникает в:

• Глубоком изучении BPMN, её элементов и абстракций. Я потратила довольно много времени на изучение, но наглядность схем бизнес-процессов сейчас оправдали эти «вложения».

• Презентации. Но это уже вопрос другого порядка, скорее организаторский или из области психологии.

Решать, конечно, вам — использовать или нет BPMN диаграммы в работе, но теперь вы прочитали про практический опыт в одной из команд Альфа-Банка. Надеюсь, было полезно.

Сейчас нам в Альфа-Банк нужен системный аналитик в УКД и системный аналитик в отдел риск-технологий. Если хотите, чтобы в команде смотрели и понимали ваши схемы, приходите:)

---

Подборка [от редактора блога]:

• Как мы ведём документацию рядом с кодом

• Как настраивать аналитику, если у вас Backend Driven UI

• Удачный шаблон документации на API, который будут читать

• Plantuml в работе системного аналитика. Пиши uml диаграммы текстом, чтобы сэкономить время

• XSS атакует! Краткий обзор XSS уязвимостей

• XSS атакует! Не краткий обзор где и как искать уязвимости

• Как мы ведём требования к ПО: формализация

• Про микросервисы на примерах

• Почему мы ошибаемся при первоначальной оценке фич?

• Как я преподавал на ИТ-курсах: буст софтов или потраченное время

• Я провёл 400 собеседований за год. Мне есть что сказать

Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.