Группа М.Видео-Эльдорадо в начале 2021 года представила стратегию Hacking Retail. За 5 лет мы планируем увеличить общий товарооборот вдвое до 1 трлн рублей и в три раза расширить ассортимент, в том числе за счет развития собственного маркетплейса. Обеспечить этот рост в короткие сроки «монолитные» ИТ-системы не способны, а нестандартные разработки замедляют весь процесс. На помощь приходят микросервисы. Рассказываем, как мы «отпилили» кусочек от SAP ERP, и что из этого вышло.
Пару лет назад мы завершили процесс слияния бэк-офисов «М.Видео» и «Эльдорадо». В итоге объединенная ИТ-инфраструктура торговой сети стала представлять собой трехслойную конструкцию: на первом уровне объединенный бэк-офис, основной учетной системой которого является «монолитная» SAP ERP.
Над ним располагается постоянно расширяемая микросервисная платформа, которая предоставляет ключевые данные всем фронт системам (цены, промоакции, товары, остатки, информацию о клиентах и т.п.) и обеспечивает интеграцию фрон-систем с бэк системами. «Наверху» эта схема венчается двумя раздельными фронт-офисами для каждого из брендов.
В целом эта связка удовлетворяет текущим потребностям бизнеса. Но они постоянно растут, так что мы находимся в непрерывном поиске неоптимальностей, устранение которых могло бы повысить производительность бизнес-процессов и подготовить их к увеличению нагрузки.
Готовиться надо серьезно. У М.Видео-Эльдорадо большие планы по расширению ассортимента товаров и запуску новых проектов. Ожидаемый рост объемов поставок должен составить два-пять раз. И не когда-нибудь, а в течение ближайшего года-двух.
Долгие часы ожидания
Одним из узких мест, которое следовало устранить как можно скорее, был алгоритм расчета логистических календарей. Поясним чуть подробнее. Существует понятие логистической доступности. Она определяет то, в какой момент из точки А в точку Б может быть доставлен товар. Параметр логистической доступности используют все фронт-офисы, к нему обращаются бизнес-приложения и т.д. – это один из основных параметров товара как логистической единицы.
Календарь содержит полную информацию о возможности перемещения товаров между поставщиком, центральными и региональными складами и магазинами в обеих сетях. Если отгрузка товара запланирована на сегодня, используется «сегодняшний» календарь. Но завтра он уже потеряет актуальность и применять надо будет «завтрашний».
Для повышения устойчивости работы логистических процессов расчет выполнялся ежедневно на три дня вперед. Это решение довольно давно было поставлено “костылем” в SAP ERP в силу скорости реализации. Процесс занимал 9-11 часов! Тестирование под более высокой нагрузкой показало, что система не может справляться с расчетом даже за 24 часа. Для достижения качественно большей продуктивности при значительном увеличении объемов важно было вывести этот сервис из монолита…
Текущая ситуация
Входящий в состав SAP ERP алгоритм расчета логистических календарей представлял собой пакет PL/SQL-процедур, предоставляемых SAP в виде кастомизированного коробочного решения. Расчет каждого из трех календарей в нем выполнялся «с нуля», с учетом всех условий для каждой логистической цепочки. Соответственно, большая часть вычислений на каждом этапе просто дублировали друг друга. Такова была логика работы продукта, а ресурсов на полноценное устранение техдолга у нас не было.
Кроме того, алгоритм оставлял в готовых календарях дублирующиеся «мусорные» цепочки поставок. Это вело к росту объема базы данных. Вместо необходимых 10 млн записей БД могла содержать 20-30 млн и требовала ручной чистки.
К такому неоптимальному состоянию исходный инструмент пришел не за один день. Он был внедрен очень давно, и на протяжении всего периода эксплуатации в него вносились многочисленные доработки, инициированные бизнес-заказчиками. Многолетний поток постепенных изменений привел к появлению разных неточностей, часть которых не была в полной мере отражена в спецификациях.
При этом речь шла о критически важном инструменте бизнеса, от работоспособности которого зависела деятельность сотен магазинов торговой сети. Поэтому подходить к развитию продукта следовало очень осторожно, но оперативно.
Отгрызть кусочек «монолита»
Поняв, что потенциал роста продуктивности SAP ERP по данному направлению (кстати, не свойственному для ERP сервису) исчерпан, мы обратились к микросервисам. М.Видео-Эльдорадо развивает это направление уже несколько лет.
У нас есть собственная микро-сервисная платформа, на которой работает больше сотни микросервисов. Надо было создать еще ряд сервисов, основанных на том же алгоритме, что и исходный модуль ERP-системы. Мы хотели, сохранить общую логику расчетов, но уйти от повторения одних и тех же процессов.
Работу выполняли по трем основным направлениям. Во-первых, надо было оптимизировать алгоритм SAP за счет исключения из него лишних расчетов. Во-вторых, требовалось исключить появление дублирующих цепочек поставок, приводящих к накоплению в базе данных ненужных записей. В-третьих, необходимо было устранить неточности в результатах работы исходного алгоритма, затрудняющие оптимизацию бизнес-процессов.
Напомним, что SAP ERP – одна из основных бэк-систем компании, в которую поступают данные от всех фронт-систем. Несмотря на то, что расчет календарей требовалось перенести в микросервисы, сами отдельные шаги закупки, перемещения товара все равно создавались именно в центральной учетной системе.
Для генерации логистических календарей SAP ERP предоставляет более 20 таблиц с настройками, полученными от бизнес-пользователей. Именно на основе этих данных микро-сервисная платформа выполняет расчеты. Сама ERP также использует их для внутренних расчетов при создании вторых и третьих плеч доставки. Поэтому просто целиком вырвать процесс из монолита и перенести было нельзя.
Схема процесса:
1 и 3 – Процесс через SAP PI получает от SAP ERP данные с настройками для расчета календарей;
2 и 4 – Запись полученных от ERP данных в БД;
5 – Процесс берет одну из версий данных, хранящихся в его БД (по умолчанию – самую последнюю версию). После этого он рассчитывает календари на основе этих данных и сохраняет их в промежуточную таблицу. В ходе работы процесс обращается за информацией по объектам.
6 – Данные переносятся из промежуточной таблицы в продуктивную в том же формате, в котором процесс получает их из SAP ERP.
7 – Удаление старых данных с настройками календарей из БД.
Инструменты, время, ресурсы
Так как созданием микросервисов мы занимаемся не первый год, особых сомнений в выборе средств разработки у нас не было. В дело пошла хорошо освоенная связка Java 11 и Spring Boot
2. Никакой магии в коде, только стандартные для Java вещи – коллекции, интерфейсы и пр.
Новый алгоритм мы изначально построили так, чтобы все операции с таблицами полностью выполнялись в оперативной памяти, а не с помощью SQL-запросов внутри базы данных.
Со стороны команды эксплуатации SAP ERP была проведена подготовка к передаче в микросервисную платформу мастер-данных для расчета календарей. На это ушло около 40 часов.
В дальнейшем с их стороны требовалось лишь сопровождение проекта. Основная работа, конечно, легла на плечи инженеров самой платформы. Логика алгоритма была создана, по сути, заново. Из ERP были взяты только мастер-данные и основные бизнес-принципы расчета календарей. На это потребовалось еще 150 часов.
В целом реализация проекта заняла около полугода. На одни только многочисленные автотесты, основанные на разных подходах, мы потратили два месяца. Еще около месяца продолжалось пилотирование нового инструмента. В этот период мы параллельно рассчитывали два вида календарей – старый и новый, изучали и сравнивали результаты, критически важно было убедиться, что сервис не ухудшился и расчет идет верно. Только после этого было принято решение о переносе нового инструмента в продуктивную среду.
Результаты
Что же мы получили в итоге? Календарь теперь рассчитывается только один раз. Затем его экземпляры для каждого из трех дней получаются в результате небольших дополнительных вычислений, связанных с изменением дат. Объем базы данных автоматически поддерживается в оптимальном состоянии благодаря отсутствию “костыльной” надстройки, уменьшилась нагрузка на ERP-систему.
Но главный результат, которого нам удалось добиться, – сокращение времени генерации календаря с 9-11 часов до… 10 минут! Впереди много работы, будущий кратный рост нагрузки на ИТ-инфраструктуру еще потребует доработок, но этот кусочек техдолга мы победили.
