Пилоты стартуют легко: технология на слуху, бюджет «на попробовать» находится, подрядчик обещает. По нашим наблюдениям – а к нам нередко приходят как раз после чужих остановившихся пилотов – до продуктивной работы доживает примерно один из трёх-четырёх. Остальные тихо сворачиваются с формулировкой «получили интересный опыт». Причины при этом повторяются с такой регулярностью, что мы собрали их в список и проверяем каждый новый проект по нему, как по чек-листу наоборот. Вот все пять – и способ обойти каждую.
Причина 1. Пилот без владельца метрики
Самая частая и самая незаметная. Пилот запускают «посмотреть на технологию»: куратором назначают ИТ-директора или собирают рабочую группу из шести человек. Через два месяца агент что-то делает, но на вопрос «стало лучше или нет» не отвечает никто – ни у кого из шестерых от этой цифры ничего не зависит. Проект не проваливается с грохотом. Он растворяется.
Как обойти: до старта назначить одного владельца и одну метрику. Руководитель поддержки – доля обращений, закрытых без оператора. Главбух – минуты на комплект первички. Заведующий отделением – сумма снятий по дефектам при проверках фонда. Владелец – тот, кто отчитывается этой цифрой перед директором, а не тот, кому «поручили курировать». Одна метрика. Не пять.
Причина 2. Автоматизация хаоса
Если процесс у трёх сотрудников выполняется тремя разными способами, агент честно воспроизведёт все три – вместе с противоречиями. Верный признак хаоса виден ещё на разборе: спрашиваем «как правильно?», и три человека дают три разных ответа, каждый – уверенно. Автоматизировать такое означает ускорить хаос и получать его в большем объёме.
Как обойти: выбирать первым процесс, где «правильно» существует, – мы для этого прогоняем кандидатов через чек-лист из семи вопросов. Если процесс важен, но разболтан, эталон фиксируется прямо в неделю настройки прототипа: одна страница, где владелец письменно отвечает на спорные случаи. Не регламент на сорок листов – одна страница.
Причина 3. «Сделаем всё и сразу»
Скоуп на шесть отделов, четыре интеграции, собственный интерфейс и мобильное приложение сверху. Такой пилот умирает под весом согласований: за восемь месяцев меняются приоритеты, увольняется спонсор, урезается бюджет – а показать всё ещё нечего. В нашей практике каждый лишний отдел в первой очереди примерно удваивает срок до первого измеримого результата.
Как обойти: один сценарий до результата. Не «автоматизация продаж», а «разбор входящих звонков с заполнением карточек». Расширяться после первой цифры: на платформе второй сценарий подключается быстрее и дешевле первого, потому что интеграции, права и оркестрация уже построены. Экономику этой модели мы разбирали отдельно – она и объясняет, почему дисциплина скоупа выгодна, а не просто «правильна».
Причина 4. Сотрудники видят угрозу, а не помощника
Пилот может быть безупречным технически и умереть социально. Менеджеры «забывают» пользоваться подсказками, операторы жмут «пропустить», врачи не открывают черновики. Метрики по итогу нулевые – не потому, что агент плох, а потому, что им не пользовались. Причина всегда одна: люди услышали в проекте слово «оптимизация» и решили, что речь о них.
Живой пример. Контакт-центр оператора связи, вторая неделя пилота: операторы приняли подсказки агента в 9% случаев. Разговариваем со сменой – страх простой: «соберёте статистику и сократите». Что сделали. Открыли операторам журнал действий агента: видно, что он делает и чего не делает, в том числе в двуязычных диалогах. Дали им право исправлять ответы агента – каждая правка попадала в настройку. Публично сменили метрику пилота с «экономии ФОТ» на «время до ответа абоненту». Через три недели доля принятых подсказок выросла до 64%, а старшие смены сами принесли список сценариев, которые хотят отдать агенту следующими. Похожие процессы описаны в решении для клиентского сервиса.
Как обойти: с первого дня проговаривать вслух, что агент забирает рутину, контрольные точки остаются за людьми и никого не сокращают по итогам пилота. И держать слово – второй раз в это никто не поверит.
Причина 5. Проект вместо платформы
Пилот сделан подрядчиком под заказ. Красивый показ, аплодисменты – а дальше подрядчик ушёл на следующий контракт. Изменился регламент – правка через смету и три недели ожидания. Обновились модели – переделка. Через полгода в компании живёт «версия на момент сдачи», которой пользуются всё меньше. Продуктив – это не «дописанный пилот». Это эксплуатация: мониторинг, журнал действий, права, обновления моделей, подключение новых сценариев.
Как обойти: ещё до пилота задать вопрос «кто и как изменит сценарий через полгода, когда поменяется процесс?». Если ответ – «закажем доработку», вы покупаете проект с датой смерти. Если «поменяем настройку сценария на платформе» – у автоматизации есть шанс пережить первый год. Подписочная модель – от 12 млн тенге в год – существует ровно для этого: платформа живёт и меняется вместе с процессами, а не консервируется на дате сдачи-приёмки.
Как довести пилот до продакшена?
Готовность к запуску = один сценарий + владелец метрики + записанный эталон «как правильно» + сотрудники, которым агент помогает + план эксплуатации после пилота.
Наш маршрут выглядит так. Разбор процессов – час, выбираем сценарий и метрику. Прототип на ваших данных – примерно неделя, бесплатно. Решение по цифрам вместе с владельцем метрики. Вывод в продуктив – от восьми недель, с контрольными точками и обучением команды. Окупаемость подписки при сценарии, выбранном по чек-листу, – 6–9 месяцев. Каждый пункт маршрута закрывает одну из пяти причин выше; в этом весь его смысл. Начать проще всего с разбора ваших процессов – час времени, никаких обязательств.
Частые вопросы
Наш пилот уже провалился. Начинать с нуля?
Сначала – вскрытие: какая из пяти причин сработала. Чаще всего это владелец метрики или раздутый скоуп, и тогда перезапуск на том же процессе занимает меньше времени, чем первый заход: данные, доступы и понимание исключений у вас уже есть.
Как заранее понять, что сотрудники примут агента?
Дать им роль в настройке. Исполнители, которых позвали на разбор и научили править агента, защищают пилот лучше любых приказов сверху. Помогают и детали: журнал действий, открытый команде, и метрика, сформулированная не про сокращение людей, а про результат процесса.
Сколько сценариев запускать в первый год?
По нашей практике – два-четыре. Первый доводится до окупаемости и становится внутренним кейсом, дальше подключаются соседние процессы: у них общие интеграции и права, поэтому каждый следующий стартует быстрее и дешевле предыдущего.