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

В каких случаях бизнесу нужна PIM-система Akeneo и Pimcore для сложносоставных продуктов

Время на прочтение: 15 мин. "По мере роста предприятия разрастается хаос в данных.

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

Рано или поздно встаёт вопрос о повышении качества данных (т. е. повышении корректности, удалении дубликатов, стандартизации).

Мы в kt.team часто консультируем клиентов на предмет качества данных, и настало время рассказать про то, с чего обычно начинают наши клиенты в области торговли, — с PIM-систем".

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

Там же есть и CRM (раскладка, позволяющая работать с клиентами), плюс можно создавать любые другие сущности, которые нужны для решения бизнес-задач.

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

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

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

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

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

Мощная иерархия атрибутов, как в Pimcore, тут отсутствует.

Атрибуты делятся на атрибуты, группы атрибутов и семейства.

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

Позволять вносить всем заинтересованным сторонам необходимые изменения и дополнения в данные по продукту в одной области и гарантировать доступ к обновлённым данным в других областях. Демо: поиск и добавление товаров в Akeneo PIM. 2.

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

Сюда входят приоритизация источников, алгоритмы действий при наличии противоречивых данных, алгоритмы стандартизации информации и т. п. 3.

Загружать данные из различных источников: CMS, CRM-, ERP-систем, узкоспециализированных программ вроде САПР/CAD (например хранить в одном месте всю документацию, чертежи и свойства по продукту). 4.

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

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

Сюда же относится и выгрузка фидов для вендоров или централизованная отправка выгрузок на маркетплейсы вроде Wildberries, OZON, Amazon, «Яндекс.Маркета», AliExpress и т. п. Демо: импорт и экспорт данных в Akeneo PIM. 5.

Обеспечивать обработку и пополнение контента в системе с учётом политики прав и ролей в компании.

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

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

Если же мы поставляем товары, например, в Испанию, то переводчикам на испанский лучше дать доступ именно к испанским атрибутам и только для тех продуктов, которые отправляются в эту страну. Демо: роли в Akeneo PIM.

И Pimcore, и Akeneo поддерживают связанность и высокое качество для различных наборов данных: структурированных и неструктурированных, внутренних и внешних.

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

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

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

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

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

Вполне возможно, что в процессе проведения товара между статусами бренд-менеджер заметит неточность в части атрибутов.

Тогда он сможет оставить комментарий и отправить продукт на доработку, и оператор увидит необходимость корректировок.

Другой вариант: бывает нужно написать какой-нибудь валидатор.

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

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

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

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

Внутренние пользователи лишь подтверждают загрузку этой информации и проверяют её корректность. В 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.

Итак, мы рассмотрели возможности систем Akeneo и Pimcore со многими их сходствами и отличиями.

Стоит запомнить, что Akeneo — всё же PIM-система, которая нацелена на работу с продуктами, тогда как Pimcore — более обширное решение, MDM-система.

Что касается стоимости Akeneo , то версия Enterprise будет стоить не менее 30 тысяч евро в год, и доработка Community иногда может оказаться дешевле.

Для лучшего знакомства с этой темой вам могут быть полезны эти материалы (все строки кликабельны): PIM-система: как не утонуть в информации и держать всё под контролем; интеграция с PIM-системой; интеграция с Pimcore; что такое MDM-, PIM-, DAM-, PXM-системы; и следующее видео.