Учет влияния минимальной партии заказа у Поставщика

Учет размера минимальной партии — это достаточно сложный вопрос.

Иногда спрашивают: «Как поступать, если раньше закупали по 10, а сейчас можем только по 15? Но, если купим по 15, то позиция может вообще застрять и лежать на складе хотелось бы взять ее поменьше…»

То есть, в этой ситуации увеличилась минимальная партия заказа у поставщика.

Это вопрос из серии: «Как бы так и на елку влезть и жопу не поцарапать?»

Если поставщик вам будет поставлять по 15, то, вообще-то, вариантов у вас нет. Вы пытаетесь договориться с поставщиком о том, что он может вам поставить партию меньшего размера, и, если договориться с поставщиком не получается, то, к сожалению, вы можете только принять решение «рисковать или не рисковать».

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

Когда поставщик увеличивает минимальную партию — это серьезная проблема. Чем больше у вас минимальная партия закупки, тем больше у вас «холостого запаса» — запаса, который вы вынуждены хранить просто потому, что меньше вы купить не можете. В результате запас — слишком большой с точки зрения продаж.

Безусловно, это попытка поставщика переложить проблемы с оборачиваемостью вниз по цепочке поставок, но тут уже выбор за тем, кто покупает: если вам это надо — вы это покупаете, если не надо — не покупаете.

Связанный с этим вопрос: «Как устанавливать Целевой Уровень Буфера при небольших продажах, если минимальная партия у нас большая?» Когда минимальная партия у нас вагон, а потребляем мы две бочки (утрирую, конечно — ДЕ).

Такие соотношения бывают в реальных проектах, когда минимальная партия тонна, а потребление за надежный срок пополнения — 120 килограмм.

Как здесь устанавливать Целевой Уровень Буфера?

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

То есть для начала мы должны принять решение: хранить эту номенклатуру или не хранить?

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

Следующий вопрос, который требует ответа: «Что такое «много», и что такое «мало»?» Сколько нам нужно хранить?

Здесь есть два способа, которыми мы можем себя повести.

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

Когда у вас немного номенклатуры, то можно помнить, что этот конкретный артикул мы закзываем так много из-за большого размера минимальной партии, но…. Когда речь идет о тысячах, десятках тысяч, а иногда и о сотнях тысяч точек управления запасами, то всего не упомнишь. И у «большого начальника», который просто смотрит на состояние наличия, могуть возникнуть вопросы: зачем вы столько заказали?

Поэтому мне больше нравится второй способ, который мы используем в НетСтоке для автоматического расчета рекомендаций ЦУБ.

Мы рассчитываем, где бы у нас находился ЦУБ, если бы у нас не было минимальной партии. Соответственно находим желтую и красную границу, как 2/3 и 1/3 от ЦУБ. Желтая граница — это 2/3 от максимального потребления за срок пополнения, и нам этого количества почти гарантированно хватит до момента, пока приедет следующая партия заказа. И к этой рассчитанной границе желтого мы плюсуем минимальную партию заказа. У нас получается ОГРОМНАЯ зеленая зона. И при анализе наличия, мы видим, что это количество — это НОРМАЛЬНО, несмотря на плохую оборачиваемость.

Ну а дальше мы вполне можем использовать типовые механизмы Динамического управления буфером.


Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.