Как описать процесс с помощью BPMN? Разбор на примере

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

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

Поехали!

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

Нам примерно всем знакомо, как работает найм в компании:

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

Как мы будем это все отражать с помощью BPMN?

Я пойду в этой статье по шагам, шаги эти я узнала в книге BPMN Method and Style, автор Брюса Сильвера (Bruce Silver). Мне понравился представленный в книге метод моделирования, да, у BPMN есть гайд и рекомендации: вот этот элемент делает так, этот так, вот этот можно исполнить так, но из руководства сложно вычленить именно стилистику и правила.

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

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

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

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

На этом шаге нам нужно ответить на вопросы:

Как начинается процесс: по запросу (по факту возникновения какой-то потребности) от внешнего или внутреннего участника / исполнителя или запланированно (регулярно повторяющийся базовый вопрос)? В нашем случае по запросу от внутреннего исполнителя (возникает потребность у нанимающего менеджера в новом сотруднике).

Как завершается процесс: имеет он одно или несколько завершений? В нашем случае несколько вариантов: наймом нового сотрудника (успех) или отсутствием найма нового сотрудника (по разным причинам, не успех), но этот конкретный экземпляр процесса мы уже завершим. Почему так? Потому что если начальное состояние — запрос, то завершение — выполнение запроса. Наш запрос — найм сотрудника, завершение — найм / не найм сотрудника.

Варианты завершения: надо описать все конечные состояния процесса (мы уже определили, что у нас есть успешное завершение, и что есть несколько причин, когда оно неуспешное, надо причины четко сформулировать):

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

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

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

Я начинаю с определения участников. В BPMN для этого используются Пулы (Pools) и Дорожки (Lanes).

Давайте внимательно посмотрим на процесс, кто у нас есть:

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

ВАЖНО: Кандидат — black-box Пул, потому что мы описываем бизнес-процесс компании, поэтому у нас к Кандидату будут идти только Поток сообщений (Message Flow).

Внутри компании у нас есть роли менеджера и HR-отдела, это будут наши дорожки внутри Пула «Компания».

Смотрим, как это будет выглядеть:

Почему я расположила Пули и Дорожки в таком порядке? Потому что это соответствует очередности появления в процессе этих участников. Вначале (первым) мы видим Нанимающего менеджера, потом появляется HR-отдел, и только потом Кандидат. Так мне будет проще переходить с исполнителя на исполнителя, и от участника к участнику.

Что важно: так как для нас пул Кандидата — black-box Пул, то он должен отображаться в свернутом виде.

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

С чего мы начинаем? С начала. Возникает потребность в сотруднике, то есть это наше стартовое событие. У кого потребность? У нанимающего менеджера внутри компании. Как нам отразить это на диаграмме?

Мы ставим Начальное событие (Start Event) в виде простого круга с названием «Возникла потребность в сотруднике» на Дорожке «Нанимающий менеджер» Пула «Компания». От начального события у нас идет Поток операций (Sequence Flow) (сплошная стрелка) к Подпроцессу (Sub-Process) (прямоугольник с + внизу) «Сформировать заявку на подбор», заявку могут согласовать / не согласовать, поэтому нам нужно уточнить, согласовали ли заявку, прежде чем двигаться дальше: ставим Исключающий шлюз (XOR Gateway) (ромб) с вопросом «Заявка согласована?».

Если заявка согласована, то ветка «Да» ведет к подпроцессу (наш следующий ключевой этап) «Провести отбор кандидатов», а если не согласована, то ветка «Нет» ведет к Конечному событию (End Event) «Вакансия закрыта без найма» (то вот наше неуспешное завершение в Шаге 1).

Смотрим:

Что дальше?

Мы можем провести отбор кандидатов, нам надо определить его успешность, поэтому ставим Исключающий шлюз (XOR Gateway) (ромб) с вопросом «Найден финальный кандидат?», по той же логике что и выше ветка «Да» ведет к подпроцессу «Сделать оффер», а ветка «Нет» ведет к Конечному событию «Вакансия закрыта без найма».

После подпроцесса «Сделать оффер» ставим Исключающий шлюз (XOR Gateway) (ромб) с вопросом «Оффер принят?», и ветка «Да» ведет к подпроцессу «Подготовиться к выходу сотрудника», а ветка «Нет» (кандидат отказался) ведет сплошной стрелкой к Конечному событию «Вакансия закрыта без найма».

После подпроцесса «Подготовиться к выходу сотрудника» ставим шлюз «Сотрудник вышел на работу?». Ветка «Да» ведет к успешному Конечному событию типа Сигнал (Signal) (круг с треугольником внутри) «Сотрудник нанят», почему сигнал? Потому что успешное завершение процесса найма является стартом (сигналом для старта) процесса онбординга. Ветка «Нет» (кандидат не вышел) ведет, как и все неуспешные завершения, к Конечному событию «Вакансия закрыта без найма».

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

Теперь давайте последовательно опишем каждый подпроцесс детальнее.

Из каких действий состоит первый подпроцесс «Сформировать заявку на подбор»:

При этом согласование — это своего рода цикл (начать согласовывать, получить правки, внести правки, согласовать после правок, получить правки и т. д., пока не будет достигнуто согласование). Поэтому Задача (Task) «Согласовать анкету» имеет маркер Loop (значок закругленной стрелки внутри задачи). Цикл Loop похож на цикл Do-While в программировании. То есть задача согласования будет выполняться до тех пор пока не будет достигнуто согласование анкеты между HR и нанимающим менеджером. Если это не очевидно, то можно порешать проверку согласованности анкеты, например, через шлюз с вопросом о необходимости правок, но маркер цикла предпочтительнее.

Как оформляется раскрытый подпроцесс в нотации? Это прямоугольник с закругленными углами, который начинается со своего Начального события типа None (это обязательное правило для подпроцессов). У нас не может подпроцесс ничем не закончиться. И вообще на схеме не может быть действия без завершения, «пути вникуда» быть не может.

В подпроцессе у нас два конечных состояния: успешное согласование заявки и отклонение заявки.

У меня был подпроцесс в свернутом виде «Сформировать заявку на подбор», в развернутом он подписан так же, начинается с события типа None, содержит 2 задачи, у одной задачи признак цикличности, отражены оба конечных состояния подпроцесса, выход из подпроцесса у меня тот же, что был на верхнеуровневой схеме — Исключающий шлюз (XOR Gateway) (ромб) с вопросом «Заявка согласована?».

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

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

Продолжаем!

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

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

Я могу использовать здесь после получения отклика многоэкземплярный подпроцесс (Multi-Instance Subprocess) (значок трех вертикальных полос), который позволяет обрабатывать каждый элемент в списке полученных откликов, но эксперты по BPMN говорят, что это возможно когда я знаю количество позиций в списке до начала обработки списка, а это не совсем наш случай, ведь я не знаю, сколько будет откликов. С другой стороны, я могу поставить пометку, мол, обрабатывать этим многоэкземплярным подпроцессом отклики как только набирается 5 новых, набралось 5 штук — разобрала, набралось еще 5 — разобрала. На мой взгляд это лишнее усложнение для нас сейчас.

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

Обратите внимание, что я здесь учла и обмен сообщениями с Пулом Кандидата, в тех моментах, когда у нас есть взаимодействие. То есть нам надо раскидать в нужных местах Поток сообщений (Message Flow) (пунктирная линия) и оформить правильно сообщения:

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

Обратите внимание так же на то, что я сначала думала, что у меня просто Задача (Task) «Провести скрининг» и просто Задача (Task) «Провести собеседование», но по факту это подпроцессы:

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

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

Пподпроцесс «Сделать оффер» состоит из следующих действий и событий:

Здесь довольно просто для нас уже должно быть:

Идем дальше.

Что нам известно:

И, соответственно, на выходе из подпроцесса мы в целом можем прийти к завершению процесса найма: если сотрудник вышел, то это успешное завершение, закрываем процесс успешным Конечным событием типа Сигнал (Signal) «Сотрудник нанят» (заканчивает текущий процесс и подает сигнал для старта процесса Онбординг). Если не вышел и / или не принял оффер, то мы закрываем вакансию без найма.

Так, тут мы закончили. Что дальше?

Давайте посмотрим на процесс целиком и поймем, все ли в порядке, вдруг мы что-то потеряли?

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

С точки зрения процессности, то есть именно описания и качества, состояния самого процесса Найма, у нас не отражено (то есть нет этой информации на момент отрисовки диаграммы, но мы можем ее подсветить владельцу процесса и внести правки, то есть смоделировать процесс TO BE):

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

А что с точки зрения нотации?

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

И так далее, вот здесь можно посмотреть самые частые ошибки в оформлении.

А в главе 11 книги BPMN Method and Style Брюса Сильвера (Bruce Silver) есть прям список правил, по которым можно проверить оформление диаграммы.

Чего у нас не не хватает: типов задач (выполняется пользователем, системная или еще как) и объектов данных.

Например, сделать оффер — задача пользователя, а задача отправить оффер — задача отправки сообщения, а сам по себе оффер — Выходной объект данных (Data Output) (то есть документ появляется в результате выполнения задачи):

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

Сама по себе текущая схема процесса не может быть исполняемой, потому что у нас нет достаточно данных для 100% полноты шагов, участников, ограничений, объектов данных и у нас нет 100% однозначности при интерпретации схемы (то есть когда кто-то, кто не мы, посмотрит на схему и скажет, что все понял, понять он может не все или не так).

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

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

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

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

Чет у меня какой-то дисклеймер получился, а не заключение, но все же! Была рада написать для вас этот разбор. Встретимся в канале (хоть не в канаве, бадум-тсс!):