Коротко
- Нужна единая модель доступного остатка и товара в пути.
- Внешняя закупка сравнивается с внутренним перемещением.
- Рекомендации объясняются на уровне SKU × склад.
Какое решение помогает принять материал
Определить функции многоскладской УТЗ и разделить закупку у поставщика, внутреннее перемещение и локальный дефицит.
- Основной вопрос
- как устроена система управления запасами на нескольких складах
- Тематический раздел
- Система управления
Приоритет решения
Сначала: проверить доступность внутри сети и ожидаемые поступления. Затем: рассчитать внешнюю закупку с учётом всей цепочки.
Локальная оптимизация каждого склада по отдельности обычно увеличивает общий запас сети.
Почему несколько складов меняют задачу
Один и тот же SKU может быть в дефиците в регионе и одновременно лежать без движения на другом складе. Поставщики имеют разные плечи, центральный склад ограничен мощностью, а перемещение тоже занимает время и деньги.
Если каждый склад заказывает независимо, сеть теряет эффект масштаба. Если всё решает центр без локального спроса, возникают неправильные распределения.
Функции, которые действительно нужны
- Единый доступный остаток: физический запас минус резервы и блокировки.
- Товар в пути с ожидаемой датой и вероятностью задержки.
- Прогноз на локальном и агрегированном уровнях.
- Политика эшелонирования страхового запаса.
- Рекомендации по перемещению с экономическим порогом.
- Консолидация заказов по поставщику, MOQ и транспорту.
- Журнал подтверждений и ручных исключений.
Единая модель данных
| Сущность | Критичные поля |
|---|---|
| SKU | Единица, упаковка, аналоги, статус, категория |
| Склад | Роль, регион, календарь, ограничения |
| Остаток | Доступный, резерв, карантин, дата снимка |
| Поставка | Поставщик, дата заказа, обещанная и фактическая дата |
| Перемещение | Источник, получатель, время, стоимость, статус |
Как система выбирает между закупкой и перемещением
Сравниваются время до дефицита, доступный избыток на других складах, срок и стоимость перемещения, риск создать дефицит у донора и условия внешнего поставщика. Рекомендация должна показывать обе альтернативы и их последствия.
Для дорогого или редкого товара экономически выгоднее центральный запас с быстрой доставкой. Для хитов — локальное покрытие. Эти правила различаются по сегментам.
Порядок внедрения
Начните с единого определения остатков и статусов товара, затем настройте прогноз и рекомендации на пилотной связке складов. После проверки внешнего заказа добавляйте перемещения и сетевую оптимизацию.
ПроЗапасы может работать как отдельный SaaS-контур или как внедрение поверх 1С/ERP. Формат выбирают после аудита данных и процесса, а не заранее.
Система должна видеть позицию сети, а не только остаток склада
Для решения учитывают доступный остаток, резервы, товар в пути, подтверждённые заказы, потребность других точек и возможность перемещения. Локальный дефицит не всегда требует новой закупки: товар может простаивать на соседнем складе. И наоборот, общий запас сети может выглядеть достаточным, но быть недоступным там, где формируется спрос.
Приоритет между закупкой и перемещением рассчитывается по сроку, стоимости логистики, риску дефицита в донорской точке и ограничениям упаковки.
Объяснимость рекомендации как обязательная функция
Пользователь должен увидеть, какие данные привели к действию: прогноз, горизонт защиты, остаток, поставки, резерв, страховой запас и ограничение поставщика. Рекомендация без расшифровки быстро превращается в ещё одну выгрузку, которую перепроверяют в Excel.
Для руководителя сохраняется журнал: что предложила система, кто изменил решение, по какой причине и каков фактический результат.
Частые вопросы
Нужен ли центральный склад для сетевой оптимизации?
Нет, но должна быть описана роль каждого узла и допустимые маршруты перемещения.
Как избежать избыточных перемещений?
Учитывать полную стоимость, минимальный экономический эффект, время и риск дефицита у склада-донора.
Можно ли начать с выгрузок, а не API?
Да. Для пилота регулярные защищённые выгрузки часто достаточны, если контролируются полнота и дата среза.
Источники и методика
Расчётные примеры в статьях являются учебными, если прямо не указано иное. Они показывают методику, но не обещают такой же результат для конкретной компании.
- SAP Help: Reorder Point Planning Пример связи точки заказа, ожидаемой потребности и страхового запаса.