Вступление
Я написал этот гайд для использования аналитиками в компании (мы интегратор решений 1С в медицине), как настольная шпаргалка и некий базовый «стандарт унификации» формируемых диаграмм данного типа.
Полезно будет как тем, кто только делает первые шаги к стандартизации своего подхода при описании логики бизнес-процессов так и тем, кто уже имеет опыт применения данной нотации.
Гайд носит только практический характер и представляет собой некий опыт и приобретенные знания при изучении данного вида нотации и использования в работе аналитика.
Многие пользователи диаграмм, создаваемых аналитиком зачастую не готовы читать схемы, содержащие большое кол-во элементов, виды которых нужно знать и понимать. Для описания бизнес-процессов из опыта в большинстве случаев достаточно элементов нотации, описанных здесь.
В конце туториала также есть пример описания процесса маршрутизация пациента, а также список полезных источников, которыми я руководствовался при написание данных рекомендаций.
Спасибо @Cordekk за подсказанный материал, ссылка на который также приведена ниже.
BPMN (Business Process Model and Notation) — это стандартизированная графическая нотация, предназначенная для моделирования бизнес-процессов. Она позволяет визуально представить процесс, что делает его более понятным для всех участников.
Базовая нотация BPMN включает не более 10 типов элементов, что позволяет описывать процессы в понятной стандартизированной форме за относительно короткое время. Расширенная нотация BPMN содержит более 100 элементов, это позволяет создавать сложные регламенты взаимодействия без разночтений.
Схемы, созданные с помощью BPMN, могут быть исполняемыми (интерактивными) при разработке в low-code платформах для управления бизнес-процессами.
Основные особенности
Схемы в нотации BPMN ориентированы слева направо.
Любая схема должна содержать начальное и конечное события.
Возможность визуально изобразить зоны ответственности исполнителей или ИС с помощью пулов и дорожек.
Возможность изобразить развилки - альтернативные и параллельные процессы.
Процессы состоят из элементов, каждый из которых обозначается на схеме специальным значком.
Основные категории элементов допускают внутренние вариации, что расширяет возможности визуализации.
Графические элементы и категории
Использование цвета
На диаграммах желательно выделять цветом элементы, в своей работе использую такой подход:
события начала - зеленым, конца - красным;
шлюзы - желтым;
облачные переходы и другие элементы - серым;
действия или дорожки - цветом, присвоенным соответствующей дорожке (если необходимо)
В результате диаграмма будет выглядеть визуально гармонично.
Но использования цвета в диаграммах не ограничивается приведенным базовым вариантом и конечно значительно шире и должно использоваться в зависимости от необходимости в каждом конкретном случае для категоризации, приоритизации и анализа тем, подтем и их ассоциаций, выделения подсистем, систем, групп объектов.
Про использование цвета при анализе и проектировании систем очень подробно описано у @RomanSeleznev
Основные графические элементы BPMN
В нотации используют шесть основных графических элемента (категорий объектов):
Пул и Дорожки
Действия
Шлюзы
События
Потоки (связи)
Данные и Артефакты
Элементы "Пул" и "Дорожка"
Дорожка BPMN – объединяет действия, выполняемые любым субъектом процесса: системой, подразделением, сотрудником или ролью. Она именуется в соответствии с названием этого субъекта, например, "МИС МО", "Аптека", "Врач", "Администратор системы" Зачастую дорожка располагается внутри пула.
Пул BPMN – элемент группировки, который показывает участника взаимодействия в процессе. Действия участников отображаются на отдельных дорожках внутри пула.
Элементы "Действия"
В основе любого бизнес-процесса BPMN лежит последовательность действий. Каждое из этих действий может быть либо простым (отдельная задача), либо сложным (подпроцесс).
Под действием понимается единица работы, выполняемой в ходе исполнения бизнес-процесса. Действия соединяются в последовательности с помощью стрелок, где последующее действие начинается сразу после предыдущего.
Задача, событие или действие изображается на диаграмме процесса в виде скругленного прямоугольника и обозначает элементарное действие, выполняемое участником процесса.
Элементы "Шлюзы"
Шлюзы - это элементы, которые определяют точки ветвления и слияния потоков работ.
BPMN описывает 7 типов развилок. В качестве основных почти всегда достаточно 2-х типов.
Элементы "События"
Событие в BPMN - это элемент управления потоком, который указывает на состояние, влияющее на выполнение процесса. События могут запускать действия в процессе или быть их результатом.
События могут быть стартовыми, завершающими или промежуточными. Стартовые обозначают начало процесса, завершающие - его окончание, а промежуточные события могут приостанавливать выполнение процесса.
Элементы "Потоки (связи)"
Поток – это последовательность действий, которая обозначается стрелкой. Элемент “поток” показывает какое действие после какого необходимо совершить. В зависимости от назначения стрелки могут изображаться сплошной, штриховой и пунктирной линиями.
Элементы "Данные" и "Артефакты"
Данные и артефакты расширяют возможности нотации, позволяют бизнес-аналитикам создавать более гибкие, комфортные для визуального восприятия модели процессов.
Под артефактами в BPMN понимают объекты, которые не влияют на исполнение бизнес-процесса напрямую. Это могут быть документы, данные, информация.
Данные BPMN обозначают информационные объекты, которые используются при выполнении бизнес-процесса или являются результатами выполнения процесса.
Артефакты BPMN используются для того, чтобы показать на диаграмме дополнительную информацию о процессе. Эта информация может быть связана с одним из потоков последовательности в процессе: потоком операций, либо потоком сообщений.
Правила которых стоит придерживаться при моделировании в нотации BPMN
✅Можно моделировать диаграммы вертикально, стандарт BPMN разрешает это, но лучше пользоваться горизонтальным расположением диаграммы. Люди склонны воспринимать лучше всего поток действий, если он описан так же, как и письменный текст (слева направо).
✅При наименовании процессов и задач необходимо придерживаться формулы: "глагол (указывает на выполняемую работу) плюс существительное (указывает на объект выполняемой работы)". Например: "Выдать карту", "Оказать услугу", "Принять согласованную заявку", "Оказать услугу по заключению договора".
✅События относятся к тому, что уже произошло независимо от процесса или в результате процесса (связка с глаголом отвечающего на вопрос "что сделано?" или "что произошло?"). Например: "Выявлено подозрение на ЗНО", "Выполнено условие", "Прошло 5 дн."
✅Дорожки в BPMN могут обозначать:
Конкретных сотрудников организации, например: Иванов И.И.
Роли в организации или ИС, например: "Главный врач" или "Администратор ИС".
Подразделения или отделения, например, "Бухгалтерия" или "Травмотология".
Информационные системы или подсистемы, например: "МИС МО" или "АРМ Врача".
Федеральные и региональные сервисы, например: ФГИС ОМС, ФРМР и т.д.
✅Шлюз должен осуществлять ветвление или слияние потоков управления. При необходимости шлюзы можно соединять между собой в любом порядке.
✅Избегайте пересечения потоков операций на диаграммах. Иногда это не возможно, но к этому стоит стремиться и потратить время на оптимизацию расположения элементов на диаграмме.
✅Изображение элементов симметрично относительно друг друга, позволяет пользователям диаграмм лучше воспринимать и понимать логику процесса.
✅Рекомендуется изображать однотипные элементы (задачи, события и т.д.) одинакового размера. Человек зачастую интерпретирует более крупные элементы как более важные. Также, задачи большего размера привлекают внимание, и маленьким задачам может быть уделено недостаточное внимание или вовсе пропущены пропущены.
Заключение
BPMN является одной из наиболее востребованных нотаций для бизнес-моделирования. Она позволяет наглядно отображать зоны ответственности исполнителей, что делает диаграммы понятными в плане распределения задач и событий.
Простое графическое представление позволяет создавать четкие схемы описания бизнес-процессов, а элементы используемые в нотации понятны большинству участников процесса и обычно не требуют дополнительных объяснений.
Возможно, я упустил некоторые особенности и поэтому если у вас есть что добавить, поделитесь в комментариях. Обратная связь, двигатель идей)
Пример описания маршрутизация пациента с подозрением на ЗНО
Список использованных и полезных источников при подготовке материала
"Свод знаний по управлению бизнес процессами: BPM CBOK 4.0", 2022
Фёдоров И.Г. "Моделирование бизнес-процессов в нотации BPMN 2.0", 2013
"Блог Comindware": https://www.comindware.ru/
"Как выбрать нотацию для моделирования бизнес-процессов": https://practicum.yandex.ru/blog/notacii-modelirovaniya-biznes-processov/
"Нотации моделирования бизнес-процессов": https://www.businessstudio.ru/products/business_studio/notations/
"Нотация BPMN 2.0". https://elma365.com/ru/bpmn2/
"База знаний по бизнес-процессам": https://optimacons.info
Справочник элементов BPMN: https://stormbpmn.com/bpmn/elements/
Комментарии (16)
tmaxell
17.09.2024 08:56В общем-то и правда очень неплохой начальный гайд по нотации, спасибо! Но думаю что было бы неплохо добавить прау ссылок на конкретные кейсы и моделирование процессов там, для пущей наглядности.
ITxasky Автор
17.09.2024 08:56спасибо за обратную связь) добавил в статью пример описания маршрутизации пациента, с краткой аннотацией
Cordekk
17.09.2024 08:56+1не рекламы ради, но пользы для.
мне кажется хороший и понятный гайд, а также готовое соглашение о моделирование внутри компании сделал Денис Котов и ребята из сервиса stormbpmn.Собственно и вам рекомендую ознакомиться, у них и примеры есть как надо и как не надо.
ITxasky Автор
17.09.2024 08:56+1Константин, спасибо. Полезный и удобный материал. Добавил ссылку в статью на ресурс и от меня благодарность с упоминанием)
Real3L0
17.09.2024 08:56Именно из-за такой сложности BPMN нельзя использовать при общении с бизнесом. Хотя, казалось бы, первая буква названия говорит об обратном. :)
Рекомендую eEPC. Проверено опытном путём: согласовал кучу схем с "бабушками из бухгалтерии". :) Получить уверенность, что вы оба всё правильно поняли - очень важный пункт.
ITxasky Автор
17.09.2024 08:56Привет и спасибо за комментарий) Я бы не назвал BPMN сложной, она хорошо подходит для описания именно бизнес-процессов.
EPC да, относительно легко читается, из-за небольшого кол-ва элементов и цветовой типизации, но мне кажется она больше подходит для описания относительно простых БП или процессов нижнего уровня, а также шагов, но выбор нотации в конечно счете зависит от конкретного случая и того, что именно будет описываться с её помощью.
Real3L0
17.09.2024 08:56"Хорошо подходит" вам, но не "бабушкам" - мой упор именно на это.
eEPC можно описать схемы любой сложности. Проверено.
Но это когда я был БА+СА. Сейчас, когда я в большей степени СА, в своей работе использую:
когда без схемы не обойтись: Sequence diagram или Swim lane;
очень редко - некоторые специфичные: Component diagram, простую ER-диаграмму, может ещё что, не вспомню.
но в основном - обхожусь без схем. Ну вот не нужны они в большинстве случаев, кроме как для повышения ЧСВ аналитика. :)
Либо у меня так происходит, что в первой версии фичи схема ЕЩЁ не нужна, а в какой-нибудь следующей - УЖЕ поздно (тратить пол дня на рисование в стол не хочется).
Когда последний раз использовал eEPC - уже и не вспомню. :)
ITxasky Автор
17.09.2024 08:56"бабушки" это да, допускаю, что с ними бывает не просто :)
инструменты и нотации выбираются под конкретную ситуацию и необходимость в них: нужны Заказчику, РП, команде.. а схемы ради схем, это уже действительно про ЧСВ :)
Grikhan
В статье приведен ошибочный подход с ошибками в нотации. Разбор ошибок и неточностей займет больше самой статьи. Базовые - задачи должны быть в терминах предметной области, а не технических терминов вроде "сохранение", БД и элементы данных не могут выступать в качестве задач. Путаница в нотации между сообщениями (вид событий) и событиями. Учитесь пользоваться аннотацией для пояснения задач процесса вместо некорректных представлений связей между элементами данных и БД. Процесс с событиями таймеров ожидания между параллельными шлюзами - вообще иллюстрация как делать не надо никогда.
ITxasky Автор
В нотации не запрещено использование технических терминов. Элементы не могут, но задача/действие над данными могут.
Событие - элемент управления потоком, который указывает на состояние, влияющее на выполнение процесса. События могут запускать действия в процессе или быть их результатом. Сообщение в свою очередь является одним из типов такого события.
Ко всем создаваемым диаграммам в обязательном порядке идет аннотация с описанием каждого бизнес-процесса, отраженного на схеме. Связи элементов важная составляющая диаграмм и понимания схемы пользователями.
Спасибо за замечание, не обратил внимание
Grikhan
Событие - это то, что произошло. Всё. В нотации все элементы указывают на состояние, все влияют на выполнение БП (зачем рисовать что-то, что не влияет?) и полно элементов управления - все, которые не элементы данных. Это "определение" вы, вероятно, подрезали у каких-то консалтеров "не умеешь сам - учи других": очень сложно и пусто. Сообщение же - это вид событий. Еще бывают события старта/конца, таймера, ошибок, отмены, сигнала, условия и, конечно, ссылки на другой процесс (если кого-то забыл, простите меня, события).
Про аннотации я писал к задачам, не ко всей диаграмме. Диаграмма-то как раз может быть в идеале самоописана.
Про технические термины - нотация не запрещает писать любой текст, даже матом. Но если вы говорите про подход, при котором вы составляете схему бизнес-процесса, то нужно оставаться на одном уровне абстракции - слое бизнес-процессов, а не скакать со слоя на слой.
Например. Задачу - в глагольной форме в терминах бизнеса, пояснения - в аннотацию. Запись в БД и элементы данных - это артефакты задач: стрелки только на них, а ИЗ них запретите себе что-то рисовать - только запутаетесь. Приводить на схеме БП "записать", "прочитать", "сохранить" и т.п - перегружают схему. Это само собой - у каждой задачи обязательно есть свои входы и выходы, логи и метрики - сохраняется всё. Слой данных, в котором их жизненный цикл, синхронные, асинхронные операции, процессы управления данными и т.д. - это другой архитектурный слой, не надо всё тащить в бизнес-процессы - получится каша - описывайте отдельно. Если уж так хочется (ну, например, основное требование - какое-то единство БД и надо его подсветить), то лучше поместите в аннотации эти функции задач, но не надо при этом из аннотаций создавать "войну и мир", как и создавать схемы больше, чем на 7-10 элементов - надо бить на подпроцессы. Вот это я коротко описал подход в парадигме многоуровневой архитектуры. Любопытно как может выглядеть другой. Жду новую статью ;)
ITxasky Автор
"Событие используется для нескольких целей. Во-первых, чтобы указать моменты времени, когда выполняется работа. Например, начать выполнение очередной операции через 1 час, после завершения предыдущей. Во-вторых, чтобы ограничить длительность операций. Например, прервать исполнение операции через 30 минут после начала. В-третьих, они описывают реакцию на изменение состояния внешних, по отношению к процессу объектов." - Моделирование бизнес-процессов в нотации BPMN2.0, И.Г. Федоров
в статье приведена классификация по типу события
"Для описания бизнес-процессов из опыта в большинстве случаев достаточно элементов нотации, описанных здесь" - туториал не имеет своей целью охватить все элементы и аспекты нотации BPMN, для этого есть специализированные издания.
Grikhan
Для чего используется - это не определение.
Ну и как вы считаете, Федоров привел все цели событий? "В-третьих" - очень неуклюжая цель. Есть throw и catch ивенты - те, которые catch еще можно натянуть на цель "В-третьих". Но это придирка. Ждать от отечественного экономиста какой-то корректной классификации - все равно, что ждать от соседа, что он споет Шаляпина без фальши.
так вот она неправильная. То, что у вас с ромбиком - это не событие ошибки, а событийный шлюз (Event based gateway).
никто и не ожидает, что вы сможете охватить все аспекты - в bpmn есть полно экзотики, даже пример применения которой придумать очень сложно. Но упомянуть о существовании, как минимум, ссылочных и условных событий стоило бы.
Со шлюзами - в нотации "или" бывает с пустым ромбиком и с косым крестом. Вы описываете пустой, а на диаграмме (обреченный пациент с подозрением ЗНО) с косым крестом. Что мешало помесить упоминание ранее? Жадность?
Пациент обречен потому, что он никогда не дождется завершения обслуживания - не пройдет параллельный шлюз с двумя входами, но с единственным токеном в процессе.
ITxasky Автор
Это возможно и в каих-то случая нужно. Но диаграмма не идет в отрыве от описания бизнес-процессов, а иначе она представляет собой только логику выполнения БП, а не комплекс диаграмма-описание.
ITxasky Автор
Спасибо за участие в обсуждение и развернутые комментарии) Все конструктивные и объективные замечания, постараюсь учесть в работе при проектировании и описании БП, а также при написании в будущем статьи, возможно более развернутой или еще более компактной ;)
ITxasky Автор
Спасибо за ваш отзыв и за то, что уделили время на его написание. Понимаю и допускаю, что могут быть различные подходы для отражения элементов на схеме. В своей статье я стремился сделать BPMN более доступным для широкой аудитории и возможно, допустил некоторые упрощения. Я обязательно еще раз просмотрю указанные вами моменты и постараюсь улучшить материал. Возможно, в будущем для другой статьи добавлю более детальные пояснения и примеры. Спасибо за ваш вклад в улучшение контента и дело Хабра. Комментарии как положительные, так и отрицательные помогают всем нам становиться лучше.