Это шаг в неизвестность. Шаг, который позволит совершить революцию, либо провалиться. Мы знаем много хороших и плохих примеров в проектах мировых IT-гигантов, например Google, Microsoft, IBM и других. Но когда российская компания реализует проекты в рамках жестко-ограниченных бюджетов, риски потерять всё значительно возрастают.

Что предстоит сделать?

Рассматривая этапы жизненного цикла продукта в B2B сегменте, разработанного Джеффри Муром, мы увидим, что любой продукт рано или поздно становиться не востребованный рынком. Исследования Мура показали, что если компания имея продукт на этапе агрессивного роста, не приступит к разработке нового, то через 5-7 лет окажется как в сказке у А.С. Пушкина «у разбитого корыта».  

Стратегия инноваций — это спланированный и организованный способ использования новых технологий и творческих идей с подробным планом, который соответствует целям компании, требующей проверки гипотез и проведения исследований. В нашем проекте для разработки стратегии мы использовали модель UNITE. Её основные этапы изображены на фото ниже:

Шаг 1. Разработка инновационной стратегии

Команде необходимо сформулировать идеи будущего продукта и бизнес-процессов, обладающие инновациями и уникальными преимуществами. Иметь в команде сотрудников “имеющих связь с космосом” является преимуществом. Но если серьёзно, для создания таких идей мы использовали “Search Field Matrix” (матрицу полей поиска). Она помогает выделить основные рыночные тенденции, сегменты потенциальных клиентов и определить приоритетные области для инноваций, что сильно сужает возможности нашей “фантазии” и направляет команду в “продуктивное русло”.    

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

Сформулированные идеи в “Search Field Matrix” мы перерабатываем в бизнес-модели И.Пинье, А. Остервальдер. На мой взгляд, она наилучшим образом подходит для разработки инновационных решений и бизнес-процессов. Впрочем, изучить все модели, которые мы используем в своих проектах вы можете в моем обзоре: “Сравнение моделей стратегического планирования”.  

Применение модели И.Пинье, А. Остервальдер на практике лучше изучить в книге авторов, которую мы с удовольствием направим вам на почту бесплатно, если вы напишете нам письмо на email: info@viat-marketing.ru. В теме письма прошу указать: “Хочу книгу про бизнес-модель”, в самом письме ваш телефон и краткую информацию о том, чем вы занимаетесь и где планируете применять бизнес-модель.

Бизнес-модель позволила исключить идеи, реализация которых практически невозможна. Простые тезисы превратились в полноценную концепцию, которая отражает бизнес-процессы, орг. структуру, бюджет, каналы сбыта и т.д. Осталось проверить жизнеспособность концепции на клиентах.

Шаг 2. Изучение клиентского опыта.

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

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

Мы провели 180 CustDev-интервью, задействовав 30 компаний, уже работающих с заказчиком, и 30 потенциальных клиентов. В компании подобрали по три сотрудника относящихся к разным типам покупателей. Глубокий подход к созданию сценария и личное общение позволили нам избежать проблем, с которыми столкнулся IT-разработчик на маркетинговой конференции. О том, как мы проводим CustDev-интервью, публиковал отдельный материал. В результате исследования выделим несколько важных проблем:

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

На все проблемы у нас появляются три потока решений. Поток А - углубленное изучение проблемы клиента и поиск продуктового решения. Поток В - разработка прототипа. Поток С - создание эффективных бизнес-процессов. 

Вновь возвращаемся к клиентам, на этот раз для построения Customer Journey Map (Карты пути клиента к принятию решения о покупке). Такая карта позволяет решить две задачи: выявить Jobs-to-be-Done, количество, и уровни лиц, участвующих в принятии решения о покупке.

Если совсем просто, то Jobs-to-be-Done, это список причин, по которым клиент может прийти к решению о покупке нового продукта. Например, растут затраты на хранение и обработку данных более чем на 10% в год, что мотивирует компанию искать новые решения, нацеленные на оптимизацию и повышение эффективности обработки данных.

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

Для действующих бизнес-проектов чаще всего достаточно глубинных интервью. При разработке инновационных продуктов отдаем предпочтение проверки гипотезы на массовой аудитории. По итогам построения Customer Journey Map проводим краткие анкетные опросы еще 3 000 респондентов, в которые включаем 50% респондентов из отраслей, уже активно использующих действующие решения Big Data и 50% респондентов из перспективных отраслей, которые только начинают задумываться о внедрении.

По итогам опроса строим Job Journey Navigator (Навигатор пути к работе), он позволяет сопоставить возможности компании с ожиданиями клиентов и математически рассчитать приоритетные направления, требующие наибольших усилий в реализации. Например, проблема высокой стоимости хранения данных наиболее приоритетна для компаний из промышленной и медицинской отрасли, но менее важна для банковского сектора. Если наш заказчик сегодня работает преимущественно с банковским сектором, то акцент в разработке необходимо будет производить с учетом проблем банковского сектора, при этом учитывать потенциальный интерес других секторов, чтобы его масштабировать.  

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

Последним этапом на потоке А будет работа по созданию карты ценностей клиента, которую мы разделили на две составляющие:
- расчет ожидаемой полной стоимости владения продуктом;
- определение ценностей для продукта.

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

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

Шаг 3. Создаем MVP

Поток B полностью посвящен созданию MVP (минимально-жизнеспособному продукту и его тестированию). Возвращаемся к бизнес-модели, построенной на основе шаблона И.Пинье, А. Остервальдер и вносим корректировки с учетом полученных сводных данных в потоке А. У команды нашего заказчика появилось 12 новых идей по развитию продукта, и еще 6 идей были перечеркнуты из-за своей нежизнеспособности.

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

Получив MVP, переходим к тестированию продукта. Мы разработали шаблон оценки продукта для потенциальных заказчиков, которые согласились участвовать в тестировании. Весь показать не могу, только сокращенная версия: 

На последнем этапе анализируем результаты тестирования и планируем перечень доработок.

Шаг 4. Определяем бизнес-модель

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

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

По результатам тестирования MVP вновь возвращаемся к нашей бизнес-модели, построенной на основе шаблона И.Пинье, А. Остервальдер и еще более осознанно вносим изменения. На первый взгляд может показаться, что мы делаем одну и ту же работу. На самом деле корректировок было много, и они были обоснованными, так как получены на основе эмпирических оценок.

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

На третьем этапе формируем процесс производства. Это сложная и кропотливая работа, в которой описываются все бизнес-процессы по внедрению и отладки продукта на стороне клиента.

На четвертом этапе рассчитываем все затраты на продвижение, продажу и сопровождение продукта, формируем его себестоимость без учета инвестиций в разработку. На этом этапе нам важно определить, как будет складываться экономика продукта, при условии, что он уже запущен в серию. Затем рассчитывается прогноз продаж, который разделили на два этапа:
1. Запуск первой версии продукта, которую будут готовы купить не более 20% лояльных клиентов;
2. Запуск доработанной версии продукта, которую могут купить 60% лояльных клиентов и 20% новых.

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

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

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

Шаг. 5. Развитие и масштабирование проекта

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

Разработанную бизнес-модель мы декомпозируем на задачи, используя матрицу Хоси Кантри. Матрица сосредоточена на исполнении 5-7 ключевых стратегических целей, которые разбиваются на задачи и этапы исполнения. На мой взгляд - это лучший инструмент формирования дерева решений и контроля реализации стратегии. Формат матрицы позволяет визуализировать зависимость исполнения стратегических целей от промежуточных задач.  

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

Продажи - наше всё! Длительные инвестиции в разработки требуют быстрого возврата денежных средств, поэтому мы внедряем метрики для отслеживания их эффективности, используя еще один инструмент, разработанный американским инвестором Дейвом Макклюром “Pirate Funnel” (Пиратская воронка).  

На каждом этапе сделки автор задает вопросы, которые помогают определить перечень метрик для контроля эффективности продаж. На фото я опубликовал пример метрик из нашего проекта. Задача такой воронки - оптимизация привлечения и удержания клиентов. Мы рассматривали показатели именно в таком виде, в каком они представлены на фото, что позволяло команде сразу увидеть, где мы “проседаем” и быстро исправить последствия.

Сфокусировали внимание генерального директора только на ключевых метриках: NSM и OMTM. Метрики NSM позволяют определить, к какому результату должна прийти компания в среднесрочной перспективе. Метрики OMTM показывают промежуточный результат, позволяющий оценить, отстаем мы от выполнения NSM или нет. Эти инструменты контроля в режиме многозадачности позволили сосредоточить внимание на главном и прекратить “распыление усилий” в ненужные направления.  

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

Итоги:

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

Надеюсь, мой материал вдохновит вас на новые смелые шаги в разработке. Успешного бизнеса!