Введение
Этот материал основан на практическом опыте регламентации бизнес-процессов в различных организация. Мы не будем рассматривать типовые правила описания нотации BPMN 2.0: каждый при желании может открыть официальный стандарт на более чем 500 страниц и изучить назначение всех элементов. Наша цель иная. На практике, когда рабочая группа моделирует процессы в компании, возникает задача выработать единый «почерк» бизнес-аналитиков. Диаграммы должны выглядеть одинаково, независимо от того, кто их создавал, и строиться по единой логике. Статья посвящена именно таким практическим рекомендациям. Вряд ли вы их найдёте в официальных спецификациях BPMN 2.0, но за много лет работы мы сформировали набор требований и правил, которые используем в проектах. Прошу относиться к статье как к сугубо техническому и практическому руководству.
Рис. 1. Этапы создания регламента бизнес-процесса
Этапы создания регламента бизнес-процесса
Многие специалисты, начиная работать с BPMN, ошибочно полагают, что сама схема уже является законченным информационным объектом. Это не так. Если попытаться изобразить на диаграмме всё, что известно о процессе, она станет нечитаемой. Человеческий мозг воспринимает информацию блоками, поэтому сложные процессы необходимо упрощать и декомпозировать, а простые, наоборот, можно детализировать на одной диаграмме (если это полезно для более качественного выполнения процесса).
Классический путь создания регламента выглядит так:
- Проведение интервью с владельцем процесса. Он знает свой процесс лучше всех, но информацию нужно структурировать. Мы работаем на руководителя, чтобы в итоге он чётко представлял свою модель. Интервью также помогает сократить дистанцию между топ-менеджментом и бизнес-аналитиком.
- Моделирование верхнего уровня в нотации VAD. На этом этапе фиксируются верхнеуровневые элементы и взаимосвязи процессов.
Рис. 2. Пример диаграммы процесса в нотации VAD
- Декомпозиция до нотации BPMN. Когда уровня VAD недостаточно для описания алгоритмов и последовательностей работ, переходим к BPMN 2.0. Переход обоснован тем, что при появлении параллельных веток (например, разные алгоритмы закупок в зависимости от суммы) или детального описания рабочих потоков VAD уже не подходит, так как не предназначен для такого уровня детализации.
- Заполнение свойств процесса и подпроцессов. Параметры, данные, требования и метрики фиксируются не на самой диаграмме, а в карточках процесса и подпроцессов. Это позволяет позже выгрузить их в виде регламента или опубликовать в веб-среде Business Studio.
- Формирование и согласование регламента. Владелец процесса определяет смежных руководителей для согласования. На этом этапе часто вносятся корректировки, учитывающие интересы всех участников цепочки.
Рис. 3. Сбор исходной информации
Правила оформления диаграммы в BPMN
Перед началом моделирования важно собрать структурированную исходную информацию. Ниже приведены практические правила, выработанные нами для единого стандарта:
- Название процесса. Используйте отглагольное существительное длиной от 1 до 4 слов. Избегайте инфинитивов: они звучат неестественно для русского языка и неудобны руководителям. Длинные пояснения выносите в описание процесса.
- Дорожки (исполнители). Располагайте их в порядке выполнения действий, начиная с первого. Ширина дорожек должна быть одинаковой для лучшей читаемости. Рекомендуется не более 5 дорожек на диаграмму: это упрощает восприятие и выделяет главное взаимодействие. В качестве исполнителя можно указывать должности, роли, подразделения или информационные системы.
Рис. 4. Первое практическое правило моделирования в BPMN 2.0
- Границы процесса. Любой процесс должен начинаться стартовым и заканчиваться конечным событиями. Формулируйте их в прошедшем совершенном времени (например, «Запрос поступил», «Договор подписан»). Не тратьте время на подбор названий в начале моделирования: удобнее нанести события-границы, а назвать их уже после завершения сборки диаграммы.
Рис. 5. Второе практическое правило моделирования в BPMN 2.0
- Направление потока. Действия располагаются слева направо в хронологическом порядке выполнения. Стрелки взаимодействия выходят из правой стороны блока и входят в левую. Верхние и нижние грани блоков рекомендуется использовать для присоединения документов и других объектов данных.
Рис. 6. Третье практическое правило моделирования в BPMN 2.0
- Количество действий. На одной диаграмме размещайте не более 12–15 действий. Большее количество перегружает схему и снижает читаемость.
Рис. 7. Четвертое практическое правило моделирования в BPMN 2.0
- Шлюзы (логические операторы). Используйте их только при необходимости разветвления или слияния потоков. Избегайте избыточного применения шлюзов: если ветвление слишком сложное (например, многоступенчатое согласование), лучше описать его текстом или вынести в отдельную диаграмму (диаграмму декомпозиции).
- Движение документов. Отображайте объекты данных между действиями. Прикрепляйте документы к последовательным стрелкам (sequence flows), а не к шлюзам. Это позволит Business Studio автоматически корректно отследить, откуда документ выходит и куда входит. Для статуса документа используйте встроенные поля карточки, которые автоматически выводят статус поле названия.
Рис. 8. Пятое практическое правило моделирования в BPMN 2.0
- Межпроцессное взаимодействие. Взаимодействие с внешними или смежными процессами отображайте за пределами основной диаграммы с помощью свёрнутых пулов. К стрелкам взаимодействия обязательно прикрепляйте документ или объект данных, иначе взаимодействие считается формальным.
Рис. 9. Шестое практическое правило моделирования в BPMN 2.0
- Промежуточные события. В регламентационных диаграммах используйте их умеренно, только для фиксации действительно значимых триггеров (например, «Клиент утвердил документы»). Чрезмерное применение промежуточных событий усложняет чтение схемы.
Рис. 10. Седьмое практическое правило моделирования в BPMN 2.0
- Владелец процесса. Обязательно назначайте владельца процесса. Владелец должен быть один. Если на этапе моделирования точный владелец неизвестен, назначьте наиболее вероятного кандидата: Business Studio передаст ему информацию в его карточку должности/роли, и он сам инициирует корректировку, если назначение неверно.
Рис. 11. Восьмое практическое правило моделирования в BPMN 2.0
Заполнение карточки процесса
После сборки диаграммы переходите к заполнению свойств. В Business Studio 7-й версии карточка открывается в боковой панели, не перекрывая схему. Данные сохраняются автоматически.
- Обязательные поля: владелец (одна должность/роль), требования к срокам (цифровые или текстовые, например «в течение 3 рабочих дней»), краткое текстовое описание.
- Рекомендуемые поля: дополнительные участники, нормативно-справочные документы (не отображаемые на схеме, но влияющие на процесс), используемые программные продукты, показатели процесса (результативность, качество, эффективность), возможные отклонения от штатного хода процесса. Все эти данные не загромождают диаграмму, но доступны по клику на элемент или в итоговом регламенте.
Рис. 12. Пример карточки заполненного процесса в Business Studio 7
Формирование отчётных документов
После завершения моделирования не нужно создавать документы вручную. В разделе «Отчёты» можно одним нажатием сгенерировать комплект: описание процесса, регламент процесса, матрицу ответственности процесса и т.д. Отчёты быстро формируются и публикуются в веб-формате. Их можно экспортировать в Word или PDF. Структура регламента формируется автоматически: титульный лист, история изменений, содержание, владелец, исполнители, границы процесса, требования к срокам, диаграмма процесса, пошаговое описание выполнения процесса, управление отклонениями и показатели. Матрица ответственности строится в формате таблицы (процессы по вертикали, участники по горизонтали, тип связи на пересечениях).
Рис. 13. Запуск формирования регламента в web в Business Studio 7
Итоговый чек-лист для проверки диаграммы
- Количество дорожек: ≤ 5.
- Границы: минимум одно стартовое и одно конечное событие (в прошедшем законченном времени).
- Действия: ≤ 12–15, расположены слева направо.
- Шлюзы: только при необходимости, без избыточности.
- Документы: прикреплены к потокам управления, отображено их движение.
- Владелец: назначен в карточке процесса, только 1 должность/роль.
- Промежуточные события: только для ключевых триггеров.
- Диаграмма должна отображать 70–80% ключевой информации. Остальные детали выносятся в карточки процесса и подпроцессов.
Организация работы проектной группы
Для достижения единого стандарта необходимо:
- До начала моделирования: выбрать инструмент и утвердить единые правила оформления.
- В процессе моделирования: назначить ответственных за нормоконтроль, который будет проверять диаграммы на соответствие стандартам и корректировать отклонения.
- После моделирования: настроить шаблоны отчётов под нужды компании. Цель – чтобы у всех руководителей и специалистов сложилось одинаковое понимание, чтение и применение моделей.
Рис. 14. Задачи проектной группы
Июль 2026 г.
Скопировано