Обновить

Комментарии 11

Хм. А детальное описание алгоритма и модулей интеграции есть? В таком виде — это просто красивые слова.
Сергей, здравствуйте!
Полностью с Вами соглашаюсь, что без конкретных алгоритмов и собственно реализации, любая идея всего лишь слова, которые так и могут остаться всего лишь словами.
Есть плохая новость, я не планировал в этой статье глубоко раскрывать саму методологию, но обязательно сделаю это в следующей статье.
Но есть и хорошая новость. Есть полное описание методологии в книге «DDMRP», и есть ее программное решение «Replenishment +», а также краткие обзоры на сайте(по ссылке внизу комментария).
Если не хотите ждать следующей статьи — 19 мая в 10 утра по Московскому времени будет вебинар, где либо я, либо мой коллега расскажем о самой методологии, конкретных алгоритмах, рассмотрим реализацию методологии в программном продукте, его модулях и возможностях интеграции.
Ссылка на вебинар: http://abmcloud.com/events/upravlenie-zapasami-na-proizvodstve/
Аргументирование в пользу отказа от прогноза на операционном уровне строится на том, что потенциальные клиенты не знают, что у прогноза помимо мат. ожидания есть еще такая характеристика, как дисперсия, и не учитывают других факторов (стоимость завышенного, заниженного запаса, а также операционных расходов). А таких людей, к сожалению, большинство (но не на хабре, надеюсь). Зато люди покупаются на красивые слова про «теорию ограничений». Ваш бизнес, наверное, прёт?)

Специалисты из MIT (да-да, того самого, Массачусетского) в свое время разработали для Zara модель управления запасами магазинов (!) на основе прогноза. Хотя, казалось бы, такой прерывистый, сезонный и непредсказуемый спрос, как в фэшн ритейле, еще поискать надо. Особенно в Zara, где новые продукты запускаются в продажу каждую неделю и могут прожить в магазине меньше месяца.

Описание модели можно найти в открытом доступе. Там есть и описание модели, и корректные расчеты повышения эффективности. Главное — не запутаться в формулах;)
Как я уже помянул — прогноз это необходимый инструмент стратегического планирования. И чем точнее он, тем лучше руководители могут принимать стратегические решение. Но что делать руководителю производства, который с утра пришел на работу? — брать утвержденный месячный план продаж и конвертировать его в объемно-календарный график производства с надеждой, что прогноз не ошибается…
Но в течении недели, например в Чт, завод может производить то, в чем пока нет необходимость при этом, не производить «товар А», пик продаж которого по непонятным причинам произошел в первую неделю месяца… А в плане производства — только на вторую неделю, соответственно и сырье заказано на вторую неделю… И даже если есть сырье, остаются ограничения по очередность(пример на красках: нельзя более светлые, производить после более темных), или переналадке(с текущего типа продукции переход на тип А занимает 2 смены, что сломает и производительность и собственно текущий план производства) или другие. Возникает вопрос — а что делать, сломать график и делать то что хочет клиент, производя ущерб всей системе, или игнорировать и придерживаться графика, вставив «товар А» за первой же возможности(чтобы минимизировать потери производительности). Это те задачи, с которыми каждый день сталкиваются руководитель производств… и что интересно… как я уже сказал — месяц к месяцу отклонения могут быть не существенны… Поэтому очень часто возникает недопонимание между коммерческим отделом и производством: «мы вам дали в общем то не плохой план, почему вы не можете произвести?»

На самом деле разница в использовании прогноза на операционным и стратегическим состоит в том, что на операционном уровне дисперсия и неопределенность настолько возрастает, что даже сложные математические модели не гарантируют хорошего результата. Это базовое свойство прогнозирования, чем более детальный прогноз, тем менее он точен.
Кроме того, прогнозирование на операционном уровне создают мнимое чувство безопасности, что было сделано лучшее из того, что возможно. И как Вы сами упомянули — главное не запутаться в формулах…
Но даже рассчитав все правильно перед Вами все же остается вопрос, а что делать дальше? На ежечасном, ежедневном или даже недельном уровне работы производства расхождения останутся существенными… Проделав такую работу, человек скорей всего продолжит искать причины отклонений и будет совершенствовать свои расчеты, очень часто упускаю из виду самые простые вещи, упомянутые в статтье.

Остается открытым вопрос — а как настроит не только производственную систему а всю цепочку поставок, чтобы она была способна сделать то, что хочет клиент, не теряя производительности и при минимальных общих затратах? — ответ методология DDMRP.

К стати, соглашаюсь по поводу MIT, сам недавно проходил там онлайн обучение по Supply Chain Management и всем читателям очень советую!
Спасибо за подтверждение моего комментария и за развернутый ответ. Прокомментирую ваш ответ:

1. Если руководитель производства из вашего примера в лоб конвертирует прогноз в производственный план, то ему лучше уволиться;) Использование прогноза не подразумевает превращение этого прогноза напрямую в план поставок / производства. Нужно ещё учесть текущий запас, дисперсию прогноза спроса, сроки (поставки / производства / …), стоимость заниженного и завышенного запаса. Делать это можно по-разному, зависит от математической подготовки и софта, имеющегося в распоряжении. Думается мне, что в вашей модели так или иначе косвенным образом используется хоть какой-то прогноз.

2. Да, более детальный прогноз имеет большую дисперсию, но это не значит, что он бесполезен. Возвращаясь к примеру Zara, в их модели управления запасами используется прогноз на уровне неделя-магазин-SKU (SKU на уровне размера артикула, т.е. самом детальном). Для информации, в фэшн ритейле прогноз спроса на этом уровне детализации может быть порядка 0.1 шт или даже 0.01 шт. Сигма там превышает мат. ожидание в несколько раз. Тем не менее используют…
Модель прогноза там, кстати, не особо сложная. Фраза «главное — не запутаться в формулах» относилась не к прогнозу, а к модели оптимизации запасов, в которой этот прогноз используется. Она учитывает не только факторы, которые я перечислил выше, но и некоторые другие. В итоге возникает задача дискретной оптимизации (для решения которой используется оптимизационной движок IBM iLog).

3. Порадовал ваш аргумент, что «прогнозирование на операционном уровне создают мнимое чувство безопасности». Но это же недостаток не прогноза, а того человека, который управляет запасами, основываясь на основе чувств и ощущений. Управлять запасами надо на основе фактов и расчетов.

Перефразирую известную фразу. Вы не любите прогнозы? Да вы просто не умеете их готовить!
«Но в течении недели, например в Чт, завод может производить то, в чем пока нет необходимость при этом, не производить «товар А», пик продаж которого по непонятным причинам произошел в первую неделю месяца… А в плане производства — только на вторую неделю, соответственно и сырье заказано на вторую неделю… И даже если есть сырье, остаются ограничения по очередность(пример на красках: нельзя более светлые, производить после более темных), или переналадке(с текущего типа продукции переход на тип А занимает 2 смены, что сломает и производительность и собственно текущий план производства) или другие. Возникает вопрос — а что делать, сломать график и делать то что хочет клиент, производя ущерб всей системе, или игнорировать и придерживаться графика, вставив «товар А» за первой же возможности(чтобы минимизировать потери производительности).»

То есть ваш сервис решает данную проблему?
Тогда можно уточнить — а как именно?
Не хочется уходить в глубь самой методологии, но если тезово:
1. Делаем анализ цепи и принимаем решение где есть смысл хранит запас. Главная идея — найти точки, с помощью которых возможно повысить управляемость всей системы, сократить цикл производственного планирования и повысить ROI.
2. Классифицируем СКЮ по типам и определяем стратегии управления по каждому типу отдельно, с учетом специфики производства(очередностей, переналадок и тд)
3. Управление не по прогнозу на период с использованием страхового запас, а через диапазоны значений в режиме реального времени.

Если еще проще: Секрет не в том, чтоб угадать, а что у меня завтра закажут, а настроит систему так, чтобы система смогла произвести то, что заказал клиент… Некий баланс между «Выталкиванием» и «Вытягиванием».

Спасибо за вопросы! Я понял — что необходимо побыстрей написать вторую статью, поскольку остается много вопросов по самой методологии…
Вы описали конкретную проблему — завод, товар А с пиком продаж, нехватка товара… Как конкретно эту задачу поможет решить ваш сервис?
Какая в данном случае цепь и где именно надо хранить запас?
Какой тип товара А и какая стратегия управления?
Какие диапазоны значений для товара А?
И самое главное — как это всё помогает решить проблему с неожиданным пиком продаж?
я описал не конкретный «товар А», а проблему с построением производственных графиков на основании прогноза и то, как они сталкиваются с реальностью. И что такой системе недостает гибкости как таковой и что совершенствование прогноза не помогает решить эту задачу.
Вот я и хочу уточнить — а как именно ваш сервис помогает решить конкретно эту проблему — недостаточная гибкость производственных графиков, построенных на основе прогноза? Можно какой-то условный пример с цифрами?
Был бы рад привести пример в комментарии, но поскольку функционал наглядности ограничен и описание всей проблемы затянется надолго, ещё раз приглашаю поучаствовать в вебинаре, по регламенту -1,5 часа, где болен подробно будет обо всем рассказано, а Вы сможете задавать вопросы по ходу вебинара в чате

Еще раз спасибо за интерес и вопросы
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации