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