[ОТВЕТИТЬ]
Опции темы
02.03.2011 12:45  
KaPrAL
Цитата:
Сообщение от fsecrets.ru
...А если исходить из предложенного Вами метода (когда мы считаем объем товара, продаваемого в среднем за день, если я правильно понял из Вашего поста) и умножаем на период, который закупщик посчитал каким-то экспертным путем, возможно исходя из некой тестовой партии, то может возникнуть тот же самый дефицит или профицит, если Вы среднее посчитали за "горячий" сезон.
Во-первых, если товары взаимозаменяемые, но не аналоги, то корректировку по дефициту делать не нужно.
Во-вторых, лучше, если при проведении корректировки по дефициту, пропорция дней умножалась не на среднюю продажу за день за весь период, а на среднюю продажу за день за последние 2-3 месяца, тем самым мы частично учтем сезонность.
В-третьих, если интервал отсутствия достаточного количества превышает 2-3 месяца, то пропорцией невозможно воспользоваться, поэтому спрос за этот период принимаем равным прогнозу продаж.
 
02.03.2011 14:59  
VVY
Добрый день!

Цитата:
Сообщение от fsecrets.ru
Понимаю Вадим, почему Вы оставили такой комментарий в блоге, потому что Вы практически не читаете то, что пишут другие. ;)
См. вопрос
1. Ответ на него дал в первом посте топикстартер.
Согласен, что здесь поторопился. Приношу извинения за доставленные неудобства. :)

Цитата:
Сообщение от fsecrets.ru
2. Я согласен с коллегой, когда возникает дефицит, действительно может, время простоя полки не оценивается.
Все зависит от степени автоматизации и понимания, в том числе руководством компании к чему это может привести. Ссылку на корректировку статистики Андрей уже дал.

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

Цитата:
Сообщение от fsecrets.ru
4. На этот вопрос давал ответ Administrator и тут коллега тоже пропустил пост. Но это не учитывает п.3.
Существует множество подходов к этому вопросу, поэтому и задал вопрос. Если у Вас есть, что добавить, то прошу написать какой подход использовали бы Вы.

Цитата:
Сообщение от fsecrets.ru
5. Нейтрально, на мой взгляд в аптеках мало влияют, потому как большинство покупок там совершаются по рекомендациям или рецептам, никто красивую упаковку не хватает.
Также позволю с Вами не согласится по-этому вопросу. Однозначно не понятно какой товар преобладает: рецептурный или не рецептурный.
Если есть не рецептурный товар и свободная выкладка, то на коррекцию заказа этот момент повлияет значительно.
 
02.03.2011 21:22  
fsecrets.ru
4. Я уже предложил VEN + сезонная декомпозиция (ARIMA, ну или с возможностью добавления внешних факторов, которая стала набирть моду ARIMAX)
5. Я так понимаю, Вы хотели сказать, что если товар не лекарство, тогда влияет. Спасибо за замечание. Согласен, действительно, аптеки в последнее время занимаются не только дистрибуцией лекарств, но и косметики и др. товаров. Я рассматривал классическую аптеку. Тогда, с учетом Вашего замечания, логично было бы дифференцировать подход. Для лекарства один подход, для косметики и прочих товаров другой.
 
02.03.2011 21:25  
fsecrets.ru
Для борьбы с пиками и выбросами применяют экспоненциальное сглаживание (1,2,3 порядка), чем выше порядок, тем больше сглаживаются выбросы. Эти возможности реализованы в любом нормальном статистическом пакете. Например, IBM SPSS, дорогой только, но если есть несколько сот тысяч рублей, то лучше, на мой взгляд нет. SAS может потягаться, но еще больше проиграет по цене.
 
02.03.2011 22:45  
KaPrAL
Цитата:
Сообщение от fsecrets.ru
Для борьбы с пиками и выбросами применяют экспоненциальное сглаживание (1,2,3 порядка), чем выше порядок, тем больше сглаживаются выбросы.
Во-первых, экспоненциальное сглаживание применяется в основном для прогнозирования.
Во-вторых, при таком сглаживании по классическим формулам, сглаженный ряд перемещается вправо, поэтому если занимаетесь сезонным товаром, есть все шансы не успеть затовариться к началу сезона, и потерять при этом львиную долю прибыли. Уверен, что руководство за это по головке не погладит, а турнёт с позором и невыплатой "кровных", и правильно сделает. Можно, конечно, преобразовать формулы так, чтобы сглаженный ряд не убегал, но для этой цели больше подходит обычное скользящее среднее с лагом 1 "в обе стороны" с необходимым количеством итераций.
В третьих, самый проверенный способ борьбы с пиками и выбросами (если с ними вообще нужно бороться, в чем я сомневаюсь), это отсечение 1-3% максимальных заказов.
Цитата:
Сообщение от fsecrets.ru
Эти возможности реализованы в любом нормальном статистическом пакете. Например, IBM SPSS, дорогой только, но если есть несколько сот тысяч рублей, то лучше, на мой взгляд нет. SAS может потягаться, но еще больше проиграет по цене.
Чтобы данные приносили пользу на практике, а не в теории, любая разработка должна быть интегрирована либо с корпоративной системой учета, либо с рабочей СУБД. Проще с СУБД. А вы пробовали интегрировать такой статистический пакет с какой-нибудь СУБД? Это далеко не так просто, как кажется. И самое главное: ради чего? Ради того, чтобы целый стат. пакет, стоимостью несколько сот тысяч рублей, сгладил данные по примитивным формулам для первого курса универа? Так не проще ли и не дешевле ли бесплатно написать SQL-запрос, который бы это сглаживание сделал? Да и формулу, по которой сглаживает, можно любую воткнуть.
 
02.03.2011 22:48  
Anatoly
Цитата:
Сообщение от fsecrets.ru
Для борьбы с пиками и выбросами применяют экспоненциальное сглаживание (1,2,3 порядка), чем выше порядок, тем больше сглаживаются выбросы.
Добрый вечер!
Мне как раз очень интересен данный момент, я даже создал отдельную тему "Корректировка статистики продаж по дефициту и пикам". Не могли бы Вы в той теме, которую я создал для этого вопроса, показать пример корректировки статистики продаж по Вашему алгоритму. Желательно сделать его на примере тех данных, которые уже выложены - так мне будет проще разобраться. Ну и конечно интересует подробный алгоритм всех действий (приблизительно так как это описал Андрей или Валерий) для возможности автоматизации данного процесса в учетной системе, т.к. выгружать статистику по каждой отдельной позиции во внешнюю программу не разумно с позиции затрат времени и сил.
Буду благодарен!
 
03.03.2011 09:10  
fsecrets.ru
Цитата:
Сообщение от KaPrAL
Во-первых, экспоненциальное сглаживание применяется в основном для прогнозирования.
Во-вторых, при таком сглаживании по классическим формулам, сглаженный ряд перемещается вправо, поэтому если занимаетесь сезонным товаром, есть все шансы не успеть затовариться к началу сезона, и потерять при этом львиную долю прибыли. Уверен, что руководство за это по головке не погладит, а турнёт с позором и невыплатой "кровных", и правильно сделает. Можно, конечно, преобразовать формулы так, чтобы сглаженный ряд не убегал, но для этой цели больше подходит обычное скользящее среднее с лагом 1 "в обе стороны" с необходимым количеством итераций.
Возможно скользящее среднее будет лучше работать, тут надо свои шишки набивать. Если знаете, что вправо убегает, сдвигайте на то, количество единиц, которое необходимо, чтобы не убегал. Скользящее среднее по всему ряду усреднит все показатели. В этом случае точно не погладит.

Цитата:
Сообщение от KaPrAL
Чтобы данные приносили пользу на практике, а не в теории, любая разработка должна быть интегрирована либо с корпоративной системой учета, либо с рабочей СУБД. Проще с СУБД. А вы пробовали интегрировать такой статистический пакет с какой-нибудь СУБД? Это далеко не так просто, как кажется. И самое главное: ради чего? Ради того, чтобы целый стат. пакет, стоимостью несколько сот тысяч рублей, сгладил данные по примитивным формулам для первого курса универа? Так не проще ли и не дешевле ли бесплатно написать SQL-запрос, который бы это сглаживание сделал? Да и формулу, по которой сглаживает, можно любую воткнуть.
SPSS практически бесшовно интегрируется с Excel -таблицами, крупнейшими СУБД, он их видит также как Вы можете видеть структуру таблиц в MS SQL, в т.ч. SAS таблицы может использовать в качестве источника данных.
Не просто, когда у Вас под несколько тысяч товарных категорий, писать SQL-запросы для сглаживания пиков, сегментации, глубинного анализа данных. Чего уж там, можно и модуль по Data mining-у закачать и обрабатывать данные с помощью запросов. Так разобраться, все можно сделать руками. Можно и количество людей увеличить и платить им все те же несколько сот тысяч рублей, а можно один раз потратится, но сделать нормальную масштабируемую систему. А MS SQL тоже имеет свои пределы, нет не по объему, а по времени обработки инфо. Если бы Вы работали в wall marte, я очень бы хотел посмотреть как Вы на MS SQL это поднимали. :D
 
03.03.2011 10:47  
KaPrAL
Цитата:
Сообщение от fsecrets.ru
Если знаете, что вправо убегает, сдвигайте на то, количество единиц, которое необходимо, чтобы не убегал.
Костыли прикручивать?
Цитата:
Сообщение от fsecrets.ru
Скользящее среднее по всему ряду усреднит все показатели. В этом случае точно не погладит.
Скользящее среднее с лагом 1 при единственной итерации в обе стороны немного сгладит ряд, но гармоники останутся на своих местах. Да, они уменьшатся на 5-10%, но по крайней мере не убегут, и на качество прогнозирования это существенно не повлияет.

Цитата:
Сообщение от fsecrets.ru
SPSS практически бесшовно интегрируется с Excel -таблицами, крупнейшими СУБД, он их видит также как Вы можете видеть структуру таблиц в MS SQL, в т.ч. SAS таблицы может использовать в качестве источника данных.
Мудро, конечно, систему планирования делать в Excel, ну да ладно, насчет SPSS: это пакет для ученых, а не для бизнеса. В него входят тысячи функций, которыми пользователь ни разу не воспользуется. Странно, что такой серьезный пакет столько лет обходился без алгоритмов машинного обучения (нейросетей). Они появились в нем недавно, в других продуктах намного раньше, поэтому SPSS и потерял свои некогда сильные позиции.


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


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

Цитата:
Сообщение от fsecrets.ru
А MS SQL тоже имеет свои пределы, нет не по объему, а по времени обработки инфо. Если бы Вы работали в wall marte, я очень бы хотел посмотреть как Вы на MS SQL это поднимали. :D
По скорости обработки MS SQL уступает Ораклу, и естественно лучше, когда OLTP система опирается на Оракл. Но мы говорим не про OLTP, а про системы аналитики (процессы ETL), основная нагрузка для которых обычно происходит по ночам, и быстродействие здесь второстепенно.
 
03.03.2011 15:24  
VVY
fsecrets.ru, добрый день!
Цитата:
Сообщение от fsecrets.ru
4. Я уже предложил VEN + сезонная декомпозиция (ARIMA, ну или с возможностью добавления внешних факторов, которая стала набирть моду ARIMAX)
А зачем так усложнять, если короткие периоды "закзаз-поставка" и "заказ-заказ"? И зачем использовать внешние факторы: кто их в торговом предприятии будет отбирать и поддерживать? Можете модель выложить в Excel с открытыми формулами?
 
03.03.2011 21:39  
fsecrets.ru
2 KaPrAL
Да, все верно излагаете, только есть минусы: один сотрудник не сможет с помощью SQL прикручивать и пересчитывать модели прогнозирования, например по 1000 товарных категорий по каждой точке реализации в отдельности, если их хотя бы пару тыс. Можно конечно реализовать простенькие алгоритмы на все случаи жизни и дуть щеки, что все и так хорошо работает, не оптимизируя модели.

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

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

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

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


Опции темы



Часовой пояс GMT +3, время: 14:38.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.