Международный центр компетенций в области планирования производства, логистики, управления цепочками поставок, управления запасами и закупками
+7 495 720-8260
Международная сертификация APICS Тренинги и семинарыот ведущих специалистов Бизнес-симуляторинновационный формат обучения Оценка компетенцийоценка компетенций

MRP – больше вреда, чем пользы. Мнение.

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

Последствия этого решения были поразительными: сроки доставки сократились от нескольких месяцев до нескольких недель, скорость реакции в системе значительно улучшилась. Это привело к увеличению доступности сырья и значительному облегчению прогнозирования – т.к. горизонт прогнозирования снизился до легко предсказуемого периода в несколько месяцев. Ежемесячная практика S&OP стала приятным развлечением. В результате компания тратит на управление гораздо меньшее количество ресурсов, а поставщик работает с более высокой загрузкой мощности. В их взаимоотношениях появилось доверие и конструктивное сотрудничество - отличная основа для дальнейшего совершенствования.

Сказка?

Этот сценарий может звучать как сказка, верно. Но с другой стороны, MRP может принести больше вреда, чем пользы, поскольку MRP полностью игнорирует первые два закона физики цепочки поставок (по Hopp&Spearman'у). Первый закон гласит, что изменчивость всегда ухудшает производительность системы. Второй закон говорит, что изменчивость в производственной системе стремится компенсировать саму себя дополнительными запасами, мощностью или временем.

На практике многие производственные компании предпочитают компенсировать изменчивость системы дополнительным временем. (Дополнительная мощность расценивается как смертный грех, если вы оцениваете производственную эффективность коэффициентом использования оборудования). С другого конца цепи поставок – конечный клиент, не готовый ждать и закладывать дополнительный срок поставки за свой счёт. Что мы имеем? Среднее звено оказывается в безвыходной ситуации и увеличивает запасы, устраняя ими разницу между сроками своего поставщика и сроками своего клиента . Именно тут всё часто идёт не так.

Вместо того, чтобы использовать запасы в качестве буфера, компенсирующего колебания спроса и помочь производству одновременно выпускать продукцию вовремя и поддерживать высокий коэффициент использования оборудования, люди обычно делают прямо противоположное. Они назначают менеджера по обеспечению запасами ответственным за оптимизацию запасов и дают ему соответствующие инструменты (точку перезаказа, MRP и др.). В этом случае менеджер не размещает заказ до тех пор, пока запасы не опустятся ниже точки перезаказа, на такое количество, которое просчитано заранее (желательно, по формуле экономически оправданного количества - EOQ), т.е.  только тогда, когда возникает потребность начать использовать страховой запас. Благие намерения компенсировать колебания спроса в результате, наоборот, фактически его усиливают и передают далее по цепочке - в производство (это явление называется «эффект хлыста»). Очевидно, что производство вынуждено реагировать с еще большей задержкой сроков поставки, чтобы справиться с этими колебаниями.

Резюме: запасы оказываются  катализатором колебаний спроса, а не буфером. Вы можете представить дальнейшие последствия без труда.

Бережливые супермаркеты

Однако, есть и совершенно другой способ управлять процессом. Самый простой и, следовательно, лучший пример эффективного использования запасов – концепция «супермаркета» из методологии бережливого производства. Недостаток подхода – он является визуальным инструментом. Это делает бережливые супермаркеты непригодными для управления масштабными складами, не говоря уже о дистанционном управлении. В книге «Supply Chain Management at Warp Speed» Eli Schragenheim представляет хороший, но, по-видимому, сложный метод эффективного использования ресурсов. Он называет концепцию «Make to availability (MTA)» альтернативой «Make to stock (MTS)». Это блестяще в теории, но слишком сложно для освоения.

Глоток свежего воздуха

Тем не менее, подход «MRP, основанный на спросе (DDMRP)», недавно ворвался в мир цепей поставок, как глоток свежего воздуха, и он, похоже, действительно начинает работать. DDMRP основывается на том же методе супермаркетов от Eli Schragenheim. По сути, является вариацией его концепции «Make to availability (MTA)». Однако, вместо того, чтобы бросать вызов существованию MRP, DDMRP занимает параллельную позицию наряду с MRP - хотя и не без погрешностей в чистоте расчётов, к сожалению.

Название «MRP, основанный на спросе (DDMRP)» оставляет желать лучшего, использует более маркетинговый подход. Тем не менее, DDMRP теперь, похоже, набирает значительную силу Этот подход исправляет фундаментальные ошибки MRP путем определения приоритетов на основе фактических уровней запасов, а не прогнозируемых сроков поставок. Кроме того, он даёт возможность разделить цепочку бесполезной зависимости в запасах.

DDMRP - панацея? Конечно нет. Но лучше ли методика DDMRP, чем MRP? Определенно - намного лучше, если у вас производство-на-склад «Make to stock (MTO)». Должны ли вы реализовать её без задней мысли? Можете, конечно, но мой совет  -  сначала получите полное представление вашей текущей ситуации и текущей динамике, чтобы определить лучший способ борьбы с колебаниями спроса и вашей конкретной ситуации на рынке. Для моего клиента этот подход привел к решению, в котором MRP не был улучшен, но фактически полностью отключен и заменен на, условно, простую цифровую версию «бережливого супермаркета» и этот подход сработал.

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

Alex Tjalsma | 19 April 2017 для involvation.nl


Вернуться


Наши клиенты

  • OracleSunInBevSyngentaLVMHAkzoNobelVolvoPfizerHenkel
  • DowAstra-ZenekaNpo_saturnContitentalrzhdJTIВертолеты РоссииОМКИркутKatkoGazpromTescoFerreroIpsen