Минимальный объем заказа (MOQ)

learn menu
By Joannes Vermorel, March 2020

В своей простейшей форме минимальные объемы заказа (MOQ) представляют собой наименьшее количество, которое можно купить у поставщика. MOQ широко распространены среди большинства предприятий, которые не классифицируют себя как розничные. MOQ обычно отражают экономические трения со стороны поставщика, связанные с обработкой заказа (например, административные задачи, такие как выставление счетов и ведение бухгалтерии) и его выполнением (например, затраты на обработку и доставку). Сложные MOQ, включающие несколько ограничений, могут возникать, когда экономические трения не могут быть должным образом отражены простыми MOQ. Кроме MOQ, наиболее заметными ограничениями при заказе являются Экономические объемы заказа (EOQ), множители лотов и ценовые промежутки.

стопка коробок, обернутых пленкой, на поддоне, загруженная в грузовик

Простые MOQ

Простой MOQ определяется одним ограничением, действующим как нижняя граница для любого заказа. Количество может измеряться в единицах (также называемых штуками) или в денежных терминах (например, долларах или евро). Область применения ограничения может быть следующей:

  • продукт, где каждое количество, связанное с каждым продуктом, включенным в заказ на покупку, должно достигать MOQ.
  • заказ, где сумма всех количеств, связанных со всеми продуктами, включенными в заказ на покупку, должна достигать MOQ.

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

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

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

Сложные MOQ

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

Например, производители одежды часто имеют сложные MOQ, которые включают несколько из следующих ограничений:

  • минимальное количество, в метрах ткани, составляет 3000 метров для каждого цвета, присутствующего в любом заказанном продукте, для всего заказа.
  • минимальное количество, в штуках, для каждого заказанного продукта составляет 600 штук.
  • минимальное количество, в долларах, для всего заказа составляет 20 000 долларов США.
  • минимальное количество, в единицах, для всего заказа составляет 2000 штук.

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

Затем второе ограничение отражает экономию масштаба на уровне продукта - как обсуждалось в предыдущем разделе - но это ограничение дополняется третьим ограничением, которое накладывает минимальный объем заказа в долларах. Это третье ограничение предназначено для предотвращения клиентов от размещения заказов низкой стоимости, например, заказа 10 000 пар носков по цене 0,30 доллара США за единицу.

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

Ограничения заказа по сравнению с механизмами ценообразования

Помимо MOQ, существуют и другие заметные ограничения заказа, такие как:

  • множители партий, где заказываемые количества продукции должны быть кратными заданному целому числу. Это ограничение часто отражает выбор упаковки, где продукт упакован в коробки или паллеты из X единиц.
  • Экономический заказной объем (EOQ), это отражает трение со стороны клиента при заказе, в то время как MOQ отражает трение со стороны поставщика.
  • ценовые промежутки, где предельная цена за единицу, взимаемая поставщиком, изменяется, обычно уменьшается, с увеличением заказанного количества.

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

Оптимизация объемов заказа при использовании MOQ

Наличие MOQ усложняет процесс заказа. С точки зрения покупателя, определение наилучших объемов заказа при соблюдении MOQ является задачей ограниченной оптимизации, широкой областью на пересечении компьютерных наук и математической оптимизации.

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

Даже при наличии подходящих программных инструментов MOQ обычно достаточно сложны для решения, особенно из-за обратного влияния, которое MOQ оказывают на планирование цепочки поставок. Действительно, чем больше MOQ, тем реже будут поступать заказы, что означает большие сроки поставки. Таким образом, поскольку применимый срок поставки при рассмотрении заказа у поставщика обычно является суммой срока поставки поставщика и срока поставки заказа, этот показатель зависит от MOQ. Это, в свою очередь, влияет на потребность в товаре.

Взгляд производителя на оптимизацию MOQ

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

Для производителя факторы, влияющие на выбор MOQ, включают:

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

Исходя из этих экономических факторов можно оптимизировать MOQ и позволить им эволюционировать со временем, чтобы правильно отражать изменяющиеся рыночные условия. Однако на практике MOQ не следует пересматривать слишком часто, поскольку постоянные изменения, даже незначительные, негативно сказываются на практиках заказа клиентов. Тем не менее, MOQ следует пересматривать регулярно, чтобы они оставались тесно связанными с рынком и стратегией производителя.

Мягкие MOQ

Мягкие MOQ1 - это самоустанавливающиеся MOQ от самой закупающей стороны. В отличие от “жестких” MOQ, которые навязываются поставщиком, мягкие MOQ отражают практику, а не требование. Мягкие MOQ обычно используются, когда процессы или программные инструменты, используемые для передачи заказов на закупку и их отслеживания, не способны справиться с большим количеством отдельных предзаказов. В такой ситуации среднее количество отдельных предзаказов можно сократить, применяя мягкие MOQ.

Концептуально мягкие MOQ являются вариантом экономического заказа. Однако на практике мягкие MOQ обычно не являются результатом какого-либо эконометрического анализа, а скорее являются аварийной практикой, которая возникает “естественным” образом, когда команда по закупкам не может справиться с объемом заказов и/или поставок, которые произошли бы, если бы заказанные количества были разделены на максимально возможное количество, учитывая затраты на заказ и транспортировку.

Мягкие MOQ часто используются в сочетании с еженедельным или ежемесячным графиком заказов, что является еще одним подходом к достижению той же цели, а именно, снижение давления на команду по закупкам при управлении поставками от поставщиков с высокой детализацией.

Общая проблема MOQ

Общая проблема MOQ является задачей нелинейной оптимизации. Относительно просто можно показать, что эта проблема является NP-трудной. Действительно, общая проблема MOQ расширяет проблему упаковки баков, которая также является NP-трудной. Таким образом, общая проблема MOQ по крайней мере так же сложна, как проблема упаковки баков. Хотя проблема является NP-трудной, следует отметить, что в практике могут быть вычислены очень хорошие решения.

Концепции, связанные с общей проблемой MOQ. У нас есть:

  • элементы, которые представляют то, что может быть фактически приобретено. Количество элементов часто является целыми числами; хотя здесь нет ограничений на их использование.
  • заказанные количества для каждого элемента (возможно, ноль), которые представляют потенциальное решение проблемы MOQ.
  • экономические награды, связанные с каждой дополнительной единицей для каждого элемента.
  • затраты, связанные с единицами, которые должны быть приобретены. Целью является максимизация награды при заданном бюджете, выраженном в затратах. Ожидается, что затраты на единицу будут плоскими, но здесь мы не делаем предположений; таким образом, могут учитываться снижения цены.
  • цели, которые представляют способ задания критериев остановки, которые могут не совпадать с фактическими затратами.
Например, Фрэнк, менеджер цепи поставок, устанавливает цель на уровне 90% заполнения. Решение проблемы MOQ состоит в вычислении наименьшего заказа - по затратам - при максимизации наград, который обеспечивает заполнение на уровне 90%. Этот заказ НЕ является наименьшим возможным заказом для достижения заполнения на уровне 90% - так как это было бы чистое приоритетное заполнение. Вместо этого это наименьший заказ, который, при приоритете наград, достаточно большой, чтобы обеспечить заполнение на уровне 90%. Чистое приоритетное заполнение было бы ошибкой, потому что, в отличие от награды за запас, оно не учитывает затраты, связанные с образованием мертвого запаса.

Пусть $${I}$$ - это набор товаров, рассматриваемых для заказа.
Пусть $${q_i}$$ с $${i \in I}$$ - это количество товара $${i}$$ для заказа.

Затем мы определяем ряд функций.

  • Пусть $${r_i(q)}$$ будет наградой при удержании $${q}$$ единиц товара $${i}$$.
  • Пусть $${c_i(q)}$$ будет стоимостью при покупке $${q}$$ единиц товара $${i}$$.
  • Пусть $${t_i(q)}$$ будет целью при удержании $${q}$$ единиц товара $${i}$$.

Функция награды может возвращать положительные или отрицательные значения, однако стоимость и целевые функции всегда строго положительны:

$$\forall i, \forall q, c_i(q) > 0 \text{ и } t_i(q) >0$$

Пусть $${M}$$ - это набор ограничений MOQ. Для каждого $${m \in M}$$ у нас есть $${I_m}$$ - список товаров, принадлежащих ограничению $${m}$$, и $${Q_m}$$ - минимальное количество, которое должно быть достигнуто для удовлетворения ограничения. Пусть $${m_i(q)}$$ - функция, которая определяет вклад товара $${i}$$ в ограничение MOQ $${m}$$ при покупке $${q}$$ единиц. Ограничение $${m}$$ считается удовлетворенным, если:

$${{\forall i \in I_m, q_i = 0 \text{ или } \sum_{i \in I_m}m_i(q_i) \geq Q_m}}$$

Таким образом, все ограничения MOQ могут быть удовлетворены двумя способами: либо достижением порога MOQ, либо имея все количество товаров равным нулю.

Затем пусть $${C}$$ - это максимальная стоимость, которую можно позволить для заказа. Мы определяем $${\textbf{q}_C=(q_i)_i}$$ - лучший заказ в виде:

$$\textbf{q}_C = \underset{q}{\operatorname{argmax}} \left\{ \sum_i r_i(q_i) \text{ с удовлетворенным $m$ } \forall m\in M \right\}$$
$$\textbf{q}_C = \underset{q}{\operatorname{argmax}} \sum_i r_i(q_i), \text{ с удовлетворенным } m \text{ } \forall m\in M$$

Заказ является “лучшим” в том смысле, что он максимизирует награду при заданном бюджете. Решение $${\textbf{q}_C}$$ не является единственным, однако это соображение является скорее теоретическим, поскольку проблема MOQ слишком сложна для точного решения в любом случае. Для упрощения мы действуем так, будто решение является единственным в следующем.

Наконец, пусть $${T}$$ - это минимальная цель, мы определяем $${\textbf{q}^T}$$ с

$$C^T = \underset{C}{\operatorname{min}} {\left\{ \left(\sum_{q_i \in \textbf{q}_C} t_i(q_i) \right) \geq T \right\}}$$

и

$$\mathbf{q}^T = \textbf{q}_{C^T}$$

Решение $${\mathbf{q}^T}$$ строится на основе $${\textbf{q}_C}$$, то есть это наименьшее оптимальное (с точки зрения бюджета) решение, максимизирующее ROI, которое достаточно хорошо для достижения цели.

Взгляд Lokad на MOQ

Значимость MOQ недооценивается многими компаниями, как со стороны закупок, так и со стороны производства, а также часто поставщиками программного обеспечения, поддерживающими их цепочки поставок.

Со стороны закупок слишком часто заказы просто округляются до следующего MOQ, не оценивая связанные с большим заказом риски инвентаризации и не оценивая также влияние на график заказов. Опытные практики в области цепочки поставок осознают эту проблему и обычно прибегают к обширным электронным таблицам Excel, не имея лучшей альтернативы.

Со стороны производителя MOQ часто определяются размерами партий и/или выбором упаковки на основе “приблизительной оценки”, а не количественного анализа, взвешивающего плюсы и минусы. После принятия MOQ многие производители жестко утверждают свои процессы вокруг этих значений, которые становятся неоспоримым статус-кво. Даже если исходное значение MOQ было хорошим, это может не быть таким через десять лет.

Наконец, поскольку MOQ являются сложной - и часто неправильно понимаемой - числовой задачей, многие поставщики программного обеспечения полагаются на упрощенные правила для их учета, рассматривая их как крайний случай, даже для тех MOQ, которые связаны с большинством заказов, прошедших или полученных. Lokad разработала специализированные численные решатели, которые точно адаптированы для решения проблем MOQ.

Примечания


  1. Терминология жестких и мягких MOQ была придумана в Lokad несколько лет назад, чтобы прояснить проблемы цепочки поставок, поскольку жесткие и мягкие MOQ отражают два довольно различных намерения. Однако некоторые из наших клиентов до сих пор используют термин MOQ, чтобы относиться одинаково к обоим ситуациям. ↩︎