Большинство компаний с многоуровневыми складскими сетями переплачивают за хранение. Не потому, что плохо считают — а потому что считают правильно, но каждый узел по отдельности.
Проблема: двойная страховка за ваш счёт
Вот как это устроено. Есть центральный склад и десять региональных. Каждый рассчитывает страховой запас самостоятельно, исходя из своего спроса, своих сроков, своего целевого уровня обслуживания. Логика железная. Но результат — системный: региональный склад закладывает страховой запас на случай, если центр задержит отгрузку, а центральный — на случай, если регионы закажут больше обычного. Оба страхуются от одного и того же риска. Оба платят.
Дальше — хуже. Один регион запускает акцию, спрос подскакивает на 20%. Региональный менеджер заказывает у центра не на 20% больше, а с запасом, потому что кто его знает, вдруг тренд продолжится. Центральный склад видит всплеск, причину не понимает, и тоже заказывает у производителя с запасом. На практике разброс в заказах на каждом уровне почти удваивается: исследования показывают, что колебания объёмов заказов растут примерно вдвое на каждый уровень цепочки. Потом акция кончается, спрос падает, а система ещё полтора месяца раскачивается в обратную сторону. В литературе это называют эффектом кнута (bullwhip effect). Мне кажется, любой, кто работал в управлении цепями поставок хотя бы пару лет, сталкивался с этим — просто не всегда называл это так.
Чтобы не рассуждать абстрактно, возьмём конкретную сеть: 1 центральный склад, 10 региональных, спрос 100 единиц в неделю на регион. При стандартном одноуровневом расчёте суммарный страховой запас — 2104 единицы. Это число стоит запомнить, мы к нему вернёмся.
Что делает мультиэшелонная оптимизация и почему она работает
Мультиэшелонная оптимизация (MEIO — Multi‑Echelon Inventory Optimization) — это когда запасы рассчитываются не поскладно, а разом по всей сети. Модель учитывает связи между узлами и ищет конфигурацию с минимальными затратами на хранение при заданном уровне сервиса.
Определение простое. Интереснее разобраться, за счёт чего это даёт экономию.
Главное — объединение рисков (risk pooling). Идея не новая, ей лет пятьдесят, но в контексте запасов она работает очень наглядно. Если спрос в десяти регионах хотя бы частично не синхронен — а он почти никогда не синхронен, — то один страховой запас на центре покрывает ту же неопределённость дешевле, чем десять отдельных страховых запасов внизу. Просто потому, что все десять регионов не испытывают пик одновременно. Здесь работает простой принцип: чем больше точек хранения вы объединяете, тем меньше суммарный страховой запас. Десять отдельных складов требуют примерно в три раза больше страхового запаса, чем один объединённый. MEIO рассчитывает, какую часть этого выигрыша можно реализовать с учётом реальных ограничений сети — расстояний, сроков доставки, минимальных партий. Это не качественная рекомендация типа «консолидируйте запасы» — это конкретные цифры по каждому SKU.
Второй момент — сквозная видимость. При одноуровневом подходе центральный склад видит заказы от регионов, но не понимает, что за ними стоит. Вырос заказ на 30% — это реальный спрос или эффект кнута? Непонятно. MEIO прослеживает спрос от конечного клиента через все уровни. Центр видит не один агрегированный поток, а десять отдельных, каждый привязан к реальному потреблению. На первый взгляд разница косметическая, но она принципиальная.
Третий механизм, который, по моему опыту, даёт основной вклад в экономию: модель оценивает надёжность каждого вышестоящего склада и транслирует это вниз. Если центральный склад хорошо обеспечен — вероятность дефицита на нём низкая, — то региональным складам не нужен дополнительный страховой «на случай задержки с центра». Модель это видит и снижает запас внизу. Эшелоны перестают страховаться друг от друга вслепую. Именно здесь исчезает дублирование, о котором я говорил в начале. Технически это работает так: модель оценивает ожидаемый дефицит на каждом складе и передаёт эту оценку вниз по цепочке. Если наверху дефицит маловероятен, нижестоящие склады получают сигнал снизить свой страховой запас. Чем надёжнее верхний склад — тем меньше запас внизу.
Есть и четвёртый механизм, который часто упускают: стратегическое размещение страхового запаса. Большинство коммерческих MEIO‑решений оптимизируют не только объём запаса, но и место хранения. Модель определяет целевой уровень обслуживания для каждого товара на каждом складе, учитывая разницу в затратах на хранение между уровнями. Результат часто контринтуитивен: оптимально, когда лишь несколько звеньев цепочки держат значительный запас, а остальные работают почти без страхового запаса. Этот подход был внедрён в HP, Intel и P&G.
Вернёмся к нашей сети. MEIO перераспределяет запасы так: центр увеличивает с 599 до 672 единиц (+73), а каждый из десяти регионов снижает со 150 до 117 (–33 на каждый). Итого: 1842 единицы вместо 2104. Минус 12%, уровень обслуживания тот же — 95%.
73 единицы наверх, 330 вниз. Каждая единица, добавленная на центре, позволяет убрать около 4,5 единиц с регионов. Это работает, потому что один центральный страховой запас обслуживает сразу десять направлений, а одновременный пик на всех — событие крайне редкое. В нашем примере эффект усиливается ещё и тем, что модель учитывает нестабильность сроков поставки и неравномерность спроса между регионами. Одноуровневый подход этого сделать не может.
12% — это наш упрощённый пример с двумя эшелонами и одинаковой стоимостью хранения. На реальных сетях с тремя‑четырьмя уровнями и сотнями SKU эффект доходит до 30%. Я видел и 40%, но там были специфические условия — очень длинные цепочки и сильный перекос в стоимости хранения между уровнями.
Что это даёт в деньгах
Например, компания из фармацевтического сектора внедрила MEIO‑решение. Два результата, оба измеримые.
Первый: запасы упали на 20%. Это высвободило 500 млн рублей оборотного капитала. При стоимости капитала 16% годовых — 80 млн рублей экономии в год. Деньги, которые раньше лежали на полках.
Второй: уровень обслуживания (fill rate) вырос на процентный пункт. Запасов меньше, а доступность выше — потому что товар сместился туда, где он реально нужен. Для компании с выручкой 5 млрд рублей один процентный пункт доступности — это 25–50 млн дополнительных продаж. Тут, правда, есть нюанс: точная цифра сильно зависит от категории и эластичности, поэтому я даю диапазон.
Про стоимость. Внедрение (аудит данных, настройка модели, интеграция с системами, обучение команды) — от 20 млн рублей. Лицензия — от 7,5 млн, зависит от масштаба. Поддержка — 22% от лицензии в год. Первый год — от 27,5 млн. Ежегодный эффект — 100–150 млн. Окупаемость — меньше полугода. Для компаний со среднегодовым запасом от 300 млн рублей MEIO окупается за 6–12 месяцев. Ниже этого порога — надо считать индивидуально, стандартного ответа нет.
Практика перехода: где ломается
Дальше — самое важное, потому что красивая математика разбивается о реальность в предсказуемых местах.
Данные. Половина трудоёмкости проекта — не модель, а подготовка данных. Структура сети, сроки поставок, затраты, история спроса. Всё это нужно вытащить, очистить, привести к единому формату. Часто обнаруживается, что данные о lead time — это не факт, а чьё‑то предположение трёхлетней давности. Или что затраты на хранение считаются по‑разному на центральном и региональных складах. Начинать лучше с уровня товарных сегментов, а не отдельных SKU — быстрее всплывают системные проблемы. Отдельная сложность — календари заказов и поставок: модель чувствительна к тому, когда именно узел может сделать заказ и когда реально получает поставку, а эти данные часто не формализованы или расходятся с практикой. В In.Plan мы заложили алгоритмы, которые находят проблемные места в данных и корректируют их, но даже с ними этап подготовки занимает большую часть времени проекта.
KPI. Это главный источник сопротивления, и я не преувеличиваю. MEIO принимает решения, которые ухудшают метрики одного склада ради выигрыша сети. Конкретно: модель может сказать — увеличьте запас на центре на 12% и сократите на регионах на 25%. Руководитель центрального склада, у которого бонус завязан на оборачиваемость, видит в этом рост затрат в своей зоне. Он не будет саботировать, он просто тихо поправит цифру в системе. Потому что его стимулы выстроены иначе. MEIO будет работать на бумаге, но не в жизни.
Доверие. MEIO регулярно выдаёт рекомендации, которые идут вразрез с интуицией практиков. Сократить запас ключевого продукта вдвое? Менеджер с двадцатилетним стажем не будет разбираться в механике модели. Он переопределит значение, и формально будет в своём праве. Обучение и презентации помогают, но не решают проблему. Единственное, что реально работает, — пилот. Берёте две сопоставимые категории. Одну ведёте по‑старому, вторую переводите на MEIO. Через три месяца сравниваете запасы и сервис. Когда команда видит цифры на собственных данных — разговор становится другим. Но пилот должен быть честным: если где‑то MEIO не дал выигрыша, это тоже надо показать. Иначе потом, когда всплывёт первая категория без эффекта, доверие рухнет ко всей системе целиком.
ИТ‑интеграция. MEIO должен быть связан с ERP, WMS, системой прогнозирования. Рассчитанные параметры — страховой запас, точка заказа, min/max — должны публиковаться в подключённые системы автоматически. Ручной перенос убивает скорость реакции модели.
Темп перехода. Даже если модель говорит снизить запас с 500 до 100 единиц — не надо делать это за один цикл. Шагами, с мониторингом сервиса на каждом этапе. Начинать с пилота на ограниченной категории. Результаты пилота — ваш внутренний аргумент для масштабирования. Без этого аргумента продвигать проект на всю сеть политически сложно.
И последнее. MEIO — не проект с датой завершения. Спрос смещается, поставщики меняются, сеть перестраивается. Пересматривать параметры нужно минимум раз в квартал, для быстрооборачиваемых категорий — ежемесячно.
Одноуровневый расчёт работает ровно до того момента, когда в сети появляется второй уровень хранения. Дальше — системное дублирование страховых запасов, и никакой Excel его не поймает. MEIO снимает это дублирование. 10–30% сокращения запасов при сохранении или росте сервиса. Но сама по себе модель ничего не решает. Без качественных данных, без перестройки KPI, без пилота и без терпения эффект останется в презентации.