Распределение товара по складам и магазинам : Реальные задачи по закупкам

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

Добрый день!

Согласен, что здесь поторопился. Приношу извинения за доставленные неудобства. :)

Все зависит от степени автоматизации и понимания, в том числе руководством компании к чему это может привести. Ссылку на корректировку статистики Андрей уже дал.

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

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

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

4. Я уже предложил VEN + сезонная декомпозиция (ARIMA, ну или с возможностью добавления внешних факторов, которая стала набирть моду ARIMAX)
5. Я так понимаю, Вы хотели сказать, что если товар не лекарство, тогда влияет. Спасибо за замечание. Согласен, действительно, аптеки в последнее время занимаются не только дистрибуцией лекарств, но и косметики и др. товаров. Я рассматривал классическую аптеку. Тогда, с учетом Вашего замечания, логично было бы дифференцировать подход. Для лекарства один подход, для косметики и прочих товаров другой.

Для борьбы с пиками и выбросами применяют экспоненциальное сглаживание (1,2,3 порядка), чем выше порядок, тем больше сглаживаются выбросы. Эти возможности реализованы в любом нормальном статистическом пакете. Например, IBM SPSS, дорогой только, но если есть несколько сот тысяч рублей, то лучше, на мой взгляд нет. SAS может потягаться, но еще больше проиграет по цене.

Во-первых, экспоненциальное сглаживание применяется в основном для прогнозирования.
Во-вторых, при таком сглаживании по классическим формулам, сглаженный ряд перемещается вправо, поэтому если занимаетесь сезонным товаром, есть все шансы не успеть затовариться к началу сезона, и потерять при этом львиную долю прибыли. Уверен, что руководство за это по головке не погладит, а турнёт с позором и невыплатой "кровных", и правильно сделает. Можно, конечно, преобразовать формулы так, чтобы сглаженный ряд не убегал, но для этой цели больше подходит обычное скользящее среднее с лагом 1 "в обе стороны" с необходимым количеством итераций.
В третьих, самый проверенный способ борьбы с пиками и выбросами (если с ними вообще нужно бороться, в чем я сомневаюсь), это отсечение 1-3% максимальных заказов.
Чтобы данные приносили пользу на практике, а не в теории, любая разработка должна быть интегрирована либо с корпоративной системой учета, либо с рабочей СУБД. Проще с СУБД. А вы пробовали интегрировать такой статистический пакет с какой-нибудь СУБД? Это далеко не так просто, как кажется. И самое главное: ради чего? Ради того, чтобы целый стат. пакет, стоимостью несколько сот тысяч рублей, сгладил данные по примитивным формулам для первого курса универа? Так не проще ли и не дешевле ли бесплатно написать SQL-запрос, который бы это сглаживание сделал? Да и формулу, по которой сглаживает, можно любую воткнуть.

Добрый вечер!
Мне как раз очень интересен данный момент, я даже создал отдельную тему "Корректировка статистики продаж по дефициту и пикам". Не могли бы Вы в той теме, которую я создал для этого вопроса, показать пример корректировки статистики продаж по Вашему алгоритму. Желательно сделать его на примере тех данных, которые уже выложены - так мне будет проще разобраться. Ну и конечно интересует подробный алгоритм всех действий (приблизительно так как это описал Андрей или Валерий) для возможности автоматизации данного процесса в учетной системе, т.к. выгружать статистику по каждой отдельной позиции во внешнюю программу не разумно с позиции затрат времени и сил.
Буду благодарен!

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

SPSS практически бесшовно интегрируется с Excel -таблицами, крупнейшими СУБД, он их видит также как Вы можете видеть структуру таблиц в MS SQL, в т.ч. SAS таблицы может использовать в качестве источника данных.
Не просто, когда у Вас под несколько тысяч товарных категорий, писать SQL-запросы для сглаживания пиков, сегментации, глубинного анализа данных. Чего уж там, можно и модуль по Data mining-у закачать и обрабатывать данные с помощью запросов. Так разобраться, все можно сделать руками. Можно и количество людей увеличить и платить им все те же несколько сот тысяч рублей, а можно один раз потратится, но сделать нормальную масштабируемую систему. А MS SQL тоже имеет свои пределы, нет не по объему, а по времени обработки инфо. Если бы Вы работали в wall marte, я очень бы хотел посмотреть как Вы на MS SQL это поднимали. :D

Костыли прикручивать?
Скользящее среднее с лагом 1 при единственной итерации в обе стороны немного сгладит ряд, но гармоники останутся на своих местах. Да, они уменьшатся на 5-10%, но по крайней мере не убегут, и на качество прогнозирования это существенно не повлияет.

Мудро, конечно, систему планирования делать в Excel, ну да ладно, насчет SPSS: это пакет для ученых, а не для бизнеса. В него входят тысячи функций, которыми пользователь ни разу не воспользуется. Странно, что такой серьезный пакет столько лет обходился без алгоритмов машинного обучения (нейросетей). Они появились в нем недавно, в других продуктах намного раньше, поэтому SPSS и потерял свои некогда сильные позиции.


А каким образом количество товарных категорий, да и вообще данных, связано со сложностью SQL-запросов? Разве что индекс кинуть на таблицы не забыть, на этом сложность и заканчивается. Запрос на сегментацию не сложен, а вот про "глубинный анализ данных" не слышал. Просвятите?
Вы правы: руками можно сделать все, если они не кривые и растут откуда надо.


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

По скорости обработки MS SQL уступает Ораклу, и естественно лучше, когда OLTP система опирается на Оракл. Но мы говорим не про OLTP, а про системы аналитики (процессы ETL), основная нагрузка для которых обычно происходит по ночам, и быстродействие здесь второстепенно.

fsecrets.ru, добрый день!
А зачем так усложнять, если короткие периоды "закзаз-поставка" и "заказ-заказ"? И зачем использовать внешние факторы: кто их в торговом предприятии будет отбирать и поддерживать? Можете модель выложить в Excel с открытыми формулами?

2 KaPrAL
Да, все верно излагаете, только есть минусы: один сотрудник не сможет с помощью SQL прикручивать и пересчитывать модели прогнозирования, например по 1000 товарных категорий по каждой точке реализации в отдельности, если их хотя бы пару тыс. Можно конечно реализовать простенькие алгоритмы на все случаи жизни и дуть щеки, что все и так хорошо работает, не оптимизируя модели.

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

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

Нейронные сети???? Честно - хорошая шутка, вот Вы мне скажите, Вы используете нейронные сети? Я тоже нет для прогнозирования. Логично применять для клиентской аналитики и прогнозирования определенных событий, но это практически "черный ящик".

Глубинный анализа данных = data mining