Какие проблемы решает
- Дефицит ходовых товаров. Система видит, какие товары закончатся раньше, чем приедет следующая поставка, и показывает потерянную выручку в гривнах, пока полка ещё не пустая.
- Деньги, замороженные в излишках. Список товаров и точек, где запаса больше, чем на 90 дней продаж, с суммой по закупочной цене.
- Перекосы между складами. На одной точке лежит лишнее, на другой не хватает. Система предлагает перемещение раньше, чем закупку у поставщика.
- Заказ «на глаз». Количество считается из прогноза, срока поставки, страхового запаса, минимальной партии и кратности упаковки. Заказ уже сгруппирован по поставщику и складу.
- Прогноз, которому никто не верит. Для каждого товара видны точность и систематическое смещение, а модель прогноза выбирается проверкой на истории, а не мнением.
- Второй учёт в Excel. Товары, остатки, продажи и поставки берутся из ERP, решения возвращаются туда документами одной кнопкой.
Для кого
Дистрибуция, розничные сети, интернет-магазины со своими складами, производство с закупкой комплектующих. Система окупается там, где товаров от сотни и больше, точек хранения несколько, а сроки поставки измеряются неделями: именно тогда ошибка в заказе стоит дороже всего.
Что видно сразу после входа
Восемь чисел, по которым руководитель за минуту понимает состояние запасов. В демо-компании (сеть «Мобилус»: 14 моделей телефонов, 5 точек):
| Показатель | Демо | Как считается |
|---|---|---|
| Дефицит | 7 позиций, 1,2 млн ₴ потерь | товар кончится до прихода поставки; потери = дни без товара × спрос × цена |
| Купить | 7 позиций, 3,6 млн ₴ | позиция ниже точки заказа; сумма по закупочной цене |
| Переместить | 85 шт | излишек одной точки закрывает дефицит другой |
| Заморожено | 626 тыс ₴ | запас сверх цели покрытия при покрытии больше 90 дней |
| Деньги в запасе | 7,3 млн ₴ | остаток × закупочная цена |
| Запас, дней | 30 | деньги в запасе / прогнозный расход в день |
| Оборачиваемость | 10,5 в год | себестоимость продаж 12 месяцев / деньги в запасе |
| Точность прогноза | 89 % | 100 % − WAPE, взвешено по выручке |
Ключевые алгоритмы
Ниже то, что обычно скрыто в «чёрном ящике». Каждое решение системы раскладывается на эти шаги и проверяется руками.
1. Подготовка данных: спрос, а не продажи
Продажи и остатки берутся по дням, по каждому товару и каждой точке. Возвраты не считаются спросом. Главная поправка: дни без остатка. Если товара не было на полке, продажи были нулевыми не из-за отсутствия спроса. Когда товар был в наличии n дней из N дней месяца (и хотя бы треть месяца), спрос месяца пересчитывается как продажи × N / n.
Без этой поправки каждый дефицит занижает следующий прогноз, система заказывает меньше, и дефицит повторяется. Это самая частая причина, по которой «прогноз в Excel» не работает.
2. ABC/XYZ: значимость и предсказуемость
- ABC по выручке за 12 полных месяцев: товары сортируются по убыванию, A набирают первые 80 % выручки, B следующие 15 %, C оставшиеся 5 %.
- XYZ по коэффициенту вариации помесячного спроса (стандартное отклонение / среднее): X меньше 10 %, Y от 10 до 25 %, Z больше 25 %.
- Пороги меняются в настройках, пересчёт мгновенный.
Сегмент здесь не отчёт ради отчёта: от него зависит страховой запас. Чем важнее товар и чем менее предсказуем спрос, тем больше дней запаса система держит сверх срока поставки.
| Сегмент | Страховые дни | Стратегия |
|---|---|---|
| AX, BX | 7, 5 | автозаказ, запас только на риск задержки поставки |
| AY, BY | 10, 7 | обязательный страховой запас на колебания спроса |
| AZ, BZ | 14, 10 | под заказ и жёсткий контроль: дефицит здесь стоит дороже всего |
| CX | 3 | заказывать реже и крупнее |
| CY, CZ | 3, 0 | кандидаты на пересмотр ассортимента |
В демо 3 модели сегмента AY дают 52 % выручки, ещё 2 модели AZ дают 36 %. Восемь из четырнадцати товаров вместе приносят меньше 10 %: на них не стоит держать деньги.
3. Прогноз: модель выбирает проверка на истории
Прогноз строится на 12 месяцев вперёд по каждому товару тремя моделями:
- скользящее среднее за 3 месяца: быстро реагирует на изменения;
- скользящее среднее за 6 месяцев: устойчиво к шуму;
- тренд × сезонность (при истории от 15 месяцев): линейный тренд считается по ряду, очищенному от сезонности, а индексы сезонности по календарным месяцам нормируются к единице. Тренд и индексы уточняются друг через друга за несколько проходов, иначе неполный год в истории (пик декабря только у одного края) перекашивает наклон. Тренд гасится: через год прогнозный уровень не уходит дальше 0,5–1,6 от текущего.
Какую модель взять, решает бэктест. Система отрезает последние 6 месяцев, строит прогноз каждой моделью по более ранним данным и сравнивает с фактом. Побеждает модель с наименьшей ошибкой WAPE. Пример из демо, iPhone 11 с выраженными пиками в сентябре и декабре:
| Модель | WAPE на бэктесте |
|---|---|
| Среднее 3 мес | 28,2 % |
| Среднее 6 мес | 20,5 % |
| Тренд × сезонность | 18,4 %, выбрана |
Прогноз считается на уровне товара, а по точкам распределяется по их доле в спросе за последние полгода. Ряды «товар × точка» слишком шумные для собственной сезонности, а сумма по сети даёт устойчивую форму.
4. Точность прогноза
WAPE = Σ|прогноз − факт| / Σ факт: средняя ошибка в долях от продаж;Accuracy = 100 % − WAPE: зелёная от 85 %, жёлтая 70–85 %, красная ниже 70 %;BIAS = Σ(прогноз − факт) / Σ факт: систематическое завышение (плюс) или занижение (минус);- MAE в штуках, окно оценки совпадает с окном бэктеста.
Точность компании взвешивается по выручке: ошибка на дорогом ходовом товаре важнее ошибки на копеечном. В демо она 89 %.
5. План: прогноз, цель года и ручные правки
- Цель года (top-down): руководитель задаёт сумму продаж на 12 месяцев, система делит её по товарам пропорционально их доле в выручке, а по месяцам раскладывает по форме прогноза.
- Ручная правка любого месяца по любому товару кликом в ячейке. Ручное значение имеет приоритет над расчётом и помечается цветом.
- Каждый пересчёт сохраняется как версия плана, последние пять доступны для сравнения.
6. Сколько и когда заказывать
Расчёт делается для каждой пары «товар × точка»:
d = план на ближайшие ~45 дней / число дней × доля точки (дневной спрос)
L = срок производства + срок доставки (lead time, дни)
SS = d × страховые дни сегмента ABC/XYZ (страховой запас)
ROP = d × L + SS (точка заказа)
P = на складе + в пути (открытые поставки и перемещения ERP) (позиция)
T = d × (L + цикл заказа + страховые дни) (цель покрытия)
дефицит если P − d × L < 0 (товар кончится до прихода поставки)
купить если P ≤ ROP
излишек если P / d > 90 дней
к заказу = max(T − P, MOQ), вверх до кратности упаковки, не больше макс. партии
потери = дни без товара × d × цена продажи
заморожено = (P − T) × закупочная ценаРазбор на реальной строке демо. Xiaomi Redmi Note 9 Pro, Магазин «Мобилус», сегмент AY:
| Величина | Значение |
|---|---|
| Дневной спрос по плану | 2,75 шт |
| Срок поставки | 21 день, цикл заказа 14 дней, страховых дней 10 |
| На складе / в пути | 13 / 0 шт |
| Нужно до прихода поставки | 2,75 × 21 ≈ 58 шт |
| Страховой запас | 2,75 × 10 ≈ 28 шт |
| Состояние | дефицит: 13 шт хватит на ~5 дней, товара не будет 17 дней |
| Потерянная выручка, если не заказать | 17 × 2,75 × 8 499 ₴ ≈ 397 тыс ₴ |
| Цель покрытия | 2,75 × (21 + 14 + 10) ≈ 124 шт |
| К заказу | 124 − 13 = 111 → кратно 5 → 115 шт, 793 500 ₴ |
Ровно эти числа пользователь видит в карточке товара: решение не нужно принимать на веру.
7. Перемещения раньше закупки
Для каждого товара система находит точки-доноры (излишек при живом спросе) и точки-получатели (сначала дефицит, потом «купить»). Получателю переносится min(нужно до цели, излишек донора) с самого большого донора. Если перемещение закрывает потребность полностью, закупка отменяется, если частично, сокращается. В демо так перераспределяется 85 телефонов, которые иначе пришлось бы покупать заново, пока они лежат на соседнем складе.
8. Скорость и актуальность
Данные из ERP подтягиваются каждые 15 минут, пересчёт запускается после синхронизации и после каждой правки параметров. Полный расчёт демо (14 товаров × 5 точек, 25 месяцев истории по дням) занимает 0,1–0,2 секунды; объём работы растёт линейно с числом пар «товар × точка».
Интеграция с ERP
Ритм не заводит второй учёт. Справочники, остатки, продажи и поставки живут в ERP (в демо это наша Forma), Ритм читает их и возвращает решения документами:
- выгрузка данных: товары, склады, поставщики, остатки, продажи по дням, открытые поставки и перемещения (они учитываются как «в пути»);
- черновик поставки: поставщик, склад, строки товаров с количеством и ценой, одной кнопкой из карточки заказа;
- черновик перемещения между складами;
- вход без отдельных паролей: если человек вошёл в ERP, он уже в Ритме (одноразовый подписанный токен).
Все запросы подписаны общим секретом (HMAC-SHA256). Документы создаются штатными механизмами ERP, поэтому оплата, доставка и приход идут привычным порядком, а Ритм лишь читает их статус. Для другой учётной системы (1С/BAS, Odoo, собственной ERP) реализуются те же три операции.
Интерфейс
Шесть экранов: решения, товары, план, матрица, документы, параметры. Текста минимум: состояние показывает цвет, решение объясняется числами, главные действия делаются в один клик. На телефоне работает так же, навигация уходит вниз.
Как внедряем
| Этап | Что делаем | Что нужно от вас |
|---|---|---|
| 1. Данные | подключаем ERP, проверяем полноту истории, чистим возвраты и дубли | доступ к ERP или выгрузка продаж и остатков по дням за 12+ месяцев |
| 2. Модели | настраиваем пороги ABC/XYZ, страховые дни, сроки и MOQ поставщиков, проверяем точность на вашей истории | условия поставщиков: сроки, минимальные партии, кратность |
| 3. Пилот | одна категория или один склад, сравнение рекомендаций с текущими заказами | ответственный за закупки на 2–4 недели пилота |
| 4. Развёртывание | все товары и точки, документы уходят в учёт автоматически, обучение команды | решение по регламенту заказа |
Срок и стоимость считаем после первого этапа: они зависят от ERP, числа товаров и качества истории. Систему ставим в вашем контуре или у нас, исходный код передаётся по договору.
Что настоящее, а что демо
- Настоящее: все алгоритмы и расчёты на сервере, вход через ERP, справочники и остатки из демо-аккаунта ERP, документы реально создаются в ERP.
- Демо: история продаж за 25 месяцев сгенерирована (в демо-аккаунте её нет), компания «Мобилус» вымышленная.
Посмотреть систему: frontend-logistic2.ingello.com (открывается без входа в режиме просмотра). Презентация: landing-logistic2.ingello.com. Обсудить внедрение: консультация с архитектором.
Похожее решение: platFORMA - продвинутая система для отделов Вашей компании.
