Роли участников бизнес-процесса: кто за что отвечает и как это зафиксировать в схеме

Когда в компании что-то идёт не так — срываются сроки, теряются задачи, не принимаются решения, — часто причина одна: непонятно, кто за что отвечает. Неявное распределение ответственности ведёт к тому, что все занимаются своими задачами, но никто не отвечает за результат.

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

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

Основные роли участников бизнес-процесса: владелец процесса, менеджер, исполнители

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

Зона ответственности и полномочия владельца

Например, типичный владелец процесса «Обработка входящих заявок» в e-commerce — это директор по продажам. Именно он отвечает за то, чтобы заявки обрабатывались в срок, конверсия не падала и клиенты получали качественный сервис, и имеет полномочия менять процесс под эти цели.

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

Функции и полномочия менеджера

На практике менеджер процесса — это часто руководитель отдела или операционный менеджер, который ведёт эту деятельность в рамках своей функции.

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

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

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

Замещение — это деталь, которую часто упускают. Пока основной сотрудник в отпуске, работа не должна останавливаться. В описании роли должно быть конкретно указано: «в случае отсутствия — [название роли или должности]».

Поддерживающие роли и сервисные функции

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

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

Методолог отвечает за систему в целом: стандарты описания, нотации, архитектуру процессов, соглашения о наименованиях. Если аналитик работает с конкретным сценарием, то методолог следит за тем, чтобы все операционные модели в компании описывались единообразно.

В небольших командах эти функции часто совмещает один человек.

Владельцы данных и ИТ. Операционная деятельность основана на данных: входящих, исходящих, промежуточных. Владелец данных отвечает за их качество и доступность: актуальность справочников, корректность в системах, соответствие форматов.

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

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

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

Роли ≠ должности: как не путать плоскости

Одна из распространённых ошибок при описании сценариев — смешивать роли и должности. На самом деле это разные плоскости:

• должность — это позиция в организационной иерархии: «старший менеджер по продажам», «руководитель отдела логистики», «финансовый контролёр»;
• роль — это набор обязанностей и полномочий в конкретном процессе: «инициатор», «согласующий», «владелец процесса».

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

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

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

Сквозная ответственность vs функциональная иерархия. Процессы, как правило, пересекают функциональные границы. Сценарий выставления счёта клиенту проходит через продажи, финансы и юридический отдел. У каждого отдела свой руководитель, но за итоговый результат отвечает владелец процесса, и это не всегда самая высокая должность в иерархии.

Это создаёт типичный конфликт: функциональный руководитель даёт сотруднику одно задание, а сквозная логика требует другого. Решение — явно зафиксировать приоритеты и маршруты эскалации ещё на этапе проектирования.

Взаимодействие между участниками: договорённости и эскалации

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

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

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

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

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

В описании сценария нужно зафиксировать:

— при каком условии происходит эскалация: срок истёк, сумма превышает лимит, клиент VIP-категории;

— к кому эскалируется вопрос;

— в какие сроки эскалация должна быть разрешена.

Каналы коммуникации и точки синхронизации. В описании сценария важно указать не только «кто что делает», но и «как участники договариваются»: через какую систему передаётся задача, в каком формате фиксируется результат, когда происходит сверка.

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

Как показать роли на диаграммах BPMN

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

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

• Пул (pool) — это контейнер процесса, который задаёт его границы и участника, от имени которого этот процесс выполняется (например, «Клиент», «Поставщик», «Банк»). Он может обозначать как отдельную организацию, так и внешнюю систему (например, платёжный шлюз или CRM), с которой происходит взаимодействие.
• Дорожка (lane) — это способ структурировать работу внутри пула. Чаще всего дорожки используют, чтобы визуально разделить ответственность между ролями, подразделениями или системами, но сама нотация не ограничивает, что именно должна обозначать дорожка. Это договорённость внутри команды моделирования.
• Поток сообщений (message flows) — это связи между пулами, которые показывают отправку сообщений из одного сценария в другой. Важно: они отражают именно факт передачи информации (запроса, ответа, уведомления), а не просто взаимодействие или последовательность действий.

Формально дорожки удобно использовать по принципу «одна дорожка — одна роль или зона ответственности». Это помогает визуально разделить участников и показать, кто за что отвечает.

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

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

Такой подход позволяет:

— не раздувать схему лишними контейнерами;
— сохранить компактность и логическую структуру процесса;
— при этом явно фиксировать ответственность участников.

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

События, ошибки, эскалации. В BPMN есть специальные события для нестандартных ситуаций:

• событие-ошибка (error event) — возникает, если задача завершилась с ошибкой, и выполнение переходит на альтернативный путь;
• событие-эскалация (escalation event) — передаёт управление на уровень выше, оставаясь внутри одного пула;
• промежуточное событие (boundary event) — прикреплено к задаче и срабатывает, если задача не завершилась в срок или завершилась с ошибкой.

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

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

— каждой дорожке в схеме должен соответствовать раздел в регламенте с описанием роли;

— у каждой задачи в схеме должно быть описание с входными данными, результатом, инструкцией и ссылкой на шаблон;

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

Если схема и регламент синхронизированы, исполнитель может работать с обоими и будет получать одну и ту же информацию.

Участники процесса бизнес-планирования

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

В этом сценарии есть несколько ключевых функций:

• Собственник процесса планирования — чаще всего генеральный директор или финансовый директор. Утверждает финальный план, разрешает конфликты между блоками, задаёт стратегические ориентиры.
• Финансовый блок — агрегирует данные от всех подразделений, формирует финансовую модель, контролирует согласованность цифр. Фактически это архитектор итогового документа.
• Продажи и маркетинг — формируют прогноз спроса по продуктам, каналам, регионам. От качества этого прогноза зависит весь план.
• Операционный блок — переводит прогноз продаж в план производства или поставок, оценивает мощности и ресурсы, выявляет ограничения.
• HR — планирует численность и расходы на персонал с учётом операционных планов.
• ИТ — обеспечивает техническую инфраструктуру для сбора и обработки плановых данных, а также интеграцию систем.

Входы и выходы планирования. Чтобы зафиксировать границы процесса, важно определить его входы и результаты:

• входы: стратегия компании, фактические данные из прошлых периодов, рыночные прогнозы, данные о мощностях и ресурсах, макроэкономические допущения;
• выходы: утверждённый бизнес-план, операционные бюджеты по подразделениям, ключевые показатели (KPI) для мониторинга, сценарии «что, если».

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

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

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

Ошибки в распределении ролей и как их избежать

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

«Роли = должности»: размытая ответственность. Если в описании сценария написано «директор по продажам согласовывает счёт», а не «согласующий согласовывает счёт», то это значит, что при смене директора сценарий нужно будет переписывать. Но хуже другое: если у директора по продажам нет времени, никто не знает, можно ли его заменить.

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

Нет эскалаций: вопросы «висят» между функциями. Если в сценарии не описан путь эскалации, то происходит одно из двух: вопросы, которые нельзя решить на оперативном уровне, либо зависают, либо решаются неформально, а договорённость нигде не фиксируется.

Решение в том, чтобы на этапе проектирования явно ответить на вопрос «Что происходит, если участник не может принять решение самостоятельно?» и зафиксировать это в схеме и регламенте.

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

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

Как это поддерживается в StormBPMN

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

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

Реестр даёт ответ на вопрос «кто отвечает за этот процесс» за несколько секунд, без поиска по папкам и рассылкам.

Комментарии к элементам, согласование «по ссылке», версии. В StormBPMN можно оставлять комментарии к конкретным элементам диаграммы — задачам, событиям, шлюзам. Это удобно для обсуждения изменений в контексте: не «смотрите слайд 17», а прямо на схеме.

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

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

Заключение

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

Главное, что нужно запомнить:

• Роли участников бизнес-процесса — это не должности. Один человек может выполнять несколько функций, одну функцию могут выполнять разные люди.
• Без эскалаций сценарий работает только в штатном режиме. При первом же отклонении происходит стопор.
• BPMN позволяет сделать ответственность видимой: пулы и дорожки показывают, кто что делает; события и шлюзы — что происходит при отклонениях.
• Схема и регламент должны синхронизироваться и обновляться вместе.

Проверьте свои сценарии прямо сейчас:

☐ У каждого процесса есть явный владелец?

☐ Описаны ли явно пути эскалации?

☐ Зафиксированы ли правила замещения для ключевых ролей?

☐ Когда последний раз обновлялись схемы и регламенты?

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