«КОРУС Консалтинг» создал облачный сервис для прогнозирования спроса в ритейле и дистрибуции

[twilight]

Цитата:

Сообщение от Ivanhoe

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

А разве вендоры не загоняют сейчас всех в облака (и даже пробный бесплатный период у них тоже есть)? ) А разве ваше решение не использует модули от мировых вендоров? )
По-моему предыдущий ответ был лучше, про кубики, которые не только лишь каждый умеет складывать ))

[Ivanhoe]

Загонять-то загоняют. Только покажите готовое облачное решение от этих вендоров? А кто интересовался стоимостью SAP APO, Oracle RPAS и т.п. знает цены в десятки и даже сотни миллионов рублей...
Мы используем платформу Microsoft Azure и компоненты внутри нее и работаем именно в сервисной модели.

[AP-1055D]

Oracle RPAS за десятки миллионов рублей? Да ладно?

[ax_mct]

Цитата:

Сообщение от Ivanhoe

Мы используем платформу Microsoft Azure и компоненты внутри нее и работаем именно в сервисной модели.

А вот любопытно. Насколько вам технически просто уйти от Azure на AWS?
Степень вашей зависимости от сумашедшего вендора? Как фактор риска.

[Ivanhoe]

Возвращаюсь. Далее в нескольких постах привожу ответ от команды. "Мнение редакции" может не совпадать с мнением автора

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

[Ivanhoe]

Уважаемые участники форума! Спасибо за Ваши комментарии и вопросы.
Ниже ответы на наиболее интересные, с нашей точки зрения, вопросы.
Примечание: мы не ставим цель кого-то убедить или оспорить. Ниже указано наше видение, как профессионалов в области прогнозирования.

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

[Ivanhoe]

Запрос конкретики: понять сильные и слабые стороны решения.

1. Сильные стороны: Методология внедрения, стоимость, сроки внедрения. Специалисты находятся в России.

Что мы даем: разово забираем в облако исторические данные за 3 года, далее еженедельно автоматически забираем дельту на последнюю неделю. Далее рассчитываем прогноз спроса вида Товар-Магазин-День-Количество (спрос) на 4 недели вперед. Далее, автоматически загружаем в текущую систему Автозаказа клиента и заменяем прогноз, рассчитываемый ранее в этом Автозаказе. Далее, пополнение и формирование заказов работает так же, как и ДО нас. Нас это не касается. При этом Бизнес-процессы не меняются никак. Это обычное применение. Так же, мы считаем и отдаем страховые запасы по требованию клиента.

Наша методология внедрения:
Первый шаг методологии состоит в анализе текущей ситуации у ритейлера по уровню списаний товаров, уровню Out-of-Stock и затрат на хранение товаров.
Вторым шагом производится математическое моделирование улучшения этих бизнес-показателей при применении прогноза, рассчитанного в нашем сервисе.

Третьим шагом является пилот – доказательство экономического эффекта на выбранных пилотных магазинах ритейлера в течение одного месяца бесплатного использования.

В случае успеха всех трех шагов, клиенту предлагается далее использовать сервис на всех магазинах и товарах сети за ежемесячную оплату с выделенной линией поддержки экспертов КОРУС Консалтинг.

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

Ни одна конкурирующая с нами серьезная система прогнозирования (Oracle RPAS, JDA, SAP, SAS, Teradata) не дает такого быстрого результата, как мы. Поиск в Google в помощь тем, кому интересно узнать об этих система подробнее.

Стоимость: Oracle RPAS, JDA, SAP, SAS, Teradata – первоначальные инвестиции около 200 млн руб. У нас 0. Поддержка после внедрения - у нас цены сопоставимы с конкурентами. Итого, мы дешевле конкурентов на 200 млн первоначальных инвестиций. А результат даем лучше. В этом суть облачных сервисов в области прогнозирования и оптимизаций.

Сроки внедрения: у конкурентов 2 года. У нас 3 месяца.
Специалисты: у конкурентов их в России единицы. У нас есть сильная команда и она в России.

2 Слабые стороны: мы зависим от облачных вендоров.
Поэтому мы развиваемся в сторону кросс-платформенности (сервис есть уже на Microsoft Azure, и переносится сейчас на Oracle Cloud) + мы используем максимально, на сколько возможно, продукты мирового сообщества (Apache Hadoop и R), включенные в облака Microsoft и Oracle.

Далее, IT-шники от клиентов часто НЕ наши друзья. Обсуждать сервис мы хотим с собственником или CEO. С теми, кто про бизнес-эффект и деньги компании. На текущий момент есть определенные проблемы с IT-департаментами, но мы их планомерно преодолеваем. Конкурентам перечисленным сейчас проще – имя раскрученное.

[Ivanhoe]

3. Техническая сторона решения:


Тому, кто разбирается в облачных технологиях, картинка скажет всё. Тот, кто не разбирается, можете записаться на наши технические семинары от КОРУС Консалтинг (либо семинары от Microsoft по Azure, которые мы же и ведем для партнеров и клиентов по всей России) и мы научим. Кто приведет к нам клиента и контракт, договоримся о комиссии и сделаем бесплатное обучение облачным компонентам Azure и расскажем, что такое Cloud Pro и к какой переквалификации нужно готовиться в недалеком будущем. Знание, на мой взгляд, бесценное.

По алгоритмам: 12 математических алгоритмов (в том числе тяжелых и сложных), заложено в модель. Включая метод гусеницы, RandomForest и нейронные сети. На последнем семинаре мы показывали клиентам на практических примерах, где, в каких случаях при прогнозировании в ритейле что лучше работает. Пример, Нейронные сети лучше отрабатывают и «ловят» спрос во время промо. Но хуже себя показывают во время регулярных продаж, по сравнению со статистическими методами.
Наш сервис сам выбирает лучший метод, делая 250 млн проходов со всеми алгоритмами по всем пересечениям товарной и географической иерархии, по всем товарам и магазинам, используя все полученные данные о статистике и доступных внешних источников. И расчет длится 3 часа. И стоит дешево. Вот это мы и называем Большие Данные.=) Именно это и ни что иное. Тем, кто не в теме, и интересуется, советую читать Harvard Business Review, Tech Crunch, The Wall Street Journal, отчеты NewVantage, McKinzey, Gartner – темы, посвещенный Big Data. Либо хотя бы мою статью, Иван давал ссылку. Много интересного узнаете.

[Ivanhoe]

4. Алгоритм оценки экономической эффективности:
Реальный кейс:
Региональная сеть FOOD: 200 магазинов. Годовой оборот: 20 млрд в год.
Уровень списаний: 0,5% от оборота
Затраты на хранение: 1% от оборота (стоимость денег взята 1% в месяц от закупочной цены). Больше ничего не учитывали – не требуется ни нам, ни заказчику.
Упущенные продажи: 1,5% от оборота.
Итого потери: 3% от оборота.

За счет нашего сервиса мы уменьшили эти 3% на 15%, то есть дали 0.5% от оборота. И подобную картину мы видим типичной для FOOD-ритейла. В итоге, для упрощения, мы заявляем именно такую цифру на старте. Экономия 15% от текущих потерь от списаний и OOS и затрат на хранение, считаемых, как я написал выше. У бизнеса это обычно не вызывает никаких вопросов.


Алгоритм оценки точности прогноза - на картинке. Считать надо так, и никак иначе. Все остальные варианты - мы в них не верим.


Наша средняя точность прогнозирования на уровне SKU-Магазин 70%. Это очень хороший результат. Он проверен на нескольких заказчиках. И лучше, чем у всех конкурентов.

[Ivanhoe]

5. Ответы на некоторые вопросы.

Зачем нужны чеки в модели прогнозирования?
Чеки нужны для более точной очистки исторических данных от аутлайеров. Сглаживание нетипичных событий с учетом чеков более правильное и точное, чем на основании продаж за день. Пример: пришла китайская мама-турист и купила 15 упаковок подгузников (а обычно продавалось по 2-3 в день в среднем). Явный аутлайер, очищается.
Далее, пришли люди и накупили 15 упаковок (обычно продается по 2-3). Чистим историю более аккуратно. Возможно, есть какой-то тренд. Это заложено в
модель и работает автоматически.
С продажами на конец дня (z-отчет), вы никогда не поймете, что было тут с продажами. А с чеками поймете.


Зачем нужен почасовой прогноз?
Мы не делаем почасовой прогноз. Мы делаем прогноз раз в неделю. Табличка вида: товар-магазин-день-количество. На 4 недели вперед. По всем товарам и магазинам сети.

Зачем нужно прогнозирование на уровне SKU?
Потому что нужно прогнозировать конкретные SKU в активной ассортиментной матрице магазинов ритейлера. Это прописная истина и странный для меня вопрос. Даже не знаю, что еще можно тут ответить. Потому что так надо.=)
Мало-оборачиваемые товары можно не прогнозировать, а пополнять по min-max. Это вопрос требований клиента.

Вопрос про бизнес-процесс прогнозирования + ассортиментного планирования.
С процессом, описанным в сообщении Nordic не согласен («КОРУС Консалтинг» создал облачный сервис для прогнозирования спроса в ритейле и дистрибуции). Он не эффективный для ритейла. Моя профессиональная точка зрения. С Nordic при встрече готов обсудить то, как я вижу правильный процесс ассортиментного планирования, планирования промо и как туда встраивается прогнозирование спроса и пополнение. Совсем не туда, куда прогнозирование встроил Nordic. При всём уважении. =)

[Ivanhoe]

Конец ответа команды

[sukhanchik]

Ivanhoe - низкий поклон и большое спасибо за столь подробное описание!

[AP-1055D]

Ivanhoe, спасибо, однако,

Он проверен на нескольких заказчиках. И лучше, чем у всех конкурентов.
Насколько лучше? С кем именно вы сравнивали? Означает ли это, что ваши инвестиции на сравнение были больше 200 миллионов рублей потому что:

Oracle RPAS, JDA, SAP, SAS, Teradata – первоначальные инвестиции около 200 млн руб

Я более чем уверен, что Oracle RPAS как и другие продукты не требуют таких инвестиций на этапе ознакомления или пилота. Тем более, я очень сильно сомневаюсь в стоимости. Ну и сравнение с Терадатой как минимум некорретное: она продаётся как программно-аппаратный комплекс, а не как отдельное решение, например, для прогнозирования.

Специалисты: у конкурентов их в России единицы. У нас есть сильная команда и она в России.

Вы не поверите, но у Оракла, САСа, Терадаты тоже есть сильные команды в Москве.

В любом случае, когда говорят, что

Итого, мы дешевле конкурентов на 200 млн первоначальных инвестиций. А результат даем лучше

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

[Ivanhoe]

Мы внедряем эти продукты и понимаем уровень цен. И сравнивать, конечно, нужно полную стоимость Проекта - включая железо, лицензии, подписки на ПО и не только Пилот.

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

[svcoder]

Что-то я совмеваюсь в успешности данного сервиса:
Вы просите данные за 3 года, но за это время ассортиментная матрица может поменяться несколько раз. Кроме того у FMCG-сегмента нет цели поставлять определенный набор SKU длительное время, главное заполнить ассортиментную матрицу с максимальной маржой для себя. А покупатель тоже ведет себя по разному:
1. При исчезновении определенных SKU методом проб и ошибок начинает покупать другой.
2. Есть товары, точный SKU которых абсолютно не важен для покупателя. Например горький шоколад - если идет в выпечку, без разницы какой это будет производитель.
3. SKU которые будут куплены либо либо в точности такие, либо никакие - например средства личного ухода, особенно женские. Для таких товаров система может правильно работать, но их очень мало
Поэтому я тут соглашусь с George Nordic, что чтобы что-то по настоящему спрогнозировать нужно построить нехилую модель потребления для каждой группы товаров в отдельности. А самое главное - какой в этом смысл, если опытный категорийный менеджер с помощью пары формул достаточно точно спрогнозирует потребление известной ему продукции на месяц вперед.

[ax_mct]

Цитата:

Сообщение от svcoder

Что-то я совмеваюсь в успешности данного сервиса:
Вы просите данные за 3 года, но за это время ассортиментная матрица может поменяться несколько раз. Кроме того у FMCG-сегмента нет цели поставлять определенный набор SKU длительное время, главное заполнить ассортиментную матрицу с максимальной маржой для себя. А покупатель тоже ведет себя по разному:
1. При исчезновении определенных SKU методом проб и ошибок начинает покупать другой.
2. Есть товары, точный SKU которых абсолютно не важен для покупателя. Например горький шоколад - если идет в выпечку, без разницы какой это будет производитель.
3. SKU которые будут куплены либо либо в точности такие, либо никакие - например средства личного ухода, особенно женские. Для таких товаров система может правильно работать, но их очень мало
Поэтому я тут соглашусь с George Nordic, что чтобы что-то по настоящему спрогнозировать нужно построить нехилую модель потребления для каждой группы товаров в отдельности. А самое главное - какой в этом смысл, если опытный категорийный менеджер с помощью пары формул достаточно точно спрогнозирует потребление известной ему продукции на месяц вперед.

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

Думаю что можно и нужно рассчитывать на уровне SKU но при этом реализовывать логику замены товара на альтернативный на стороне конечной системы.

C другой стороны согласен что группировка на уровне расчета важна так как один и тот же товар может иметь разное SKU в силу привязки к поставщику, а не из-за отличий. К примеру 50 SKU свиных сосисек которые идентичны. Эти 50 поставщиков в сумме покрывают потребность. Где разумнее реализовывать альтернативность/общность - в прогнозе или при создании заказов, не знаю.

Вопрос как будет работать модель для "50 SKU свиных сосисек которые идентичны"?

[ena_ax]

Вы правда верите что все свиные сосиски идентичны?

[potential]

Цитата:

Сообщение от Ivanhoe

Явный аутлайер, очищается.

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

[AlGol]

Цитата:

Сообщение от ena_ax

Вы правда верите что все свиные сосиски идентичны?

Для того, чтобы покормить уличного кота - абсолютно неотличимы.

[Ivanhoe]

Цитата:

Сообщение от svcoder

Что-то я совмеваюсь в успешности данного сервиса:
Вы просите данные за 3 года, но за это время ассортиментная матрица может поменяться несколько раз. Кроме того у FMCG-сегмента нет цели поставлять определенный набор SKU длительное время, главное заполнить ассортиментную матрицу с максимальной маржой для себя. А покупатель тоже ведет себя по разному:

Всё верно Мы учитываем статистику и SKU, и категории. Дальше если статистика по SKU не достаточная или статистически не значимая используется статистика категории, а вес внутри считается по отдельному алгоритму: продажи за последний период (3 месяца) или явная связь с товаром-аналогом или товаром-заменителем, указанными в мастер-данных.

Но в итоге мы даем прогноз конкретного SKU.