Пилот — это отдельный оплачиваемый мини-проект на 3–6 недель, который отвечает на один заранее сформулированный вопрос и стоит 15–25 % бюджета полного внедрения. Всё остальное, что называют пилотом, — это либо демонстрация чужого продукта, либо начало основной разработки под другим именем.
Проверять до полного внедрения имеет смысл не всё подряд, а ровно то, что нельзя выяснить разговором: качество ваших данных, поведение ваших клиентов, реальную долю нетиповых случаев. Всё, что можно узнать за час на созвоне, пилотом проверять не нужно — это дорогой способ получить ответ, который уже есть.
Дальше — разбор пилота как процедуры: чем он отличается от трёх похожих форматов, как формулируется вопрос, как выбирается участок, какие пороги записываются до старта, сколько это стоит в рублях и по каким пяти признакам видно, что пилот стал способом откладывать решение. Числа — модельный пример компании, которая обрабатывает 3 200 документов первички в месяц.
Демонстрация, прототип, пилот, MVP: одно слово — четыре разных счёта
Эти четыре слова употребляют как синонимы, и из-за этого заказчик регулярно платит за одно, ожидая другого. Разница между ними не в масштабе, а в том, какой вопрос каждый формат закрывает и чьи данные и люди в нём участвуют.
| Формат | На какой вопрос отвечает | Чьи данные и люди | Срок | Доля бюджета проекта |
|---|---|---|---|---|
| Демонстрация | Как это выглядит и что продукт вообще существует | Данные подрядчика, работает подрядчик | 1–2 часа | 0 % |
| Прототип | Сходится ли ключевая техническая гипотеза | Ваши обезличенные данные, работают инженеры | 1–3 недели | 10–20 % |
| Пилот | Работает ли решение в вашем реальном процессе | Боевые данные и часть потока, работают ваши сотрудники | 3–6 недель | 15–25 % |
| MVP | Нужен ли процессу такой продукт вообще | Весь узкий участок целиком, работают все его участники | 6–10 недель | 30–50 % |
В нашем порядке работ проверочный этап называется прототипом и идёт 1–3 недели на ваших обезличенных данных, а пилотом мы называем запуск уже построенной системы на части потока перед полным переключением. Разница важна для денег: после прототипа в договоре стоит точка выхода — если гипотеза не подтвердилась, проект останавливается, и заказчик платит только за пройденные этапы, обычно 20–30 % бюджета. Отдельный пилот до основного договора нужен, когда неопределённость настолько велика, что под неё нельзя посчитать даже смету.
Сравнение в четыре вертикальные колонки: «Демонстрация — 1–2 часа — 0 % бюджета», «Прототип — 1–3 недели — 10–20 %», «Пилот — 3–6 недель — 15–25 %», «MVP — 6–10 недель — 30–50 %». В каждой колонке три строки-ярлыка: «вопрос», «чьи данные», «кто работает». Колонки нарастают по высоте слева направо. Под ними общая подпись «Чем правее, тем ближе к боевой работе и тем дороже ошибка в постановке вопроса». Чертёжный стиль, подписи по-русски.
Один вопрос, на который отвечает пилот
Главная работа в пилоте делается до того, как кто-то что-то запустил: надо сформулировать вопрос так, чтобы ответ «да» и ответ «нет» вели к разным решениям. Если при любом исходе вы всё равно продолжите проект, вопрос сформулирован неверно и пилот не нужен — это просто первый этап разработки.
Одно предложение вида «Достигает ли <решение> <числового порога> на <нашем реальном объекте> за <срок наблюдения>». В нём обязаны быть число и срок. Формулировка «проверить, подходит ли нам система» вопросом не является: у неё нет проверяемого исхода.
Вот как выглядит разница между рабочей и нерабочей формулировкой на четырёх типовых задачах.
- Документы. Плохо: «проверить распознавание нашей первички». Хорошо: «извлекает ли система 6 полей из наших счетов и накладных с точностью не ниже 92 % по полю на контрольной выборке в 150 документов».
- Голос. Плохо: «посмотреть, как робот отвечает клиентам». Хорошо: «доводит ли робот до записи не менее 55 % входящих звонков в нерабочие часы за 10 рабочих дней при доле переводов на оператора не выше 25 %».
- Прогноз. Плохо: «оценить качество модели спроса». Хорошо: «даёт ли модель на 120 позициях категории А среднюю ошибку прогноза ниже той, что даёт текущий ручной метод, на горизонте четырёх недель».
- Поддержка. Плохо: «попробовать бота на базе знаний». Хорошо: «закрывает ли бот без оператора не менее 40 % обращений первой линии за 2 недели при доле ошибочных ответов ниже 3 %».
Число в формулировке берётся не с потолка — оно приходит из замеров текущего процесса. Если процесс не измерен, сначала нужно обследование и карта процесса: там появляются и объёмы, и текущее качество, относительно которого потом сравнивают. Порог, выставленный «на глаз», обычно оказывается либо недостижимо высоким, либо ниже того, что уже даёт ручная работа, — и оба варианта делают пилот бессмысленным.
Вопрос формулирует заказчик, а не подрядчик. Это принципиально: исполнитель, который сам придумывает критерий успеха для своей работы, поставит его туда, куда уверенно дотянется. Нормальная схема — подрядчик приносит проект формулировки с обоснованием каждого числа, владелец процесса его правит и утверждает, и после утверждения порог не двигается до конца пилота. Единственное допустимое изменение — уточнение способа измерения, если выяснилось, что считать так, как записано, физически нельзя.
Как выбрать участок: узкий объём, но настоящие данные и настоящие люди
Соблазн при выборе участка всегда один — взять самый удобный: чистые данные, лояльный отдел, простые случаи. Такой пилот проходит блестяще и ничего не доказывает. Правило противоположное: сужать надо объём, а не сложность.
- 1Один процесс, не два. Пилот на «заявках и возвратах» одновременно даёт смешанный результат, из которого нельзя вычленить причину. Возвраты идут отдельным пилотом или не идут вовсе.
- 2Реальные данные, включая плохие. В выборку обязаны попасть кривые сканы, документы нестандартных поставщиков, записи со сбойным звуком — в той же пропорции, в какой они встречаются в потоке. Выборка «из лучшего» завышает результат на 10–20 процентных пунктов.
- 3Реальные люди на реальных задачах. Проверяет тот, кто будет работать в системе, а не руководитель и не сотрудник подрядчика. Замечания от человека, который делает эту работу каждый день, стоят дороже любого технического отчёта.
- 4Объём достаточный для статистики. Для документов это 300–500 штук, для звонков — 200–400, для обращений — 500–800. На 30 документах разница между 88 % и 94 % статистически неотличима, и спор об этом займёт больше времени, чем сам пилот.
- 5Контрольная часть выборки откладывается сразу. В модельном примере из 500 документов 350 идут на настройку, а 150 не показываются системе до финального замера. Без этого разделения вы измеряете не качество, а способность подрядчика подогнать правила под известные примеры.
Отдельный вопрос — какой отдел или филиал брать. Логика «возьмём самый продвинутый, там быстрее пойдёт» ломает пилот дважды: сначала завышает результат, потом обеспечивает провал при масштабировании, потому что остальные подразделения работают иначе. Рабочее правило — брать средний участок: не образцовый и не проблемный. Если разброс между подразделениями большой, честнее взять два участка по половине объёма каждый и сравнить результаты между собой: расхождение больше 10 процентных пунктов означает, что проблема не в технологии, а в разных процессах под одним названием.
Если подрядчик предлагает проверить решение на сгенерированных или «типовых» примерах, вы получите результат, который не переносится на боевой поток. Настоящая ценность пилота — именно в столкновении с вашим бардаком: чужими форматами, опечатками, документами от поставщика, который присылает фото накладной с телефона. Обезличить данные можно и нужно, заменять их выдуманными — нельзя.
Схема слева направо. Слева блок «Боевой поток, 3 200 документов в месяц», из него отвод «Выборка 500 документов» с подписью «пропорции сохранены, кривые сканы включены». Выборка делится на два блока: «350 настроечных» (стрелка в цикл «настройка → прогон → разбор ошибок», у цикла подпись «2 круга») и «150 контрольных» под замком с подписью «не показываются до финала». Обе ветви сходятся в блок «Замер по 5 критериям». Справа развилка «Порог взят → полный проект» и «Порог не взят → отчёт и остановка». Чертёжный стиль, подписи по-русски.
Критерии успеха, зафиксированные до старта
Критерии пишутся до первой строки настройки и подписываются обеими сторонами. Это единственная защита от разговора «ну в целом же работает» — разговора, в котором всегда выигрывает тот, кому сильнее нужно продолжение. У каждого критерия обязаны быть число, способ измерения и фамилия того, кто принимает по нему решение.
| Критерий | Порог | Как измеряется | Кто принимает |
|---|---|---|---|
| Точность извлечения по полю | не ниже 92 % | 150 контрольных документов × 6 полей = 900 значений, сверка с ручным эталоном | Владелец процесса |
| Доля документов без единой правки | не ниже 85 % | те же 150 документов, считается документ целиком | Владелец процесса |
| Время обработки одного документа | не больше 40 секунд | журнал системы, медиана по 150 документам | ИТ-контакт |
| Доля документов, уходящих человеку | не выше 15 % | журнал очереди исключений за период наблюдения | Владелец процесса |
| Срок наблюдения | 10 рабочих дней | фиксированное окно, продление — только новым соглашением | Руководитель проекта |
В модельном пилоте первый прогон на 350 настроечных документах дал 78 % по полю — это нормальный старт, а не провал. После первого круга разбора (перечень из 462 ошибочных значений из 2 100, правила под четыре нестандартных формата поставщиков) вышло 91 %, после второго — 96 % на настроечных. Финальный замер на 150 контрольных документах, которых система не видела, дал 94 % по полю: 54 ошибки из 900 значений.
Ошибки при этом распределились не равномерно, а гнёздами: 54 ошибки пришлись на 20 документов из 150. Остальные 130 прошли без единой правки — это 87 % при пороге 85 %. Такая концентрация типична: плохой скан ломает сразу несколько полей. Именно поэтому два показателя — точность по полю и доля чистых документов — надо мерить отдельно, а не выводить один из другого. Подробнее о том, что стоит за цифрами точности, — в статье реальная точность распознавания.
В модельном пилоте разрыв составил 2 процентных пункта: 96 % на настроечных против 94 % на контрольных. Это норма. Разрыв в 5 пунктов и больше означает, что правила подогнаны под конкретные примеры и на боевом потоке качество просядет. Если подрядчик показывает результат только на тех документах, на которых настраивался, замера, по сути, не было.
Столбчатая диаграмма из четырёх столбцов с горизонтальной пунктирной линией порога на отметке 92 %. Столбцы: «Первый прогон, настроечные — 78 %», «После первого круга — 91 %», «После второго круга — 96 %», «Контрольные 150 документов — 94 %». Последние два столбца соединены скобкой с подписью «разрыв 2 п. п. — норма; больше 5 п. п. — подгонка». Ось подписана в процентах точности по полю. Чертёжный стиль, подписи по-русски.
Сколько стоит пилот и почему меньше трёх недель не бывает
Пилот считается по работам, а не по проценту от чего-то. Процент получается уже после — и обычно попадает в вилку 15–25 % бюджета полного проекта.
Разброс по рынку для пилота такого масштаба — 120 000–260 000 ₽. Дороже всего обходятся два пункта, о которых обычно не думают заранее: разметка эталона, если её делает подрядчик, а не ваши сотрудники (это 3 000 значений вручную, около 16 часов), и получение доступов, когда данные лежат в системе, которую поддерживает третья сторона. Если выборку и разметку берёт на себя заказчик, смета падает примерно на 40 000 ₽ — но тогда и ответственность за репрезентативность выборки переходит к нему.
Три недели — практический минимум, и упирается он не в объём работ, а в количество кругов. Первый прогон почти всегда даёт результат ниже порога: система впервые видит ваши форматы. Дальше нужен разбор ошибок, правки и второй прогон — это ещё неделя. Третья уходит на финальный замер и отчёт. Пилот, уложенный в неделю, физически успевает сделать один прогон, и его результат говорит только о том, насколько повезло с выборкой.
Горизонтальная лента на 4 недели с подписанными неделями. Неделя 1 — «Границы, критерии, доступы; отбор 500 документов и разметка эталона». Неделя 2 — «Настройка шести полей, первый прогон — 78 %». Неделя 3 — «Разбор 462 ошибок, правила, второй прогон — 91 %». Неделя 4 — «Третий прогон 96 %, замер на 150 контрольных — 94 %, отчёт и решение». Под лентой две отметки: «156 000 ₽ — 20 % бюджета» и «Порог 92 % взят». В конце ленты развилка с двумя стрелками: «Полный проект, 780 000 ₽» и «Остановка, отчёт остаётся у заказчика». Чертёжный стиль, подписи по-русски.
Отрицательный результат: что забрать и как не потерять материал
Пилот, который не взял порог, — это не потраченные 156 000 ₽, а сэкономленные 624 000 ₽ невыполненной разработки и три сэкономленных месяца. Но экономия становится реальной, только если из пилота вынесли материал. Забирать надо не «выводы», а вещи.
- Размеченная выборка. 500 документов с ручным эталоном по 3 000 значениям — самый дорогой актив пилота. Она годится для любого следующего подрядчика и любой другой технологии, и повторно её делать не придётся.
- Перечень ошибок с классификацией. Не «система ошибается», а разбивка: сколько ошибок от качества скана, сколько от нестандартных форм поставщиков, сколько от неоднозначных полей. Это и есть ответ на вопрос, что чинить в первую очередь — и часто чинить надо процесс, а не систему.
- Отчёт с методикой замера. Как считали, на чём, какие пороги. Он позволяет сравнить следующее предложение с этим по одной линейке, а не по обещаниям.
- Оценка полного проекта. Даже при отрицательном исходе подрядчик обязан назвать, что и за сколько сделало бы результат достижимым. Иногда выясняется, что порог берётся, но проект стоит уже не 780 000 ₽, а 1 200 000 ₽ — и это тоже ответ.
- Права на всё перечисленное. Условие о том, что материалы пилота остаются у заказчика при отказе от продолжения, пишется в договор на пилот заранее, а не обсуждается по факту.
Вечный пилот: пять признаков
Отдельный сценарий провала — пилот, который не заканчивается. Формально всё идёт хорошо: команда занята, отчёты приходят, объём растёт. Фактически пилот стал способом не принимать решение, потому что решение неприятно любому из участников. Признаки видны раньше, чем истечёт бюджет.
- 1Критерии переписывались после прогона. Порог 92 % стал 88 %, потому что вышло 89 %. Это не корректировка методики, а подгонка задачи под ответ.
- 2Срок продлевался больше двух раз без нового вопроса. Продление ради «ещё немного докрутить» означает, что вопрос был не сформулирован и докручивать можно бесконечно.
- 3Объём растёт вместо принятия решения. Добавили второй тип документов, потом второй отдел, потом второго поставщика. Расширение пилота — это новый пилот, и у него должна быть своя смета и свой вопрос.
- 4Нет человека, чья подпись закрывает вопрос. Если решение «принимает совещание», оно не принимается. Имя должно стоять в критериях с самого начала.
- 5Отчёт есть, решения нет дольше трёх недель. После защиты отчёта у сторон должно остаться максимум три недели на «да», «нет» или «переформулировали вопрос и посчитали новый пилот».
У пилота должна быть дата, после которой он не продлевается. Не «дата окончания работ», а дата, к которой на столе лежит решение: идём дальше, не идём или задаём другой вопрос за отдельные деньги.
Когда пилот не нужен
Пилот оправдан там, где есть настоящая неопределённость. Если её нет, он добавляет месяц и пятую часть бюджета, не отвечая ни на один вопрос. Четыре ситуации, в которых мы пилот не предлагаем:
- Задача типовая и решение обратимое. Обмен между двумя системами по документированным API, уведомления, распределение заявок по правилам. Здесь неизвестных нет, а если что-то пойдёт не так, откат занимает часы.
- Объём маленький. При бюджете проекта до 250 000 ₽ пилот за 40 000–60 000 ₽ съедает четверть сметы ради ответа, который получится через две недели самой разработки.
- У продукта есть настоящий бесплатный тестовый период. Коробочные системы часто дают 14–30 дней на своих условиях. Это дешевле любого пилота, и разумно сначала израсходовать эту возможность.
- Гипотеза проверяется расчётом, а не работой. Если вопрос звучит как «окупится ли», его закрывает расчёт окупаемости на замерах текущего процесса, а не четыре недели настройки.
И обратная сторона: есть три ситуации, где пилот обязателен независимо от бюджета. Первая — неизвестное качество данных: никто, включая вас, не знает, насколько ваши документы, записи или справочники пригодны для машинной обработки. Вторая — технология, которой в компании ещё не было: языковые модели, компьютерное зрение, распознавание речи, где разница между «в целом работает» и «работает на нашем материале» огромна. Третья — большой необратимый бюджет: если решение потребует перестройки процесса и его нельзя откатить за неделю, четыре недели проверки дешевле любого исхода наугад.
