Почему внутренние продукты корпораций "не взлетают" на рынке и что с этим делать

Все больше корпораций из различных отраслей экономики России не только создают внутренними силами цифровые продукты, но и стремятся вывести их на коммерческий рынок. Однако истории успеха с рыночными продажами inhouse-разработок отраслевых холдингов и их дочерних ИТ-компаний пока единичны. О причинах этого и необходимых шагах для коммерциализации внутрикорпоративных разработок в эксклюзивном материале для портала ComNews рассуждает Максим Кутузов, управляющий директор АО "Сбербанк-Технологии" ("СберТех").

После ухода с российского рынка западных ИТ-вендоров в 2022 году новыми разработчиками ПО в России стали крупные корпорации - банки, страховые, торговые, промышленные компании.

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

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

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

Ошибка 1. Компания закладывает в продукт собственную идеологию.

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

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

Ошибка 2. Конфигурируемость продукта низкая или отсутствует.

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

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

Едва ли надо аргументировать, насколько эта модель нецелесообразна и непригодна к дальнейшему масштабированию.

Ошибка 3. Вендор не переписывает ключевые компоненты, которые есть в ИТ-ландшафте якорного заказчика.

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

Получаем продукт, который неплохо работает в периметре материнской организации (что прямым образом влияет на позитивное восприятие продукта акционерами). Однако при попытках "пересадить" его в другой компании выясняется, что продукт не работает. И попытки реализовать его на рынке сродни намерению продать автомобиль без руля и приборной панели.

Ошибка 4. Требования внутреннего заказчика превалируют над потребностями рыночного решения.

Все фичи категории nice to have будут в ранге must have и наоборот. И убедить топ-руководство, что для успеха продукта на рынке нужно управлять приоритетами в разработке иначе, бывает практически невозможно. В это должны поверить на самом высоком уровне: правление, акционеры, генеральный директор.

Есть и другие, менее критические, но все же значимые ошибки:

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

и многое другое.

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

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

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

В результате, по мере расходования согласованного бюджета, все чаще и чаще будет подниматься вопрос "Где продажи?". В то время как правильным был бы вопрос: "А есть ли у нас рыночный продукт?".

Что же делать?

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

Шаг 1. Валидируйте продуктовую гипотезу на открытом рынке. Изучите объем рынка в терминах общей и доступной емкости, проанализируйте спрос и эластичность спроса. Выясните, как сейчас решается заявленная "боль". Для этого достаточно провести 10-12 глубинных интервью с представителями нужного сегмента целевой аудитории.

Шаг 2. Соберите и реализуйте рыночные требования. Для этого нужно 40-50 встреч с рыночными заказчиками. Необходимо провести сбор требований, их ранжирование и формирование бэклога продуктовой разработки.

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

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

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

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

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

Шаг 7. Внедрите Customer Success - лучшие практики сопровождения клиента после продажи. Мало продать продукт: надо убедиться, что им начали пользоваться и на него "пересели". Это гарантирует продление контрактов, что при показателе от 80% и выше означает рыночный успех продукта.

Кто-то скажет: мы и так все это делаем, а продукт все равно не продается. Вывод прост: либо делается не все, либо не совсем так. Дьявол в деталях, и на любом этапе есть пространство для принятия решения.

Тем не менее этот алгоритм существенно повышает вероятность, что продукт достигнет того, что лучшие продуктовые практики рынка называют product-market fit. А это гарантирует захват и удержание значительной доли рынка.

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