Проверка концепции (proof of concept) начинается с критериев остановки

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

Чем проверка концепции отличается от прототипа, MVP и пилота?

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

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

Какой риск снимает PoC, а какой — MVP

Каждый формат снимает свой риск. PoC проверяет технологию и способ реализации, спрос он не измеряет. Важность отдельной проверки спроса подтверждают данные о закрытии стартапов. Аналитики американской CB Insights разобрали причины закрытия 431 венчурной компании, прекратившей работу с 2023 года. В 43% случаев они обнаружили слабое соответствие продукта рынку.

Спрос на продукт проверяют с помощью MVP. Руководитель ошибется, если примет успешный PoC за доказательство спроса на продукт.

Где заканчивается пилот

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

«Пилот — это когда несколько человек пользуются инструментом и экономят свое рабочее время. Компания при этом не получает никакого прямого финансового эффекта».

Оксана Морсина, управляющий партнер Regroup.

Инвестиции в масштабирование оценивают после проверки реализуемости идеи и результатов MVP или пилота.

Что должно быть готово до старта PoC?

Если PoC проверяет эффект на одной операции, до старта необходимо:

• Назначить владельца. Без него некому будет принять решение по итогам проверки.
• Подготовить данные. Иначе во время эксперимента команда будет заниматься их выгрузкой вместо проверки идеи.
• Выбрать показатель для сравнения до и после эксперимента. Без него команда будет оценивать результат по впечатлениям, а не по данным.

По данным IDC за 2024 год, из каждых 33 запущенных ИИ-PoC до промышленной эксплуатации дошли четыре. Авторы исследования связывают низкую долю внедрений с проблемами в данных, процессах и ИТ-инфраструктуре организаций.

12 ноября 15:00 МСК Онлайн Бесплатно Открытый разбор: КП отправили, а дальше тишина Для руководителей продаж: как узнать, что происходит со сделкой, пока клиент молчит, и как вернуть разговор. Зарегистрироваться

Фильтры отбора идей для проверки концепции

Перед тем как выделить команду, оценивают, поможет ли эксперимент решить, продолжать работу над идеей или отказаться от нее. Если нет, проверку не запускают. Так, похожий подход к отбору идей для пилотов ИИ использовали в «Зетта Страхование». Проектный офис опросил семь подразделений и получил 138 идей применения ИИ. Из них 67 признали пригодными, а 26–30 включили в длинный список для пилотов. Перед запуском каждую идею оценивали по пяти критериям:

• Задачу нельзя решить с помощью скриптов или роботизации. Если хватает простой автоматизации, ИИ не нужен.
• Есть показатели для сравнения до и после пилота. Без такого сравнения нельзя оценить эффект.
• У идеи есть инициативный владелец. Он отвечает за результат и за внедрение.
• Данные оцифрованы и очищены. Иначе команда потратит время эксперимента на подготовку данных.
• Решение можно переиспользовать. Один и тот же инструмент должен подходить для нескольких задач.

Запустили два пилота: проверка медицинских услуг и помощник по документообороту. Для обоих до старта задали измеримые цели: первый должен высвободить 7 ставок, второй — сократить число рутинных запросов на 80%. В двух других направлениях компания поступила иначе: речевую аналитику отложила после неудачного пилота, а от ИИ в коммуникациях с клиентами отказалась.

Владелец и данные для PoC

Владельцем PoC назначают руководителя с полномочиями принять решение по итогам. Исполнитель эксперимента на эту роль не подходит: он отвечает за ход работ, но не распоряжается бюджетом следующего этапа разработки. Владелец утверждает гипотезу, порог и срок. Он же определяет, что делать с результатом.

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

Какие критерии успеха PoC фиксировать до старта?

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

Почему пилоты не доходят до внедрения

Данные об ИИ-проектах показывают, что пилоты редко доходят до внедрения. Исследователи «Интеллектуальной аналитики» опросили представителей около 50 крупнейших организаций. Лишь 7–10% пилотов генеративного ИИ, запущенных в 2025 году, дошли до внедрения. Остальные проекты продолжают тестировать, переводят в другой формат или закрывают.

Показатель относится к пилотам генеративного ИИ в этой выборке и не описывает все PoC на рынке. После пилота команде еще предстоит обосновать бюджет внедрения.

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

Егор Алешин, директор по развитию бизнеса профессиональных ИИ-сервисов в «Яндексе».

Количественные и качественные критерии успеха

Критерии делят на два типа. Количественные отвечают на вопрос «сколько», качественные — на вопрос «при каких условиях».

• Количественные критерии: измеримые показатели по одной операции, срок проверки и потолок бюджета. Для операции устанавливают числовой порог по времени обработки, доле ошибок или стоимости.
• Качественные критерии: допустимый уровень рисков, соблюдение требований безопасности и готовность процесса к внедрению. Их формулируют как ограничения: при нарушении любого из них результат не засчитывают.

Чтобы обосновать бюджет масштабирования, оценивают, какой финансовый эффект может дать достижение количественного порога.

Порог остановки назначают вместе с целью

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

Записанный заранее порог защищает от двух ошибок:

• Команда не продлевает проверку лишь потому, что рассчитывает вскоре получить результат.
• Руководитель не закрывает перспективную идею из-за неудачной первой недели.

Продлить эксперимент можно в одном случае: команда сформулировала новый вопрос и записала для него новый порог и срок.

Как измерить результат проверки концепции?

Когда команда с помощью PoC оценивает эффект от нового решения в одной операции, она сравнивает показатели до и после эксперимента. Дополнительно результат сопоставляют с контрольной группой, которая работала без нового решения. Без исходного замера команда не узнает, насколько изменились показатели после эксперимента. Без контрольной группы трудно понять, что вызвало изменения: новый инструмент или другие факторы. Среди них — сезонность, усилия участников и внимание руководителей к эксперименту.

Чтобы результаты оставались сопоставимыми, срок и число участников фиксируют до начала эксперимента. Если во время эксперимента добавлять участников или продлевать срок до получения удачного результата, итоговые показатели нельзя будет корректно сравнить с исходными.

Базовая линия до старта PoC

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

Так, во внутреннем пилоте hh.ru внедрили ИИ-ассистента для работы с базой знаний технической поддержки. Время поиска информации сравнили до и после запуска. При разборе сложных случаев оно сократилось на 60%. Этот показатель относится только к поиску в базе знаний и не описывает всю работу поддержки.

Контрольная группа в пилоте

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

Например, в пилоте «Альфа-Банка» 2022 года с внешним поставщиком результаты тоже сравнивали с контрольной группой. Такой способ измерения подходит и для PoC, когда команда оценивает эффект от нового решения. Офис инноваций банка тестировал голосовой тренажер стартапа SkyTtrainer для операторов контакт-центра. Задачу и ожидаемый бизнес-эффект определили до старта. Поставщик назвал срок: месяц на запуск. В пилот вошли 100 сотрудников.

По итогам пилота сотрудники стали тратить на решение вопросов клиентов во время звонка на 10 секунд меньше, а продажи выросли на 4%. Оба показателя измерили среди участников пилота. Отдельно сравнили их результаты с контрольной группой: участники выполнили план на 3,7% лучше коллег без тренажера.

Сколько стоит PoC и как обосновать бюджет?

Единой нормы сроков и бюджета у PoC нет. Открытые российские исследования описывают пилоты ИИ в крупном бизнесе, поэтому их данные не задают норму для всех проверок концепции. Стоимость PoC зависит от гипотезы, данных и состава команды. Чтобы обосновать бюджет, оценивают возможные потери, которых поможет избежать PoC. Срок и масштаб эксперимента ограничивают расходы.

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

Из чего складывается бюджет проверки концепции

Бюджет PoC собирают из четырех статей:

• Время команды. Разработчики, аналитик и владелец идеи отвлекаются от текущих задач.
• Доступ к данным. Выгрузка, очистка и согласование прав в рабочих системах.
• Внешний подрядчик или поставщик. Его работа, лицензии и тестовая среда.
• Замер результата. Базовая линия, контрольный замер и время на анализ.

Сравнение с ценой ошибки

Итоговую смету сравнивают с ценой ошибки без проверки: сколько бизнес потеряет, если вложит деньги в разработку, а идея не сработает. В информационной безопасности такой расчет приводят руководству, когда запрашивают бюджет на PoC: стоимость проверки сопоставляют с потенциальными убытками. Но даже сравнение затрат с возможными потерями не всегда убеждает руководство выделить бюджет на PoC.

«Главная проблема — многие руководители считают PoC лишней тратой времени».

Артур Кондаков, руководитель направления разработки и внедрения систем ИБ компании «МойОфис».

Когда проверку концепции пора остановить?

Проверку останавливают по критериям, установленным до старта. Если к установленному сроку результат ниже порога остановки, команда не может подтвердить, что решение реализуемо в заданных условиях.

Почему проекты обрываются после PoC

Причины, по которым проекты обрываются после PoC, известны. Gartner прогнозировал, что не менее 30% проектов генеративного ИИ будут брошены после этапа проверки концепции к концу 2025 года. Аналитики компании перечислили четыре фактора. Их учитывают до старта:

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

Если не учесть эти риски до старта, компания может закрыть проект позже и понести большие потери.

Стоп-сигналы проверки концепции

Стоп-сигналы устанавливают с учетом рисков, названных Gartner, порога остановки и наличия ответственного за внедрение:

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

Чем заканчивается проверка концепции: масштабировать, переделать или закрыть

У проверки концепции три исхода, и каждый из них считается результатом:

• Масштабировать: перейти к MVP или пилоту. Порог достигнут, ограничения известны, у решения есть владелец.
• Переформулировать вопрос и проверить снова. Такой вариант выбирают, если результат достиг порога остановки, но остался ниже цели, или если проверка выявила новое ограничение.
• Закрыть идею. К установленному сроку результат остался ниже порога остановки, поэтому компания не тратит бюджет на дальнейшую разработку.

Переход к масштабированию зависит от трех условий: наличия владельца, стабильной работы ИИ-решения и устойчивого экономического эффекта. Согласно исследованию «Инфосистемы Джет», 40% респондентов не могут масштабировать пилоты. Причины — отсутствие владельца продукта или процесса и нестабильное качество ИИ-решений. По тем же данным, 46% не видят устойчивого экономического эффекта от ИИ.

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