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

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

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

Какие символы нужны для схемы

Читай маршрут по стрелкам от начального события к конечному. Для примера достаточно шести обозначений:

• Начальное событие - круг с тонкой границей. Показывает запуск процесса: «Заявка поступила».
• Задача - прямоугольник со скруглёнными углами. Обозначает работу: «Проверить данные заявки».
• Исключающий шлюз - ромб, который может содержать маркер X. Направляет поток по одной из альтернативных веток: «Данных достаточно?».
• Поток управления - сплошная линия со стрелкой. Показывает порядок выполнения элементов внутри одного пула.
• Конечное событие - круг с толстой границей. Обозначает завершение маршрута: «Отказ отправлен».
• Дорожка - полоса внутри пула. Помогает распределить задачи по ролям.

Задачу называй через действие и объект: «Проверить заявку». Событие - через свершившийся факт: «Заявка поступила». Название «Обработка» не объясняет, что должен сделать сотрудник.

Шлюз сам не выполняет проверку. Он направляет поток на основании её результата. Поэтому перед вопросом «Можем выполнить?» нужна задача «Оценить возможность выполнения».

Схема приёма заявки с пояснениями

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

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

(Заявка поступила) -> [Проверить данные заявки] -> <Данных достаточно?>

• Нет -> [Уточнить данные] -> возврат к [Проверить данные заявки].
• Да -> [Оценить возможность выполнения] -> <Можем выполнить?>.
• Из «Можем выполнить?», Нет -> [Отправить отказ с причиной] -> (Отказ отправлен).
• Из «Можем выполнить?», Да -> [Назначить исполнителя и передать заявку] -> (Заявка передана исполнителю).

У схемы один вход и два возможных завершения. Передача исполнителю завершает приём заявки, но не означает выполнения заказа.

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

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

Хочешь навести порядок в задачах и процессах команды? Начни с одного маршрута в Legend BMS. Зарегистрироваться →

Как собрать схему за пять шагов

1. Зафиксируй начало и результаты. Используй конкретные факты: «Заявка поступила», «Заявка передана исполнителю», «Отказ отправлен». Не завершай схему событием «Заказ выполнен», если выполнение на ней не показано.
2. Выпиши действия. В примере пять задач: проверить данные, уточнить их, оценить возможность выполнения, отправить отказ, назначить исполнителя и передать заявку. Последняя задача объединяет два действия одной роли. Если назначение и передачу выполняют разные люди, раздели её.
3. Добавь условия выбора. После проверки данных поставь вопрос «Данных достаточно?», после оценки возможности - «Можем выполнить?». Подпиши ветки «Да» и «Нет». Условия должны позволять выбрать ровно одну ветку для каждого допустимого случая. Для более сложного выбора при необходимости задай поток по умолчанию.
4. Распредели ответственность. Проверку, уточнение, оценку и отказ отнеси к менеджеру. Назначение и передачу - к руководителю отдела. На схеме укажи роли, а при организации работы назначь конкретных ответственных.
5. Пройди маршруты на примерах. Возьми полную заявку, неполную заявку и запрос, который нельзя выполнить. Проследи каждый путь до завершения. После уточнения проверь оба варианта: данных достаточно или нужен ещё один запрос.

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

Как показать передачу ответственности

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

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

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

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

У развилки нет условий. Подпиши выходящие ветки и проверь выбор на конкретных заявках. Если сотруднику приходится угадывать значение «Данных достаточно», уточни критерии проверки.

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

Задача скрывает смену роли. Блок «Проверить и согласовать» не показывает передачу ответственности, если проверяет менеджер, а согласует руководитель. Раздели работу на задачи по ролям.

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

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

Что проверить руководителю и перенести в Legend BMS

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

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

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