Привет! С вами Евгений Катасонов, product-менеджер, и Вадим Волков, лидер группы аналитики в СберТехе. Рассказываем, как разработали Platform V Product 360 — PIM-решение для управления продуктовым каталогом, ориентированное на e-commerce и подходящее для управления банковскими продуктами.

Архитектура и ключевые компоненты

Platform V Product 360 — готовое решение для управления продуктовым каталогом, хранения маркетинговой информации, работы с карточками товаров и выгрузки данных в каналы продаж. Более четырёх лет система успешно работает в масштабах Сбера, автоматизируя ведение каталогов банковских услуг.

Продукт состоит из пяти основных компонентов:

• Каталог продуктов — центральное хранилище данных для структурированного хранения и редактирования карточек товаров.
• Модуль MDM — предназначен для хранения и унификации больших объёмов справочных данных, которые невозможно разместить в карточках.
• Модуль интеграций — обеспечивает обмен данными между PIM и внешними системами.
• Витрина — инструмент визуализации карточек через API.
• Web UI — графический интерфейс для управления данными о продуктах.

Мультитенантная архитектура

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

Преимущества:

• Экономическая эффективность — несколько подразделений используют один экземпляр системы без необходимости развёртывания отдельных решений.
• Масштабируемость — легко добавлять новые подразделения без дополнительной инфраструктуры.
• Безопасность — строгий контроль доступа, данные одного подразделения недоступны другим.

Бэкенд: масштабируемость и отказоустойчивость

Бэкенд играет ключевую роль в управлении информацией о продуктах. Он обрабатывает данные, обеспечивает интеграции и взаимодействие с базой через API.

Product 360 разрабатывался как коробочное on-premise решение. Для развёртывания выбрали Openshift и Kubernetes. В качестве СУБД используется PostgreSQL, язык разработки — Java.

Оптимизация производительности

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

Для ускорения доступа к данным внедрено многоуровневое кэширование:

• On-heap кэш — для небольших, часто используемых данных.
• Off-heap кэш — для больших объектов, например, карточек товаров.
• Глобальный кэш — обеспечивает согласованность данных между узлами.

Такой подход снижает нагрузку на базу и ускоряет работу с каталогом, особенно при миллионных объёмах.

Удобный и гибкий интерфейс

Мы сделали интерфейс интуитивно понятным, чтобы 90% задач пользователи могли решать без участия разработчиков.

Базовый сценарий:

1. Создание структуры каталога (характеристики, категории, инфомодель).
2. Импорт, экспорт или ручное создание карточек.
3. Наполнение карточек данными.
4. Настройка выгрузки в каналы через Excel или JSON.

Расширенный сценарий:

1. Настройка бизнес-правил заполнения.
2. Подписка на события обновления через Kafka.
3. Управление связями между продуктами.
4. Использование справочников.
5. Работа с медиа-активами.

Интеграции: от CSV до Kafka

Изначально интеграции ограничивались импортом и экспортом в CSV и Excel. Но с ростом требований мы добавили:

• API для чтения данных из витрины.
• Методы записи для регулярной загрузки данных.
• Интеграцию с Kafka — теперь при обновлении карточки событие отправляется в топик и распространяется по системам компании.

Также реализован ETL-процесс с языком трансформации данных. Пользователь может забирать данные из внешних систем, преобразовывать их и загружать в PIM в нужном формате.

Сейчас система транслирует обновления в личные кабинеты маркетплейсов, интернет-магазины и порталы поставщиков — через Excel и API (в том числе Wildberries). В планах — подключение других API-каналов.

Аудит и безопасность

Все изменения в системе фиксируются и версионируются. Это позволяет отслеживать действия пользователей и при необходимости откатывать данные к предыдущему состоянию.

Мы интегрировали PIM с системами мониторинга и аудита, чтобы собирать и анализировать логи. Версионирование охватывает все сущности, из которых строится карточка продукта.

Использование ИИ

Мы внедрили ИИ-инструменты, чтобы упростить работу контент-менеджеров:

• Генерация описаний товаров на основе характеристик.
• Создание изображений по текстовому промпту.

Эти функции доступны прямо в интерфейсе — «из коробки».

Итоги и перспективы

Мы создали on-premise PIM-систему, готовую к высоким нагрузкам и отвечающую строгим требованиям enterprise-компаний. Product 360 сочетает банковский уровень безопасности, отказоустойчивость и удобный интерфейс.

Сейчас мы выводим решение на рынок и готовы делиться его возможностями.

Привет! С вами Евгений Катасонов, product-менеджер, и Вадим Волков, лидер группы аналитики в СберТехе. В статье расскажем, как мы разработали Platform V Product 360 — решение по управлению продуктовым каталогом (PIM) ориентированное на рынок e-commerce и при этом закрывающее задачу управления банковскими продуктами

Архитектура и технологии

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

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

В продукте пять ключевых компонентов— для простоты назовем их по основным функциям:

• Каталог продуктов — основное хранилище данных для структурированного хранения и работы пользователей с продуктовыми карточками.
• Модуль MDM — позволяет хранить и унифицировать большие данные в справочниках, которые невозможно хранить в рамках продуктовой модели карточек товаров.
• Модуль интеграций — связывает данные PIM-системы с внешними источниками и потребителями данных.
• Витрина — инструмент визуализации и представления продуктовых карточек потребителям при использовании API сервиса.
• Web UI — графический интерфейс для пользователей системы, предоставляющий инструменты для эффективного управления данными о продуктовых карточках.

Мультитенантная архитектура

Для системы была выбрана мультитенантная архитектура, которая в нашем случае позволяет изолированно обслуживать разные отделы в организации в рамках одного продукта (сервиса).

Плюсы такой архитектуры:

• Экономическая эффективность: одним сервисом могут пользоваться сразу несколько бизнес-подразделений одной компании, и не нужно развертывать дополнительные решения.
• Эффект масштабируемости: возможность увеличить количество разных бизнес-подразделений организации, использующих продукт (сервис) без необходимости дополнительного развертывания продукта (сервиса).
• Безопасность: можно разделять доступы и работать только с данными, которые относятся к конкретному бизнес-подразделению.

Бэкенд, или как нагрузки вас держат в тонусе

В PIM-системах бэкенд очень важен — от него зависит качество управления информацией о продуктах. Он не только обрабатывает данные, но и обеспечивает интеграции и обмен с базой данных для взаимодействия по API с фронтендом сервиса.

Мы создавали Product 360 в формате коробочного решения (on-premise), поэтому важно было понять, какими инструментами его можно будет развернуть. Остановились на двух форматах: Openshift и Kubernetes. Для хранения данных использовали PostgreSQL, язык разработки — Java.

Масштабируемость и производительность

Важно, чтобы система росла вместе с потребностями бизнеса. Меняется масштаб и количество клиентов — меняется и мощность ИТ-системы. Она должна обеспечивать работу с большим количеством запросов, потому что от производительности зависит эффективность работы пользователей с системой.

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

Оптимизация запросов и кеширование

При работе с ИТ-системой пользователь не хочет тратить время на поиски нужных данных. Важно хранить данные в специальном хранилище и точно знать, откуда система их берет при обращении. В PIM-системах кеширование используется для оперативного доступа к информации о хранимых продуктах. Если организация хранит миллионы товаров в каталоге, то кеширование позволяет мгновенно показать данные о товарах, не нагружая систему.

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

В Product360 была использована архитектура многоуровневого кэширования включая on-heap, off-heap и глобальный кэш. Такой подход обеспечивает масштабируемость и снижает нагрузку на базовые системы хранения данных. Небольшие часто используемые данные хранятся в быстром on-heap кэше, данные большего размера, например продуктовые карточки, перемещаются в off-heap. Глобальный кэш гарантирует доступность и согласованность информации для пользователей системы. В результате система становится более гибкой и готовой к обработке трафика и интеграции с цифровыми платформами.

Пользовательский интерфейс во благо, а не просто набор кнопок

С самого начала мы стремились сделать красивый, удобный, гибкий и интуитивно понятный, который поможет реализовать любой пользовательский путь. Сам пользовательский путь проектировали так, чтобы в 90% случаев не нужно было привлекать к решению задач разработчика.

Базовый сценарий пользователя получился следующим:

1. Создание в системе всех сущностей каталога (характеристики, группы характеристик, категорийное дерево, спецификация/инфомодель).
2. Импорт, экспорт или создание в UI продуктовых карточек.
3. Наполнение данными карточек.
4. Настройка трансляции данных в каналы с помощью Excel или Json.

Расширенный сценарий пользователя предоставляет дополнительные возможности:

1. Настройка бизнес-правил заполнения характеристик
2. Настройка подписок на каталог и события обновления в Kafka
3. Настройка связей продуктов
4. Создание и использование справочников в продуктах
5. Управление медиа активами

Интеграции: как другие узнают, что у вас обновилась карточка

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

Это привело к новым задачам развития — реализации API продуктового каталога на чтение, которое закрывало вопросы экспорта данных из нашей высоконагруженной витрины. Следующим шагом стала автоматизация на уровне записи данных и реализация методов для загрузки данных с возможностью еженедельного обновления в каталоге. Но и этого оказалось мало, и мы реализовали работу с Kafka, в топик которой попадал весь продуктовый каталог и расходился по другим системам компании.

Реализация интеграции с Kafka позволила сделать инструмент подписки на события и получения обновлений в топик при изменении данных в каталоге пользователем. В дополнение к существующим настроенным режимам работы с Kafka мы реализовали ETL-процесс («Extract, Transform, Load — извлечение, преобразование, загрузка») с языком трансформации данных. Пользователь системы с помощью такого инструмента может успешно трансформировать и загружать данные из сторонних систем. Инструмент позволяет взять данные из исходной системы в одном формате и преобразовать в требуемый формат данных при загрузке в систему.

Все эти действия помогли закрыть вопросы интеграционного взаимодействия внутри организации, в которой развернут сервис. После чего мы приступили к реализации интеграции с каналами продаж и трансляции обновлений о продуктах в личные кабинеты маркетплейсов, интернет-магазины и порталы поставщиков по формату Excel (рис. 3) и Wildberries по формату API. В будущем планируется постепенное подключение и всех возможных других API каналов.

Это просто аудит и безопасность

Современные mission critical решения, помимо высокой отказоустойчивости, также должны предоставлять все данные об их текущем состоянии в промышленном контуре. При этом для отслеживания пользовательских действий все изменения в системе должны как минимум фиксироваться,а как максимум — версионироваться, чтобы была возможность откатиться до состояния«как было».

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

Это позволило пользователю получить актуальную информацию о том,чтодругиепользователи делают в системе,и удобный инструмент управления версиями каждой сущности и самой карточки продукта (рис. 4)

ИИ поможет или нет?

Одна из важных задач — упростить работу контент-менеджера за счет инструментов на базе ИИ прямо «из коробки». Сейчас, например, в Product 360 уже есть возможность генерировать описание продукта прямо в карточке товара с учетом его характеристик, а также изображение на основе текстового промпта (рис. 5). Про другие сценарии использования ИИ в PIM мы рассказываемздесь.

Так же пользователю доступна функция генерации фото на основе текстового промпта (рис 6).

Результаты и планы на будущее

На старте нашей целью было создание pim-системы для рынка e-commerce, которая отвечала бы высоким требованиям крупных компаний. Как итог, получили on-premise решение, готовое к большим нагрузкам. Сейчас Product 360 — это сервис с безопасностью уровня банковских mission critical решений и интуитивно понятным удобным интерфейсом, помогающим пользователю качественно и быстро решать свои задачи.

В данный момент мы выводим решение на рынок и предлагаем протестировать его возможности.

Запросить консультацию можноздесь.

• Вебинар
• Видео о продукте
• Демо-ролик