Учет размера минимальной партии – это достаточно сложный вопрос.
Иногда спрашивают: “Как поступать, если раньше закупали по 10, а сейчас можем только по 15? Но, если купим по 15, то позиция может вообще застрять и лежать на складе хотелось бы взять ее поменьше…”
То есть, в этой ситуации увеличилась минимальная партия заказа у поставщика.
Это вопрос из серии: “Как бы так и на елку влезть и жопу не поцарапать?”
Если поставщик вам будет поставлять по 15, то, вообще-то, вариантов у вас нет. Вы пытаетесь договориться с поставщиком о том, что он может вам поставить партию меньшего размера, и, если договориться с поставщиком не получается, то, к сожалению, вы можете только принять решение “рисковать или не рисковать”.
Если нам самим это дорого, то мы можем попытаться купить это на паях с товарищем – найти еще одного потребителя, который такой товар потребляет и закупать вскладчину. Этакий вариант закупочного кооператива. Но принципиально это сути не меняет.
Когда поставщик увеличивает минимальную партию – это серьезная проблема. Чем больше у вас минимальная партия закупки, тем больше у вас “холостого запаса” – запаса, который вы вынуждены хранить просто потому, что меньше вы купить не можете. В результате запас – слишком большой с точки зрения продаж.
Безусловно, это попытка поставщика переложить проблемы с оборачиваемостью вниз по цепочке поставок, но тут уже выбор за тем, кто покупает: если вам это надо – вы это покупаете, если не надо – не покупаете.
Связанный с этим вопрос: “Как устанавливать Целевой Уровень Буфера при небольших продажах, если минимальная партия у нас большая?” Когда минимальная партия у нас вагон, а потребляем мы две бочки (утрирую, конечно – ДЕ).
Такие соотношения бывают в реальных проектах, когда минимальная партия тонна, а потребление за надежный срок пополнения – 120 килограмм.
Как здесь устанавливать Целевой Уровень Буфера?
Оттолкнемся мы от первоначальной исходной посылки: мы обеспечиваем запасы для того, чтобы гарантировать высокую скорость реакции.
То есть для начала мы должны принять решение: хранить эту номенклатуру или не хранить?
Нам надо хранить номенклатуру, если клиент не готов ждать пока мы ее привезем, или готов взять один процент от минимальной партии, а мы не можем привезти и, при этом, это клиент, от которого мы не можем отказаться. Или если это какой-то компонент, без которго мы не можем производить готовую продукцию. В этих случаях, нам надо хранить эту номенклатуру и мы можем переходить к следующим шагам, иначе – возите ее “под заказ”.
Следующий вопрос, который требует ответа: “Что такое “много”, и что такое “мало”?” Сколько нам нужно хранить?
Здесь есть два способа, которыми мы можем себя повести.
Первый способ – установить ЦУБ на уровне максимального потребления и заказывать выше расчитанного ЦУБ, что назвывается в “голубое” или “овербуфер”, но это будет вызывать ненужные вопросы и внимание при анализе управления наличием.
Когда у вас немного номенклатуры, то можно помнить, что этот конкретный артикул мы закзываем так много из-за большого размера минимальной партии, но…. Когда речь идет о тысячах, десятках тысяч, а иногда и о сотнях тысяч точек управления запасами, то всего не упомнишь. И у “большого начальника”, который просто смотрит на состояние наличия, могуть возникнуть вопросы: зачем вы столько заказали?
Поэтому мне больше нравится второй способ, который мы используем в НетСтоке для автоматического расчета рекомендаций ЦУБ.
Мы рассчитываем, где бы у нас находился ЦУБ, если бы у нас не было минимальной партии. Соответственно находим желтую и красную границу, как 2/3 и 1/3 от ЦУБ. Желтая граница – это 2/3 от максимального потребления за срок пополнения, и нам этого количества почти гарантированно хватит до момента, пока приедет следующая партия заказа. И к этой рассчитанной границе желтого мы плюсуем минимальную партию заказа. У нас получается ОГРОМНАЯ зеленая зона. И при анализе наличия, мы видим, что это количество – это НОРМАЛЬНО, несмотря на плохую оборачиваемость.
Ну а дальше мы вполне можем использовать типовые механизмы Динамического управления буфером.