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

Проблема.

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

В то время в Деливери Клабе зарождалась практика «высадки руководства в поля». Она существует очень во многих технологических компаниях и не только в них. Это такой универсальный способ сделать так, чтобы руководители, находящиеся очень далеко от «земли», на эту землю спускались и смотрели на происходящее незамыленым взглядом. Столкнувшись с проблемой роста, было решено взять всю руководящую команду и отправить ее работать курьерами в один из проблемных городов на несколько дней. Назовем его для удобства город Анск.

Вести с полей и SWAT-команда.

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

Всем привет! 

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

Глава 1. Про рынок доставки еды и откуда у агрегаторов курьеры.

Агрегаторы вроде Деливери Клара (ДК) и Яндекс.Еды (ЯЕ), как и их международные собратья вроде DoorDash, Just Eat Takeway, Careem и прочие, не придумали доставку еды. Задолго до их появления существовали и рестораны, и курьеры. Именно поэтому в первые годы развития фудтеха доминировала модель маркетплейса. Фактически, фудтех компании решали задачу поиска ресторанов с доставкой и выбора, и на первых порах этого хватало. Возникли сайты и приложения с заметной аудиторией, фудтехи заключили контракты с тысячами ресторанов и стали работать - причем, преимущественно в плюс. Оно и понятно - расходов не много (только маркетинг, продукт и общие административные, никакой операционки), доходов - много (рестораны с хорошими чеками плюс комиссия в десяток-два процентов). 

На этом этапе фудтех опирался на те типы ресторанов, что располагали своей доставкой - и 90% этих ресторанов были похожими с точки зрения типа компаний и кухонь. Это были заведения, готовящие пиццу, сущи, китайскую еду или фастфуд. Кроме того, большое количество точек (то есть физических ресторанов) представляли большие бренды вроде Subway или Domino’s. Рестораны при этом, даже имея доставку, далеко не всегда уделяли ей много внимания и внимательно работали с сервисом. По моему наблюдению, вообще большинство руководителей в ресторанном бизнесе мыслят не в терминах конверсий, юнит-экономики и ретеншна, а в более приземленных выручках и кэше. Поэтому они могут не видеть проблем там, где их увидит фудтех - например, в плохом клиентском опыте и том, что клиенты редко заказывают повторно. 

Вероятно, многим знакомо такое явление, как стратегическая функция в компании. Возможно, кто-то даже слышал про компании, специализирующиеся на стратегическом консультировании - про большую тройку, состоящую из McKinsey & Company, The Boston Consulting Group (BCG) и Bain & Company, а также компании поменьше: Oliver Wyman, Roland Berger, Partners in Performance и прочие. Или же вы знаете людей, должность которых называется “аналитик / менеджер / руководитель отдела / директор / вице-президент по стратегии”. Чаще всего такие люди встречаются в относительно больших компаниях. Но чем они занимаются? И если в организации нет отдельных людей, именуемых стратегами, кто делает стратегическую работу?

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

Придя на работу в свою первую технологическую компанию, я тут же столкнулся с методикой OKR (Objectives & Key Results). Оказалось, а позже и подтвердилось разговором с экспертом, знакомым с многими стартапами из Кремниевой долины, что эта методика - норма для стартапов.

Довольно понятно, почему она так популярна. OKR (а для тех, кто с методикой не знаком, рекомендую просмотреть сайт whatmatters.com) обещают несколько заманчивых преимуществ:

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

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

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

Иногда размер технического долга оказывается настолько большим, что для его устранения запускаются отдельные проекты, рассчитанные на месяцы и годы - а это сопоставимо с 5-10 time-to-market новых решений. Соответственно, все новые запуски откладываются до тех пор, пока авгиевы конюшни не будут расчищены, покрашены и перестроены. Отдельное зрелище - СТО, который убеждает СЕО и добрую половину правления, а также акционеров, потратить несколько тысяч человекочасов драгоценных разработчиков на то, что по завершении не поможет бизнесу моментально, а только ускорит на неизвестное время получение выгод от новых продуктов в будущем. Правда, после того, как запуск каждого из этих продуктов будет отложен на несколько месяцев.

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