Проблемы внедрения ИИ почти никогда не начинаются с модели. Проект останавливается раньше: процесс не разобран, у него нет владельца, а пилот собран на удобных примерах. Модель при этом работает нормально.
Внедрение ИИ — это изменение процесса, а не установка программы. Поэтому и список мест, где проекты застревают, оказывается про людей, данные и границы ответственности.
Ниже — семь точек остановки с признаками каждой, подробный разбор трёх самых дорогих и короткий список проверок, которые делаются до подписания договора.
Почему проблемы внедрения ИИ редко связаны с технологией
Модель в проекте — деталь. Её берут готовую, дообучают редко, и на итог она влияет меньше, чем состояние данных и договорённости внутри компании. Основная работа уходит на другое: описать процесс, дать агенту доступ к системам, задать критерии готового результата, предусмотреть поведение в нештатных случаях.
Отсюда порядок, с которого начинается любой наш проект: сначала процесс, потом ИИ. Внедрение ИИ в процессы, которых никто не описывал, даёт предсказуемый итог — агент делает не то, что нужно, а виноватой назначают технологию.
По оценке McKinsey Global Institute из отчёта The economic potential of generative AI, до 60–70 % рабочего времени сотрудников в принципе поддаётся автоматизации с помощью генеративного ИИ. Это оценка потенциала отрасли, а не обещание. Сколько из неё дойдёт до конкретной компании, решает не модель, а то, насколько аккуратно разобран процесс.
Семь мест, где проект останавливается
Точки остановки повторяются от проекта к проекту. Их удобно держать перед глазами: каждая опознаётся по признаку, и у каждой есть понятное действие.
| Где встаёт | По чему видно | Что делать |
|---|---|---|
| Нет владельца процесса | решения об исключениях принимать некому, приёмку никто не подписывает | назначить руководителя, которому результат нужен по работе |
| Процесс не описан | регламент расходится с тем, как люди работают на самом деле | снять реальную последовательность шагов на интервью с исполнителями |
| Пилот на удобных примерах | на показе всё работает, на боевых заявках сыпется | собирать пилот на реальных случаях, включая спорные |
| Старый порядок не отменён | люди делают ту же работу второй раз, на всякий случай | назначить дату, после которой ручной маршрут закрывается |
| Доступы не готовы | разработка ждёт ИТ-службу неделями | начинать согласование доступов и тестового контура в первый день |
| База знаний без хозяина | агент отвечает по прошлогоднему прайсу | назначить ответственного за обновление и срок пересмотра |
| Нет замера «до» | эффект не с чем сравнить, спор о пользе уходит в ощущения | снять исходные показатели до старта, а не после запуска |
Три из этого списка встречаются чаще остальных и стоят дороже всего. Их обнаруживают поздно — когда бюджет уже потрачен, а процесс идёт по-старому. Разберём каждую.
Пилот, который ничего не доказывает
Демонстрация всегда собирается на удачном примере: данные полные, система отвечает, клиент написал понятно. В работе рядом с такими случаями идут исключения, и именно они занимают основное время разработки.
Вот что ломает пилот, собранный на витрине:
- данных в заявке не хватает, и их надо запросить, а не додумать;
- учётная система недоступна, и задачу надо отложить, а не потерять;
- формулировка клиента допускает два прочтения, и нужен вопрос человеку;
- запуск повторился, и второй счёт по той же заявке появляться не должен;
- сумма или скидка вышли за границу допустимого, и требуется согласование.
Проверка простая. Возьмите два десятка настоящих обращений за прошлый месяц — не отобранных, а подряд — и прогоните пилот на них. Доля случаев, которые агент довёл до конца без человека, и есть честный результат. Всё остальное — презентация.
Какие задачи вообще имеет смысл отдавать агенту на этом этапе, а какие оставить людям, разобрано в каталоге ИИ-агентов.
Старый порядок работы никто не отменил
Эта проблема выглядит безобидно, а съедает эффект целиком. Агент запущен, работает, но рядом продолжает крутиться прежний маршрут: менеджер всё так же дублирует заявку в таблицу, руководитель всё так же сверяет её глазами.
Причина понятная — людям не сказали, что старый путь закрыт, и они подстраховываются. Через месяц выясняется, что работы стало больше, чем было.
Лечится это не уговорами, а решением владельца процесса: с такого-то числа заявки принимаются только через новый маршрут, ручной способ закрывается. До этой даты — период, когда оба способа работают параллельно и расхождения разбираются. После — только один.
Похожая история с внедрением ИИ в бизнес-процессы, где занято несколько отделов. Там старый порядок держится дольше: каждый отдел ждёт, что первым перестроится соседний.
Никто не снял показатели «до»
Через полгода после запуска разговор об итогах превращается в обмен впечатлениями. Одни говорят, что стало заметно легче. Другие — что ничего не изменилось. Проверить нельзя: исходных цифр нет.
Снимать их надо до старта, и это занимает меньше времени, чем кажется. Нужны четыре вещи: сколько задач проходит через процесс за месяц, сколько времени уходит на одну, сколько из них возвращается на переделку и сколько людей в этом занято.
Пример расчёта, чтобы было видно масштаб: если 9 сотрудников тратят по 2 часа в день на перенос данных между системами, это около 378 часов в месяц. Цифра условная — но она превращает разговор о смете в разговор об окупаемости.
Как выбрать показатели под конкретный процесс и что с ними делать после запуска, разобрано отдельно в материале про эффективность внедрения ИИ.
Риски внедрения ИИ, о которых говорят слишком поздно
Риски принято обсуждать в терминах безопасности данных, и это правда важная часть. Но проекты чаще останавливаются от вещей попроще — тех, что не попали в договор.
| Риск | Как проявляется | Что снимает |
|---|---|---|
| Утечка данных | во внешний сервис уходит то, что уходить не должно | разделение прав на чтение и запись, журнал обращений, перечень данных в договоре |
| Ошибку замечает клиент | неверная цена или срок доходят до письма клиенту | границы допустимых значений, согласование на выходе за них, выборочная проверка |
| Решение осталось без хозяина | автор ушёл на другой проект, правила устарели вместе с процессом | сопровождение зафиксировано в договоре, у правил есть владелец внутри компании |
| Сопротивление сотрудников | работу делают по-старому, агент числится, но не используется | участие исполнителей в разборе процесса, честный ответ, что забирает агент |
| Зависимость от подрядчика | компания не понимает, как устроено то, что у неё работает | описание процесса и документация остаются у заказчика |
Последняя строка — ответ на частый вопрос про внедрение ИИ в компании. После проекта у вас должен остаться не только работающий агент, но и разобранный, описанный процесс. Это актив, который переживёт любую смену технологии.
Что проверить до старта
Короткий список. Если хотя бы на трёх пунктах ответа нет, проект пока не готов к запуску — сначала разбор, потом договор.
- Владелец процесса назван. Не куратор, а человек, которому результат нужен по работе и который подпишет приёмку.
- Процесс описан как он идёт. Реальная последовательность шагов, снятая с исполнителей, а не регламент из папки.
- Исключения перечислены. Что считается нештатным случаем и что агент делает в каждом из них.
- Доступы запущены в согласование. Учётная система, CRM, почта, тестовый контур — до начала разработки.
- Материалы для базы знаний актуальны. Прайс, условия работы с клиентами, шаблоны документов, и у них есть ответственный.
- Показатели «до» сняты. Объём задач, время на одну, доля переделок, число занятых людей.
- Дата отключения старого маршрута назначена. Пусть предварительная, но она должна быть в плане.
- Критерии приёмки записаны. Что считается правильно выполненной задачей — до разработки, а не после неё.
Этот список закрывает первый из четырёх этапов, по которым идёт проект: разбор процесса и критериев результата, проектирование и разработка, тестирование на реальных сценариях с запуском, затем сопровождение. Подробно каждый этап разобран в статье о внедрении ИИ-агентов.
Что получается, когда процесс разобран
Два примера из наших проектов — для понимания, как выглядит результат, когда предыдущие пункты соблюдены.
На производстве внедрили систему обучения с курсами, тестами и базой знаний. Подготовка электронного курса сократилась примерно с 5 дней до 1 часа, теста — примерно с 2 часов до 10 минут. По нашей оценке, помогла подготовленность материалов: инструкции, регламенты и стандарты у компании уже были. Как они превращаются в курсы и тесты — на странице про создание курсов и тестов.
Второй пример — обработка заявок торговых представителей. Агент уточняет недостающие данные, проверяет остатки и цены в учётной системе, формирует заказ и счёт. Устроено это так, что человек остаётся в процессе, но занимается клиентом, а не вводом. Процесс целиком описан на странице ИИ-оператора.
Оба результата — итог конкретных внедрений, а не обещание такого же эффекта каждому. В другой компании другой процесс, другие данные, другая точка старта.
Коротко
Проблемы внедрения ИИ лежат не в технологии, а в трёх местах: процесс не описан, у него нет владельца, старый порядок работы не отменён. Проверить их можно до договора и почти бесплатно.
Пилот стоит собирать на настоящих заявках подряд, а не на отобранных. Показатели «до» снимать заранее, иначе спор об итогах уйдёт в ощущения.
А если в ходе разбора окажется, что процессу нужны собственный интерфейс, своя база данных и разделение прав между отделами, задача выходит за рамки агента — это уже разработка корпоративной системы.
Частые вопросы
Не с выбора другой модели. Возьмите тот же процесс и ответьте на четыре вопроса: кто его владелец, как он идёт на самом деле, какие случаи считаются исключениями и по каким цифрам вы поймёте, что стало лучше. Чаще всего на втором вопросе выясняется, что первый пилот автоматизировал процесс, которого в компании нет.
Срок задаёт не разработка, а две вещи: насколько описан процесс и как быстро дают доступы к системам. Согласование доступов и тестового контура нередко идёт дольше, чем сборка первой версии. Для ориентира: HRM-систему с воронкой подбора, интеграцией с hh.ru и кадровым учётом мы запустили примерно за 2 месяца. Это результат конкретного проекта, а не типовой срок.
Сопротивление обычно вызывает не ИИ, а неясность: людям не сказали, что будет с их работой. Помогает участие в разборе процесса — те, кто выполняет работу, лучше всех знают, где она буксует. И честный ответ про зону: агент забирает ввод данных и переписку по шаблону, а решения и работа с клиентом остаются за человеком.
Можно, но тогда вы получите ту же работу быстрее — вместе со всеми лишними согласованиями и двойным вводом, которые в ней уже есть. Разбор процесса часто показывает, что половина шагов существует из-за ограничений старых программ. Эти шаги дешевле убрать, чем автоматизировать.
Спросите про исключения. Что агент делает, когда учётная система недоступна, данных в заявке не хватает или запуск повторился дважды. Спросите, где смотреть журнал действий и как разбирается случай, в котором агент ошибся. Если внятного ответа нет, вам показали прототип на удачном примере.
Разберём этот процесс в вашей компании
На бесплатной онлайн-экскурсии покажем, как устроены процессы внутри ИНОБО, и обсудим, что из этого применимо к вашей задаче.
Записаться на экскурсию
