Риски при внедрении Data-Driven ценообразования

Заметка про то, как подружить ожидания и реальность.

Коллеги по цеху, всем привет!

Сегодня хочу поделиться своими мыслями по теме внедрения Data-Driven ценообразования в ритейле (в обиходе его ещё часто называют динамическим, но это не полностью раскрывает суть подхода), а точнее с сопряженными рисками и о том, как их обойти.

Осторожно, лонгрид! Приготовьте чай и печенье.

Зачем это нужно

Я думаю, сегодня уже никто не будет отрицать, что ценообразование - это один из важнейших факторов определяющих успешность бизнес модели розничной сети. Если оглянуться всего на несколько лет назад, то можно увидеть, какие существенные изменения претерпели подходы к этому процессу. Что более важно, так это то, с какой динамикой эти изменения происходят. Еще недавно все сети работали на наценках, на "целевой рентабельности". Потом научились мониторить конкурентов, выделять корзины FrontBasket / BackBasket, формировать списки KVI, сегментировать товар по ценовым диапазонам, выстраивать ценовые лестницы, считать ценовые индексы, строить разные ценовые модели в зависимости от локации и конкурентного окружения и так далее и так далее.. В общем, ценообразование выросло в полноценную, "взрослую", самостоятельную дисциплину, в которой у менеджера есть задача обеспечить оптимальную цену для своих покупателей учитывая множество факторов, как внутренних так и внешних.

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

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

Таким инструментом стал Data-Driven подход к принятию решения о цене. Data-Driven - означает, что решение принимается на основании анализа данных. "Искуственный интеллект", "Машин лёрнинг", "Биг-дата" - все про это.

Риски при внедрении Data-Driven ценообразования

С чего начать

Розовые очки бьются стеклами внутрь..

Народная мудрость

Итак, представим, что есть некая компания, назовем её, условно, "Семёрочка" коротая решила покончить с "экселями" и играть по-взрослому.

Действительно, а как тут устоишь, когда конкуренты окружили, цены становятся все прозрачнее для покупателя, из отдела ценообразования все чаще слышан "плачь Ярославны" о том, что ресурсов не хватает и нужно брать ещё одного менеджера, а даже небольшие сети внедрившие SmartPricing хвалятся приростами "валовки" в 16%!

Но как и при внедрении любого продукта нужно, важно, что называется "на берегу", подготовиться ко всем возможным трудностям и минимизировать все риски. И чтобы не учиться на собственном опыте я хочу рассказать о нескольких уже типичных рисках при внедрении продуктов data-driven ценообразования.

Кому это нужно

В нашей сети "Семёрочка" есть два потенциальных заказчика подобного проекта, это:

- ТОП-менеджмент (Генеральный директор, Коммерческий Директор, Директор по маркетингу или IT-Директор)

- Отдел ценообразования

В зависимости от того, кто является инициатором проекта, сразу же возникают риски.

В случае если инициатором проекта является Топ-менеджер, и дальше он спускает реализацию этого проекта в отдел ценообразования, который будет работать с этим инструментом, есть риск низкой мотивации и заинтересованности в проекте со стороны уже упомянутого отдела ценообразования (дальше по тексту просто ЦО). Но плюсом этой же ситуации является то, что т.к. инициатором является ТОП-менеджер - ему не нужно "продавать" этот проект и объяснять почему ценообразованием заниматься важно (а это, поверьте на слово, часто очень не просто). Основная мотивация ТОПа при внедрении подобного продукта - это возможность зарабатывать больше без последствий.

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

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

Все это - управленческие риски о которые стоит помнить и упреждать ещё до старта проекта.

Управленческие риски – это риски связанные с сопротивлением руководителей, менеджеров, разных уровней.

Что проверить перед стартом проекта

  • Есть ли у руководства компании заинтересованность в проекте?
  • Кто конкретно выступает куратором со стороны ТОПов?
  • Аргументы «против» со стороны других руководителей.

Что сделать перед стартом проекта

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

Технические риски

Технические риски – это риски связанные с отсутствием у заказчика необходимой информационной структуры, единого КХД и разметки данных.

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

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

Не корректный товарный классификатор. Самая распространенная проблема. Даже сейчас если задать вопрос: "Что такое категория товара", мы не получим единого ответа. Для кого-то это будет "Бакалея", для кого-то "Крупы" для кого-то "Гречка фасованная". Еще хуже, когда у каждого категорийного менеджера свои представления о товарной классификации и нет единой структуры упорядочивания товарных атрибутов.

Кто владеет информацией, тот владеет миром!

Натан Ротшильд

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

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

Пример используемых полей в системе SmartPricing
Пример используемых полей в системе SmartPricing

Пока краткий чек-лист для упреждения технических рисков.

Что проверить

  • Товарный классификатор;
  • КХД (где данные лежат, как их вытащить, столько времени это займет, и как загрузить обратно);
  • Полнота источников данных для поставленных бизнесом задач.

Что сделать

  • Совместно с проектной группой сформировать список бизнес-задач;
  • Включить доработки в дорожную карту проекта;
  • Провести пилотный проект.

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

Пилотный проект на примере SmartPricing
Пилотный проект на примере SmartPricing

Важным преимуществом входа через пилотный проект является возможность максимально объективно оценить и эффективность внедренных изменения используя принципы A/B тестирования, когда мы выделяем пилотную группу которую будем сравнивать с контрольной группой. Во время тестового использования в пилотной группе ценообразование проводится через внедряемый инструмент, а в контрольной методика ценообразования остаемся без изменений. Спустя пилотный период проводится оценка как за этот период приросли пилотные точки, а как контрольные. Например, за время пилота контрольные точки приросли на 14%, а пилотные на %, соответственно, эффект от внедренных изменений: 14%-23% = 14%

Пример оценки пилотного проекта
Пример оценки пилотного проекта

Ошибки при постановке задачи и риск неиспользования

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

Несмотря на то, что подобного рода риски кажутся весьма маловероятными, на практике же, это не редкость.

Я с завидной регулярностью слышу вопросы по типу:

- "Как система поможет улучшить NPS"

- "А давайте будем цены только снижать и наращивать оборот и перекроем потери по марже" и тд.

На самом деле - с таким же успехом можно задавать эти же вопросы "экселю". Но ведь никому не приходит в голову позвонить в службу поддержки Microsoft и задать эти же вопросы?

И дело все в том, что подобные вопросы вскрывают более фундаментальные проблемы, и пробелы в позиционировании розничного формата в целом.

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

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

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

Риск неиспользования – это ситуация, при которой сотрудники не будут использовать систему в повседневной работе.

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

Управляющая система не может быть проще управляемой.

Принцип кибернетики

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

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

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

Типичные "убийцы проекта"

  • Игнорирование предыдущих рисков;

  • Несоответствие планируемых сценариев использования реальным сценариям;

  • Отсутствие кастомизации под требования ключевых пользователей;

  • Отсутствие единой точки сборки – менеджера ЦО;
  • Психология человека: нежелание меняться, ложные ожидания.

Как минимизировать риски связанные с некорректной постановкой задачи и риском неиспользования?

Ниже небольшой чек-лист как модно самих себя проверить. Нужно честно ответить на вопросы:

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

  • Реальны ли поставленных цели?

  • Закроет ли избранный инструмент наши потребности?

  • Сможем ли мы оценить полученные результаты, определены ли критерии оценки?

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

Напишите, с какими вы сталкивались из перечисленных рисков? Сталкивались ли с другими рисками? Какие из рисков для Вас видятся самыми большими?

Спасибо за внимание и обратную связь!

с уважением,

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

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

Начать дискуссию