Адресное хранение в гипермаркетах: SAP, Big Data и backend приложения в одной системе

В ретейл-проектах масштаба гипермаркета удобное приложение на ТСД — это верхушка айсберга. За экраном, на котором сотрудник видит задачу «пополни полку», стоят три слоя архитектуры, потоки данных между SAP и Data Lake и пять команд, которым нужно не только писать код, но и договариваться друг с другом.

В статье расскажу, о том, как устроена эта система изнутри, какие компромиссы пришлось принять и почему координация команд оказалась не легче самой разработки.

Я работаю в ретейле больше двадцати лет, и за это время успела убедиться: самые дорогие проблемы в магазине — не технические, а операционные. Товар лежит на складе, но не на полке. Покупатель уходит, продажа теряется. Мы с командой Lenta tech (ИТ-бренд «Группы Лента») решили, что пора выстроить платформу, которая сама определяет, какой товар донести до полки, из какой палеты и в каком порядке. Проектную группу собрали из сотрудников разных подразделений: Big Data, SAP, мобильная разработка, онлайн и операционный бизнес. Именно то, что за одним столом сидели инженеры, аналитики и люди, которые каждый день работают в торговом зале, позволило учесть все аспекты — от архитектуры до количества кликов на экране ТСД.

Почему классические процессы перестали масштабироваться

Гипермаркет — это не магазин у дома. Это десятки тысяч товарных позиций (SKU), сотни палет ежедневно и непрерывный поток перемещений между складскими зонами, верхними стеллажами и торговым залом. Ручной поиск товара, бумажные описи на палетах, выкладка «на глаз» — все это работало до определенного момента. Но при масштабах крупной сети процесс перестал справляться.

Главная проблема была не в хранении данных, а в принятии решений. Система понимала, что товар находится в магазине, но не знала, где именно, и выложен ли он на полку. А если не знала — не могла сформировать задачу. Все держалось на памяти и инициативе конкретных сотрудников.

Три слоя архитектуры: что оставили, а что написали с нуля

Архитектурно решение выстроили вокруг трех слоев: система планирования ресурсов предприятия (ERP) на базе SAP, слой больших данных (Big Data) и серверная часть мобильного приложения (backend), написанная с нуля.

SAP уже содержал информацию о запасах товаров. Для адресного хранения команда задействовала уже готовый механизм ячеечного размещения из модуля складской логистики SAP. Перестраивать эту часть не было смысла — она работала стабильно и закрывала задачу учета мест хранения.

Слой Big Data взял на себя аналитику и генерацию задач. Здесь лежит основной объем логики: обработка прогнозов, анализ расхождений между запасом и фактическими продажами, формирование потребностей к пополнению полки. Данные содержатся и обрабатываются в корпоративном хранилище (Data Lake), откуда потребности уходят дальше — в backend приложения.

Backend мобильного приложения — новый компонент, созданный специально для проекта. Команда мобильной разработки отвечала за этот слой с нуля: он получает от Big Data потребности к пополнению, формирует задания для сотрудников, обрабатывает операции изъятия товара из палет и передает информацию о местах хранения обратно в SAP. Помимо этого, backend взаимодействует с системой онлайн-заказов (PDA PickerApp): когда сборщик не находит товар на полке, событие поступает в backend и тоже превращается в задание.

Для директоров магазинов и руководителей секций предусмотрен веб-интерфейс (Web UI), где визуализируются списки задач, отчетность и статистика. Сотрудники торгового зала работают через мобильное приложение «Адресное хранение» на ТСД или смартфоне, где могут фильтровать задания, выполнять сверку ценников и управлять палетами.

Почему legacy не стало препятствием

В крупных ретейл-проектах legacy-системы воспринимаются как неизбежное зло, с которым нужно «бороться». Наши архитекторы пошли другим путем: не боролись, а использовали legacy там, где это было эффективнее.

Решение о том, что оставить на существующих системах, а что вынести в новые сервисы, команда принимала прагматично. SAP отлично справлялся с учетом запасов и ячеечным хранением — зачем его дублировать? А вот логику формирования задач, приоритизацию, аналитику и мобильный интерфейс строили с нуля, потому что здесь нужны были скорость разработки и гибкость, которые legacy-контур дать не мог.

Аналогичный подход сформировали к интеграционным инструментам: на каждом стыке выбирали то решение, которое лучше всего справлялось с конкретным потоком данных. Никакой догматики — только инженерная целесообразность.

Логика задач: прогнозы, приоритеты и пересечения списков

Ключевая логика системы сосредоточена в механизме формирования задач. Эту часть взяла на себя команда Big Data. Нельзя проверить весь ассортимент — ресурс сотрудника ограничен. Поэтому система выдает только наиболее приоритетные задания, и логика их отбора довольно сложная. В продакшне работают несколько видов автоматических задач:

• Событие «нулевого пика» (zero pick). Сборщик онлайн-заказа не нашел товар на полке и ставит отметку в PickerApp. Система проверяет остаток: если он ненулевой, рассчитывает количество к выкладке и создает задание. Это самый «чистый» сигнал — живой человек уже подтвердил, что товара на месте нет.
• Пустая полка. Раз в час Big Data сверяет остатки на основном складе магазина с запасом в палетах. Если эти цифры совпадают, значит, весь товар лежит в палетах — на полке ноль. Генерируется задача.
• Недостаточный запас. Товар на полке есть, но система сопоставляет текущий остаток с прогнозом продаж. Если остатка не хватает для покрытия спроса, формируется задание на пополнение. Здесь важно, что задача возникает не по факту «полка пуста», а на опережение.
• Товары без продаж. Если по позиции в течение недели не было ни одной продажи, система берет товары с наибольшим объемом запаса для каждой секции и собирает из них перечень задач на неделю. Если по позиции уже была отработка — повторно она не добавляется. Логика здесь в том, что большой запас без движения — потенциальный симптом невыложенного товара.

Помимо автоматики, руководящий персонал может создать задачу вручную через Web UI.

Внутри каждого типа работает приоритизация. У нас есть перечни товаров — топы по продажам, топы по маржинальности. Алгоритм берет пересечение этих списков и на их основе определяет, какие позиции требуют внимания в первую очередь. Вычисление пересечений и ранжирование — одна из самых нетривиальных задач с точки зрения логики обработки данных.

«Каждый лишний клик стоит денег»

В крупных корпоративных проектах продуктовое мышление часто отходит на второй план; важнее интеграция, масштабирование, стабильность. Но в нашем случае пользователь — сотрудник торгового зала, и каждое лишнее действие в интерфейсе при тысячах операций в день превращается в колоссальные временные затраты.

Поэтому каждый клик в приложении проектная команда оценивала с позиции «что он дает» против «сколько стоит». Пример такого компромисса: когда сотрудник вытаскивает товар из палеты и фиксирует изъятие в системе, считается, что он донес продукцию до полки. Долгое время обсуждали, нужно ли дополнительное подтверждение выкладки — отдельное сканирование. Отказались: вероятность, что человек достал товар и не донес его до места, минимальна. А еще один клик на каждой позиции — это реальные часы, потерянные на масштабе сети.

Аналогичным образом команды балансировали между точностью данных и скоростью работы во всех сценариях: объединение палет, частичная разборка, перемещение. Адресное хранение — это полноценный инструмент управления палетами в магазине, а не просто учет ячеек.

Пять команд и одна зона неопределенности

Как я уже говорила, проектная группа была собрана из пяти подразделений: Big Data, SAP, мобильная разработка, команда онлайна и операционный бизнес. Каждое было опытным, каждое умело работать по своим задачам. Проблема проявилась на стыках.

Когда в продакшн-среде возникала ошибка, далеко не всегда было очевидно, какое именно подразделение ее допустило. Данные проходят через несколько слоев: Big Data сформировала потребность, backend ее получил, мобильное приложение отобразило задачу, SAP отдал информацию о палетах. Если задание некорректно, нужно пройти всю цепочку и определить, где произошел сбой. Разграничение зон ответственности и процедура разбора инцидентов — то, на что было заложено недостаточно времени на старте. Притирка заняла ощутимый ресурс, хотя ни одна из команд не была новичком.

Синхронизация изменений тоже требовала внимания: когда Big Data меняет логику формирования задач, backend должен корректно обработать новую схему, а мобильное приложение — отобразить результат. Каскадные доработки ускоряли одно звено и ломали соседнее. Со временем процесс выстроился, но в ретроспективе — это одна из главных недооцененных статей расхода по срокам.

Лавина ложных задач и контроль качества данных

Проект работал уже почти год, и серьезных инцидентов не случалось. Затем произошел сбой: из-за ошибки в одном из потоков данных массово сформировались ложные задания на пополнение. Магазины получили лавину задач, сотрудники приходили к полкам и обнаруживали, что товар на месте.

Технически разовая ошибка, но ее воздействие оказалось непропорционально масштабным. Магазины, которые до этого выстраивали доверие к платформе, моментально откатились к скепсису: зачем выполнять задания, если они могут быть ложными?

После этого инцидента команда Big Data совместно с мобильной разработкой и операционным бизнесом выстроила отдельный контур контроля качества данных. На входе проверяется полнота: сколько записей ожидалось и сколько поступило. Результаты сопоставляются со среднестатистическими значениями по магазину. Если фиксируется аномалия — превышение порога отклонений, — конвейер задач останавливается до ручного разбора. Дополнительно внедрили мониторинг потоков: трекинг задержек, разрывов и нестыковок между слоями. Цель — свести вероятность повторения подобного сценария к нулю, а не просто реагировать постфактум.

Волны, feedback loops и продукт, который менялся на ходу

Внедрение разделили на пять волн, и это было осознанным инженерно-процессным решением, а не просто осторожностью.

Первая волна — пилотные магазины, директора которых вошли в рабочую группу. Они не просто тестировали продукт, а участвовали в согласовании технического задания, экранных форм и пользовательских сценариев. Обратная связь приходила быстро, и решение дорабатывалось уже в процессе раскатки.

Циклы обратной связи (feedback loops) работали следующим образом: магазин фиксирует проблему, операционная служба передает ее в проектную команду, разработка вносит изменение, следующая волна получает обновленную версию. Между этими этапами проводится анализ метрик дисциплины и качества отработки задач. Если магазины первой волны показывали низкие результаты, разбирались: проблема в инструменте или в процессе?

Обучение тоже выстраивалось итерационно. Изначально подготовили короткие видеоролики, объясняющие конкретные операции — как разметить палету, как зафиксировать изъятие, как работать со списком задач. По результатам внутреннего опроса удовлетворенности этот формат получил высокую оценку.

Важно отметить: два крупных проекта, требующих перестройки операционных процессов, невозможно вести на одном магазине одновременно. Команда столкнулась с этим ограничением и была вынуждена пропускать вперед параллельные инициативы, которые шли по графику. Это добавило к срокам проекта — вместо запланированных 12 месяцев реализация заняла 17.

Что показал проект

Дополнительная прибыль за 2025 год превысила целевые показатели на 7%. Но, помимо финансовых результатов, проектная группа вынесла несколько важных инженерных и процессных выводов.

Большие ретейл-технологические проекты — это всегда про процессы, а не только про код. Можно написать идеальный backend, но если магазин не размечает палеты, система бесполезна.

Качество данных — фундамент, а не надстройка. Контроль нужно закладывать с первого дня, а не встраивать после первого крупного инцидента.

Архитектура должна учитывать реальную работу людей. Каждый лишний клик — это деньги, и инженерное решение обязано проходить через фильтр продуктового мышления.

И наконец: метрики эффективности нужно проектировать заранее. Проектная команда начала разрабатывать инструменты замера дисциплины уже в процессе внедрения и потратила на это дополнительное время. Без них невозможно отличить ситуацию «гипотеза не работает» от ситуации «магазин не выполняет то, что должен». Именно кроссфункциональный состав команды — инженеры, аналитики данных и операционный бизнес за одним столом — позволил в итоге выстроить эти метрики так, чтобы они отвечали на вопросы каждой из сторон.