Когда старые системы планирования поставок перестают справляться с нагрузкой — частая проблема в современном крупном ритейле. Объемы данных растут, цепочки поставок усложняются, а решения нужно принимать быстрее. В Magnit Tech с этим столкнулись при разработке новой системы F&R (Forecasting & Replenishment — прогнозирование спроса и пополнение запасов). Рассказываем, как компании удалось перестроить систему планирования поставок с помощью сервисов Yandex Cloud, и к каким результатам это привело.
Зачем нужна была перестройка системы
– У «Магнита» десятки тысяч магазинов и распределительных центров. При таком масштабе ключевая задача — точно планировать поставки: товар должен быть на полке, но без излишков. Старая система автозаказа в целом работала хорошо, однако не позволяла решать все растущие новые задачи бизнеса:
Первая задача — прогнозирование спроса с использованием машинного обучения. Это требовало обработки огромных объёмов информации и хранения длинной истории продаж.
– Вторая причина — сквозное планирование всей цепочки поставок. Важно было учитывать движение товара от поставщика до магазина как единую систему, а не рассчитывать каждый этап отдельно. Например, товар может идти из другой страны, затем распределяться по складам и только потом попадать в магазины. Все эти этапы нужно просчитать одновременно, чтобы избежать дефицита или излишков.
– Третья — скорость реакции. В реальности поставки часто отклоняются от плана. Если объём товара оказался меньше ожидаемого, систему нужно пересчитать буквально за минуты и перераспределить товар туда, где он принесёт наибольшую прибыль.
Почему не подошли классические решения
Традиционные системы планирования устроены модульно. Это значит, что прогнозирование, расчет пополнения и пользовательские интерфейсы работают как отдельные блоки со своими базами данных. На практике это приводит к тому, что одни и те же данные копируются между системами, а расчёты замедляются. При небольших объемах это не критично, но в масштабе Магнита речь идёт уже о миллиардах записей и петабайтах данных. В таких условиях классические хранилища данных просто не успевают выполнять расчёты в нужное время. Попытки использовать готовые решения уже предпринимались, но всегда упирались именно в архитектурные ограничения.
Ставка на Lakehouse и ограничения роста
Чтобы справиться с объемами и скоростью, команда выбрала концепцию Data Lakehouse на базе Yandex Cloud. Архитектуру, в которой данные хранятся в едином слое и доступны сразу всем системам. Идея подхода в том, чтобы не копировать данные между модулями, а работать с ними напрямую. При этом вычислительные ресурсы (серверы, которые выполняют расчёты) можно масштабировать отдельно от хранения данных. Это дает гибкость и позволяет ускорять отдельные процессы без перестройки всей системы. Это означало, что прогнозирование, расчет пополнения и аналитика начали работать с одним и тем же источником данных. Архитектура стала проще, а дублирование исчезло.
На этапе прототипа такой подход работал достаточно быстро. Однако при масштабировании возникли вопросы, связанные с особенностью самой технологии. В Lakehouse нет классических индексов (механизмов, которые ускоряют поиск данных), как в традиционных базах данных. Это означает, что при сложных запросах системе приходится просматривать большие объемы информации, и это замедляет работу.
Как следствие — интерфейсы начали отвечать медленнее, что было критично для бизнес-пользователей. К примеру, разные категории товаров требуют разной скорости обработки данных: если для бакалеи достаточно ежедневного пересчета, то для категории Fresh (фрукты, овощи) — оперативность критически важна.
От классического «озера» данных к гибриду
Чтобы решить проблему скорости, в архитектуру добавили отдельную аналитическую базу — ClickHouse (система, оптимизированная для быстрых запросов по большим данным). Lakehouse остался основным хранилищем и местом обработки данных, ClickHouse же стал отвечать за быстрые выборки для интерфейсов, а отдельная база использовалась для транзакционных операций (операции с частыми изменениями данных, например редактирование заказов). Это позволило ускорить работу системы, но сделало архитектуру сложнее. Теперь данные нужно синхронизировать между разными слоями, а разработка и поддержка стали требовать больше ресурсов.
Как менялась модель взаимодействия IT и бизнеса
Проект потребовал перестройки не только технологической архитектуры, но и самой модели взаимодействия команд. На старте в Magnit Tech усилили архитектурную функцию: появились роли Business Architect, Solution Architect и Data Architect. Их задачей стало не только проектирование системы, но и увязка бизнес-процессов, данных, интеграций и инфраструктуры в единую модель работы F&R.
Отдельно усилилось направление Data Engineering. Для системы прогнозирования и пополнения критичны стабильность потоков данных, история продаж, остатки, поставки, промо и логистические ограничения. В результате были выделены отдельные команды, отвечающие за сервисы остатков и управление цепочками поставок.
По мере развития проекта взаимодействие IT и бизнеса становилось более плотным. Команда постепенно переходила от классической проектной модели к продуктовому подходу, где фокус смещается с формального выполнения задач на устойчивый бизнес-результат — доступность товара, снижение излишков и контроль списаний.
Внедрение новых процессов проходило неравномерно. В отдельных командах изменения вызывали сопротивление, особенно там, где сохранялась прежняя модель разработки и взаимодействия. Однако, со временем команды начали лучше понимать зоны ответственности друг друга и выстраивать более рабочую модель взаимодействия.
При этом новые процессы пока не заменили действующие операционные практики полностью. Это следующий этап развития: перейти от пилотного и проектного внедрения к устойчивой операционной модели, где F&R становится штатным инструментом управления запасами во всей сети.
Итоги и выводы: чего удалось достичь уже на этапе пилота
Максимальный эффект по снижению товарного запаса был получен на уровне распределительных центров. Это ожидаемо, поскольку РЦ концентрируют значительный объем запасов и являются ключевой точкой управления товарным потоком между поставщиками и магазинами. При этом положительный эффект наблюдается и на уровне магазинов: улучшается доступность товара, снижаются излишки, повышается оборачиваемость.
В настоящий момент проект еще не завершил стадию масштабирования. Но текущие бизнес-эффекты получены на ограниченном объеме пилота: около 4 000 товаров и 600 магазинов. По результатам трехмесячных A/B-тестов F&R стабильно показывает лучшие результаты по доступности товара и оборачиваемости по сравнению с контрольной группой.
Наращивание результатов: что еще должна ускорить система в будущем
Пока решение работает в рамках ограниченного пилотного контура, поэтому в Magnit Tech осторожно оценивают влияние системы на операционные показатели всей сети. Тем не менее, ожидаемый эффект уже понятен.
- В первую очередь речь идет об ускорении реакции на сбои поставок. Система должна быстрее пересчитывать потребность и перераспределять товарные потоки с учетом фактических остатков, доступности товара и ограничений цепочки поставок.
- Вторая зона изменений — управление заказами. Вместо ручных корректировок и усредненных правил решения о пополнении должны приниматься на основе актуального прогноза спроса и расчетной потребности.
- Третье направление — более быстрая реакция на изменения спроса. Система должна оперативнее учитывать промо-активности, сезонность, изменения ассортимента и отклонения фактических продаж от прогноза.
Фактически речь идет о переходе от более инерционной модели управления запасами к модели, где решения принимаются на основе более свежих данных и централизованных расчетов.
Каким компаниям подойдет такая архитектура
Lakehouse и гибридная модель дают максимальный эффект там, где есть большие объемы данных, сложная логика планирования, высокая частота пересчетов и необходимость одновременно поддерживать машинное обучение, пакетные расчеты и быстрые пользовательские интерфейсы.
Для небольших сетей, например до 10 000 связок товар-локация, классических реляционных баз данных обычно должно быть достаточно для построения системы класса F&R. Такое решение будет проще, дешевле в разработке и сопровождении. Гибридная архитектура становится оправданной, когда один технологический контур уже не закрывает все типы нагрузки: хранение больших объемов истории, тяжелые расчеты, машинное обучение, событийные пересчеты и быстрый интерактивный доступ для пользователей. В этом случае Lakehouse может использоваться как основа для данных и расчетов, а специализированные хранилища, например ClickHouse, — для быстрых витрин и пользовательского UI.
