(function(m,e,t,r,i,k,a){m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)}; m[i].l=1*new Date(); for (var j = 0; j < document.scripts.length; j++) {if (document.scripts[j].src === r) { return; }} k=e.createElement(t),a=e.getElementsByTagName(t)[0],k.async=1,k.src=r,a.parentNode.insertBefore(k,a)}) (window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym"); ym(95051534, "init", { defer: true, clickmap:true, trackLinks:true, accurateTrackBounce:true }); ym(95051534, 'hit', window.location.href);

Проблема time-to-market в екоме

Содержание

  1. Что такое time-to-market и почему он важен
  2. Проблема ожиданий
  3. Функции екома и важность time-to-market
  4. Как сократить time-to-market
  5. Кейсы, связанные с реализацией новых возможностей
  6. Как сократить ТТМ на этапе реализации
  7. Высокий TTM при эксплуатации новых функций и способы его уменьшения

Что такое time-to-market и почему он важен

Поговорим об одной из ключевых концепций электронной коммерции, о time-to-market. TTM — это время, которое проходит с момента возникновения намерения реализовать новую функцию до ее выпуска на реальных пользователей.

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

Способность быстро выпускать новые функции — ключевой фактор конкурентоспособности в екоме.

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

Проблема ожиданий

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

С клиентскими ожиданиями работать не так просто. С ними есть 2 проблемы:

  1. Они всегда ретроспективны: человек имел какой-то опыт в прошлом, и его ожидания отталкиваются от этого опыта. Если ориентироваться только на мнение клиентов, то вы всегда будете решать проблемы прошлого, а не создавать новые возможности.
  2. Только часть ожиданий клиенты способны осознать и выразить. Остальные нельзя механически зафиксировать с помощью опросов, фокус-групп и других исследовательских инструментов. Когда в 2007 году вышел первый айфон, оказалось, что рынок хотел именно такое устройство (экран без кнопок, приложения в App Store). Но если бы людей опросили заранее, вряд ли бы они высказались за такой формат.

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

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

Функции екома и важность time-to-market

Возможности, которые еком дает покупателю, удобно классифицировать по модели Кано и разбить их на группы: Must have, Would be nice, Killer feature (модель Кано предусматривает еще 2 группы, но об этом поговорим в отдельной статье).

  1. Must have — то, что пользователь ожидает без всяких условий. Например, возможность оплатить картой.
  2. Would be nice — то, без чего пользователь готов прожить, но появление чего он ожидает в ближайшее время. Например, возможно оплатить с помощью Apple Pay или Google Pay.
  3. Killer feature — то, что приводит пользователя в восторг. Те самые превосходящие ожидания клиентов. Например, доставка продуктов Яндекс Лавкой за 15 минут.

Базовые ожидания, которые можно выявить с помощью исследований, укладываются в первые две категории. Функции, способные удивить клиента и выдвинуть компанию в лидеры, принадлежат в основном к группе Killer feature. Такие функции можно нащупать с помощью быстрых экспериментов на реальных пользователях.

В екоме функции очень быстро мигрируют из Killer feature в Would be nice и далее в Must have. Чтобы оставаться конкурентоспособным, нужно иметь низкий time-to-market внедрения новых возможностей и расширения товарного предложения.

Еще недавно возможность заказать неограниченное количество одежды для примерки было killer feature Wildberries. Но сегодня то же самое есть у Ламоды и некоторых других продавцов одежды. Функция уже переехала в категорию Would be nice и стремится стать Must have.

Как сократить time-to-market

Причины большого ТТМ могут быть связаны:

  • с управлением;
  • проектированием;
  • реализацией;
  • эксплуатацией.

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

Кейсы, связанные с реализацией новых возможностей

Новые пользовательские функции в екоме появляются, когда вновь разработанная функциональность (или целые решения) отгружена на боевые системы, залиты актуальные данные и запущены операции. Системы разрабатывают либо внутреннее IT, либо подрядчики, либо гибридные команды, а значит источник проблем с ТТМ будем искать в деятельности этих ребят.

Кейс 1: внутренняя команда все делает медленно

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

  1. IT не основной бизнес у ритейлеров. Команде нет нужды быть эффективной, потому что вместо конкуренции на открытом рынке, она работает в тепличных условиях постоянного внутреннего спроса. «Мы не Microsoft: наша задача открывать новые магазины и продавать по всей стране 250 тысяч наименований, а не программные продукты выпускать».
  2. Внутренние команды заняты перманентным внедрением новых корпоративных решений. «У нас плановый переход на новую ERP, в которой будет все идеально через 2 года».
  3. Внутренние команды постоянно разруливают блокеры, которые бизнес бесконтрольно вываливает напрямую разработке. «У меня актуальные остатки не прогрузились, и люди сделали 250 заказов туалетной бумаги, которой давно нет в наличии. Андрей, это же ты разрабатывал, срочно посмотри!».

Кейс 2: зависимость от подрядчика

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

  1. Разработанное подрядчиком решение сложно поддерживать самостоятельно или передать другой компании. «Мы почти сразу перестали требовать документацию из-за сроков. У нас все в куче и мы не знаем, как это устроено».
  2. Поддерживать внедренное подрядчиками решение можно, но это очень дорого и долго. «Мы внедрили интерпрайз-решение, но теперь за развитие выставляют огромные косты. А своих людей нанять сложно и дорого».

Как сократить ТТМ на этапе реализации

Распространено заблуждение, что выбор правильного IT-решения — главная проблема разработки в екоме. А на самом деле в екоме не существует универсального ПО, которое само по себе обеспечит бизнесу продажи.

  1. Еком разнообразен, и в нем много процессов.
  2. Разные екомы сильно отличаются друг от друга.

При этом позиционирование вендоров строится на том, что их система — лучшая и ее внедрение автоматически поднимает продажи.

Фокус должен быть не на решениях и технологиях, а на быстром запуске новых процессов. И не столь важно на каких решениях и технологиях.

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

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

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

Высокий TTM при эксплуатации новых функций и способы его уменьшения

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

Ритейлеры алкоголя давно готовятся продавать в онлайне из-за слухов о легализации дистанционной торговли. В ожидании этого некоторые компании запустили онлайн продажи на полулегальных схемах.

Чаще всего на этапе эксплуатации ТТМ растет по следующим причинам:

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

    Раскатывать новые функции не на всю компанию сразу, а на отдельные подразделения.

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

    ✅ Сформировать команду внедрения, которая будет ездить по подразделениям и рассказывать, как пользоваться новыми функциями.

  3. Даже если персонал обучен, остается проблема мотивации. Часто сотрудники не пользуются или даже саботируют новые функции. Решение: добавить работу с новыми функциями к расчету KPI. Когда в магазинах Вкусвилла появились кассы самообслуживания, количество покупок через них стало влиять на KPI продавцов. После этого персонал стал сам предлагать клиентам оформиться через кассы самообслуживания. Это решало сразу две задачи: продавцы обучались новым функциям, а клиенты привыкали сами пробивать покупки.
  4. Невозможность масштабирования из-за ограниченности MVP версии. Например, часть операций нужно делать вручную, поэтому функциональность нельзя раскатать на всю страну/ассортимент. Решение: запустить разработку целевого решения, не дожидаясь окончания эксперимента с MVP.

Итого

Основной проблемой time-to-market является то, что он часто находится вне зоны внимания людей, занимающихся екомом. Вместо этого команды сосредоточены на вещах, которые совершенно не интересуют покупателей, вроде технологического стэка или методологии гибкой разработки. Но если вы строите конкурентоспособный еком, вам нужно сосредоточиться на способности быстро удовлетворять новые ожидания клиентов и реагировать на изменения рынка (🦠).

Автор материала: Сергей Мелихов

0
2 комментария
vitaliy neret

Мне нравится концепция микросервисной архитектуры, про которую вы пишете.

При этом понятия микросервисов можно отнести не только к ИТ, но и ко всей компании, ко всем её процессам, отделам.

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

Ответить
Развернуть ветку
Сергей Мелихов

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

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда