Готовность бизнеса к ИИ: 20 проверок перед первым пилотом

Компания может быть готова к помощнику по внутренним инструкциям и одновременно не готова к автоматическому подтверждению заказов. Готовность относится к выбранному процессу. Общая оценка «мы технологичный бизнес» мало помогает при первом сбое.

Ниже двадцать проверок. На каждую нужен ответ с подтверждением: документ, пример записи или имя ответственного. Простое количество ответов «да» использовать как разрешение на запуск нельзя. Отсутствие законного и согласованного способа работы с данными важнее нескольких удачных технических демонстраций.

Проверки процесса и данных

1. Названо конкретное действие для автоматизации. «Принимать первичную заявку» достаточно понятно; «внедрить ИИ в отдел» ещё требует уточнения.
2. Есть примеры нормального завершения задачи. Команда может показать, что должно появиться в учёте и что получит клиент.
3. Собраны исключения. Известно, когда сотрудник меняет обычный порядок и почему это разрешено.
4. У сведений есть утверждённый источник. Цены, расписание и условия не берутся из случайной старой переписки.
5. Есть владелец актуальности. Конкретный человек отвечает за обновление материала после изменения условий.

Первые проверки часто выявляют противоречия внутри команды. Один менеджер считает бронь подтверждённой после сообщения, другой после предоплаты. Бот не должен самостоятельно выбирать, чья версия правильная. Руководитель сначала утверждает правило.

Проверки команды

6. У проекта назначен владелец с правом принимать решения по процессу.
7. Ему выделено рабочее время на проверку и согласование. Надежда на свободные вечера не заменяет договорённость.
8. Пользователи системы участвуют в разборе задачи. Их реальные затруднения собраны до выбора инструмента.
9. Определён порядок передачи человеку. Сотрудник знает, где увидит обращение и что обязан сделать дальше.
10. Есть человек, способный работать по инструкции во время отсутствия основного владельца.

Обсудите, как изменится работа сотрудников. Не обещайте, что ИИ никого не затронет, если решение об организации работы ещё не принято. Лучше назвать конкретную задачу и объяснить, какие полномочия остаются у людей. Неясность вокруг проекта порождает сопротивление даже удобному инструменту.

Проверки экономики

11. Измерен исходный объём работы. Есть количество обращений или документов и потраченное время.
12. Назван показатель успеха. Например, доля полностью заполненных заявок, а не число сгенерированных ответов.
13. Учтена цена ошибки. Команда понимает последствия неверной записи, пропущенного обращения или лишнего обещания.
14. Оценены расходы после запуска. В смете есть подписки, поддержка и человеческая проверка.
15. У пилота есть бюджетная граница и условие остановки. Проект не продолжается автоматически потому, что в него уже вложились.

Экономия времени не равна сокращению фонда оплаты труда. Если сотрудник остаётся в команде, покажите, на какую полезную работу он переключится. Для роста продаж считайте дополнительную прибыль после расходов, а не весь оборот клиента, которому ответил бот.

Проверки техники и доступа

16. Проверен разрешённый способ соединить нужные системы. Наличие сайта у поставщика не доказывает доступность интеграции.
17. Аккаунты и права принадлежат компании. Есть порядок выдачи и отзыва доступа подрядчику.
18. Согласован состав передаваемых данных и условия их обработки. Секреты и лишние сведения исключены из входных материалов.
19. Есть испытанный запасной маршрут при отказе модели или внешнего сервиса.
20. Определены журнал событий, срок хранения и возможность восстановить работу после ошибки.

Проверку доступа проводят отдельно от качества диалога. Помощник может отвечать правильно и при этом видеть лишние документы. Для первого испытания достаточно искусственных примеров, чтобы не использовать реальные данные клиентов ради демонстрации.

Как принять решение

Результат диагностики	Следующее действие
Не согласованы доступ или работа с данными	Остановить подключение реальных данных, решить условия
Не определён нормальный результат процесса	Описать правило и разобрать примеры с командой
Процесс понятен, но эффект ещё не измерен	Сначала собрать исходные показатели
Основные условия выполнены, остаются небольшие пробелы	Провести ограниченный пилот с владельцем каждого пробела

Учебный пример решения

Небольшая компания хочет принимать обращения на замер. Правила квалификации известны, но расписание мастеров ведут в личных календарях. Запуск помощника для окончательного подтверждения времени преждевременен. При этом можно испытать сбор адреса и пожеланий с последующей передачей администратору.

У такого пилота другой результат: заполненная заявка без обещанного слота. Команда измеряет качество данных и время обработки, затем решает вопрос с расписанием. Это позволяет учиться на ограниченном процессе без ложного обещания клиенту.

Для каждого пробела назначьте владельца и наблюдаемый признак закрытия. Запись «обновить базу» слишком расплывчата. Запись «администратор сверил расписание с календарями мастеров и проверил отменённую бронь» уже позволяет принять работу.

Заполните проверки вместе с человеком, который выполняет задачу каждый день. Если нужно превратить ответы в требования к пилоту, приходите на разбор в АГЕНСТВО ИИ TRUE.