pim система что это
Популярные PIM-системы: функционал, особенности, стоимость
Содержание
Когда мы начинали работать с PIM-системами, это направление было относительно непопулярным в России. Им интересовались в основном крупные компании и представительства международных холдингов, для которых управление информацией о товарах было насущной проблемой.
Думается, интерес к таким системам развивался бы и органически, в рамках общего тренда на цифровизацию. Но 2020 год подстегнул рынок PIM, вернее, заставил торговый и производственный бизнес активнее автоматизировать процессы.
Зачем бизнесу PIM-система
Каждый товар может обладать более чем 200 атрибутами: описания, артикулы, цены, фотографии, сезонность, скидки, взаимосвязь товаров и т. д. Эти атрибуты приходится назначать, править, принимать, передавать на каналы продаж и во внутренние системы, обновлять, снова передавать.
При правильной передаче на маркетплейсы каждый атрибут может улучшить позиции в каталоге или что-то изменить в его связанности. Следовательно, добавление атрибутов или новых значений к ним — это отдельный бизнес-процесс, который сам по себе требует действий. Кроме того, каждый атрибут может быть отдельным сложным справочником, с которым должны работать и отдел закупок, и производство, и поставщики.
Ещё в 2012 году исследовательская компания Goodmasters посчитала, что на сбор и обновление данных об одном SKU тратится примерно 25 минут в год. Для непрофильных систем и приложений этот показатель и сейчас остаётся примерно таким же. На скорость внесения данных, например, в Excel слабо влияет то, в какой именно версии продукта работает менеджер.
Если у компании каталог на 100 SKU (что редко, но случается), временными затратами на операции с атрибутами можно пренебречь. А если речь идёт хотя бы о 1000 SKU?
При 5000 SKU цифры и вовсе получаются внушительные. Путём несложных вычислений мы получим показатель в 12 человеко-месяцев в год, затрачиваемых на ручную работу с данными. Условно: один из сотрудников ВСЁ своё рабочее время тратит на работу с данными о товарах!
Чем больше каталог, тем заметнее затраты на его поддержание и выше вероятность возникновения сбоев и ошибок, обусловленных человеческим фактором. Тем больше бизнес-процессов в головах у людей, а не в информационных системах. Тем хуже качество данных. И тем больше время вывода товаров на рынок.
PIM-система (сокр. от англ. product information management system, рус. «система управления информацией о товарах») автоматизирует работу с информацией о товарах: контроль заполнения, обновление, версионирование, отправку и получение данных, поиск сведений и т. д. Согласно всё тем же исследованиям, внедрение PIM-системы сокращает время на сбор и обновление данных о каждом SKU до 4 минут в год — это в шесть раз меньше! Также сокращается время вывода на рынок отдельных товаров — в три-четыре раза. Не менее важно и другое — повышается качество данных.
Product Information Management – что это такое и нужно ли это в России?
Западные аналитики оценили рынок Product Information Management (PIM) систем в 7 миллиардов долларов в 2019 году и предсказывают его рост до 11 миллиардов к 2024 году.
Я уже более 10 лет занимаюсь PIM, участвовал и в разработке, внедрял их на местах и даже создал свою собственную систему. Но весь этот опыт внедрения был на западе. Я хотел бы рассказать, что такое PIM, зачем он нужен и послушать в комментариях насколько это востребовано у нас в России.
Product Information Management можно перевести как система для управления информацией о продукции. Что это такое и насколько это важно для бизнеса? Недавно искал ребенку конструктор, и обратил внимание насколько разной может быть информация об одном и том же товаре.
Вот описание одного и того-же товара, но на разных сайтах:
Понятно, что мне как покупателю интереснее второй сайт, так как там мне дают гораздо больше информации, и я могу выбрать именно то, что мне надо. Особенно важно это сейчас, когда мы все чаще и чаще покупаем все онлайн.
Информация о товаре это не только описание, картинка и цена. Она может быть очень разнообразной, например, для телевизора необходимы свои атрибуты (вы не станете покупать телевизор онлайн если не знаете какая у него диагональ), для велосипеда – другие, для пиццы – свое и т.д.
Вот примерный список того, что может быть необходимо чтобы описать товар:
Основные данные, такие как идентификатор товара, описание и т.д.
Иерархия, то есть к какой категории принадлежит товар (а категории могут быть разные в зависимости от канала продаж, например на своем сайте она одна, на маркетплейсе – другая и т.д.)
Связанные с товаром файлы, такие как изображения, документация, видео и т.д.
Маркетинговые данные. Это могут быть какие-либо теги, атрибуты для SEO, отзывы клиентов и т.д.
Локализация, если продажи идут на разных языках.
А теперь представьте себе, что у вас тысячи наименований таких товаров, а у некоторых и миллионы. Вот для того, чтобы управлять всей этой массой информации и были разработаны системы PIM.
Первое, что, получает компания после внедрения — это снижение издержек на управление всей этой информацией. Вы сможете потратить меньше времени на ведение ваших товаров, и они смогут быстрее идти в продажу.
Плюс, повышается качество информации. Вы будете уверены, что все необходимы атрибуты заполнены и проверены у ваших товаров, прежде чем они попадут на веб сайт.
Вам не надо будет иметь доступ в несколько систем, чтобы управлять продуктовой информацией. То есть, вам не надо будет думать, что наименование товара надо подправить в системе электронной коммерции, а вот вес товара хранится в ERP.
Обычно PIM системы поддерживают возможности автоматизации, так что вы сможете автоматизировать часто повторяющиеся операции.
Ну и обычно такие системы имеют аналитические отчеты, которые будут очень полезны для маркетингового отдела.
Основная идея PIM систем, что они являются мастер системами для продуктовых данных. То есть вся необходимая информация о продукте должна хранится именно в PIM, и изменяться только в нем. Все остальные системы, такие как веб сайт, маркетплейсы и т.д. уже получают продуктовую информацию посредством экспорта из PIM.
Типичная картинка, которую вам покажут, когда будут рассказывать про PIM это:
В начале, нам необходимо загрузить продуктовую информацию в систему. Это может происходить по-разному, если вы сами производите товар, то вы и сами должны создать эту информацию, в таком случае человек вносит это вручную, либо она поступает из внутренних информационных систем, связанных с производством.
Ритейлеры же обычно получают эту информацию от поставщиков и производителей, но эту информацию надо как минимум проверять, а часто ритейлеры в любом случае обогащают эту информацию, например, делают свои фото и т.д.
PIM неразвязно связан с другими информационными системами. Обычно часть информации идет из ERP (например, идентификатор продукта, его цены)
То есть, PIM система должна уметь импортировать данные из различных источников. Ведь часто мы не может диктовать поставщикам, какой формат использовать для обмена данных. Надо еще замапить данные, что мы получаем на те атрибуты что у нас в системе. И желательно чтобы эта настройка импорта была легка и удобна, ведь источники этих данных тоже постоянно меняются, мы можем начать получать новые товары от нового поставщика и т.д.
После того как информация попадает в систему, она проверяется. Например, проверяется заполнены ли все необходимые атрибуты. Проверки могут быть и человеком и автоматически, обычно все PIM системы имеют возможность задать логику проверок. И если что-то не заполнено, то могут автоматически сгенерироваться задачи для разных отделов по исправлению этих ошибок. Если нет картинки, то задача будет сформирована для одного отдела, а если не заполнена логистическая информация – то для другого.
Кроме проверок товар всегда проходит классификацию. Необходимо поместить товар в правильную категорию в иерархии. И проблема еще в том, что этих иерархий может быть много. Дерево номенклатуры может быть одно, на нашем веб сайте мы можем показывать другую классификацию, каждый маркетплейс задает свою иерархию и т.д. Есть еще отраслевые иерархии, например ETIM, их тоже необходимо загрузить в систему и классифицировать по ним товар.
То есть PIM система должна поддерживать множество иерархий, которые тоже надо в свою очередь импортировать и проверять.
Как я уже писал, каждая категория товаров имеет свои атрибуты. То есть этим тоже надо управлять, надо ввести все эти атрибуты, выставить им соответствующие категории. Плюс еще атрибуты часто меняются, бизнес очень динамичен и часто необходимо хранить дополнительную информацию, например, решили мы делать скидки, надо создать соответствующие атрибуты у товара или категорий чтобы хранить это.
На стадии насыщения над товаром могут работать разные люди, поэтому система должна поддерживать и задачи (workflows), чтобы работники четко понимали что от них требуется и автоматические проверки (надо проверить информацию после изменения ее человеком) и разделение доступа (лучше не давать доступ на редактирование логистической информации отделу что занимается фотографией).
Ну и наконец, когда наши продукты содержат всю необходимую информацию и она проверена происходит выгрузка (экспорт) информации о товарах.
Экспорт — тоже вещь не простая, необходимо поддерживать все возможные форматы, например, разные маркетплейсы обязывают вас предоставлять информацию в удобной для них, а не для вас форме. Выгрузка может происходить в пакетном режиме (когда вы выгружаете продуктовую информацию раз в день, например) или режиме реального времени, когда сразу после изменения и проверки товара информация передается в другие системы.
Опять же разные каналы продаж требуют разные данные, для печатного каталога вам будет необходим один набор атрибутов, для сайта – другой, для маркетплейса – третий, и т.д.
Плюс, данные у вас в системе хранятся в той форме как удобно вам и часто их необходимо трансформировать чтобы выдать другой системе, например перевести единицы измерения в другую систему и т.д.
И конечно хочется, чтобы все эти настройки экспорта можно было сделать за короткий срок, и чтобы не было необходимости подключать программистов и тратить их ресурсы и время.
Теперь становится понятно почему компании готовы тратить деньги на подобные системы и почему этот рынок измеряется миллиардами.
Существует множество производителей подобных систем, есть и бесплатные, такие как Pimсore или Akeneo (правда ее бесплатная версия сильно урезана в функционале что я не уверен, что она полезна вообще).
Есть и дорогие системы, лидеры рынка, такие как Stibo, EnterWorks, Contentserv и т.д. Стоимость внедрения таких систем может стоить сотни тысяч долларов для крупных компаний, правда и делать они могут все что надо и умеют обрабатывать миллионы записей.
Я плотно работал с системами Stibo и Informatica PIM и знаю, что существуют единичные внедрения подобных систем в России, часто, это западные ритейлеры которые приходят в Россию, и так как у них внедрены подобные системы то они начинают использовать их и у нас. Хотя знаю и об одной чисто Российской компании, которая внедрила крупный PIM.
Знаю, что у нас пытаются внедрять Akeneo ссылаясь на ее простоту и бесплатность и такие внедрения – есть, но не много.
Насколько я понимаю, обычно, у нас продуктовую информацию хранят в Ecommerce системах и потом пытаются выгружать ее оттуда в маркетплейсы. Но вот насколько это удобно и хорошо? Да, Ecommerce системы предназначены для того чтобы показывать продуктовую информацию покупателю, но умеют ли они ей управлять? Есть ли в них возможности по проверке такой информации, хранения разной информации для разных каналов продаж и т.д.?
А как вы управляете информацией о продуктах? Было бы интересно прочитать в комментариях мнение людей кто каждый день занимается этим.
Обычно вся информация о товарах хранится в компаниях в 1С. И выгрузка товаров на сайт(ы) происходит по средствам API из 1С. Почему тогда 1С не подходит для этой задачи или 1С не рассматривается в качестве PIM системы?
Это далеко не всегда так. Есть разные варианты как бизнес это реализует, иногда просто хранят в Excel (конечно в 1С товар заведен, но только артикул и название), часто хранят ecommerce системе (веб сайт), иногда в 1С и есть еще и вариант PIM.
Вот вам реальный пример запроса от одной из компаний:
Технически можно все хранить в 1C, но часто это плохо когда маркетологи (или контенщики как это иногда называют) будут работать в 1С. Как вы например будете запускать туда внешних людей (фрилансеров которые работают с контентом)?
Еще есть проблемы поддержки 1С. Хорошо если в компании есть свои специалисты которые смогут быстро добавить новые поля в карточку товара, или изменят выгрузку если надо. А если их нет? На каждое изменение платить деньги? В PIM например маркетологи сами могут добавить поля в любое время, для этого не надо быть технарем. Конечно изменени выгрузок не так просто, но и это можно освоить (есть примеры когда не технические люди делали это с нашей системой).
В общем, это надо смотреть и считать в каждом конкретном случае что выгоднее бизнесу.
Ну если описание продукции и ее атрибуты которые они получают от поставщиков их устраивают, то им это и не надо.
Вы просто хотели вставить свою ссылку в чужую статью. Напишите лучше свою.
Вот сегодня общались с компанией (ритейлер), у них бизнес работает так:
1. Они хотят продавать какой-то новый товар.
2. Они УЖЕ готовы наполнять его контентом для сайта, присоединять картинки, даже выгружать его на сайт хотя его еще нет на складе (и в 1С).
3. Это значит что мы уже можем ввести его в PIM, задать ему весь контент и даже цену. Конечно цена не должна полностью вестить в PIM, это операционные данные, но мы должны эту цену в PIM иметь так как выгружаем это все из PIM на сайт (или в другие каналы, например маркеплейсы и т.д.), эта цена в дальнейшем будет подгружаться из 1С, но в первый раз мы можем ввести ее в PIM.
4. Все это выгружается куда надо из PIM и товар продается.
5. В какой-то момент времени товар приходит на склад и попадает в 1C. И у нас настроена интеграция с 1С раз в день (например, или раз в 5 мин. и т.д). Товар выгружается из 1С (у нас уже есть его код 1С), но у этого же товара есть еще SKU (или EAN), в общем уникальный номер от производителя. Вот по этому номеру товар находтся в PIM, ему там заполнятся код 1С и обновляются цены. Потом он выгружается на сайт или куда надо (если надо опять же автоматически).
Но если у вас процесс другой и товар всегда сперва появляется в 1с то можно сделать по другому. Вы заводите товар в 1С, он автоматом попадает в PIM, но из 1С приходит минимальная информация, там не хранятся картинки, все характеристики и т.д.
Как товар попадат в PIM можно стартануть автоматический процесс чтобы всем кому надо пришло письмо что появился новый товар. Ответственный за картинки например должен их добавить, кто-то ответсвенный за контент еще добавить свое и т.д. Можно даже организовать проверку, если новый товар не наполняется информацией в течении 5 дней например, то идет письмо менеджеру об этом, пусть он принимает решения.
Можно автоматом проверять все ли заполнено и только когда все заполнено, то автоматом выгружать. Можно вообще задать проверки качества какие угодно.
PIM системы это не готовые системы, это больше похоже на конструктор с готовыми кусками из которого мы быстро собираем решение для конкретного бизнеса. Тут уже бизнес решатет что ему надо, а мы это делаем в рамках системы (обычно без дополнительного программирования)
Забыл добавить, PIM это мастер система по отношению к продуктовм (маркетинговым) данным. То есть все изменения данных делаются в нем, а затем автоматом выгружаются во все каналы (сайты, маркетплейсы, партнеры и т.д.). Конечно до выгрузки часть информации подгружается из разных систем (в том числе из 1С). например остатки обычно подгружают, цены, чтобы все это показать на сайте (за эти данные PIM не отвечает, но он их использует). Но я не уверен зачем из PIM снова выгружать в 1С. в 1С то зачем хранить маркетинговую информацию.
Введение в MDM- и PIM-системы на примере Akeneo и Pimcore
По мере роста предприятия разрастается хаос в данных. Иногда он начинается с информации о продуктах (например, у торговых компаний), но может начинаться и с клиентских данных, с дублирования информации об инфраструктуре (для телекома).
Рано или поздно встаёт вопрос о повышении качества данных (т. е. повышении корректности, удалении дубликатов, стандартизации).
Мы в kt.team часто консультируем клиентов на предмет качества данных, и настало время рассказать про то, с чего обычно начинают наши клиенты в области торговли, — с PIM-систем.
Классическая MDM-система — это система, которая знает про разные источники данных и отвечает за качество данных, т. е. содержит «золотую запись» данных. Например, ваши пункты продаж обладают одной информацией о клиентах, интернет-магазин — другой, маркетинговые сервисы — третьей. MDM-система может привести все адреса и имена клиентов к единому стандарту, найти одних и тех же клиентов, записанных по-разному, и устранить ошибки на основании разных алгоритмов.
MDM-системы управляют разными областями данных, которые часто называют доменами (домен «клиенты», домен «продукты» и т. д.).
Сегодня можно сказать, что PIM-система — это MDM-система по домену «продукты».
Благодаря MDM в едином пространстве содержатся валидаторы на изменения, интеграции с другими системами и правила, по которым эта информация выгружается в другие системы.
Все возможные атрибуты, всё-всё-всё о каждой сущности — всё сосредоточено в MDM.
Понять суть MDM-систем намного проще, если в качестве примера рассматривать PIM-системы. Поэтому далее поговорим именно про них.
PIM-системы позволяют сосредоточить всю информацию от операторов, фотографов, поставщиков, а также различные правила по продуктам. С помощью PIM-систем можно управлять разными представлениями товаров на маркетплейсах и в соцсетях.
Как правило, PIM-системы также имеют возможность настройки статусов продукта («Валидация менеджером», «Готов к публикации» и т. д.) и инструменты массовой обработки товаров (быстро загрузить что-то из файла XLS, обновить общий атрибут для группы товаров и т. п.).
Наиболее продвинутые PIM-системы включают в себя DAM-системы (или PLM-системы), т. е. системы управления файлами и картинками, которые могут иметь собственные атрибуты.
В таком случае у изображений, которые являются атрибутами товаров, могут быть свои атрибуты, например «Картинка боковая», «Сертификация». Вы не просто указываете картинку в качестве атрибута, но и эта картинка сама по себе находится в определённом каталоге, может быть переиспользована, и по ней может быть создан отдельный workflow («на ретуши», «устарело», «нужно переснять»).
— Если у вас сложные бизнес-процессы по продуктам (например собственный фотопродакшн или большой штат сотрудников, поддерживающих информацию и контент),
— Если у вас много информации о продуктах (производство, бренд-менеджеры, продажи — каждый генерирует свои XLS-таблицы),
— Если у вас большое количество информационных систем, если в текущих информационных системах вроде «1С» ваши операторы тратят очень много времени на рутинные операции,
то MDM/PIM-система вам, скорее всего, нужна.
Вы сможете упростить все бизнес-процессы и разгрузить другие источники от ненужной информации. Например, зачем «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 — это гибкая, удобная и многофункциональная 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.
Итак, мы рассмотрели возможности систем Akeneo и Pimcore со многими их сходствами и отличиями. Стоит запомнить, что Akeneo — всё же PIM-система, которая нацелена на работу с продуктами, тогда как Pimcore — более обширное решение, MDM-система.Что касается стоимости Akeneo, то версия Enterprise будет стоить не менее 30 тысяч евро в год, и доработка Community иногда может оказаться дешевле.