Подрядчик спрашивает, что агенту отвечать клиенту, который просит скидку, — и неделю ждёт ответа, потому что в компании нет человека, который может сказать «делаем так». Вопрос, кто отвечает за AI в компании, звучит организационной мелочью, но именно из-за него внедрение чаще всего растягивается на месяцы: деньги за подрядчика и лицензии уходят, а результат ждёт совещания. Владелец AI-проекта — это человек, который принимает решения по изменяемому процессу и отвечает за его результат. Ниже — кому отдавать эту роль, какие полномочия ей нужны, почему «поручить IT» обычно не работает и когда отдельный владелец не нужен вовсе.
Проект без владельца не стоит — он буксует
Без владельца проект не останавливается. Это было бы даже честнее. Он буксует: работа идёт, созвоны проходят, отчёты пишутся, но каждое решение уходит на согласование, и срок определяется не сложностью задачи, а календарём совещаний.
Узнаётся это по характерным признакам. Подрядчик задаёт вопрос и ждёт ответа неделю. На демонстрацию приходят пять человек, и у каждого своё мнение о том, что нужно, причём двое видят проект впервые. Никто не может назвать метрику, по которой будут судить о результате, зато все могут назвать, что им не понравилось.
AI-проект не требует много времени от компании, но требует быстрых ответов. Роль владельца существует не ради контроля, а ради скорости.
Для нас это не теоретический вопрос. Отсутствие человека, который будет вести изменения со стороны клиента, — один из случаев, когда мы не берёмся за проект: без него внедрение упирается в согласования и не доходит до результата, сколько бы денег в него ни вложили.
Почему «поручить IT» обычно не работает
Логика понятна: технология — значит IT. Но задача, которую решает агент, лежит не в IT, а в продажах, поддержке или логистике. IT может подключить системы и обеспечить доступы, но не может решить, что говорить клиенту при просьбе о скидке. И не должен: это не его работа и не его ответственность.
На практике выглядит это так: проект формально идёт, технически всё подключено, а по существу стоит, потому что вопросы о содержании некому адресовать. Отдел, чей процесс меняется, при этом уверен, что «внедряют айтишники», и не участвует. Айтишники уверены, что делают одолжение продажам. Оба правы, и проект от этого не двигается. Как выстроить работу с IT, чтобы она помогала, а не тормозила, — в статье о том, как договориться с IT-отделом.
Кому отдавать роль владельца AI-проекта
| Кандидат | Когда подходит | Чего не хватит |
|---|---|---|
| Руководитель процесса | Почти всегда: он знает содержание и заинтересован в результате | Времени, если роль не разгрузили от текущего |
| Операционный директор | Когда процесс проходит через несколько отделов | Погружения в детали конкретного отдела |
| IT или CTO | Когда задача действительно техническая | Знания содержания разговоров с клиентом |
| Внешний консультант | Как помощь владельцу, но не вместо него | Полномочий принимать решения за компанию |
Моя позиция: почти всегда верный ответ — руководитель того процесса, который меняется, с поддержкой IT по доступам и интеграциям. Не наоборот. Он единственный, кто одновременно знает, как процесс устроен на самом деле, и теряет что-то, если результата не будет.
Самый соблазнительный неправильный вариант — назначить владельцем подрядчика. Он разбирается, он на связи, он заинтересован. Но он не может решить, какие обещания клиенту компания готова давать и какие данные можно показывать агенту. Хороший подрядчик сам откажется от этой роли. Если не отказывается — это повод насторожиться, а не радоваться.
Четыре полномочия, без которых роль декоративная
- Решать по содержанию. Что агент говорит, чего не говорит и по каким темам зовёт человека — без вынесения каждого вопроса на совещание.
- Останавливать. Право выключить агента без согласований, если что-то пошло не так.
- Требовать время своих людей. Внедрение тратит часы сотрудников, и это должно быть согласовано заранее, а не выпрашиваться.
- Отвечать за метрику. Одна цифра, зафиксированная до запуска, за которую отвечает он.
Второй пункт кажется избыточным ровно до первого инцидента. Если для отключения агента нужно найти трёх человек, агент будет работать неправильно всё время, пока их ищут, — а ищут их обычно в пятницу вечером.
Четвёртый пункт — самый неудобный. Одна цифра, названная до запуска, лишает всех возможности потом объявить успехом то, что получилось. Именно поэтому её так не любят фиксировать и именно поэтому без неё нельзя. Как выбрать такую цифру и посчитать эффект, разобрано в статье о том, как измерить эффект от внедрения AI.
Роли нужны не часы, а быстрые ответы
Времени нужно меньше, чем принято думать, но не ноль. На разборе процесса — несколько часов подряд, потом два-три коротких разговора в неделю на время пилота, дальше — регулярный разбор поводов эскалации раз в месяц.
Опасность не в объёме, а в форме: роль требует не выделенных дней, а быстрых ответов. Человек, который отвечает раз в неделю, тормозит проект сильнее, чем человек, у которого мало времени, но он на связи.
Как совместить роль с основной работой
Владельцем процесса почти всегда становится человек, у которого уже есть полная занятость. Нового человека под роль, как правило, не нанимают, и правильно делают. Роль не требует много времени, но требует его в определённые моменты, и именно с этим возникают трудности.
Работает не «выделить время под AI», а привязка к существующему ритму. Разбор находок — в те же полчаса, что и подготовка к планёрке. Решения по спорным случаям — на самой планёрке, отдельным пунктом на пять минут. Проверка выборки — раз в неделю в фиксированный день, как отчёт.
Что не работает — держать это в списке дел без даты. Задача «посмотреть, как там система» переносится бесконечно, потому что не имеет срока и никто её не ждёт. Привязка к событию, которое и так происходит, решает вопрос надёжнее любой мотивации.
Что должно быть у владельца на руках
Роль без инструментов превращается в ответственность без возможностей, и человек в ней быстро выгорает. Минимальный набор короткий, но каждый пункт обязателен.
Доступ к системе на уровне, позволяющем видеть всё, а не только сводку: конкретные разговоры, конкретные ошибки, историю изменений. Право менять содержание — формулировки, факты в базе знаний — без согласования каждой правки. Прямой канал к подрядчику, минуя посредников. И понятный порядок эскалации: к кому идти, когда нужно решение выше его полномочий.
Проверить достаточность просто: спросите владельца, что он не может изменить сам из того, что его просят изменить. Если список длинный, роль назначена формально.
Что делать, если владельца не назначили, а проект идёт
Ситуация типичная: проект стартовал, все участвуют, никто не отвечает. Обнаруживается это обычно на первом спорном вопросе, который некому решить.
Назначать задним числом неудобно, но необходимо, и делать это лучше явно, а не подразумевая. Полезная формулировка на встрече: «нам нужен один человек, который принимает решения по содержанию, иначе каждый вопрос будет стоить нам недели». Возражений против такой постановки обычно не бывает.
Второй шаг — разобрать накопившиеся нерешённые вопросы разом. К моменту, когда отсутствие владельца замечено, их обычно набирается пять-десять, и они и есть причина, по которой проект буксует. Один разбор на час снимает затор, который копился месяц. Если проект к этому моменту уже признали неудачным, прежде чем ставить крест, стоит прочитать, что делать, если пилот провалился: отсутствие владельца — одна из самых частых причин, и она лечится.
Как понять, что владелец не справляется
Признаки видны раньше, чем провал, и лучше замечать их вовремя — обычно дело не в человеке, а в том, что роль не обеспечена.
Первый признак: решения по спорным случаям откладываются больше чем на неделю. Второй: подрядчик пишет напрямую другим людям, потому что через владельца долго. Третий: владелец не может ответить, что изменилось в системе за последний месяц.
Реакция должна быть не заменой человека, а разговором о том, чего не хватает. В большинстве случаев ответ один из двух: нет времени, потому что роль не учли в нагрузке, или нет полномочий, и каждое решение приходится согласовывать. Обе причины решаются управленчески, а смена человека их не устраняет.
Есть и третья причина, о которой говорят реже: человеку неинтересно. Владелец процесса, назначенный по должности, но не верящий в проект, будет выполнять роль формально, и это видно по тем же признакам. Здесь замена действительно уместна — но искать замену стоит среди тех, кто уже проявлял интерес, а не по той же должностной логике.
Когда отдельный владелец не нужен
Всё написанное выше относится к проектам, которые меняют процесс: агент разговаривает с клиентами, система оценивает звонки и влияет на обучение, автоматика решает, кому звонить. Есть случаи, когда назначать отдельную роль — лишняя бюрократия.
Компания маленькая, и решения принимает собственник. Если между «спросить» и «решить» один человек, он и есть владелец — просто по умолчанию. Назначать его приказом смешно, но договориться, что он отвечает на вопросы подрядчика в пределах дня, стоит.
Процесс не меняется. Сотрудники пользуются нейросетью, чтобы быстрее писать письма или готовить КП, и никакой системы вокруг этого нет. Здесь нужен не владелец проекта, а понятные правила — что можно загружать и что нельзя; их удобно собрать в регламенте работы с AI.
Владельца назначить некого. Это не повод искать обходной путь, а повод отложить проект. Если в компании нет человека, у которого есть время, полномочия и интерес, внедрение не окупится, как бы хорошо ни была выбрана технология. Честнее вернуться к вопросу, когда такой человек появится.
Роль владельца заканчивается, когда про агента говорят на обычной планёрке
После вывода в прод потребность в отдельном владельце не исчезает, но меняется: он перестаёт быть проектной ролью и становится частью обычного управления процессом. Признак, что переход состоялся, — вопросы про агента обсуждаются на тех же планёрках, что и остальная работа отдела, а не в отдельном чате внедрения, который все давно замьютили.
Следствие для руководителя, который собирается что-то внедрять: вопрос «кто у нас будет за это отвечать» стоит задать до выбора подрядчика, а не после первой сорванной недели. Проверка простая. Напишите на листе имя человека, четыре полномочия из списка выше и одну метрику, по которой через два месяца будет понятно, сработало или нет. Если имя не пишется, выбирать технологию рано. Если пишется, но полномочия приходится вычёркивать, — роль будет формальной, и срок проекта уже можно умножать.
Мы начинаем пилоты по методу «Цель → метрика» именно с этого листа: цель, метрика, условие остановки и человек, который вправе остановить. Что ещё нужно от компании при внедрении — на странице внедрения ИИ. Как подготовить людей, чей процесс меняется, — в разделе обучения сотрудников.
AI в компании редко проваливается из-за того, что модель оказалась глупой. Гораздо чаще — из-за того, что умных людей на совещании было пятеро, а ответственного ни одного.
