Антон Антоничев: Симфония систем. Как METRO интегрирует данные для эффективной работы
Антон, какие основные вызовы вы видите в интеграции различных систем, таких как ERP, WMS, TMS и CRM, в логистику сети METRO?
В компании METRO существуют два основных логистических потока: Primary — это когда товары поступают в торговый центр для дальнейшей продажи, и Secondary — когда товары из торгового центра доставляются клиентам. Secondary, в свою очередь, разделяется еще на два потока, поскольку у нас две категории клиентов: B2C и B2B – рестораны, отели, офисы, независимая розница и т. д. В логистике сети METRO мы используем все перечисленные вами инструменты. В ERP — системе управления предприятием – в нашем случае хранится информация о товарах и запасах. WMS – система управления складом – позволяет отслеживать местонахождение конкретного товара и определять, какой товар нужно собрать для отправки в торговый центр. Это решение может использоваться для нескольких логистических потоков. Например, Central Stock: когда на складе хранится большое количество товара, несколько торговых центров могут заказать по две-три палеты и система распределит товар соответственно. С этого склада пополняются запасы, есть также процесс BBXD, где товар разбирается на коробки и для магазина собирается палета с набором разных товаров. Всеми этими процессами управляет система WMS.
В свою очередь, TMS – система управления транспортом – отвечает за перемещение товара из точки А в точку Б и управление этим процессом. Это скорее бизнес-процесс, чем ИТ-система. TMS применяется как в Primary-логистике, когда товары загружаются в фуру и едут на склад, так и в Secondary – для клиентской доставки, где используется уже другая система. Например, в фуру загружаются товары для пяти клиентов, и для этого грузовика выстраивается оптимальный маршрут, чтобы он мог посетить все пять точек в течение дня.
А CRM-система не связана напрямую с логистикой, она работает с клиентами. У нас есть разные категории клиентов – оптовые, розничные, и CRM хранит информацию о каждом из них, что позволяет выстраивать правильную коммуникацию, информировать о новинках и акциях.
Можно ли какую-то из систем заменить или исключить?
Заменить CRM на WMS нельзя, так как это совершенно разные категории систем с различной механикой работы. Можно ли исключить? Ответ – скорее да, чем нет. Смысл применения ИТ-системы — в повышении эффективности работы организации. Теоретически можно вручную бегать по складу и отмечать товары карандашом, но тогда через неделю со складом что-нибудь случится. Для малых и средних организаций это, возможно, еще приемлемо, но в крупных организациях это приведет к серьезным расходам и проблемам.
Как вы объединяете базы данных этих систем? Есть ли трудности при объединении данных, как вы их анализируете?
Ответ прост: у нас есть системы BI, куда стекаются данные из всех этих систем и не только. Далее на основе этих данных строится аналитика либо по одной, либо по нескольким системам одновременно. В разных системах используются технологии разных поколений. На данный момент у нас существует два параллельно работающих ландшафта. Старый ландшафт представляет собой монолитные приложения — большие и тяжелые, с которыми сложно интегрироваться. Второй ландшафт, современный, рассчитан на работу в облачных средах и построен на базе микросервисов, взаимодействие с ним изначально предполагает интеграцию. Проблема старых ландшафтов в том, что при их создании не предусматривалась гибкая интеграция с другими системами, они связаны друг с другом и обмениваются данными, но добавлять новые потоки сложнее.
Как часто обновляются эти программы? Если одна обновляется чаще, а другая реже, может ли возникнуть десинхронизация и потеря данных?
Потери данных не происходит. Основа — это бизнес-процесс, а не система. Если процесс динамичен и в нем регулярно проводятся изменения, то система подстраивается под него. Система — это средство автоматизации процесса, она позволяет сделать его эффективным и контролируемым.
Изменения бывают трех видов. Первые связаны с изменениями в законодательстве и обязательны к выполнению. Например, введение маркировки на молочную продукцию. Такие изменения вносятся независимо от планов релизов. Вторые обусловлены изменением процессов, например внедрением нового типа логистического потока или новой бизнес-модели. Третий вид – замена одной системы на другую по окончании ее жизненного цикла. Систем 10-летней давности, которые бы не менялись, просто не существует – они меняются регулярно, причем изменения обычно затрагивают не одну, а несколько систем одновременно. При выводе любой из эксплуатации все связанные с ней также меняются, дорабатываются или заменяются. Вывод обычно происходит из-за устаревания технологий, но чаще всего потому, что замена системы оказывается дешевле, чем ее модернизация. Часто это связано с тем, что технология настолько устарела, что ее трудно дорабатывать. Либо бизнес развился настолько, что старая система уже не справляется с нагрузкой, и тогда ее заменяют на более зрелую и мощную как с точки зрения скорости работы, так и развития ее функционала на будущее.
Таким образом, у системы не бывает финального состояния, она динамична и всегда «жива». Кроме того, есть отдельный тип изменений, связанный с обеспечением безопасности и защитой от угроз.
Можете ли вы привести пример конкретного проекта интеграции данных, который был успешно реализован в METRO, и какие результаты он принес?
Эта история связана с появлением в МЕТRO в 2019 году электронной коммерции. Задача стояла следующая: нужно было интегрировать новый цифровой продукт от партнера — компании «Купер» (бывший «Сбермаркет»), которая обеспечивает нам доставку клиентам. Первая проблема заключалась в необходимости оперативно передавать информацию на витрину электронной коммерции. Прежде всего об артикулах – фото, описание; во-вторых – цены, которые меняются в течение дня; в-третьих – остатки: наличие товаров в торговых центрах, где будет проходить сборка заказа. Эта информация должна была передаваться в реальном времени с задержкой максимум в час. Мы не хотели показывать клиенту товар, который уже закончился утром. Эти интеграционные потоки в режиме реального времени нужно было каким-то образом реализовать – на тот момент у нас такого механизма не было.
Еще одна проблема заключалась в том, что у нас в то время был старый ИТ-ландшафт, который управлял остатками и ценообразованием. Ситуация осложнялась тем, что «Купер» – это внешняя компания. Мы разработали несколько облачных сервисов – своего рода посредников, которые, с одной стороны, видны партнеру, а с другой — умеют работать со всеми типами наших ландшафтов, собирая в себе всю необходимую для партнера информацию. Есть несколько систем, из которых отбираются эти данные, они разного «возраста» и имеют разные возможности онлайн-взаимодействия. Всё это работает в режиме реального времени.
Данный кейс позволяет решать важную задачу. Дело в следующем: если появляются новые продукты, то в систему ценообразования я должен передать определенный набор данных, например информацию о текущих продажах. Кроме того, нужен отчет для e-commerce, чтобы клиент мог зайти в приложение и посмотреть свои покупки. То есть две совершенно разные категории продуктов, но им нужна одна и та же информация. Как бы мы сделали раньше? Создали бы две отдельные интеграции. Сейчас же все данные можно получить из единого интеграционного слоя. Если появится новый партнер по сборке, мне не нужно будет создавать новую интеграцию, я просто предоставлю ему доступ к уже существующему сервису, где есть вся необходимая информация. А если каких-то данных не хватает, мы их добавим.
Эту платформу мы разрабатывали несколько лет, и в итоге она позволяет нам быстро интегрировать новые бизнес-процессы, даже те, которые изначально не планировались. Например, значительно упростился запуск российской кассовой системы, которой нужны данные о ценах и клиентах, и теперь она получает их из нашего сервиса.
Как обучаете и поддерживаете свою команду в процессе внедрения и использования интегрированных систем? Ведь у вас целые дивизионы отвечают за сборку и другие операции?
Люди, которые работают с системами, не видят интеграционных процессов. Для них важно, что стало удобнее работать. Если говорить не про ИТ, а про e-commerce, то благодаря этой интеграционной платформе, которую мы разработали, сборщик собирает заказ, нажимает кнопку «Я собрал» – и выходит из магазина. Ему даже не нужно стоять на кассе и пробивать товар. А нам не нужно учить его пробивать товар, поскольку кассы для сборщика в принципе больше нет – всё автоматизировано под капотом.
С точки зрения логистического ландшафта – при доставке B2B-клиентам у нас используется мобильная касса. Там есть определенный интерфейс: можно сделать коррекцию заказа, если он принимается не полностью, принять оплату товара, если она производится при получении. Лучший интерфейс приложения тот, для которого не нужна инструкция. Мы стараемся избежать необходимости инструкций, потому что наша задача – сделать продукт интуитивно понятным. В последние годы у нас на этом особый акцент, наша цель — создать не только красивый и современный, но в первую очередь понятный интерфейс.
Сотрудника можно обучить, но сотрудники меняются, а новых нужно заново обучать. Зачастую новичок, не понимая, куда и какую кнопку нажать, теряет свое рабочее время. Но теряется также и время сотрудника, который его обучает, а это, как правило, опытный и высококвалифицированный специалист, мы отвлекаем его от основного рабочего процесса. В результате страдает эффективность. Чем понятнее приложение, тем эффективнее мы используем время и деньги.
Сотрудничаете ли вы с внешними партнерами или консультантами для реализации проектов по интеграции данных? Если да, то как вы их выбираете?
С консультантами мы стараемся не сотрудничать, поскольку у нас есть внутренняя экспертиза и мы ее постоянно развиваем. Что касается разработки, сотрудничаем с партнерами, которые помогают нам в создании программного обеспечения. Важно различать консультантов и партнеров. К первым мы обращаемся, когда не понимаем, что делать, или хотим посмотреть лучшие практики, а ко вторым – когда нужно привлечь дополнительные ресурсы, например временно расширить команду для работы над каким-то продуктом. Бывает, что на три–шесть месяцев нужно увеличить команду, чтобы справиться с накопившимися задачами. Для этого мы и пользуемся ресурсами партнеров.
В разных проектах мы сотрудничаем с разными партнерами в зависимости от поставленных задач. С технологической точки зрения продукты довольно сильно отличаются друг от друга. Исходя из этого, во-первых, у партнера должен быть опыт работы с технологическим стеком, который используется в продукте, он должен «говорить с продуктом на одном языке». Во-вторых, мы ожидаем от партнера практического опыта в реализации похожих идей, которые у нас уже были, – не хочется тратить время, пока он сам научится делать то, что нам нужно. А еще хуже, если партнер с нашей помощью приобретет новую экспертизу, а затем выйдет на рынок для продажи этих знаний кому-то другому. Поэтому при подборе партнеров мы в первую очередь обращаем внимание на их практический опыт и профессионализм.
Еще один из критериев выбора – наличие у партнера пула ресурсов. Бывает, партнер приходит без базовых ресурсов, начинает их под нас искать, и мы теряем месяц работы. Показатель Time To Market никто не отменял, поэтому нам важно, чтобы партнер был готов быстро включиться в проект.
Как решаете вопросы безопасности и конфиденциальности данных при интеграции различных систем? Как управляете рисками?
Безопасность — наш главный приоритет. Существуют различные риски в этой сфере, выделю три основные категории. Первая — защита персональных данных как клиентов так и сотрудников. Вторая — коммерческая тайна, когда некоторые соглашения с поставщиками являются конфиденциальной информацией и не должны раскрываться на рынке с точки зрения защиты конкуренции: например, условия контрактов, закупочные цены. Третья категория — защита от внешних угроз (атак хакеров) для предотвращения помех в работе организации.
По всем трем направлениям у нас четкое понимание, что и где нужно делать. Мы используем различные методики. Если рассматривать персональные данные, то фокус защиты направлен на предотвращение утечки данных, а если речь идет о внешних угрозах, то осуществляется работа с антивирусами и контроль сети. С точки зрения кибербезопасности мы проводим регулярное обучение сотрудников по этой теме. Нам важно, чтобы каждый понимал: существуют ситуации, когда злоумышленником отправляется фейковое письмо с просьбой ввести логин и пароль для расширения объема памяти почтового ящика, например. На самом деле настоящая цель — кража логина и пароля.
Системы безопасности – единое целое, но представляет собой набор мер. И это не всегда ИТ-продукт. Существуют антивирусы, выступающие одним из элементов безопасности, они обновляются в круглосуточном режиме. Есть комплексы мер по защите персональных данных, которые в первую очередь касаются управления развитием других продуктов по конкретному списку критериев, которым должны соответствовать эти продукты. Например, запрет на доступ к внутреннему продукту из Интернета. Получается, это не программа, а набор мер, которые применяются к ресурсу, чтобы доступ снаружи был недоступен.
Сталкиваетесь ли вы с проблемами устаревших систем и технологий при интеграции с современными платформами? Если да, то на какие компромиссы приходится идти?
Работа с интеграцией через API позволяет нам связать воедино системы из разных исторических эпох, поскольку такой подход находится вне времени. Например, к старому продукту может быть прикреплен микросервис, который умеет и «входить» в классический монолит, и интегрироваться по современным технологиям. Либо уже есть продукты Cloud native с изначально современными облачными технологиями, где встроены интеграционные слои. Мы умеем работать с продуктами разных эпох через эти интеграционные слои.
В старых продуктах создание современного интеграционного слоя может быть слишком дорогим, но позволяет в дальнейшем переиспользовать их в других интеграциях. К старому продукту сложно «прикрутить» какой-то API, но возможно. Если же говорить об интеграции продуктов внутри компании, мы, вероятнее всего, будем стремиться к подключению их по современным стандартам, хотя это и сложнее. Лучше идти по этому пути, потому что в будущем мы начнем работать в едином технологическом интеграционном направлении.
Какова роль аналитики данных в процессе интеграции различных систем и какие новые возможности она открывает для METRO?
Аналитика данных отличается тем, что чем больше мы собираем данных, тем более продвинутую аналитику можем строить, и чем больше у нас источников, тем интереснее изучать влияние различных событий на бизнес-модели. Это не имеет прямого отношения к интеграции. Интеграция является необходимой частью для того, чтобы эти данные появились в экосистеме. Простыми словами: интеграция — это огромная поляна, так называемое озеро данных (data lake), куда можно складывать всё, что угодно: цены, кассовые чеки, информацию из систем геоаналитики о прогнозах продаж в различных регионах, данные о поставщиках, планируемых поставках и т. д. Из всего этого можно формулировать определенные выводы. Однако для того, чтобы эти данные попали на эту огромную поляну, нужны интеграции, и чем их больше, тем лучше.
Существуют три пути работы с аналитикой данных. Первый – использование для просмотра исторической отчетности, например отслеживание событий по неделям в течение 365 дней. Второй – построение прогнозов: например, есть система, которая прогнозирует, сколько товаров нужно заказать торговому центру. Такая система базируется на исторических данных, введенных в систему. Третий путь — работа с данными в режиме реального времени. Например, оценка эффективности сотрудников по количеству собранных коробок за день: это не совсем аналитика данных, но это важно для контроля и повышения эффективности операционных процессов. Все обозначенные пути важны, но в целом источниками информации для них служат одни и те же данные.
Опубликовано 27.08.2024
