Владелец процесса: кто отвечает за результат, когда часть работы делает агент

Владелец процесса — это роль, а не должность

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

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

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

Четыре роли, которые нельзя смешивать

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

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

Что происходит с автоматизацией без владельца

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

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

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

Что показывают цифры

Процессное управление — не модная надстройка, но и не всеобщая практика. По опросу APQC, в 2025 году команда процессного управления была у 73% организаций против 82% в 2024-м: формальных структур стало меньше. Одновременно вырос интерес к сквозным процессам — их описание назвали главным приоритетом 40% респондентов против 34% в предыдущие годы. Читать это можно двояко: компании режут штабные структуры, но признают, что процессы выходят за границы отделов, а значит, нужен кто-то, кто отвечает за процесс целиком.

С автоматизацией картина жёстче. Gartner (январь 2026) оценивает: к концу прошлого года не менее 50% проектов генеративного ИИ закрывали после пилота. Причины, которые называет Gartner, — качество данных, недостаточные контроли риска, растущая совокупная стоимость владения и неясная бизнес-ценность. Ни одна из них не техническая: все четыре упираются в вопрос «кто отвечает за то, чтобы это работало в процессе».

Исследование RAND (август 2024, 65 интервью с дата-сайентистами и инженерами с опытом от пяти лет) называет пять корневых причин провала ИИ-проектов. Первая — задача понята или сформулирована неверно: модель обучают и внедряют под не тот показатель, а в рабочий процесс она не встаёт. Дальше — нехватка данных, погоня за технологией вместо решения задачи, слабая инфраструктура и задачи, которые ИИ в принципе не решает. По некоторым оценкам, которые приводит RAND, больше 80% ИИ-проектов заканчиваются неудачей — вдвое чаще, чем ИТ-проекты без ИИ.

Пять решений, которые остаются за владельцем

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

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

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

Как назначить владельца, если его нет

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

Границы владения стоит разметить заранее — по двум вопросам: описан ли процесс и есть ли у него ответственный. От ответов зависит не «начинать или нет», а с чего начинать.

Метрики, за которые отвечает владелец

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

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

Если владельцев двое, а процесс один

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

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

Где остаётся человек

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

Начать можно без бюджета и без подрядчика. Возьмите процесс, который чаще всего обсуждаете на совещаниях, выпишите его шаги на одном листе и поставьте против каждого имя — кто отвечает за результат шага. Затем ответьте на три вопроса: кто владелец процесса целиком, какие пять решений он принимает и по какой метрике видно, что процесс стал лучше. Если ответы есть, автоматизация будет опираться на роль, а не на надежду. Как мы ведём такую разметку, описано в разделе подхода; примеры похожих проектов — в кейсах.