Почему проекты по внедрению новых технологий в розницу терпят неудачу?

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

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

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

Первая проблема носит “человеческий” характер.

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

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

Как результат, модное устройство одиноко стоит в зале или заброшено в дальний угол кладовой магазина, а руководство компании и проекта ищут виновников…

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

Как показывает мой опыт, в начале запуска важно проработать внутри компании следующие вопросы:

1. Определить показатели, на которые влияет технология/ приложение,
2. Обозначить сроки тестового использования технологии на магазине или группе магазинов (если условия использования технологии/ приложения будут различные),
3. Согласовать и пересчитать в выручку целевое значение показателей на период тестового запуска,
4. Определить ценность технологии для клиента,
5. Обучить работе с приложением сотрудников, которые, при этом, должны уметь донести его ценность до клиента,
6. Обыграть в рамках обучения все случаи по работе с возражениями клиента по использованию технологии в рамках продажи,
7. В начале проекта организовать кросс-функциональную команду из представителей розничного руководства, сотрудников магазина, ИТ, финансов/ контроллинга/ аналитиков, специалистов по управлению ассортиментом в магазинах, визуальных мерчендайзеров. Как показывает практика, только в таком составе разработанное решение быстро принимается всей организацией и быстро находит популярность,
8. Разработать систему мотивации для проектной команды и пилотных (тестовых) магазинов, связав премию с достижением показателей проекта,
9. Назначить регулярные встречи внутри команды для обсуждения текущих показателей проекта, действий по улучшению и его дальнейшему тиражированию,
10. Организовать встречи с руководителем компании и отделов/ департаментов для того, чтобы команда смогла эскалировать проблемы и информировать о результатах. Такие встречи помогут показать важность мероприятия команде и мотивировать ее,
11. Принимать решение о тиражировании технологии только после подведения итогов пилотного проекта. При этом, для тиражированию потребуется обязательно подготовить 2 документа: схема подготовки магазина к запуску и план запуска.

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

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

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

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

1. Определить данные, которые нужны для правильной работы системы (мастер-данные),
2. Установить, какая система является их источником. Если единой (мастер-системы) нет, то рекомендуется внедрить промежуточное приложение, которое будет собирать данные этого типа в единую таблицу. Такой подход нужен для облегчения интеграции и более гибкого управления данными,
3. Согласовать обязательные поля, которые должны присутствовать и заполняться у каждого типа мастер-данные. Например, тип валюты и срок действия — могут быть обязательным для цен, артикул и название товарной группы — у товаров,
4. Согласовать частоту обновления данных в системе. Особенно критично оценить бизнес-риски, связанные с потребность в обновлении информации в режиме он-лайн (исходя из практики, такой режим требуется только для получения информации по товарным остаткам при большой оборачиваемости стока),
5. Если товар имеет несколько статусов, определить, какая система и на основании какой формулы должна рассчитывать доступный для продажи сток (часто это требуется для расчёта товарных остатков, которые могут находиться в состоянии транзита, в заказах, в отменах и пр.),
6. Определить, что происходит при обновлении данных каждого типа в разрабатываемой системе. Например: при изменении характеристики товар перемещается в новое отделение каталога, а при изменении остатков до 0 — карточка товара становится реактивной в каталоге и товар не выводится в результаты поиска. Если массовые изменения критичны для торговых процессов, то предусмотреть процесс модерации, при котором будут определяться те изменения, которые нужно применить,
7. Разделить потоки данных на синхронные и асинхронный; при этом, важно избежать ситуации, когда в один момент времени происходит обновление 3 и более типов данных,
8. Разработать систему по мониторингу передачи информации, чтобы быстро определять ошибки в интеграции,
9. После настройки интеграции с учётом п. 1-8 провести тестирование скорости работы приложения/ системы, предварительно согласовал внутри команды значения, которые будут рассматриваться как критичные, хорошие, отличные,
10. Проверить состояние и качество работы поддержки пользователей: фиксирование инцидентов, их классификация, эскалация ошибок в разработку или организация обучения, если ошибки носят массовый пользовательские характер.

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

Надеюсь, данные рекомендации будут полезны и обеспечат успех не одного проекта:)

Удачи!