Критерии приёмки пилота: когда результат «считается»

Почему пилот не заканчивается {#pochemu-pilot-ne-zakanchivается}

Через три месяца после старта пилота ИИ типичная картина выглядит так: система работает на демо-стенде, команда интегратора показывает красивые примеры, внутри компании есть энтузиасты и скептики, а у спонсора нет ответа на один вопрос: это успех или нет?

Проблема не в технологии. Проблема в том, что большинство пилотов нефальсифицируемы — они физически не могут ни пройти, ни провалиться, потому что порог успеха не был зафиксирован числом до первого инференса. Любой результат можно интерпретировать оптимистично («система обучается, нужно ещё время») или осторожно («пока не готово к продакшну»). Обе стороны правы, потому что правота не была определена заранее.

Итог: пилот тихо продолжается, бюджет расходуется, следующая команда через год начинает с нуля — потому что решение так и не было задокументировано.

Этот playbook закрывает именно этот gap: как зафиксировать финиш пилота так, чтобы решение о масштабировании принималось по данным, а не по настроению совещания.

Данные как предусловие: без этого критерии нефальсифицируемы

Прежде чем фиксировать пороги — проверьте, можно ли их вообще измерить. Вот чеклист готовности данных: если хотя бы один пункт не выполнен, критерии приёмки станут мнением, а не фактом.

Чеклист: данные готовы к пилоту

• Baseline зафиксирован до старта. Время на операцию, процент ошибок, стоимость единицы работы — измерены и подписаны. Baseline после старта — это не baseline, это ретроспективная оценка.
• Тестовая (hold-out) выборка размечена заранее. Минимум 200–500 реальных примеров из вашей среды, с правильными ответами, которые не видел интегратор до финальной оценки.
• Источники данных подключены к реальным, не тестовым данным. Пилот на «чистых» данных, приёмка на реальных — классическая ловушка: 30% документов окажутся PDF-сканами, права доступа сложнее, источники конфликтуют. Бюджет вырастает в 2–3 раза.
• Качество данных измерено. Зафиксирован процент записей, прошедших валидацию (data quality gate). Если он ниже 80% — это отдельный проект, не пилот ИИ.
• Персональные данные классифицированы. Если в данных есть ПДн — определено, как они обрабатываются в соответствии с 152-ФЗ. Это не юридическая формальность: нарушение — hard stop пилота.
• Интеграция с 1С/ERP протестирована на реальном контуре. Не на тестовой базе, не на выгрузке в Excel — на живом соединении с реальными правами доступа.
• Среда измерений существует до первого инференса. Логирование, мониторинг метрик, дашборд — всё это должно работать до старта, иначе вы не сможете доказать, что порог был достигнут.

Как зафиксировать baseline, если процесс не был оцифрован

Это самый частый вопрос: «У нас нет метрик по этому процессу — как измерить 'до'?» Четыре рабочих метода:

1. Ручной хронометраж. 20–30 операций с секундомером, фиксация в таблице. Даёт среднее время и разброс. Занимает полдня, но это единственный способ получить честный baseline для ручного процесса.
2. Выборочный аудит логов или почты за 90 дней. Если есть почта, тикеты или любые цифровые следы — выборка из 50–100 случаев даёт статистически значимую картину.
3. Shadow mode. ИИ работает параллельно с человеком, но решение принимает человек. Результаты сравниваются. Это одновременно и метод сбора baseline, и первая итерация пилота — два в одном.
4. Экспертная оценка с доверительным интервалом. Если данных нет совсем — три эксперта независимо оценивают «сколько времени занимает операция», результат фиксируется письменно с диапазоном. Это слабее, чем измерение, но лучше, чем ничего.

Любой из этих методов, зафиксированный в документе приёмки до старта, превращает ROI-расчёт из мнения в факт.

Таблица: тип задачи → метрика → порог → кто подписывает

Это ключевой артефакт. Заполните её до первого инференса — и вставьте в договор с интегратором.

Важно: пороги в таблице — примеры для ориентира. Ваши пороги зависят от baseline. Если baseline не измерен — начните с него, не с порога.

Матрица ролей: кто что проверяет и подписывает

Документ приёмки подписывают четыре роли — каждая читает своё.

Три исхода пилота: определить до старта

Каждый из трёх исходов должен быть описан в документе приёмки до первого инференса — с числовыми порогами, не с описаниями.

Масштабировать — все первичные метрики достигли порогов на реальных данных, adoption rate в норме, hard stop не сработал, ROI-gate пройден. Решение: переход к продакшн-внедрению с зафиксированным бюджетом и дорожной картой.

Доработать — часть метрик в норме, часть — нет, но gap объясним и устраним. Условие: новый числовой порог + жёсткий дедлайн (конкретная дата, не «ещё месяц»). Без дедлайна «Доработать» — это вход в бесконечный пилот. Бюджет на доработку фиксируется отдельной строкой.

Закрыть — метрики не достигнуты, gap не объясним или не устраним в разумный срок, либо сработал hard stop. Закрыть — это тоже успех: вы получили данные, сэкономили бюджет на масштабировании нерабочего решения, и следующая команда не начнёт с нуля — потому что решение задокументировано.

Hard stop: условия немедленной остановки

Эти условия фиксируются в договоре и не требуют совещания — они автоматически переводят пилот в статус «Закрыть»:

• Инцидент с данными, нарушающий 152-ФЗ — утечка, несанкционированный доступ, передача ПДн за пределы разрешённого контура.
• Деградация ниже baseline — система работает хуже, чем ручной процесс, по первичной метрике на протяжении более X дней (зафиксируйте X до старта).
• Превышение бюджета пилота на Y% без согласованного решения спонсора (типичный порог — 20–30%).
• Отказ от предоставления данных для измерения — если интегратор или внутренняя команда не может предоставить данные для расчёта метрик, критерии нефальсифицируемы и пилот не может быть принят.
• Скоуп вырос настолько, что исходный критерий приёмки потерял смысл — пилот одного workflow превратился в «платформу», граница исчезла.

Мини-шаблон документа приёмки (Pilot Acceptance Card)

Скопируйте в договор, Confluence или Notion. Заполняется до старта, подписывается всеми сторонами.

PILOT ACCEPTANCE CARD

Тихий провал: как распознать, что пилот завис

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

• Совещания по пилоту всё реже, но формально он «продолжается».
• Команда интегратора показывает новые фичи вместо измерения исходных метрик.
• Внутри компании нет человека, который может ответить: «Каков текущий статус по критериям приёмки?»
• Adoption rate не измеряется или не обсуждается.
• Decision gate прошёл, но решение не было принято — и новой даты нет.

Лекарство одно: pilot ledger — таблица для CFO/спонсора с тремя колонками: трата к дате / критерий / статус (pass / in progress / kill date). Если статус «in progress» дольше, чем зафиксировано в документе приёмки — это автоматический триггер для decision gate.

Антипаттерны: что разрушает приёмку

Коротко — чтобы не повторять:

• Критерий без числа. «Модель должна работать хорошо» — не критерий.
• Baseline после старта. Измерять «до» уже после запуска — ROI становится мнением.
• Пороги согласуются после получения результатов. Классический конфликт интерпретаций.
• Пилот на тестовых данных, приёмка на реальных. Бюджет вырастает в 2–3 раза.
• Escalation rate воспринимается как провал. 15–20% эскалаций на человека в первой итерации — норма, не катастрофа. Зафиксируйте допустимый диапазон заранее.
• Оплата вендору за трудозатраты, а не за результат. Привязывайте хотя бы часть оплаты к прохождению критериев.

Связанные материалы

Этот playbook закрывает вопрос финиша пилота. Если вы ещё на этапе подготовки — что нужно собрать до старта (данные, доступы, CRM, FAQ) — читайте «Пилот ИИ-агента за 3 дня: что подготовить до старта».

По вопросам внедрения и структуры пилота под вашу задачу — услуги brezatech или контакты.