Введение в MDM- и PIM-системы на примере Akeneo и Pimcore

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

MDM-системы управляют разными областями данных, которые часто называют доменами (домен «клиенты», домен «продукты» и т. д.).

Сегодня можно сказать, что PIM-система — это MDM-система по домену «продукты».

Благодаря MDM в едином пространстве содержатся валидаторы на изменения, интеграции с другими системами и правила, по которым эта информация выгружается в другие системы.

Все возможные атрибуты, всё-всё-всё о каждой сущности — всё сосредоточено в MDM.

Понять суть MDM-систем намного проще, если в качестве примера рассматривать PIM-системы. Поэтому далее поговорим именно про них.

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

Как правило, PIM-системы также имеют возможность настройки статусов продукта («Валидация менеджером», «Готов к публикации» и т. д.) и инструменты массовой обработки товаров (быстро загрузить что-то из файла XLS, обновить общий атрибут для группы товаров и т. п.).

Наиболее продвинутые PIM-системы включают в себя DAM-системы (или PLM-системы), т. е. системы управления файлами и картинками, которые могут иметь собственные атрибуты.

В таком случае у изображений, которые являются атрибутами товаров, могут быть свои атрибуты, например «Картинка боковая», «Сертификация». Вы не просто указываете картинку в качестве атрибута, но и эта картинка сама по себе находится в определённом каталоге, может быть переиспользована, и по ней может быть создан отдельный workflow («на ретуши», «устарело», «нужно переснять»).

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

Давайте рассмотрим те две системы, в разработке на которых мы наиболее экспертны: Akeneo и Pimcore. С точки зрения технологического стека они очень похожи: это PHP / Symfony 4, MySQL и Elasticsearch. Но по подходу это две очень разные системы.

Pimcore — это MDM-система. Несмотря на то что в её названии звучит PIM, де-факто в ней просто есть раскладка, которая позволяет работать с продуктами. Там же есть и CRM (раскладка, позволяющая работать с клиентами), плюс можно создавать любые другие сущности, которые нужны для решения бизнес-задач.

Это не означает, что PIM-функционал там слабый. Наоборот, он очень сильный, ещё и с возможностью пользоваться дедупликацией.

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

В отличие от универсального Pimcore, Akeneo — это только PIM-система, т. е. узкоспециализированный инструмент.

Есть две версии этого продукта: Enterprise и Community. В архитектурном плане это одна система (одно ядро) с разным набором модулей. Версия Enterprise отличается тем, что в ней больше модулей и по большей части они связаны с управлением продуктами в крупных организациях (там, где много согласований, сложные права доступа, где у операторов большая иерархия и т. п.).

Мощная иерархия атрибутов, как в Pimcore, тут отсутствует. Атрибуты делятся на атрибуты, группы атрибутов и семейства. Нет возможности создать «абстрактную сущность», от которой можно отнаследоваться. Например, нет возможности создать «Мебель» со своими атрибутами, а потом расширить её с помощью «Дивана» и «Стола», которые будут добавлены в качестве атрибутов «Мебели».

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

Другой пример: вы производите диваны. Обивку для них можно изготовить из тысячи материалов разных цветов и фактуры. Они различаются габаритами, механизмом раскладывания, материалом подлокотников. Эти отличия — не просто свойства товаров, они определённым образом зависят друг от друга: диваны некоторых ценовых категорий могут иметь обивку только из определённого вида тканей и только ограниченного количества цветов, а некоторые конструкции имеют разные опции.

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

Akeneo поддерживает плоскую модель данных (с нюансами: в версии Enterprise могут быть составные атрибуты, т. е. атрибут может содержать свои атрибуты).

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

Составной атрибут в Akeneo Enterprise и Pimcore означает, что атрибут содержит свои атрибуты. Например, атрибут «Цвет» может содержать название, HEX- и CMYK-коды и картинку, а атрибут «Ткань» — название ткани и условия её стирки/мойки.

В Pimcore эта задача решается коробочным интерфейсом: любой класс может быть расширен, и тот, в свою очередь, тоже может быть расширен. Атрибуты могут быть связью, в т. ч. многие ко многим, составными, вычисляемыми.

Наиболее интересные кейсы для понимания работы Akeneo и Pimcore могут быть такими: у бизнеса есть некая базовая продукция с базовой ценой (например базовая модель дивана с обивкой из определённой ткани), а при добавлении какой-либо конфигурации нужно автоматически изменить цену (диван с другой обивкой стоит дороже), причём сделать это по правилам (есть несколько категорий ткани, и цена для каждой следующей категории увеличивается на 100 рублей за погонный метр).

Интерфейс настройки атрибутов в Akeneo выглядит так:

В Pimcore:

Pimcore — это гибкая, удобная и многофункциональная MDM-система. Давайте познакомимся с её возможностями подробнее и обсудим, какие из них есть и в Akeneo.

И Pimcore, и Akeneo поддерживают связанность и высокое качество для различных наборов данных: структурированных и неструктурированных, внутренних и внешних. Информацию можно сопоставлять, проверять и стандартизировать, чтобы всегда иметь актуальные и точные данные для операций. К примеру, можно обогащать информацию о товарах, используя другие сайты и облачные сервисы. С точки зрения управления качеством данных Pimcore богаче архитектурно, зато Akeneo — нагляднее.

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

Иногда нужно провести товары по статусам так же, как таск-трекер проводит задачу. Например, последовательность статусов товара может быть такой: «Новый», «На проверке копирайтером», «На проверке бренд-менеджером», «Опубликован».

Такая возможность есть и в Akeneo (Enterprise), и в Pimcore.

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

Статус может быть связан с запуском процедуры импорта или экспорта данных этого продукта.

В Pimcore есть понятие валидаторов и правил отмены операции. Например, нельзя опубликовать продукт, если его цена не обновлялась более 30 дней, нельзя отправить на валидацию продукт в статусе «Заблокирован» и т. п.

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

В интерфейсе Pimcore workflow выглядит так:

В любой PIM-системе — даже без DAM — есть возможность загрузить картинки к товару.

Однако бывает нужно сделать так, чтобы файлы сами по себе были независимыми сущностями (например фотографы просто делают фото и не указывают артикул или нам нужно переиспользовать одно фото в разных продуктах). В таком случае нужен DAM. Сначала он назывался PCM, и, кажется, название взято от SAP. Теперь это просто DAM.

DAM — это системы по хранению файлов (картинок, документов) со своими атрибутами. Бывает, нам нужно не просто знать фото артикула, но и отличать, что это именно боковое фото. Не просто видеть, что это скан сертификата, но и определять срок, когда он заканчивается. Т. е. файл сам по себе обрастает метаданными и эти метаданные могут быть связаны с продуктами (например нельзя публиковать товар с истёкшим сертификатом).

Весь этот функционал можно настроить в DAM.

Как правило, DAM подключается туда, где генерируется контент (чтобы можно было использовать штатный NFS или какой-либо другой сетевой протокол доступа к «папке»), а контент-менеджеры используют файлы из DAM в своих продуктах (присваивают фото и сертификаты конкретным артикулам).

При этом если нам нужно будет отправить все сертификаты, мы сможем сделать это одним кликом (даже предоставить публичную ссылку на скачивание, чтобы не пересылать гигабайты по почте). И в выгрузку попадут только те сертификаты, дата которых актуальна.

DAM является частью и Pimсore, и Akeneo (только Enterprise, хотя к Community можно подключить любой open source DAM или даже написать свой, если требования скромные).

В Pimcore также есть простые функции работы с документами и редактирования изображений (через сторонние библиотеки).

Версионирование показывает, когда, кем и как именно обновлён продукт (GIT для продуктов).

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

Эти функции есть и в Akeneo Community (хотя здесь функционал сильно урезан), и в Akeneo Enterprise, и в Pimcore.

Бывает необходимо знать, что у нас заполнены не все нужные атрибуты в разрезе каналов (канал — это получатель информации: сайт, маркетплейс, ERP и т. п.).

А иногда это нужно знать не просто в разрезе канала, но и в разрезе какой-либо группы продуктов. В Akeneo Enterprise можно смотреть за наполненностью и качеством данных по группе в разрезе источников — это называется Teamwork Assistant. Например: скоро осенне-зимний сезон, и мы выделяем все товары для этого сезона в отдельную группу. В результате мы видим процент заполненности по каналам с наложенным фильтром группы, и нам проще отслеживать прогресс по наполненности.

Кроме настраиваемых профилей импорта и экспорта, обе системы (Akeneo и Pimcore) имеют немного разный подход к данным.

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

Akeneo заточена на работу с продуктами и имеет сервис обогащения информации (Franklin), а также достаточно простые механизмы импорта и экспорта (можно загрузить таблицу, настроив профиль импорта). Franklin собирает сведения о продукте в Интернете и умным образом объединяет их, устраняя противоречивость данных.

Иногда бывает необходимо сделать так, чтобы информация о продукте обогащалась за счёт завода-производителя.

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

В Akeneo Enterprise для этого есть облачный сервис Onboarder, а в Akeneo Community и Pimcore единственный вариант — использовать имеющиеся права доступа и гибко конфигурировать их так, чтобы поставщикам всё-таки был предоставлен определённый доступ.

Хотя лучше всё же настроить импорт данных из их источников (и чаще всего какой-то такой импорт уже имеется).

PXM (product experience management) — это такой PIM, который умеет предоставлять разную информацию в разные маркетинговые каналы.

Если классический PIM рассматривает информацию о продукте как «золотую запись» (да, у продукта могут быть разные локализации — языковые и т. п., — но это один набор атрибутов), то PXM рассматривает продукт как набор описаний для разных маркетинговых каналов.

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

Akeneo заявляет, что её Onboarder и Franklin вместе с самой PIM и есть PXM. На деле же и Akeneo, и Pimcore предоставляют схожий интерфейс для реальной маркетинговой активности: это вариации продукта, которые можно объединить или связями (Akeneo и Pimcore), или наследованием (Pimcore).

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

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

Причины — как в многообразии EDI-сообщений и их форматов, так и в редкой надобности таких обменов.

Однако в России спрос на EDI повышается, и многообразие форматов сглаживают крупные ЭДО-центры (СБИС / «Диадок» / «СКБ Контур» и т. п.), так что эта задача преобразуется в задачу на интеграцию с каким-либо местным ЭДО-провайдером.

Немаловажным является вопрос отношения к продуктам, если в вашей компании — микросервисная экосистема.

Строго говоря, без доработок Akeneo вы не сможете управлять бизнес-процессами Akeneo PIM из вашей BPMS. В Pimcore дела обстоят чуть проще ввиду богатых возможностей доступа workflow через API. Однако мы рекомендуем не интегрировать такие бизнес-процессы и относиться к PIM как к закрытой системе, которая имеет собственные бизнес-процессы. Всё, что вы можете делать с такой системой из других сервисов, — пользоваться её API.

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

Строго говоря, чем больше и сложнее процессы, тем меньше для них подходят модульные системы (пусть и open source).

Другой вариант: разработать модуль для Akeneo или Pimcore так, чтобы интерфейсы и валидаторы получались из Camunda или jBPM, а отображались PIM-системой. Конечно, это недешёвая разработка, но такое решение позволит сохранить прозрачность бизнес-процессов из BPMS при сохранении богатого интерфейса PIM.