Управление пилотным проектом и POC
Ведите пилот так, чтобы он не стал бесплатным консалтингом: какие запросы отклонять, как писать критерии успеха и как устроены объём, роли и день решения.
Среда, вторая половина дня, последние пять минут удачного разговора. Руководитель на стороне клиента произносит фразу, которая звучит щедро: давайте попробуем две недели на нескольких пользователях, потом обсудим. Менеджер соглашается сразу — это выглядит как продвижение. Через шесть недель картина такая: два разработчика потратили тридцать часов на настройку, из пяти открытых учётных записей три заходили дважды, никто не записал, что именно измеряем, а клиент закрывает тему одной фразой — честно говоря, разницы мы не увидели. Потеряна не только сделка. В этой компании теперь зафиксировано мнение: пробовали, не подошло. Такое мнение держит вас за дверью год, а то и дольше.
POC и пилотный проект при верной постановке — самый убедительный инструмент цикла продажи, при неверной — бесплатный консалтинг. В этом материале разбираем, почему POC и пилот отвечают на разные вопросы, какие запросы принимать, а какие отклонять, из чего состоит соглашение о пилоте, как пишутся критерии успеха, почему сужение объёма спасает пилот, кто должен участвовать, как выбирается срок, чем занят отдел продаж во время пилота, чего стоит бесплатный пилот, как принимается решение и какие показатели говорят о здоровье всей программы.
POC и пилот — не одно и то же
Они задают разные вопросы. Проверка концепции отвечает на технический: это в принципе возможно, заработает ли на нашей инфраструктуре, дойдут ли эти данные до той системы? Участники обычно технические, срок короткий, результат — «да» или «нет». Пилот отвечает на операционный вопрос: работает ли это в нашей ежедневной рутине, с живыми пользователями и живыми данными? Участники — те, кто делает работу руками, срок длиннее, а результат — измерение.
Команды, пропускающие это различие, ошибаются двумя способами. Первый — отвечать на технический вопрос операционным пилотом: неделями учить пользователей, когда клиенту нужно было понять, держится ли интеграция. Второй — обратный: показать трёхдневную настройку и назвать её пилотом, когда клиент ждал доказательства, что решение выдержит реальную жизнь. Названный вслух вопрос решает половину задачи.
Вы не обязаны соглашаться на каждый POC
Общий совет — принимать любую просьбу о тесте, чтобы показать уверенность. Небольшой компании этот совет обходится дорого. Неквалифицированный пилот — самое дорогое, что можно отдать бесплатно: часы разработки, часы поддержки, время продавца и, главное, импульс к решению. Просьба к тому же не всегда означает интерес. Иногда это способ отложить, иногда дешёвый метод сравнить трёх поставщиков, иногда документ для внутренней подстраховки.
Найдите настоящий вопрос за просьбой
Прежде чем отказать, спросите одно: что произойдёт, если пилот пройдёт успешно? Если в ответе нет ни даты подписания, ни лица, принимающего решение, перед вами не пилот, а экскурсия. Помогает и второй вопрос: можно ли ответить на это без пилота? Обычно можно — референс похожего внедрения, ограниченная техническая проверка, хорошо собранный сценарный показ. Как мы пишем в материале о том, как проводить демонстрацию продукта, подготовленное демо закрывает значительную часть запросов на пилот гораздо дешевле. Для чтения самого процесса решения крепкую рамку даёт методология MEDDIC.
Есть важное исключение. Если вы вытесняете то, чем клиент уже пользуется, инерция настолько сильна, что пилот часто оказывается единственной точкой перелома. Здесь взять расходы на себя разумно: ваш конкурент — не другой поставщик, а привычка.
Пилот, который не записан, — не пилот
Большинство пилотов проваливаются не из-за продукта, а из-за расхождения ожиданий. Стороны ждут разного, никто это не фиксирует, и в итоге определение успеха достаётся клиенту в одиночку. Спасает не длинный договор, а соглашение на одну страницу.
- Вопрос: на какой единственный вопрос будет дан ответ к концу пилота, сформулированный прямо; если вопросов несколько, вы делаете не пилот, а проект.
- Критерий успеха: измеримый и заранее согласованный порог, который принадлежит клиенту; тот, кто пишет критерий, выигрывает и спор о нём.
- Объём: какая команда, какой процесс, какие данные и какая интеграция входят, и, что важнее, что явно не входит.
- Данные и доступы: живые данные или нет, кто их предоставляет, когда они будут готовы; задержка данных — самая частая причина смерти пилота.
- Роли и обязательство по времени: сколько часов в неделю выделяет каждый участник со стороны клиента; невыделенное время не тратится.
- Календарь и день решения: старт, промежуточная сверка и встреча по решению стоят в календаре до начала работ.
- Условие выхода: при каких обстоятельствах пилот завершается досрочно; этот пункт защищает обе стороны и, как ни странно, повышает доверие.
Когда соглашение ложится на общий календарь, остальное идёт легче. Логика материала о взаимном плане действий работает здесь напрямую: план, даты в котором ставили обе стороны, держится намного лучше одностороннего графика.
Как пишется критерий успеха
У хорошего критерия три свойства: он числовой, написан словами клиента и согласован до старта. Заметное сокращение среднего времени подготовки коммерческого предложения — критерий. Довольство команды — нет. Пусть критерий пишет клиент, а вы лишь делаете его измеримым: тот, кто перешагнул собственный порог, не обязан защищать результат внутри компании. Он этого хочет.
Если «до» не измерено, вы уже проиграли
Здесь кроется самая коварная ошибка. Чтобы доказать улучшение, нужно было измерить исходное состояние, но этого почти никто не делает. В конце вы говорите «стало быстрее», финансовая служба спрашивает «по сравнению с чем», и ответа нет. Базовое измерение — первая задача пилота: сколько минут занимает эта работа сегодня, сколько раз в месяц повторяется, как часто даёт сбой. Три цифры, час работы и опора для всего дальнейшего разговора. Как вести этот разговор в числах, разбираем в материале о продаже через ценность.
Тот, кто обсуждает критерий успеха после окончания пилота, этот спор уже проиграл.
Почему сужение объёма спасает пилот
Интуиция голосует за широту: чем больше покажем, тем убедительнее. На практике верно обратное. Широкий пилот удлиняет настройку, умножает участников, рассеивает внимание и не даёт ясного результата нигде. Узкий пилот показывает бесспорную разницу в одном процессе, и эта разница становится аргументом для всего остального.
Практическая мера — один процесс, одна команда, живые данные. Часть про живые данные не обсуждается: пилот на чистых демонстрационных данных скрывает, насколько беспорядочны собственные записи клиента, и удивляет всех при переходе в продуктив. Небольшой кризис с чисткой данных внутри пилота обходится куда дешевле большого кризиса после него.
Кто участвует в пилоте
Подбор участников определяет результат не меньше продукта. Со стороны клиента нужны четыре роли: спонсор, который принимает решение, чемпион, который ведёт процесс изнутри, ежедневные пользователи и, где нужно, ИТ или безопасность. Чемпион важнее всех: на каждой встрече, где вас нет, вас представляет он. Как строить эти отношения, разбираем в материале о внутреннем чемпионе.
Здесь общий совет стоит перевернуть. Набирать в пилот только энтузиастов заманчиво и бесполезно: энтузиаст уже убеждён и молча обходит любые препятствия. Возьмите внутрь хотя бы одного скептика. Скептик отдаёт настоящие возражения во время пилота, а услышать их на встрече по закупке стоит несравнимо дороже. У крупных клиентов рано подключаются безопасность и комплаенс — как проходить эту часть, разбираем в материале об анкетах по безопасности и соответствию.
Сколько должен длиться пилот
Срок вытекает из вопроса, на который вы отвечаете, и у каждого срока есть цена. Фраза «давайте две недели» чаще всего вежливость, а не план.
| Срок | На какой вопрос отвечает | Чего стоит |
|---|---|---|
| Три-пять дней | Ставится ли, идут ли данные? | Реальное использование не видно |
| Две недели | Ложится ли в ежедневный поток? | Работы конца периода остаются вне окна |
| Месяц | Выдерживает ли полный рабочий цикл? | Внимание участников начинает падать |
| Два-три месяца | Действительно ли команда осваивает? | Импульс решения гаснет, спонсор меняется |
| Без срока | Ни на какой | Пилот тихо превращается в бесплатное пользование |
Последняя строка — не шутка. Пилоты без даты окончания превращаются в месяцы бесплатного пользования безо всякого злого умысла, и с какого-то момента решение становится ненужным всем участникам. Дата окончания — самое важное поле пилота.
Чем занят отдел продаж, пока идёт пилот
Отойти в сторону после старта пилота — самая частая ошибка продавцов. Дать клиенту пространство выглядит как деликатность, а на деле означает позволить пилоту умереть: использование падает, вопросы копятся, их никто не закрывает, а виноватым оказывается продукт. Пилот — самый плотный по контактам отрезок всей продажи.
Здоровый ритм такой: первая неделя — настройка и обучение, вторая — промежуточная сверка, дальше короткий еженедельный статус, в конце встреча по решению. Промежуточная сверка и есть сердце ритма: вы вместе открываете данные об использовании, видите, кто ни разу не зашёл, и решаете, что изменить за оставшееся время, если отстаёте от критерия. Такая дисциплина сокращает и весь цикл; остальные рычаги мы собрали в материале о сокращении цикла продажи.
Чего на самом деле стоит бесплатный пилот
Бесплатный пилот не оставляет следа на стороне клиента. То, что ничего не стоит, не закладывают в бюджет; то, чего нет в бюджете, не контролируют; то, что не контролируют, сползает вниз в списке приоритетов. Какое-то обязательство — символическая плата, письменное обещание времени, стартовая встреча с участием руководства — делает пилот видимым внутри организации.
Но и здесь есть граница. В части компаний провести даже небольшой платный пилот через закупки дольше, чем купить сразу: договор, регистрация поставщика и цепочка согласований превращают двухнедельный пилот в шесть недель бумаг. У такого клиента требование оплаты убивает тот самый импульс, который вы берегли. Правило простое: просите плату, когда она усиливает обязательство, и не просите, когда она удлиняет процесс. Как устроена сторона закупок, разбираем в материале о переговорах с отделом закупок, а логику самостоятельных пробных периодов — в материале о переводе пробного периода в платный.
Как принимается решение по итогам пилота
Главный риск пилота не в провале. Главный риск в том, что он проходит успешно, а решение никто не принимает. Единственная надёжная профилактика — поставить встречу по решению в календарь до начала пилота и заранее написать её повестку: каким был критерий, каким получился результат, при каких условиях продолжаем. Не презентуйте продукт заново на этой встрече.
Если пилот не удался, проиграть тоже можно правильно: запишите прямо, что не сработало, назовите условие, при котором тему можно открыть снова, и поставьте к этому условию дату. Если удался, настоящая работа только начинается — как пилотная настройка становится продуктивной, какие данные переезжают, как расширяется обучение. Всё это передаётся письменно; про сам переход мы пишем в материале о передаче клиента из продаж в клиентский успех.
Какие показатели говорят о здоровье программы
Оценивать пилоты поштучно обманчиво: правда видна на уровне программы. Сравните конверсию сделок с пилотом и без него — если разницы нет, пилот никого не убеждает, а только откладывает. Считайте часы разработки и поддержки на один пилот: пока это число невидимо, пилоты кажутся бесплатными. Фактический срок против планового показывает, держите ли вы объём. А доля брошенных на середине пилотов вместе с причинами — самое честное зеркало качества квалификации.
Увидев эти цифры, большинство команд приходит к одному выводу: пилотов меньше, но собраны они лучше. Команда с пятнадцатью рыхлыми пилотами в год выигрывает меньше и устаёт больше, чем команда с шестью дисциплинированными. Разницу создаёт ровно одно: пилот ведут как маленький проект с границами, а не как этап воронки.
Управление пилотами сводится к тому, чтобы собрать задачи, даты и ответственность вокруг одной записи сделки: критерий, участники, промежуточная сверка, день решения и заметка о передаче должны лежать в одном месте. В Rocketly этапы сделок, задачи и напоминания, история документов и отчётность сходятся на одной записи — создайте бесплатный аккаунт и соберите собственный процесс пилотов.