Шаблон оценки AI-готовности перед пилотом
Я бы сказал так: запускать AI-пилот без быстрой проверки готовности - значит тратить 1–2 недели впустую. Если за 1–3 рабочих дня нельзя собрать карту процесса, базовые метрики, список систем, владельца и ограничения по доступу, пилот пока лучше не начинать.
Я вижу в этом материале одну простую схему: сначала фиксируется _один процесс, одна команда, один владелец и одна цель_, потом ставятся баллы по 6 блокам по шкале 1–5, а после этого принимается одно из 3 решений:
- 25–30 баллов - можно запускать пилот
- 15–24 балла - сначала убрать пробелы
- ниже 15 - поставить паузу
Что я бы вынес в первую очередь:
- AI-пилот надо привязывать не к идее «внедрить ИИ», а к одной метрике: времени цикла, цене операции, качеству или конверсии
- если процесс часто меняется, оценка теряет смысл
- если данные каждый раз собираются вручную, запуск будет буксовать
- если нет отката на ручной режим за 5 минут, команда не готова
- если у пробела нет владельца и срока 14 / 30 / 90 дней, он так и останется в списке
Мне нравится сам подход: он не уходит в теорию и сразу сводит разговор к фактам - цель, процесс, данные, системы, риски, команда. А в конце всё должно помещаться в _одну страницу_ для руководителя: баллы, риски, что подтверждено, что не подтверждено и какой следующий шаг.
Блоки чеклиста и оценочная таблица
Ниже - шесть блоков оценки и шкала 1–5.
Сначала оцените все шесть блоков по шкале от 1 до 5. Это делает руководитель отдела или лидер трансформации: проходит по каждому блоку, смотрит на факты и ставит балл.
Блоки 1–3: бизнес-цель, процесс и доступ к данным
Первые три блока проверяют базу: зачем вообще запускать пилот, какой процесс он затрагивает и есть ли данные, с которыми можно работать.
| № | Блок | Критерий | Доказательство | Балл (1–5) | Комментарий |
|---|---|---|---|---|---|
| 1 | Бизнес-цель | Есть конкретный ожидаемый результат и базовая метрика процесса. Цель привязана к измеримому результату, а не к формулировке «внедрить ИИ» | Документ с целевым показателем, базовым значением и рисками | - | Укажите текущее и целевое значение метрики |
| 2 | Процесс | Процесс описан: входы, выходы, шаги, исключения и ручные точки. Он стабилен и повторяем | Карта процесса, описание исключений и ручных точек | - | Отметьте, если процесс нестабилен или часто меняется |
| 3 | Доступ к данным | Данные описаны, доступны и сведены в один контур доступа; их не нужно вручную собирать перед каждым запуском | Перечень источников данных, схема контура, подтверждение прав доступа | - | Укажите, где данные хранятся и кто владелец |
Если по блоку 2 процесс нестабилен, пилот лучше отложить. Сначала стоит зафиксировать сам процесс, иначе вы будете проверять не ИИ, а хаос в работе.
Блоки 4–6: системы, управление и готовность команды
Вторая тройка блоков - уже про то, можно ли это запустить на практике: с точки зрения систем, контроля рисков и подготовки людей.
| № | Блок | Критерий | Доказательство | Балл (1–5) | Комментарий |
|---|---|---|---|---|---|
| 4 | Системы и инфраструктура | Ключевые системы сценария (CRM, 1С, почта, диск, телефония) доступны для интеграции, а ресурсы и доступы подтверждены | Техническая документация, результат проверки API, инвентаризация инфраструктуры | - | Укажите конкретные пробелы: например, «API 1С не открыт» |
| 5 | Управление и риски | Определены правила работы с данными, роли проверки результатов ИИ, план отката и лог действий; учтены требования 152-ФЗ | Реестр рисков, протокол резервного сценария, политика доступа | - | Укажите, кто отвечает за финальное решение в спорных случаях |
| 6 | Готовность команды | Сотрудники понимают, как работает инструмент, умеют проверять результат и знают, когда эскалировать решение | Результаты тестовых заданий, журнал обучения, результаты пробных проверок | - | Укажите долю команды, прошедшей подготовку |
В блоке 6 мало проверить, что команда умеет нажимать кнопки. Важно другое: люди должны понимать границы инструмента - что ИИ делает нормально, где ошибается и по какой причине.
Модель оценки и пороги готовности
Дальше эти баллы сводятся в одно решение. Каждый блок оценивается по шкале от 1 до 5. Максимум - 30 баллов. Если сумма 25 и выше, это означает готовность к пилоту. Если ниже 15 - это сигнал остановиться и доработать слабые места [1].
| Сумма баллов | Уровень готовности | Следующий шаг |
|---|---|---|
| 25–30 | ✅ Готов к пилоту | Запускайте. Зафиксируйте метрики и план мониторинга |
| 15–24 | ⚠️ Нужна доработка | Устраните критичные пробелы, затем повторите оценку |
| Ниже 15 | 🚫 Не готов | Остановитесь. Определите приоритет устранения причин |
Балл 1 означает, что подтвержденных данных нет. Балл 5 - что процесс задокументирован, проверен и стабилен.
Далее - задания, которые помогают понять, совпадает ли выставленный балл с тем, как работа идет на деле.
Практические задания для проверки реальной готовности
После оценки по баллам стоит проверить всё на рабочих кейсах. Тут уже видно не теорию, а то, как человек и процесс ведут себя в деле. Такие задания помогают подтвердить оценки по блокам 3–6: данные, управление, команда и откат.
Задания для сотрудников и владельца процесса
Сначала проверьте сотрудника и сам процесс на живом примере.
Попросите сотрудника написать промпт для реальной повторяющейся задачи. Например, для квалификации входящего лида. После этого покажите ему результат, который выдал ИИ, и попросите разобрать его по сути: что верно, что нужно поправить, а что нельзя принимать без доппроверки.
Дальше дайте нестандартный кейс. Например, ситуацию, где ИИ выдал неточный или противоречивый ответ. Смотрите, как человек поступит в такой момент: исправит сам, передаст на эскалацию или отклонит результат. Тут важна не только точность решения, но и то, насколько быстро и уверенно оно принято.
Владельцу процесса дайте отдельное задание: письменно зафиксировать путь эскалации. Нужно указать, кто принимает решение, в какой срок и через какой канал.
Задания для проверки данных и управления
Попросите ответственного за данные выгрузить конкретный набор данных из рабочей системы. Например, сделки из CRM за последние 30 дней. Затем - загрузить этот набор в тестовый контур. Зафиксируйте три вещи: сколько времени ушло, нужна ли была помощь ИТ и возникли ли проблемы с правами доступа. Так вы проверяете блок 3.
Потом проверьте резервный сценарий - это уже блоки 5 и 6. Отключите доступ к ИИ-инструменту и посмотрите, как команда выполняет ту же задачу вручную. Главный критерий простой: переход на ручной процесс должен занять не более 5 минут, без потери данных. Если команда начинает метаться или никто не понимает, что делать дальше, это явный сигнал: процесс без инструмента не понят.
Сведите всё в один лист: задание, факт, критерий прохождения.
| Задание | Что проверяем | Критерий прохождения |
|---|---|---|
| Составить промпт для реальной задачи | Умение поставить задачу ИИ | Промпт даёт пригодный результат |
| Проверить вывод ИИ | Качество проверки | В тестовом примере найдены все ошибки |
| Описать путь эскалации | Качество эскалации | Документ готов, роли и сроки указаны |
| Выгрузить данные из системы | Доступ и права | Данные получены в рамках выданных ролей |
| Переключиться на ручной процесс | Работа при сбое | Переход за 5 минут, данные сохранены |
От баллов к решению: запускать, исправлять или остановиться
После подсчёта баллов выберите один из трёх вариантов: запуск, доработка или пауза.
| Баллы | Решение | Горизонт действий |
|---|---|---|
| 25–30 | Запуск | 1–2 недели до старта пилота |
| 15–24 | Исправить | 30–90 дней на доработку |
| Ниже 15 | Пауза | Возврат к базовой подготовке |
Дальше для каждого варианта нужен свой план. Иначе оценка так и останется цифрой на бумаге.
Назначьте владельца и срок для каждого пробела
Каждый существенный пробел из чеклиста должен получить одного ответственного, одно действие и один срок. Логика тут простая: если у задачи нет владельца, она, скорее всего, зависнет.
Сроки можно задать так:
- две недели - для технических мелочей, вроде прав доступа или тестового контура
- 30 дней - для командной отработки: кто проверяет вывод ИИ, кто эскалирует
- 90 дней - если нет бизнес-цели, данные не структурированы или переход на ручной режим не описан
После этого перенесите приоритеты в дорожную карту пилота. Так команда увидит не просто список проблем, а понятный набор шагов.
Свяжите результат с дорожной картой пилота
Высокий балл означает, что команда готова к финальной фазе слаживания - уже в рабочей среде. Первые две недели пилота лучше потратить на фиксацию базовых KPI и еженедельный разбор метрик. Без этой базы не получится измерить эффект.
Средний балл - это не провал. Это, по сути, список задач. Составьте план на 30–90 дней, где каждое действие связано с конкретным риском: нет доступа к данным → риск «слепоты» системы → задача на интеграцию API с дедлайном 30 дней, ответственный - назначенный владелец процесса. В таком виде диагностика становится точкой входа в пилот с планом внедрения и измеримым результатом.
Низкий балл или хотя бы один критический пробел означают одно: пилот не запускается, а команда возвращается к базовой подготовке. После этого зафиксируйте решение в одностраничном отчёте для руководителя.
Одностраничный отчёт для руководителя и выводы
Когда баллы уже выставлены, а пробелы отмечены, соберите всё в одностраничный отчёт для руководителя.
Финальный документ по итогам оценки должен занимать одну страницу и держать все результаты диагностики в одном месте. Его задача простая: дать руководителю, который принимает решение, всё нужное, чтобы понять ситуацию за 5–10 минут - баллы, статус, риски и следующий шаг.
Карточка руководителя: что вносить на одну страницу
| Элемент | Что указать |
|---|---|
| Баллы по блокам | Баллы |
| Сводный балл | Решение: Запуск / Доработать / Стоп |
| Владелец пилота | Владелец |
| Подтверждено | Что проверено |
| Не подтверждено | Что не подтверждено |
| Ключевые риски | Риски |
| Нужна поддержка | Бюджет, доступы, решение ИТ, мандат руководства |
| Шаги на 30–90 дней | Шаги |
Отчёт без строки «Не подтверждено» - неполный. Без неё трудно отделить декларации от того, что команда на деле уже проверила и подтвердила.
Главное для быстрого и дисциплинированного старта
Отсюда и главный принцип: отчёт должен быть коротким. Руководителю нужен не большой разбор, а ясное решение.
Оценка AI-готовности работает только тогда, когда опирается на факты, а не на заявления. Шкал 1–5, порога для решения и плана на 30–90 дней хватает, чтобы запустить пилот без хаоса и лишних догадок. Такой формат делает диагностику перед пилотом быстрой и управляемой: показывает узкие места и сразу переводит разговор в плоскость действий.
И есть ещё одна простая мысль. Чем проще шаблон, тем выше шанс, что команда и правда будет им пользоваться.
FAQs
Кто должен проводить такую оценку?
Такую оценку до старта пилота лучше поручать профильным специалистам или руководителям проектов, у которых уже есть опыт операционной трансформации.
Здесь мало просто посмотреть на технологии. Нужно понять сразу две вещи: потянет ли инфраструктура и готова ли команда менять привычный порядок работы.
Именно на этом этапе Слаживание помогает с методикой диагностики, оценкой навыков и настройкой того, как сотрудники будут работать с ИИ-агентами.
Что считать критичным пробелом?
Критичный пробел - это любое отклонение, которое мешает достичь цели внедрения и нормальной работе системы. В контексте оценки AI-готовности речь идёт о разрыве между тем, что команда умеет и чем располагает сейчас, и тем уровнем, который нужен для полноценной работы с ИИ-агентами.
Проще говоря, это момент, где план упирается в стену: не хватает навыков, процессы не выстроены, или техника просто не тянет нужный сценарий.
Если диагностика показывает такой барьер, его лучше убрать до старта активной фазы пилота. Иначе система будет работать отдельно, а сотрудники - отдельно, что почти всегда ведёт к сбоям, путанице и слабому результату.
Как часто повторять оценку готовности?
Оценку готовности команды к внедрению ИИ лучше проводить регулярно на ключевых этапах проекта, а не только один раз перед запуском.
Проще всего привязать такую оценку к самому циклу внедрения: перед стартом пилота, после обучения сотрудников работе с ИИ-агентами и после первой интеграции инструментов в бизнес-процессы - например, в CRM, 1С и электронную почту.