PIM: дорого, сложно. И почему без него иногда нельзя

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

Конец года оказался богатым на проекты, где так или иначе всплывала тема внедрения или серьёзной переработки системы хранения товарных данных. В простонародье это PIM. Product Information Management. Формально PIM почти всегда уже есть. Иногда эту роль выполняет CMS или 1С или какая то иная система. Где-то лежат описания, где-то характеристики, где-то изображения.

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

Когда всё начинает ломаться?

Проблемы редко появляются резко. Обычно они накапливаются. Контент начинают править в нескольких системах одновременно. Характеристики дублируются и расходятся. Картинки теряются, переименовываются вручную и живут без связи с товаром. SKU начинают вести себя как отдельные сущности, но управлять ими по-прежнему пытаются как попало.

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

И именно здесь появляется PIM. Не как ещё одна модная платформа, а как попытка навести порядок в данных.

Зачем вообще нужен? 

Ключевая мысль, которую важно принять сразу. PIM не заменяет 1С и не конкурирует с CMS. У каждой системы своя роль.

1С остаётся учётной системой. Там создаются товары и SKU, живут GUID, цены и остатки. PIM становится единым источником товарного контента. Описания, характеристики, изображения, история изменений. Сайт и маркетплейсы в этой схеме выступают потребителями данных, а не местом их редактирования.

Как только это разделение ответственности зафиксировано, дальше архитектура начинает складываться сама собой.

Входные требования 

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

Если на старте эти требования игнорировать, дальше почти всегда начинается дорогостоящий кастом.

Akeneo. Классический PIM без сюрпризов

Akeneo — это зрелая и понятная PIM-система. Очень хорошо подходит для каталогов с большим количеством атрибутов, сложной структурой и аккуратной моделью данных. У неё сильное сообщество, понятная логика работы и адекватная Community-версия.

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

Pimcore. Максимальная гибкость, максимальная ответственность

Pimcore — это уже не просто PIM, а целая платформа. Здесь можно собрать PIM, DAM, MDM и много чего ещё в одном контуре. Возможности почти безграничны, но за это приходится платить сложностью.

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

Pimcore отлично подходит компаниям с сильной технической командой и пониманием, зачем им такая гибкость. Без этого внедрение легко превращается в бесконечный проект.

Ensi PIM. Прикладной подход для e-commerce

Ensi — это решение с явным фокусом на e-commerce и маркетплейсы. Модель данных проще, зато сразу ориентирована на практические сценарии. Интеграции с маркетплейсами доступны в коммерческой версии, и это сильно сокращает время выхода в прод.

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

Как всегда важен контекст

Главная ошибка, которую мы видим снова и снова, это попытка сделать идеальный PIM сразу. На практике работает только итерационный подход. Сначала выносится контент из CMS. Потом аккуратно отсоединяется контентная часть от 1С. Затем расширяется модель атрибутов. И только после этого имеет смысл активно развивать интеграции с маркетплейсами.

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