Автопополнение запасов
Система сама следит за остатками всех точек хранения и, когда позиция подходит к порогу, готовит предложение: переместить с соседнего склада или заказать у поставщика. С расчётом на экране и подтверждением в одну кнопку — черновики документов уходят в 1С и ЭДО.
Иллюстрация показывает рабочий контур направления; конкретные шаги и интеграции разобраны ниже.
Как это выглядит без автоматизации
Когда точек хранения больше десяти, картина остатков перестаёт помещаться в голову. Товаровед открывает утреннюю выгрузку, глазами сравнивает десятки тысяч строк и решает, куда что двинуть. Дефицит он видит не в момент возникновения, а через день-два — когда с точки уже позвонили. Дальше начинается спасательная операция: срочная машина, такси, экспресс-перевозчик — за счёт компании.
Дефицит обнаруживается по звонку с точки, а не по данным
Между реальным исчерпанием остатка и реакцией проходит 1–3 дня: выгрузка вчерашняя, руки доходят не до всех групп, часть точек смотрят раз в неделю. Всё это время позиция не продаётся, хотя лежит на соседнем складе в двух часах езды.
Товар есть в сети, но не там, где спрос
Классическая картина сети: на одной точке позиции нет три недели, на другой её запас рассчитан на полгода. Совокупного дефицита нет — есть неверное распределение. Закупщик тем временем оформляет новый заказ поставщику и оплачивает то, что уже куплено.
Срочные доставки съедают маржу тихо
Отдельная машина под одну паллету, догруз чужим перевозчиком, доставка ночью — каждая такая история стоит в разы дороже планового рейса и почти никогда не попадает в аналитику: расход растворяется в общей строке транспорта.
Мониторинг остатков — это чья-то полная ставка
Два-три сотрудника ежедневно тратят по 2–3 часа на сверку выгрузок и переписку с точками. Работа не создаёт ценности: она компенсирует то, что система не умеет сама поднять отклонение к ответственному.
Во что это обходится: Сеть из 26 точек хранения, выручка 48 млн ₽/мес, валовая маржа 25%. Срочные пополнения: 55 в месяц × 5 500 ₽ переплаты ≈ 302 000 ₽. Мониторинг: 3 товароведа × 2,5 часа × 21 рабочий день × 600 ₽/час ≈ 94 000 ₽. Дефицит на точках 4,5% спроса — это 540 000 ₽ недополученной маржи, из них примерно половина приходится на товар, который в этот момент лежал на другой точке той же сети. Итого около 660 000 ₽ в месяц.
Возможности системы
Мы строим контур пополнения поверх ваших систем — 1С, WMS, кассы и каналы продаж. Он непрерывно сравнивает остаток каждой позиции на каждой точке с её нормой и, когда порог достигнут, готовит конкретное действие: перемещение от донора внутри сети или заказ поставщику. Ответственный видит расчёт целиком и подтверждает одной кнопкой — после чего черновики документов создаются автоматически.
Нормы по каждой паре точка–позиция, а не общий мин-макс
Норма считается от продаж именно этой точки, графика подвоза и плеча поставки, а не от среднего по сети. Магазин у вокзала и магазин в спальном районе получают разные нормы по одной и той же позиции — это и есть источник большей части эффекта.
Сначала перемещение, потом закупка
Прежде чем предложить заказ поставщику, система ищет донора внутри сети: точку, где по этой позиции излишек относительно её собственной нормы. Сравнивает стоимость перемещения с ценой закупки и риском заморозить деньги — и выбирает то, что дешевле для компании в целом.
Объяснение расчёта на каждой строке
Карточка предложения раскрывается: текущий остаток, продажи за период, товар в пути, резервы, норма и как она получилась, кто выбран донором и почему, во что обойдётся перемещение. Ответственный проверяет логику, а не верит числу на слово.
Подтверждение одной кнопкой и черновики документов
После подтверждения система создаёт черновик перемещения в 1С или заказ поставщику и отправляет его в ЭДО. Ничего не уходит контрагенту само: документ рождается только из подтверждённого предложения и остаётся под обычным контролем бухгалтерии.
Групповая обработка вместо построчной
Предложения собираются по донору, маршруту и поставщику: подтверждается не 200 строк по одной, а одна отправка целиком. Спорные позиции выносятся отдельным списком — на них и уходит внимание человека.
Контроль исполнения и метрика срочности
Система ведёт подтверждённые пополнения до фактического прихода, напоминает о просрочках и считает две цифры, которых раньше не было: долю срочных пополнений и долю спроса, не закрытого из-за отсутствия товара на точке.
Путь одного события через систему
Каждый шаг оставляет след в журнале: любое решение системы можно открыть и проверить — что пришло, что проверено, что сделано.
Система собирает срез по всей сети
Каждую ночь и далее в течение дня по расписанию подтягиваются остатки всех точек, продажи, товар в пути, резервы под заказы клиентов и подтверждённые ранее пополнения — чтобы не предложить одно и то же дважды.
Считается потребность каждой точки
По каждой паре точка–позиция сверяются текущий остаток и норма с учётом графика подвоза и плеча поставщика. Позиции, которые дойдут до нуля раньше следующего планового рейса, попадают в очередь на действие.
Ищется источник покрытия
Первым делом внутри сети: система находит точки с излишком относительно их собственной нормы и проверяет, что перемещение не создаст дефицит у донора. Если внутри товара нет — формируется потребность к поставщику.
Сравнивается стоимость вариантов
Перемещение попутным рейсом, отдельная машина, плановый заказ или срочный дозаказ — у каждого варианта своя цена и свой срок. Система выбирает вариант, который закрывает потребность к нужной дате с наименьшими затратами, и показывает отклонённые альтернативы.
Ответственный подтверждает
Предложения приходят в веб-панель и коротким дайджестом в мессенджер: сгруппированы по донору и поставщику, с расчётом на каждой строке. Подтверждение, правка количества или отклонение с причиной — причины накапливаются и правят настройки.
Документы и контроль исполнения
Черновик перемещения или заказа создаётся в 1С, заказ поставщику уходит в ЭДО. Дальше система ведёт пополнение до прихода: не собрано, не отгружено, не доехало — отклонение поднимается к ответственному само.
Что происходит по неделям
Каждый этап заканчивается результатом, который вы видите и принимаете. Оплата привязана к приёмке, а не к обещаниям.
Аудит сети пополнения
Собираем карту точек хранения: кто кого снабжает, графики подвоза, плечи и фактическая стоимость рейса и попутного перемещения. Поднимаем историю за год: сколько было срочных доставок и во что они обошлись, по каким позициям и точкам был дефицит, сколько раз товар везли извне при наличии внутри сети.
Правила пополнения и нормы
Согласуем матрицу «что и в каком объёме держим на каждом типе точки», уровни доступности по товарным группам, правила выбора донора и стоп-листы (что не перемещаем никогда — маркированное, крупногабарит, товар под клиентский заказ). Считаем нормы на исторических данных и показываем, как они выглядят по вашим реальным позициям.
Расчётное ядро и объяснение решений
Собираем витрину остатков и движений по всем точкам, реализуем расчёт потребности, поиск донора и сравнение стоимости вариантов. Отдельно делаем раскрытие расчёта: каждая строка предложения должна разворачиваться в понятную человеку логику.
Интеграции и черновики документов
Подключаем 1С или ERP и WMS через API, настраиваем создание черновиков перемещений и заказов поставщикам, подписи и маршруты согласования, отправку заказов через ЭДО. Делаем интерфейс подтверждения: веб-панель и дайджест в мессенджер, роли и права по направлениям.
Пилот на части сети
Запускаем 6–8 точек и 2–3 товарные группы на реальном потоке, остальные ведутся по-старому как контрольная группа. Еженедельно сверяем дефицит, долю срочных доставок и оборачиваемость пилота с контролем, разбираем каждое отклонённое предложение и правим нормы и правила.
Раскатка и сопровождение
Расширяем контур на всю сеть и ассортимент, пересчитываем нормы по мере накопления данных, добавляем новые точки и поставщиков, следим за долей отклонённых предложений — рост этой доли означает, что правила разошлись с жизнью.
Модельный расчёт: из чего складывается эффект
Не «до 90% экономии», а конкретная модель с вводными, которые можно оспорить и пересчитать под себя.
| Показатель | Сейчас | После внедрения |
|---|---|---|
| Срочные пополнения за свой счёт | 55 в месяц | 20–25 (только форс-мажоры) |
| Дефицит на точках | 4,5% спроса | 2–2,5% |
| Реакция на приближающийся дефицит | 1–3 дня, по звонку с точки | в тот же день, по расчёту |
| Доля пополнений перемещением внутри сети | ~12% | 30–35% |
| Время на мониторинг остатков | 2,5 часа в день на товароведа | 30 минут на разбор предложений |
Полная цена владения — три составляющие
Никаких скрытых платежей: внешние сервисы вы оплачиваете напрямую по своим договорам, мы не делаем наценку на чужие тарифы.
Внедрение
- типовой проект: 850 000 ₽
- срок: 8–16 недель
- диагностика, разработка, интеграции, пилот
- документация и обучение команды
Поддержка
- мониторинг и реагирование по SLA
- исправление дефектов бесплатно
- обновление сценариев и интеграций
- ежемесячный отчёт о работе системы
Эксплуатация
- Облако под витрину остатков и регулярный пересчёт (PostgreSQL/ClickHouse): 6 000 – 20 000 ₽/мес
- ЭДО-провайдер для заказов поставщикам (если ещё не подключён): по тарифу провайдера, от 3 000 ₽/мес
- LLM-токены на текстовые пояснения к предложениям (опционально): 1 000 – 6 000 ₽/мес
- число точек хранения и глубина сети: РЦ — магазин проще, чем схема с региональными складами и кросс-докингом
- откуда берётся прогноз спроса: если прогнозного контура нет, расчёт норм внутри проекта добавляет 2–3 недели
- состояние 1С: типовая конфигурация подключается быстро, сильно доработанная требует отдельного обследования обменов
- как уходят заказы поставщикам: выгрузка в 1С, письма, ЭДО или API поставщика — каждый канал настраивается отдельно
- число ролей и маршрутов согласования: одно подтверждение проще, чем цепочка «товаровед — категорийный менеджер — логист»
Участие заказчика
На диагностике достаточно обезличенных примеров. Боевые доступы — только после договора и NDA, через защищённые каналы.
С чем соединяем
Работаем с тем, что у вас уже есть. Если вашей системы нет в списке — скорее всего, подключимся через API: уточним на диагностике.
Как это решение работает в разных бизнесах
Сеть из 22 магазинов и РЦ: подсортировка шла по заявкам директоров точек, кто активнее — тот и получал товар. Система считает норму каждой точки по её собственным продажам и сама предлагает подвоз к плановому рейсу. Срочные машины между точками сократились с 55 до 22 в месяц, полка при этом стала пустеть реже.
Дистрибьютор с центральным складом и 5 региональными: 8 000 SKU, часть позиций одновременно в дефиците в Екатеринбурге и в излишке в Новосибирске. Перемещения между регионами выросли до трети всех пополнений — компания перестала докупать то, что уже лежит на её собственных складах.
Продавец на маркетплейсах с 9 складами FBO и собственным складом FBS: система следит за остатками по каждому складу отдельно, учитывает лимиты приёмки и сроки поставки и предлагает перераспределение до того, как карточка уйдёт в нулевой остаток. Дней с нулём по ходовым позициям стало втрое меньше.
Сеть из 14 сервисов с центральным складом запчастей: раньше при отсутствии детали механик обзванивал соседние точки, а мастер-приёмщик оформлял такси. Теперь система сама видит деталь на соседней точке и ставит её в утренний развоз. Ремонтов в статусе «ждём запчасть» стало вдвое меньше.
Сеть из 16 кафе с заготовочным цехом: пополнение считалось шеф-поварами вечером на глаз, отсюда и стоп-листы по позициям меню, и списания просрочки. Система считает потребность каждой точки от её продаж и оборачиваемости и формирует заявку в цех — стоп-листы стали редкостью, а списания сократились примерно на четверть.
Что обычно спрашивают
Чем это отличается от планирования закупок и прогнозирования запасов?
Мы не готовы, чтобы система заказывала сама. Это обязательно?
Как система решает, перемещать или заказывать у поставщика?
У нас 1С доработана до неузнаваемости. Подключитесь?
Что если товар подтвердили к перемещению, а на точке-доноре его по факту нет?
Сколько точек хранения нужно, чтобы это имело смысл?
Когда это решение не окупится
- меньше ~10 точек хранения или один склад: перераспределять нечего, эффект даст скорее планирование закупок
- остатки сводятся вручную и обновляются раз в неделю: контур будет считать от устаревших данных — сначала нужен оперативный складской учёт
- учёт расходится с фактическим остатком на десятки процентов: любые рекомендации окажутся расчётом от фикции, начинать нужно с инвентаризации и дисциплины учёта
- торговля только под заказ клиента, без собственного складского запаса: пополнять нечего, важнее сроки и цена поставщика
- ожидание, что система заменит логистику: она предлагает и объясняет, но рейсы, приёмку и отгрузку по-прежнему выполняют люди и ваши перевозчики
Если на диагностике расчёт не сойдётся — мы предложим более простой вариант или честно скажем, что автоматизация вам пока не нужна. Это дешевле для всех, чем проект ради проекта.
Прогнозирование запасов
Считает будущий остаток и риск дефицита по каждой паре товар-склад на 8–13 недель вперёд, с учётом сроков поставки, минимальных партий и сезонности. Закупщик видит не остаток на сегодня, а дату, когда товар закончится.
Склад и логистикаАвтоматизация склада
Приёмка, размещение, отбор и инвентаризация превращаются в задания на ТСД, которые система выдаёт по правилам и контролирует по факту сканирования. Работает поверх вашей 1С или WMS — без замены учётной системы.
Финансы и закупкиПланирование закупок
Система считает потребность по каждой позиции — из прогноза спроса, остатков, сроков поставки, минимальных партий и доступных денег — и каждое утро выдаёт план заказа с объяснением каждой строки. Решение остаётся за закупщиком.
Посчитать «Автопополнение запасов» на ваших цифрах?
Пришлите объёмы и пару примеров — вернёмся с картой процесса, честным расчётом экономики и точной сметой. Если не сойдётся — так и скажем.
