[ОТВЕТИТЬ]
09.02.2011 21:25
Закупщик56127
 
Добрый вечер!

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

Вот напишу, как делал наш директор и как я это понимала.
Может это поможет меня правильно направить.

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

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

Я понимаю, что как было раньше с кремами - это все "пальцем в небо".

Спасибо за ответ.
10.02.2011 04:26
andrey_f
 
Анна, здравствуйте.

Цитата:
АннаАнна Заказы формировались и распределялись с учетом статистических данных и динамики продаж, н-р - если на филиале было 10 шт и все они продались, то в следующий раз отправят 11.
если было 5 шт, а продалось 4, то добавят до заказа только 4.
Как здесь предугадать - 11 это не мало, а 4 это не много? (товар крема)
И естественно распределяли товар исходя из опыта - По-сезонности. (н-р летом-больше солнцезащитной серии, а зимой ее вообще не брали).
Описанная Вами логика возможна, т.е. она видна и это лучше, чем отправлять товар вообще без каких либо расчетов наугад. Для того, чтобы оценить потребность филиала необходимо проанализировать не только продажи, но и наличие товара. Делим продажи на дни наличия - получаем скорость продаж. Исходя из скорости продаж и периода доставки (возможно еще вместимости) получаем количество товара, необходимое для продаж без дефицита.

Цитата:
АннаАнна Сейчас товар - лекарственные препараты.
Формируется и распределяется товар с центрального склада в филиалы (а уже сами филиалы распределяют по аптекам).
Как красиво и правильно провести анализ оборачиваемости и уровня товарных запасов на складах,
анализ недостатка и избытка по товарным позициям, сформировать заказ и распределить товар.
В данном случае получаем трехуровневую систему. Позволю себе назвать ее именно так. Одноуровневая система - прямые заказы поставщикам на каждый магазин. Двухуровневая система - заказ на склад каждого филиала, а затем распределение по магазинам (общий запас сокращается). Трехуровневая система - заказ на РЦ, затем распределение по складам филиалов, а затем по магазинам (общий запас так же снижается).
Кстати, я в в последних двух предложения изложил содержание книги Голдратта "Я так и знал! Теория ограничений для розничной торговли", в которой идет речь о преимуществах централизации заказов и распределения. :)
Так вот, в Вашем случае при распределении с РЦ на склады филиалов нужно оценивать потребность всех магазинов данного филиала. Т.е. если товар был на складе филиала постоянно, но при этом в магазинах был дефицит, то понятно, что текущие продажи не отражают реального спроса на товар в филиале. Т.е. скорость продаж филиала = сумме скоростей продаж всех его магазинов. В остальном, данный вопрос рассматривался достаточно подробно в теме "Распределение товара по филиалам".
Если после изучения этого материала у Вас останутся вопросы - пишите.
10.02.2011 12:54
VVY
 
АннаАнна, добрый вечер!
Добавлю только то, что если у Вас товар расположен в открытой выкладке на торговом оборудовании, то вероятно заказ нужно корректировать на фейсинги. То есть на количество товара, которое помещается на полку.
10.02.2011 18:25
Закупщик56127
 
Спасибо большое!
Уже стало понятнее :)
01.03.2011 03:22
Toyer
 
логика распределения товаров - старое количество+-1???
А если магазин может продавать не 10 штук за период, а 1000? Скорее всего вы об этом никогда не узнаете, в отличие от конкурентов.

Не пойму, а почему бы не посчитать количество проданных товаров В ДЕНЬ, и не вычислить необходимое количество умножением этого показателя на необходимое количество дней?

Фэйсинги. Если для вас это актуально, то надо ограничить минимальное количество товара на полках не ниже количества для фэйсинга.
01.03.2011 14:20
VVY
 
Toyer, добрый день!
Прошу дать пояснения:
Цитата:
Toyer логика распределения товаров - старое количество+-1???
1. А почему именно +-1, а не 2 или 4. Что значит старое количество, и почему оно верное с точки зрения потребности в конкретный момент?

Цитата:
Toyer А если магазин может продавать не 10 штук за период, а 1000? Скорее всего вы об этом никогда не узнаете, в отличие от конкурентов.
2. Что значит может и почему это не поддается прогнозированию?
3. Почему считаете, что конкуренты лучше Вас самого знают Ваши же продажи.

Цитата:
Toyer Не пойму, а почему бы не посчитать количество проданных товаров В ДЕНЬ, и не вычислить необходимое количество умножением этого показателя на необходимое количество дней?
4. Вопрос как посчитать. Как Вы считаете правильным посчитать: начинная от количества проданных товаров, заканчивая окончательной формулой?

Цитата:
Toyer Фэйсинги. Если для вас это актуально, то надо ограничить минимальное количество товара на полках не ниже количества для фэйсинга.
5. То есть огранивать заказ фейсингом?
01.03.2011 16:16
fsecrets.ru
 
Понимаю Вадим, почему Вы оставили такой комментарий в блоге, потому что Вы практически не читаете то, что пишут другие. ;)
См. вопрос
1. Ответ на него дал в первом посте топикстартер.
2. Я согласен с коллегой, когда возникает дефицит, действительно может, время простоя полки не оценивается.
3. А конкуренты лучше знают, потому что пока у Вас пусто, они продают то, чего у Вас нет.
4. На этот вопрос давал ответ Administrator и тут коллега тоже пропустил пост. Но это не учитывает п.3.
5. Нейтрально, на мой взгляд в аптеках мало влияют, потому как большинство покупок там совершаются по рекомендациям или рецептам, никто красивую упаковку не хватает.

Для продвижения товара, работать с провизорами.
Если дефицита не возникает, см. 4. Можно усложнять методы прогнозов, если есть знания и желание. Лекарственные препараты имеют сезонность. Ее необходимо также учитывать, иначе п.3.
02.03.2011 04:31
andrey_f
 
Цитата:
fsecrets.ru Я согласен с коллегой, когда возникает дефицит, действительно может, время простоя полки не оценивается.
Приветствую.
Именно простой полки оценить почти невозможно, ведь товар может быть в магазине, но не выставлен на полку. Зато мы можем оценить запас, предполагая, что если он не нулевой, то он обязательно есть на полке (как добиться своевременного пополнения запаса на полках - вопрос другой). Нам нужно оценить дни наличия товара и скорректировать статистику продаж при дефиците и пиках. Правда, вручную сделать это достаточно трудоемко и при отсутствии автоматизации этот момент может не учитываться. Но мы здесь как раз и пытаемся обратить внимание на важность этого момента.
Я исключаю предложенный клинический случай, когда каждый день в магазин привозится 10 ед. товара при реальном спросе в 1000 ед. (в данном случае нам нужно анализировать запас не по дням, а по часам, либо прислушаться к замечаниям розничного персонала, ведь, такой случай не может остаться незамеченным ими). В любом случае, у нас будет множество "качественных" дней наличия, по которым мы сможем восстановить реальный спрос.
02.03.2011 08:15
fsecrets.ru
 
Цитата:
administrator В любом случае, у нас будет множество "качественных" дней наличия, по которым мы сможем восстановить реальный спрос.
С одной стороны да, с другой стороны, если есть сезонность продаж, а как мы понимаем из темы она есть, потому как лекарства товар сезонный, то пока не накопится достаточной статистики продаж, возможен как дефицит, так и простои. А если исходить из предложенного Вами метода (когда мы считаем объем товара, продаваемого в среднем за день, если я правильно понял из Вашего поста) и умножаем на период, который закупщик посчитал каким-то экспертным путем, возможно исходя из некой тестовой партии, то может возникнуть тот же самый дефицит или профицит, если Вы среднее посчитали за "горячий" сезон. На первом этапе такой подход возможен, после накопления статистики продаж сезонная декомпозиция самое оно ну или что-то посложнее типа ARIMAX.

Автору топика можно было бы также обратить на VEN-анализ, все-таки аптека она не просто должна втюхивать товар с поводом и без повода, а делать еще это и по делу, все-таки клиенто-ориентированность должна быть выше, поэтому и запас должен чуть корректнее формироваться а не исходя из того, что только продается.
02.03.2011 08:53
andrey_f
 
Цитата:
fsecrets.ru
Цитата:
administrator В любом случае, у нас будет множество "качественных" дней наличия, по которым мы сможем восстановить реальный спрос.
С одной стороны да, с другой стороны, если есть сезонность продаж, а как мы понимаем из темы она есть, потому как лекарства товар сезонный, то пока не накопится достаточной статистики продаж, возможен как дефицит, так и простои. А если исходить из предложенного Вами метода (когда мы считаем объем товара, продаваемого в среднем за день, если я правильно понял из Вашего поста) и умножаем на период, который закупщик посчитал каким-то экспертным путем, возможно исходя из некой тестовой партии, то может возникнуть тот же самый дефицит или профицит, если Вы среднее посчитали за "горячий" сезон.
Мое предложение касается корректировки статистики, отношения к сезонности это не имеет. Мы всего лишь подготавливаем таким образом статистику для дальнейшего прогноза. Без такой обработки прогноз может оказаться некорректным, особенно это характерно для позиций с коротким плечом поставки и для распределения в сети (здесь как раз речь об этом случае). Есть товары, образующие группу с одинаковой сезонностью (сезонные коэффициенты нет смысла считать для каждой позиции, а лишь для группы). Нам ничего не стоит перенести сезонные коэффициенты группы на новый товар внутри этой группы, не дожидаясь пока пройдет год и у нас появится статистика продаж именно этого товара.

Цитата:
fsecrets.ru Автору топика можно было бы также обратить внимание на VEN-анализ...
У нас на форуме так же обсуждался вопрос о сущности VEN-анализа, прочитав Вашу статью заметил, что в случае классификации ресурсов и запчастей производственных компаний мы сходимся во мнении буква в букву :).
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
03.03.2011 22:07
fsecrets.ru
 
Это и есть простенькие модели сезонной декомпозиции.

P_1=P_0*P_(1-T)/P_(0-T) - мультипликативная модель, лучше использовать при нисходящем тренде или стагнации.
P_1=P_0+P_(1-T)-P_(0-T) - аддитивная модель, рекомендуется при восходящем тренде и при большом коэффициенте вариации.

P_m- объем за перид m
T - период цикла (год, квартал и т.д.)

ARIMA сложнее изобразить в виде формулы, как и ARIMAX.
03.03.2011 23:07
Anatoly
 
Цитата:
fsecrets.ru Это и есть простенькие модели сезонной декомпозиции.

P_1=P_0*P_(1-T)/P_(0-T) - мультипликативная модель, лучше использовать при нисходящем тренде или стагнации.
P_1=P_0+P_(1-T)-P_(0-T) - аддитивная модель, рекомендуется при восходящем тренде и при большом коэффициенте вариации.

P_m- объем за перид m
T - период цикла (год, квартал и т.д.)
Вы начинаете уходить от вопросов. Вы сами конкретно используете эти модели? То что "рекомендуется" мы в книгах тоже читаем.
Вы реально встречали аддитивную сезонность?
Вас попросили выложить модель в Excel на реальных данных. Прошу Вас это сделать по тем формулам что Вы привели, а мы подивимся эффективности прогноза.

Вы так и не ответили на мой вопрос выше:
Цитата:
Anatoly
Цитата:
fsecrets.ru Для борьбы с пиками и выбросами применяют экспоненциальное сглаживание (1,2,3 порядка), чем выше порядок, тем больше сглаживаются выбросы.
Добрый вечер!
Мне как раз очень интересен данный момент, я даже создал отдельную тему "Корректировка статистики продаж по дефициту и пикам". Не могли бы Вы в той теме, которую я создал для этого вопроса, показать пример корректировки статистики продаж по Вашему алгоритму. Желательно сделать его на примере тех данных, которые уже выложены - так мне будет проще разобраться. Ну и конечно интересует подробный алгоритм всех действий (приблизительно так как это описал Андрей или Валерий) для возможности автоматизации данного процесса в учетной системе, т.к. выгружать статистику по каждой отдельной позиции во внешнюю программу не разумно с позиции затрат времени и сил.
Буду благодарен!
Извините, но складывается впечатление, что Вы работаете преподавателем в институте, а о том что творится в реальности - имеете не совсем четкое представление. Ничего личного, но Вы сами уходите от вопросов и наталкиваете на эту мысль.
04.03.2011 00:42
KaPrAL
 
Цитата:
fsecrets.ru ...один сотрудник не сможет с помощью SQL прикручивать и пересчитывать модели прогнозирования, например по 1000 товарных категорий по каждой точке реализации в отдельности, если их хотя бы пару тыс.
Прогнозировать по каждой точке реализации в отдельности бессмысленно и ошибочно, точно также, как прогнозировать по каждому товару в отдельности. Точки реализации объединяют в группы по городам, областям, регионам, площадям самих точек, проходимости и т.п. Точно также товары объединяются в товарные группы (категории, как вы и сказали). И прогнозируются продажи каждой товарной группы в каждой группе точек реализации. Затем сопоставляются продажи каждого товара в каждой точке реализации, масштабируются линейной регрессией k*x+b (желательно с b=0), и получается прогноз в разрезе: "Товар---Точка реализации".
Если специфика товара такова, что он имеет 12-ти месячную сезонность, то можно обойтись только SQL-ем (линейным трендом с коэффициентами сезонности), но если сезонность представляет собой гармоники с частотой, отличной от 1/12, то на любом языке программирования несложно написать формулу, на вход которой подается массив, а на выходе- прогноз. Суть такой формулы описана во многих источниках: сначала находится наиболее вероятная степень полинома тренда, затем тренд удаляется, находится наиболее вероятное количество гармоник, определяются их первоначальные частоты периодограммой, затем рекурсией уточняется каждая из частот, возвращается тренд, и по-новой переопределяются параметры спроса. Трёх итераций обычно достаточно. Только не забыть учесть периоды кризиса, в моменты перехода которого тренд разрывался, и воспользоваться этой единой функцией для прогнозирования каждой товарной категории в каждой группе точек реализации.
В зависимости от исходных данных, функция дает прогнозы. О каких "моделях" идет речь?
Цитата:
fsecrets.ru Второй минус если человек 1, он становится незаменимым, и даже если его эффективность падает, заменить его становится некем, так как разбираться в чьем то мускул-коде, который может быть не документированным. Так как есть у Кулибиных минусы в том, что если его кто-то хочет кинуть, то документации какой-то внятной не остается.
Риски всегда были, есть и будут, только рассматривать их стоит в тандеме с затратами и эффективностью, и выбирать свою нишу. Знаю несколько известных компаний, системы учета которых держатся на одном-единственном человеке- руководителе IT-департамента, заменить которого некем, т.к. обычно он её и разрабатывал, и разрабатывает, и поддерживает, и все довольны. Также знаю компании, бесполезно потратившие несколько десятков лямов "консультантам-внедренцам" за ту же пресловутую 1С-ку, которая за 2 с лишним года с начала внедрения заработала лишь на 40%.
Цитата:
fsecrets.ru Я понял, почему мы иногда друг друга не очень понимаем, потому что мы работаем немного с разным количеством данных, я работаю с топовыми промышленными системами, Вы пользуетесь тем, что может позволит себе компания и потом пытаетесь сделать из того, что есть конфету.
Согласен, вы работаете с розницей, с террабайтными высоконагруженными хранилищами, а я в скромном опте с базой в 100 Гигов, и то использую меньше одного гига для своих нужд, поэтому и выбор инструментария разный: нас пока устраивает MS. Кстати, зря вы так пренебрежительно относитесь к MS Analysis Servaces, пусть он и без клиента, но бизнес-логику в нем можно задать любую, и производительность не на последнем месте. В отличие от Cognos-а с его костылями, MS очень даже ничего...
И еще, компания не "даёт то, что может позволить", а позволить она себе может многое, любой инструментарий. Руководство не раз обращалось ко мне с просьбой его усовершенствования. Я же в свою очередь настаиваю на наиболее эффективном варианте для текущих объёмов: MS.
Цитата:
fsecrets.ru Я тоже когда-то был за такой подход, пока не понял, что "умные" дядьки давно уже ушли вперед и почему бы не пользоваться этими умностями, не извращаясь в Excel-е, хотя и продолжаю это делать.
Простите, а о каких "умностях" вы говорите? Если об OLAP-е, то вся "умность" зависит не от платформы, а от архитектора и от MDX-писаки. Если же вы имеете в виду Data Mining, то уже ответили сами:
Цитата:
fsecrets.ru ...сам категорически против "черных ящиков".
Так чем же может похвастаться "умная платформа"?
Цитата:
fsecrets.ru Нейронные сети???? Честно - хорошая шутка, вот Вы мне скажите, Вы используете нейронные сети? Я тоже нет для прогнозирования. Логично применять для клиентской аналитики и прогнозирования определенных событий, но это практически "черный ящик".
Для прогнозирования пока не использую, а не использую, пока не разработаю свою сеть, т.к. пользоваться готовым "черным ящиком" не рискну. Сеть можно и нужно использовать для прогнозирования многофакторных событий, ведь только она реализует нелинейную регрессию.
04.03.2011 09:06
fsecrets.ru
 
2 Kapral
Да, использую, но я не прогнозирую реализацию товаров, я работаю в телекоме, реализация услуг в котором имеет очень хорошую сезонную динамику, я больше чем уверен, что реализация каждой партии имеет свою динамику, которая очень будет похожа на распределение Гаусса. То, что я написал в качестве рекомендуется взято не из литературы, а набитые шишки долгими годами практики. Вы не можете написать простую формулу в ячейке и растянуть? Очень печально.
Не поверите, действительно есть аддитивная динамика, она существует в природе. :lol:

Хотите подивиться, ОК, берем карандаш, рисуем график на 13 месяцев с декабря, потом сверху прикладываем кальку и обводим график, потом кальку сдвигаем вправо таким образом, чтобы декабрь первый соответствовал декабрю последнему, вуаля аддитивная модель :D

Видите ли 100 Гб и 200 Тб цифры немного разного порядка.

Черный ящик относился не ко всем алгоритмам Data mining-а, не нужно передергивать, я сказал, что в данном случае упомянутые Вами нейронные сети относится к черному ящику, алгоритмы кластеризации, деревья решений, очень отлично представляются визуально и их можно четко интерпретировать почему именно такой ответ, а не иначе.

Умная платформа ничем не может похвастаться, Вы просто гуру, я преклоняю перед Вами колени, а Вы продолжаете писать SQL запросы, тестировать их, долго и упорно распределять продажи в Excel-е в то время, как я их формирую drug&drop-ом в режиме визуализации и исполняю на серваке за секунды. В то время как Вы еще проводите анализ, я уже разработал стратегию и как только Вы приступаете к реализации стратегии, я уже на рынке с предложением. А Вы вдруг выяснили, что забыли учесть некий параметр в анализе:) А так мы с Вами делаем почти все то же самое
Только одна из заповедей маркетинга, любое предложение должно быть in time. А MS на моих 200Тб как-то in time не справляется. Как бы я хотел, чтобы справлялся. Если бы объем данных не увеличивался, тогда Terradata и Oracle со своей Exadata разорились бы.

Ну так если Вы нейронные сети не использовали, к чему это было замечания для SPSS? Просто показать свой уровень ерундиции, я оценил, спасибо.
Я не хочу сильно защищать IBM, но Вы когда последний раз Cognos видели, наверное начальные его версии, так знаете многие с Oracle Discoverer, который сам Oracle уже года 3 как не поддерживает, плюются, чертыхаются, дуют щеки и говорят, фу какие костыли. Так ясен пень, тогда MS лучшая платформа на земле.

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

Я понимаю, что я немного не в свою тему влез, но немножечко в методах прогнозирования пытаюсь разобраться, конечно не на таком уровне как Вы, Вы-то ого-го. Спасибо Вам большое, что раскрыли мне глаза на многие вещи, впредь попытаюсь быть более сдержанным и не писать то, в чем вообще не разбираюсь, пойду учить студентов.
04.03.2011 10:50
Anatoly
 
fsecrets.ru, давайте без истерики по факту:
я не люблю когда не отвечают за свои слова (такой я есть), как говорится, назвался груздем - полезай в кузовок.
Я вынужден просить Вас по 2-3 раза ответить на вопрос, это нормально? Нет, это не нормально.

Я прошу Вас в 3ий раз:

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

P_1=P_0*P_(1-T)/P_(0-T) - мультипликативная модель, лучше использовать при нисходящем тренде или стагнации.
P_1=P_0+P_(1-T)-P_(0-T) - аддитивная модель, рекомендуется при восходящем тренде и при большом коэффициенте вариации.

P_m- объем за перид m
T - период цикла (год, квартал и т.д.)
Вы начинаете уходить от вопросов. Вы сами конкретно используете эти модели? То что "рекомендуется" мы в книгах тоже читаем.
Вы реально встречали аддитивную сезонность? Реально на практике! Карандашом можно любую фантазию нарисовать.
Вас попросили выложить модель в Excel на реальных данных. Прошу Вас это сделать по тем формулам что Вы привели, а мы подивимся эффективности прогноза.
04.03.2011 11:17
KaPrAL
 
Цитата:
fsecrets.ru Да, использую, но я не прогнозирую реализацию товаров, я работаю в телекоме, реализация услуг в котором имеет очень хорошую сезонную динамику, я больше чем уверен, что реализация каждой партии имеет свою динамику, которая очень будет похожа на распределение Гаусса.
Распределение Гаусса- нормальное распределение, т.е. случайное. Если есть сезонность, значит динамика уже не случайна. Если вы уверены, что каждая партия имеет свою динамику, то если сезонность классическая 12-ти месячная, эффективнее использовать коэффициенты сезонности, чем искать гармоники, тогда динамика реализации каждой партии будет иметь свой тренд и свои коэффициенты сезонности. Аддитивную ли модель использовать, или мультипликативную- вам решать, но есть замечательные базисы вейвлетов. Можно попробовать разложить ряд по ним.
Цитата:
fsecrets.ru Вы не можете написать простую формулу в ячейке и растянуть? Очень печально.
Не поверите, действительно есть аддитивная динамика, она существует в природе. :lol:
Хотите подивиться, ОК, берем карандаш, рисуем график на 13 месяцев с декабря, потом сверху прикладываем кальку и обводим график, потом кальку сдвигаем вправо таким образом, чтобы декабрь первый соответствовал декабрю последнему, вуаля аддитивная модель :D
Это, видимо, адресовано Anatoly.
Цитата:
fsecrets.ru Видите ли 100 Гб и 200 Тб цифры немного разного порядка.
Конечно разного! Но из всех этих двухсот Тб полезной информации для анализа не больше 100 Гб. (ориентировочно)

Цитата:
fsecrets.ru Умная платформа ничем не может похвастаться
А я о чем?! Стоит ли она своих нескольких десятков лямов???

Цитата:
fsecrets.ru ...а Вы продолжаете писать SQL запросы, тестировать их, долго и упорно распределять продажи в Excel-е в то время, как я их формирую drug&drop-ом в режиме визуализации и исполняю на серваке за секунды. В то время как Вы еще проводите анализ, я уже разработал стратегию и как только Вы приступаете к реализации стратегии, я уже на рынке с предложением. А Вы вдруг выяснили, что забыли учесть некий параметр в анализе:)
Показатели (меры) бывают двух видов:
1) Фактические (запасы, продажи, заказы и пр.).
2) Расчетные (прогнозы, планы, КЗ, оптимальные заказы и запасы и пр.). Многие из них вычисляются рекурсивно, поэтому они расчитываются на уровне хранилища ETL-ем, а не MDX-ом в момент запроса.
Оба вида показателей представляют собой меры, которые обновляются в OLAP-хранилище по-ночам, во избежании рассогласования данных и нагрузки серверов, поэтому делая drug&drop отчеты, вы используете меры, обновленные ночью. И не важно, каким образом они рассчитаны: на уровне куба или ETL, данные-ночные, поэтому об on-line отчетности можете забыть, если обращаетесь к кубам. SQL же обращается к реляционке, и отчеты получаются on-line, поэтому в то время, когда вы будете крутить вчерашние данные, я уже разработаю стратегию по свежим данным.

Цитата:
fsecrets.ru А MS на моих 200Тб как-то in time не справляется.
Может быть у вас не очень грамотная архитектура реляционки или кубов была на MS? Кубы MS без особо сложно-вычисляемых мемберов потянет, если разбивать меры на партиции, и процессить только последнюю из них.

Цитата:
fsecrets.ru В дальнейшем я бы не хотел переходить на личности, а Ваша эмоциональная окраска постов немного вызывает опасение, складывается впечатление, что пришел человек (я имею себя) в чужой монастырь, все выскочили и давай мериться одним местом. Я предлагаю как-то конструктивнее, я понимаю, что здесь собрались самые умные люди планеты, но не повод себя так вести. Незнакому человеку говорить какие-то гадости, обзывать теоретиком, преподом и т.д.
Это, видимо, тоже адресовано не мне, т.к. я не переходил на личности, с психикой вроде все пока в порядке (тьфу-тьфу), и не обзывался ни "теоретиком", ни "преподом". Извините, если что-то вас обидело в каком-либо из моих сообщений. У меня нет byt было цели кого-то обидеть или чем-то помериться, цель одна: объективная критика существующих методов анализа и инструментария. Грустно видеть, что втюхиваемая за десятки миллионов система не стоит и ста тысяч...
04.03.2011 11:59
fsecrets.ru
 
Anatoly рад, что Вы мой стеб приняли за истерику :D
Выложил простой пример.
04.03.2011 12:12
fsecrets.ru
 
KaPrAL
В вопросе IT как и в медицине не бывает одинаковых мнений. В телекоме к сожалению, мы не можем себе позволить не тарифицировать соединения абонентов, и поэтому и объемы такие какие есть.

BI система не стоит больших денег, больших денег стоит интеграция с несколькими системами, биллингом, инвентори и т.д., хранилища стоят больших денег, сервера стоят больших денег. А несколько миллионов стоит комплексное решение. А умеет все делать система за 2 тыс. долл. на 1 пользовательскую лицензию. Так что смотря что считать дорогим.

Спасибо что просвятили на счет данных.
Пока Вы будете загружать на MS SQL- несколько ночей мои данные за одни сутки, Вам точно будет не до стратегии. :D
04.03.2011 12:22
Anatoly
 
Цитата:
fsecrets.ru Выложил простой пример.
Спасибо, но я не могу его скачать, пытался несколько раз с разных компов.
Прикрепите, пожалуйста, файл к Вашему ответу на это сообщение.
Спасибо.
04.03.2011 12:29
fsecrets.ru
 
Битая ссылка была, обновил.


Опции темы


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

 

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