Самый неудачный (нет) и полезный пилот SmartPricing

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

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

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

- убедиться в эффективности продукта

- в соответствии поставленным задачам

- оценить ресурсы и исходную базу

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

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

На первом этапе подготовки к проекту были решены следующие задачи:

1. Интеграция данных

2. Выбор контрольных и пилотных торговых точек

3. Выбор категорий для теста и фиксация правил и ограничений

Обычно при проведении пилота клиенты выделяют 5-10 торговых точек и выбирают 3--5 категорий товаров. В данном случае было выбрано только две торговых точки для эксперимента и столько же контрольных точек. Так же было принято решение компенсировать малую базу точек участием в пилоте всего ассортимента торговых точек. Забегая вперед - потом нам оба этих решения доставили не мало хлопот.

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

В с в результате оценки системой был обозначен потенциал прироста валового дохода в 3,5%. Этот результат мы и зафиксировали на бизнес ревью в качестве целевого по проекту.

Первая проблема с которой мы столкнулись - это объемы переоценок.

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

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

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

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

Сначала пару слов о том, как проводилась оценка. Оценка эффективности пилота проводится по принципу A/B тестирования. Т.е. мы смотрим, как пилотные и контрольные точки выросли во время пилота к аналогичному периоду до, и дельту между приростом основных показателей по пилотным точкам и контрольным считаем результатом проекта.

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

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

Прирост Выручки: +0,8%

Прирост Валового дохода: +2,7%

Прирост Кол-ва продаж: +0,9%

При более детальном рассмотрении цифр более 70% всех категорий показали положительный результат.

Основные категории по которым контрольные точки "обогнали пилотные" - категории фреш, да-да, это как раз те категории которые мы не могли до появления модуля управления событиями переоценивать достаточно часто.

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

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

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

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

Best practices for best practitioners!

с уважением,

Александр Выголко

Руководитель практики ценообразования, myRetailStrategy

[email protected]

all about excellence in retail

#ценообразование #pricing #ритейл #retail