Планирование продаж категории

[igorekvarus]

Всем доброго дня !
Бьюсь над вопросом кооректного планирования по категориям товаров для сети супермаркетов. Сейчас план считается на основании динамики прошлого года (месяц к месяцу) и наложения этой динамики на текущий период. Погрешности в основном 10-15%, на некоторых группах - до 40%. Меня такие цифры абсолютно неустраивают - тем более что мотивация привязана к выполнению этих показателей для каждого категорийщика.
Поделитесь опытом - кто как считает? какую погрешность считать нормальной?

[KaPrAL]

Бьюсь над вопросом корректного планирования по категориям товаров для сети супермаркетов. Сейчас план считается на основании динамики прошлого года (месяц к месяцу) и наложения этой динамики на текущий период. Погрешности в основном 10-15%, на некоторых группах - до 40%. Меня такие цифры абсолютно не устраивают.
Поделитесь опытом - кто как считает?

Алгоритмы различаются в зависимости от вида товарных групп: если в пределах группы товары частично или полностью взаимозаменяемы, то используется подход "сверху-вниз": вычисляется план по товарной группе, и для каждого товара из этой группы вычисляется параметр k в модели взвешенной линейной регрессии (k*x+b) с b=0, затем план по каждому товару находится умножением соответствующего k на план всей группы. Для этого подхода, на этапе нахождения плана всей группы учитываются и обрабатываются периоды дефицита группы в целом.

Если же в пределах группы товары не взаимозаменяемы, то используется подход "внизу-вверх": сначала очищается статистика продаж каждого товара в отдельности,затем прогноз находится либо по каждой позиции отдельно, либо применяются алгоритмы нормировки для нахождения поведения всей товарной группы. Затем это "поведение" прогнозируется, и для каждого товара из этой группы вычисляется параметр k в модели взвешенной линейной регрессии (k*x+b) с b=0, затем план по каждому товару находится умножением соответствующего k на план "поведения" всей группы. Для этого подхода, учитываются и обрабатываются периоды дефицита каждого товара.

какую погрешность считать нормальной?

Ту, которая Вас устраивает.

[igorekvarus]

Логически понятно, но как технически это быстро реализовать? 70 групп (около 500 категорий)? Особенно при расчете снизу-вверх. Плюс большое количество групп на которые влияют внешние факторы (погода, цена, ажиотажный спрос и т.д.) Как это все учесть?

[KaPrAL]

Логически понятно, но как технически это быстро реализовать?

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

как технически это быстро реализовать?

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

70 групп (около 500 категорий)?

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

Плюс большое количество групп на которые влияют внешние факторы (погода, цена, ажиотажный спрос и т.д.) Как это все учесть?

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

[igorekvarus]

А можно по конкретнее про специализированое програмное обеспечение для планирования? Т.е. если я правильно понимаю одним Excel здесь и близко не обойтись?
На счет торговых точек - 100% то же правильное замечание - колличество растет и у каждой своя специфика.

[igorekvarus]

Презентацию просмотрел. Достойный материал. Кто занимался внедрением и сопровождением этого проэкта. Как это ПО работает с другими учетными системами - 1С, Спрут? Какие еще есть возможности?

[KaPrAL]

А можно по конкретнее про специализированое програмное обеспечение для планирования?

У Валеры и у Стаса хорошие обзоры ПО для планирования.

Т.е. если я правильно понимаю одним Excel здесь и близко не обойтись?

Ну почему же? Если модель упростить, то можно справиться и Excel-ем. Только трудозатрат на ежедневное обновления данных потребуется больше.

Презентацию просмотрел. Достойный материал.

Спасибо.

Кто занимался внедрением и сопровождением этого проекта.

Если это вопрос, то разработкой, внедрением и сопровождением занимаюсь я.

Как это ПО работает с другими учетными системами - 1С, Спрут? Какие еще есть возможности?

ПО работает не с учетными системами, а напрямую с СУБД MS SQL Server, поэтому если Ваша учетная система базируется на этой СУБД, Вы можете использовать проект бесплатно. Новая версия появится уже скоро, но готового решения для розницы у меня пока нет, т.к. не было в этом необходимости.

[igorekvarus]

А можно по конкретнее про специализированое програмное обеспечение для планирования?

У Валеры и у Стаса хорошие обзоры ПО для планирования.

[/quote]

Сейчас посмотрим

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

[/quote]


А здесь у меня вопрос о "ежедневном обновлении данных". О каких конкретно данных идет речь? Т.е. например для корректного составления прогноза НУЖНЫ:
1.)Динамика продаж категории, в шт и ден. выражении в разрезе конкретных наименований (какая периодичность? -по месяцам, неделям, дням)
2. Динамика изменения цены в разрезе конкретных наименований
3. Анализ дефицитов за прошлые периоды
Или есть еще что нибудь?

p.s А как учесть изменение покупательских предпочстений - например переход на более низкий ценовой сегмент (в шт покупают столько-же а в деньгах прироста нет)?

[KaPrAL]

А здесь у меня вопрос о "ежедневном обновлении данных". О каких конкретно данных идет речь? Т.е. например для корректного составления прогноза НУЖНЫ:
1.)Динамика продаж категории, в шт и ден. выражении в разрезе конкретных наименований (какая периодичность? -по месяцам, неделям, дням)

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

2. Динамика изменения цены в разрезе конкретных наименований

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

3. Анализ дефицитов за прошлые периоды

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

p.s А как учесть изменение покупательских предпочстений - например переход на более низкий ценовой сегмент (в шт покупают столько-же а в деньгах прироста нет)?

Увидеть эти и другие закономерности помогает удобная отчетность.

[igorekvarus]

А здесь у меня вопрос о "ежедневном обновлении данных". О каких конкретно данных идет речь? Т.е. например для корректного составления прогноза НУЖНЫ:
1.)Динамика продаж категории, в шт и ден. выражении в разрезе конкретных наименований (какая периодичность? -по месяцам, неделям, дням)

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

Т.е. мне чтобы посчитать прогноз на следующий месяц например по группе "коньяк" нужны продажи за предыдущие периоды (аналогичные месяца прошлого года по дням в разрезе брендов и наименований + предыдущий месяц этого года опять же по дням)? А как быть с новыми брендами - которых не было в прошлом году? наложить на них среднюю регрессию всей группы (k*х)+b

Увидеть эти и другие закономерности помогает удобная отчетность.

[/quote]
Какая например?

[KaPrAL]

А как быть с новыми брендами - которых не было в прошлом году? наложить на них среднюю регрессию всей группы (k*х)+b

За новинку возьмем SKU, тогда для нахождения прогноза по ней при отсутствии статистики продаж:

1) Если новинка принадлежит "рабочей" товарной группе, и не сильно отличаются от какого-то товара в этой группе по свойствам и цене, то новинку считаем аналогом этого товара, и суммируем показатели.
2) Если новинка принадлежит "рабочей" товарной группе и умеренно отличается по свойствам и цене от наиболее близкого к ней товара из этой группы, то прогноз продаж новинки вычисляется из прогноза продаж этого наиболее близкого к ней товара простой пропорцией по цене. Аналогами эти товары не являются.
3) Если новинка принадлежит новой товарной группе, и сильно отличается по свойствам и цене от наиболее близкого к ней товара из всех групп, то для составления плана продаж используются внешние источники информации: конкуренты, таможня, исследования и пр.

Если статистика все-же есть, тогда да, используем линейную регрессию с b=0.

Увидеть эти и другие закономерности помогает удобная отчетность.

Какая например?

OLAP- это самая удобная отчетность, придуманная человечеством.

[KaPrAL]

Т.е. мне чтобы посчитать прогноз на следующий месяц например по группе "коньяк" нужны продажи за предыдущие периоды (аналогичные месяца прошлого года по дням в разрезе брендов и наименований + предыдущий месяц этого года опять же по дням)?

Да, если Вы используете прогнозы для составления заказов.
Прогноз с детализацией "Месяц" используется в рознице только для оценки долгосрочного финансового плана.

[stanley]

коллеги, я извиняюсь, можно специально для крайне неторопливого меня пояснить фишку насчет применения "регрессии с b=0"?
я напрочь не улавливаю нити рассуждений...

[KaPrAL]

коллеги, я извиняюсь, можно специально для крайне неторопливого меня пояснить фишку насчет применения "регрессии с b=0"?
я напрочь не улавливаю нити рассуждений...

Пусть, например, даны 2 вектора: X=(100; 120; 95; 97) и Y=(12; 14; 10; 11) и надо найти такое k, при котором Y=k*X+b (если b=0, то Y=k*X).
k можно найти по обычной формуле:
k=(100*12+120*14+95*10+97*11)/(100^2+120^2+ 95^2+97^2) = 0,114325, а можно по "взвешенной" по-времени (это мои мысли):
k=(100*12*0,25 + 120*14*0,5 + 95*10*0,75 + 97*11*1)/(100^2*0,25+120^2*0,5+ 95^2*0,75+97^2*1) = 0,112819

Смысл взвешенности- в добавлении весов, которые тем больше, чем новее данные.

[igorekvarus]

Спасибо за информацию. А по поводу ПО на основе OLAP - видел презентацию по Qlikview http://www.qlikview.com/ru. Кто нибудь знаком с этой программой? Если кто видел ее в работе? Есть ли другие аналоги для розницы?

[igorekvarus]

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

[KaPrAL]

Спасибо за информацию. А по поводу ПО на основе OLAP - видел презентацию по Qlikview http://www.qlikview.com/ru. Кто нибудь знаком с этой программой?

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

Есть ли другие аналоги для розницы?

Если для MS, то выбирайте. Лично мне больше нравится
Tableau, но использую свой OWC-клиент. Простенький, но с возможностями управления бэкапами и скулевыми отчетами.

[igorekvarus]

Есть ли другие аналоги для розницы?

Tableau, но использую свой OWC-клиент. Простенький, но с возможностями управления бэкапами и скулевыми отчетами.[/quote]

Разница в цене покупки, внедрения и сопровождения?

[KaPrAL]

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

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

Разница в цене покупки, внедрения и сопровождения?

Еще из отечественных разработок могу порекомендовать "детище" Игоря Бобака-Бит Импульс. Когда проект только запускался (в 2009-ом году), полная версия сервера предлагалась за 5000$, сейчас стоит около десятки, плюс по 150-200$ за каждого пользователя.
В цене разница не большая, по-сравнению с той же tableau.
Внедрение состоит из двух частей:
1) Создание кубов. Кубы создаются обычными сотрудниками средствами сервера БД: Oracle, MS SQL и пр. И просматривать их можно из Excel-ля.
2) Настройка приложения для просмотра. Обычно занимает не много времени: чем совершеннее приложение, тем быстрее оно настраивается.

А сопровождение в основном требует серверная часть, т.е. обязанности по сопровождению можно возложить на DBA, поддерживающего СУБД.

[stanley]

коллеги, я извиняюсь, можно специально для крайне неторопливого меня пояснить фишку насчет применения "регрессии с b=0"?
я напрочь не улавливаю нити рассуждений...

Пусть, например, даны 2 вектора: X=(100; 120; 95; 97) и Y=(12; 14; 10; 11) и надо найти такое k, при котором Y=k*X+b (если b=0, то Y=k*X).
k можно найти по обычной формуле:
k=(100*12+120*14+95*10+97*11)/(100^2+120^2+ 95^2+97^2) = 0,114325, а можно по "взвешенной" по-времени (это мои мысли):
k=(100*12*0,25 + 120*14*0,5 + 95*10*0,75 + 97*11*1)/(100^2*0,25+120^2*0,5+ 95^2*0,75+97^2*1) = 0,112819

Смысл взвешенности- в добавлении весов, которые тем больше, чем новее данные.

я в принципе еще помню, что такое регрессия, но вот это ставит меня в тупик:

Алгоритмы различаются в зависимости от вида товарных групп: если в пределах группы товары частично или полностью взаимозаменяемы, то используется подход "сверху-вниз": вычисляется план по товарной группе, и для каждого товара из этой группы вычисляется параметр k в модели взвешенной линейной регрессии (k*x+b) с b=0, затем план по каждому товару находится умножением соответствующего k на план всей группы. Для этого подхода, на этапе нахождения плана всей группы учитываются и обрабатываются периоды дефицита группы в целом.

[KaPrAL]

но вот это ставит меня в тупик:

Алгоритмы различаются в зависимости от вида товарных групп: если в пределах группы товары частично или полностью взаимозаменяемы, то используется подход "сверху-вниз": вычисляется план по товарной группе, и для каждого товара из этой группы вычисляется параметр k в модели взвешенной линейной регрессии (k*x+b) с b=0, затем план по каждому товару находится умножением соответствующего k на план всей группы. Для этого подхода, на этапе нахождения плана всей группы учитываются и обрабатываются периоды дефицита группы в целом.

Например, товарная группа "Белые сухие вина" состоит из двух артикулов А и В, помесячная динамика их спроса с января по май такова:
А(0; 12; 11; 13; 15), В(28; 35; 30; 32; 36) =>А+В(28; 47; 41; 45; 51).
1) Прогнозируем А+В, найдя линейный тренд и коэффициенты сезонности: А+В(28; 47; 41; 45; 51;55,6; 60; 64,4; 68,8; 73,2)
2) Для каждого товара из этой группы вычисляется параметр k в модели взвешенной линейной регрессии (k*x+b) с b=0:
Для "А": k_для_А=(12*47*0,25 + 11*41*0,5 + 13*45*0,75 + 15*51*1)/(47^2*0,25 + 41^2*0,5 + 45^2 *0,75 + 51^2*1)=0,284852608
Для "В": k_для_В=(28*28*0,2 + 35*47*0,4 + 30*41*0,6 + 32*45*0,8 + 36*51*1)/(28^2*0,2 + 47^2*0,4 + 41^2*0,6 + 45^2*0,8 + 51^2*1)=0,724210526
3) И получаем прогнозы: А=(15,84; 17,09; 18,34; 19,6; 20,85); В=(40,27; 43,45; 46,64; 49,83; 53,01)

[stanley]

ага, вектор k - доля в общем котле.
осталось проверить состоятельность взвешивания, что-то мне тут подозрительно...

[KaPrAL]

ага, вектор k - доля в общем котле.

Да, так и есть!

осталось проверить состоятельность взвешивания, что-то мне тут подозрительно...

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

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

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

[Роман Бодряков]

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

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

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

Через эту же схему можно аналоги от разных поставщиков отрабатывать.

[KaPrAL]

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

По аналогам уже объединяем переходящие года: например, "Анжу розовое 2008г", "Анжу розовое 2009г" и "Анжу розовое 2010г" объединяются на последнюю карточку, т.е. на "Анжу розовое 2010г", чтобы по ней сделать заказы.

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

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

Через эту же схему можно аналоги от разных поставщиков отрабатывать.

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

[Роман Бодряков]

Саша,
Прямые и однозначные наследники это просто и очевидно.

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

А как быть с твоим маслом Анжу 200, 300 и 400 мл?

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

Есть еще более интересные фишки.

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

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

[KaPrAL]

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

Отличная идея! Спасибо!

А как быть с твоим маслом Анжу 200, 300 и 400 мл?
Это будут разные, но взаимозаменяемые товары. Причем прямая заменяемость будет отличаться от обратной.

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

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

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

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

[Gromych]

Кстати сейчас у QlikView есть классные карты: http://biconsult.ru/products/qlikview-addons/geoqlik
И Tableau мы тоже занимаемся -
будет интерес - пишите grom@biconsult.ru или звоните +7-812-334-08-01
расскажем и покажем :)