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