Хотите посмотреть систему изнутри и понять, насколько она применима для ваших задач?
С удовольствием проведем демонстрацию
Discovery в проекте ценообразования: этап, который спасает от дорогих ошибок
Перед запуском любого проекта мы проводим этап глубокой диагностики – discovery. Это не формальность и не "сбор требований", а структурированное погружение в данные, процессы, правила и бизнес клиента. В статье делимся опытом – на что обращать внимание, чтобы закрывать риски прежде, чем они начали влиять на сроки и успех проекта.
Контракт подписан. Бизнес и технические команды синхронизированы и готовы как можно быстрее запустить обмен данными и дойти до запуска расчетов цен - ведь сроки уже озвучены совету директоров, и скоро нужно будет отчитаться об успешном старте.
В этот момент чаще всего и совершается первая ошибка. Кажется, что можно быстро пройти этап интеграции, перейти к настройкам и получить долгожданные первые цены. Бизнес стремится ускориться, пропустить или пройти "по диагонали" промежуточные этапы вроде discovery, воспринимая их больше как формальность.
Логика понятна: все все уже обсудили, основные вводные известны, команда опытная. Что может пойти не так?
На практике именно в этот момент закладываются будущие проблемы проекта, которые в итоге могут сдвинуть полноценный запуск на недели и даже месяцы.
#
Почему детали "ускользают"
и это нормально
и это нормально
Сотрудники любого уровня часто пропускают важные подробности. Они делают это не из злого умысла, а потому что эти тонкости кажутся слишком очевидными, чтобы их проговаривать. Однако, как известно, дьявол кроется в деталях.
Один недосказанный элемент в одном месте, не до конца раскрытый или неформализованный процесс в другом и предпосылки для проектирования системы уже искажены. А неверные исходные позиции с большой вероятностью приведут к неоптимальной реализации и, как следствие, к упущенной выгоде от внедрения.
И это особенно критично в ценообразовании. Здесь речь не про софт, который поставили и забыли, а про процесс, который напрямую влияет на P&L. Каждое ценовое решение - это либо заработанные, либо потерянные деньги. И цена ошибки здесь не баг в интерфейсе, а реальные потери маржи. Именно поэтому discovery в проектах ценообразования - фундамент, на котором строится весь проект.
Один недосказанный элемент в одном месте, не до конца раскрытый или неформализованный процесс в другом и предпосылки для проектирования системы уже искажены. А неверные исходные позиции с большой вероятностью приведут к неоптимальной реализации и, как следствие, к упущенной выгоде от внедрения.
И это особенно критично в ценообразовании. Здесь речь не про софт, который поставили и забыли, а про процесс, который напрямую влияет на P&L. Каждое ценовое решение - это либо заработанные, либо потерянные деньги. И цена ошибки здесь не баг в интерфейсе, а реальные потери маржи. Именно поэтому discovery в проектах ценообразования - фундамент, на котором строится весь проект.
Что покрывает discovery
Discovery в ценообразовании - это не про собрать требования, а про честный разговор о том, как устроен бизнес сегодня. И у этого разговора есть конкретная структура.
Данные
Где живет себестоимость - в ERP, в Excel, в переписке с поставщиком? Как часто обновляются цены конкурентов? Есть ли история изменения цен за год? Какие виды закупочных цен используются - максимальная, последняя, средняя? Как считается себестоимость для разных каналов?
На практике "у нас все в ERP" часто означает "часть в ERP, часть в Excel, часть в головах". И это нормально. Но если не заложить время на выявление и сведение всех источников данных на этапе discovery, пилот стартует на ненадежном фундаменте. В этом случае система будет считать корректно, но на некорректных данных.
На практике "у нас все в ERP" часто означает "часть в ERP, часть в Excel, часть в головах". И это нормально. Но если не заложить время на выявление и сведение всех источников данных на этапе discovery, пилот стартует на ненадежном фундаменте. В этом случае система будет считать корректно, но на некорректных данных.
Процесс
Кто сейчас принимает решение о цене? Один человек на 10 000 SKU? Как устроена замена ценников - сколько ценников персонал может заменить в день, в какие дни, как расставляются приоритеты?
При погружении в бизнес клиента мы часто сталкиваемся с тем, что процесс ценообразования не до конца формализован. Цепочка действий не описана, зоны ответственности размыты, а часть решений принимается по ситуации. Автоматизировать такой процесс можно, но тогда система будет воспроизводить и масштабировать все его слабые места. Поэтому на discovery мы не просто описываем текущий процесс, а переводим неявные решения и разрозненные практики в прозрачную и управляемую структуру.
При погружении в бизнес клиента мы часто сталкиваемся с тем, что процесс ценообразования не до конца формализован. Цепочка действий не описана, зоны ответственности размыты, а часть решений принимается по ситуации. Автоматизировать такой процесс можно, но тогда система будет воспроизводить и масштабировать все его слабые места. Поэтому на discovery мы не просто описываем текущий процесс, а переводим неявные решения и разрозненные практики в прозрачную и управляемую структуру.
Правила
Есть ли формализованная ценовая политика, или все держится на опыте и незафиксированных договоренностях? Сколько исключений из правил и кто их согласовывает? Какие ограничения заданы поставщиками или государством (регулируемые товары, МРЦ, РРЦ)?
Если единой ценовой политики нет, а логика ценообразования живет в головах отдельных людей - это не стоп-фактор, а стартовая точка. И именно на discovery эту логику нужно вытащить на поверхность и переложить в набор понятных и воспроизводимых правил, с которыми сможет работать и бизнес, и система.
Если единой ценовой политики нет, а логика ценообразования живет в головах отдельных людей - это не стоп-фактор, а стартовая точка. И именно на discovery эту логику нужно вытащить на поверхность и переложить в набор понятных и воспроизводимых правил, с которыми сможет работать и бизнес, и система.
Метрики
Что бизнес считает успехом? "Рост маржи" - это +1 п.п. к валовой прибыли или +20% к чистой? Без согласованных целевых метрик пилот не имеет смысла. На discovery фиксируем: что измеряем, как сравниваем, какой период и контур считаем корректным для оценки эффекта.
Что проясняет discovery: три истории из практики
1
Когда "самый дешевый" товар не самый дешевый
В одном из проектов мы обнаружили проблему в существующей логике ценообразования: товары, которые должны были позиционироваться как самые дешевые в категории, на самом деле таковыми не являлись.
Причина оказалась в путанице с единицами измерения. Из-за часто допускаемых ошибок в ходе ручной проверки цены в пересчете на килограмм или литр, самый дешевый товар в категории зачастую фактически им не был.
Это типичный пример проблемы в слое данных. Информация формально есть, но ее качество не проверено, и это искажает всю логику ценообразования. Если бы мы вышли на пилот с этой ошибкой, эффект от оптимизации был бы непредсказуемым - система оптимизировала бы цены на основе неверных предпосылок.
Причина оказалась в путанице с единицами измерения. Из-за часто допускаемых ошибок в ходе ручной проверки цены в пересчете на килограмм или литр, самый дешевый товар в категории зачастую фактически им не был.
Это типичный пример проблемы в слое данных. Информация формально есть, но ее качество не проверено, и это искажает всю логику ценообразования. Если бы мы вышли на пилот с этой ошибкой, эффект от оптимизации был бы непредсказуемым - система оптимизировала бы цены на основе неверных предпосылок.
2
Когда кластеры не работают
Изначально в проекте предполагалось кластерное ценообразование - магазины группировались по характеристикам, и цена задавалась на уровне кластера. Однако в процессе discovery стало понятно, что различия внутри кластеров критичны: поведение спроса, конкуренция и локальные факторы слишком различались.
В итоге от идеи кластеров пришлось отказаться в пользу магазинного ценообразования - более сложного, но адекватного реальности.
Это пример ситуации, когда предположения о правилах не выдерживают проверки фактами. Кластеризация - мощный инструмент, но она должна быть основана на реальном поведении спроса, а не на удобных допущениях. Если бы мы пришли к этому выводу только на этапе пилотирования, весь результат проекта был бы поставлен под угрозу - пришлось бы пересобирать архитектуру решения уже на работающей системе.
В итоге от идеи кластеров пришлось отказаться в пользу магазинного ценообразования - более сложного, но адекватного реальности.
Это пример ситуации, когда предположения о правилах не выдерживают проверки фактами. Кластеризация - мощный инструмент, но она должна быть основана на реальном поведении спроса, а не на удобных допущениях. Если бы мы пришли к этому выводу только на этапе пилотирования, весь результат проекта был бы поставлен под угрозу - пришлось бы пересобирать архитектуру решения уже на работающей системе.
3
Когда цены из центра не доходят до полки
В B2B-сегменте мы не раз сталкивались с тем, что сам бизнес понимает разумность внедрения системы динамического ценообразования. А менеджеры на местах либо недостаточно информированы, либо сопротивляются такой истории.
Как результат, финально согласованные цены из центра подвергаются значительной корректировке на местах, иногда на десятки процентов, что в итоге делает невозможной оценку эффекта от внедрения системы.
Это проблема готовности к изменениям. Технически система может рассчитать оптимальную цену, но если организационно не обеспечен контроль ее применения, весь проект превращается в "черный ящик", который что-то считает, но никто не знает, работает ли.
Этот момент нужно прорабатывать на discovery с двух сторон: и при выстраивании стратегии ценообразования, и со стороны бизнеса в части работы с менеджерами.
Как результат, финально согласованные цены из центра подвергаются значительной корректировке на местах, иногда на десятки процентов, что в итоге делает невозможной оценку эффекта от внедрения системы.
Это проблема готовности к изменениям. Технически система может рассчитать оптимальную цену, но если организационно не обеспечен контроль ее применения, весь проект превращается в "черный ящик", который что-то считает, но никто не знает, работает ли.
Этот момент нужно прорабатывать на discovery с двух сторон: и при выстраивании стратегии ценообразования, и со стороны бизнеса в части работы с менеджерами.
Как понять, что discovery завершен
Discovery мало провести, его нужно грамотно завершить. Как же понять, что этап закончен и можно двигаться дальше? Обязательно нужно учесть две вещи:
- ПерваяЗаранее согласованный список артефактов подготовлен и одобрен обеими сторонами.
- ВтораяНи у вас, ни у клиента не остается чувства недосказанности. Ничего не гложет изнутри, мол, "вот эту тему, кажется, не до конца обсудили".
Второй критерий может звучать субъективно, но на практике это самый точный индикатор. Если что-то "гложет", значит, есть зона неопределенности, которая обязательно даст знать о себе позже. Только позже она будет стоить значительно дороже.
Артефакты discovery
В нашей практике завершенный discovery выражается в конкретных артефактах. Почти всегда список выглядит так:
✓ Схемы ценообразования as-is и to-be - как устроено сейчас и как будет после внедрения
✓ Описание процесса - вплоть до уровня слепка рабочего дня, если требуется детализация (кто принимает решения, с какой периодичностью, на основании чего)
✓ Понятные цели и метрики пилота - что считаем успехом, как измеряем, какой контур и период сравнения
✓ Список необходимых доработок - полный перечень настроек, а также ограничений и зафиксированных рисков
✓ Техническое задание на интеграцию - какие данные откуда берутся, как сводятся, где пробелы
✓ Карта стадий проекта (roadmap) - с этапами и сроками реализации
✓ Реестр участников проекта со всех сторон - с ролями и зонами ответственности
✓ Схемы ценообразования as-is и to-be - как устроено сейчас и как будет после внедрения
✓ Описание процесса - вплоть до уровня слепка рабочего дня, если требуется детализация (кто принимает решения, с какой периодичностью, на основании чего)
✓ Понятные цели и метрики пилота - что считаем успехом, как измеряем, какой контур и период сравнения
✓ Список необходимых доработок - полный перечень настроек, а также ограничений и зафиксированных рисков
✓ Техническое задание на интеграцию - какие данные откуда берутся, как сводятся, где пробелы
✓ Карта стадий проекта (roadmap) - с этапами и сроками реализации
✓ Реестр участников проекта со всех сторон - с ролями и зонами ответственности
Если чего-то из этого списка нет, риски, что в проекте что-то пойдет не так, увеличиваются.
#
Плохой discovery легко узнать
Плохой discovery делается формально: без глубокого погружения в бизнес-процессы, без попытки задать неудобные вопросы и без реального интереса к тому, как все устроено на стороне бизнеса.
В этом случае артефакты появляются, но понимания так и нет. А значит, все ошибки и недочеты просто откладываются на следующие этапы.
Discovery - не подготовка к работе. Это и есть работа.
Сейчас нам уже очевидно, что discovery - это стадия, которая усиливает обе стороны и не замедляет проект, а, наоборот, предотвращает его замедление.
Исправление ошибки или неточности, найденной на этом этапе, измеряется в часах или днях. Коррекция той же самой ошибки на последующих этапах может занять недели, ведь она будет включать ревизию уже готовых решений: пересборку правил, перекалибровку алгоритмов, пересогласование метрик, а, возможно, и перезапуск пилота.
Но дело не только в скорости. Discovery - это этап, на котором неформализованный процесс ценообразования превращается в четкий и понятный набор правил. Иначе система будет автоматизировать хаос - она всё равно что-то посчитает, но качество результата будет непредсказуемым.
Если вы в поисках успешных практик ценообразования - от аудита "серых зон" до построения управляемых процессов и масштабирования - команда Imprice открыта к диалогу и обмену опытом. .
Исправление ошибки или неточности, найденной на этом этапе, измеряется в часах или днях. Коррекция той же самой ошибки на последующих этапах может занять недели, ведь она будет включать ревизию уже готовых решений: пересборку правил, перекалибровку алгоритмов, пересогласование метрик, а, возможно, и перезапуск пилота.
Но дело не только в скорости. Discovery - это этап, на котором неформализованный процесс ценообразования превращается в четкий и понятный набор правил. Иначе система будет автоматизировать хаос - она всё равно что-то посчитает, но качество результата будет непредсказуемым.
Если вы в поисках успешных практик ценообразования - от аудита "серых зон" до построения управляемых процессов и масштабирования - команда Imprice открыта к диалогу и обмену опытом. .
Хотите понять, какой потенциал скрыт в вашем ценообразовании?
Проведем аудит и поможем найти точки роста