PIM: дорого, сложно. И почему без него иногда нельзя
Конец года оказался богатым на проекты, где так или иначе касалась темы внедрения PIM. Формально PIM почти всегда уже есть. Иногда эту роль выполняет CMS или 1С или какая то иная система. Где-то лежат описания, где-то характеристики, где-то изображения.
До определённого момента этого хватает. А потом наступает состояние, когда дальше так жить больно. Больно обновлять каталог, больно создавать новые товары, больно обновлять данные на маркетплейсе и поддерживать порядок.
Когда всё начинает ломаться? Проблемы редко появляются резко. Обычно они накапливаются. Контент начинают править в нескольких системах одновременно. Характеристики дублируются и расходятся. Картинки теряются и так далее.
В какой-то момент 1С перестаёт быть чисто учётной системой и превращается в неудобный редактор контента. И именно здесь появляется PIM. Не как ещё одна модная платформа, а как попытка навести порядок в данных.
Для чего? Ключевая мысль, которую важно принять сразу. PIM не заменяет 1С и не конкурирует с CMS. У каждой системы своя роль.
1С остаётся учётной системой. Там создаются товары и SKU, живут GUID, цены и остатки. PIM становится единым источником товарного контента. Описания, характеристики, изображения, история изменений. Сайт и маркетплейсы в этой схеме выступают потребителями данных, а не местом их редактирования.
Входные требования За последние проекты у нас сформировалась довольно приземлённая памятка с требованиями которые мы выдвигаем при выборе. PIM должен разворачиваться на своём сервере. Желательно быть реализованным на не экзотическом стеке, чтобы при необходимости систему можно было развивать своими силами. Важно, чтобы модель данных нормально поддерживала работу с товарами и SKU как с разными сущностями. И конечно, чтобы интеграции с сайтом и маркетплейсами либо уже существовали, либо были реализуемы без сверхусилий.
Кандидаты? Akeneo — это зрелая и понятная PIM-система. Очень хорошо подходит для каталогов с большим количеством атрибутов, сложной структурой и аккуратной моделью данных. У неё сильное сообщество, понятная логика работы и адекватная Community-версия.
Но важно понимать ограничения. Akeneo почти не решает задачи интеграции с маркетплейсами из коробки. Всё, что связано с Ozon, Wildberries и подобными площадками, придётся проектировать и реализовывать самостоятельно. DAM-возможности в бесплатной версии тоже достаточно базовые. В итоге это отличный фундамент, но с расчётом на последующую разработку.
Pimcore — это уже не просто PIM, а целая платформа. Здесь можно собрать PIM, DAM, MDM и много чего ещё в одном контуре. Возможности почти безграничны, но за это приходится платить сложностью.
Для работы с маркетплейсами и выгрузками данных в Pimcore практически неизбежно понадобится Data Director. Это отдельный коммерческий модуль, который позволяет настраивать импорт, экспорт и трансформацию данных без глубокого кода. С ним жить сильно проще, но он не бесплатный и не решает всё автоматически.
Ensi — это решение с явным фокусом на e-commerce и маркетплейсы. Модель данных проще, зато сразу ориентирована на практические сценарии. Интеграции с маркетплейсами доступны в коммерческой версии, и это сильно сокращает время выхода в прод.
Минус здесь тоже очевиден. Меньше универсальности и больше зависимости от вендора. Некоторые функции доступны только в PRO-версии, и при масштабировании важно заранее понимать, на каких условиях система будет развиваться дальше.
Как всегда важен контекст Главная ошибка, которую мы видим снова и снова, это попытка сделать идеальный PIM сразу. На практике работает только итерационный подход. Сначала выносится контент из CMS. Потом аккуратно отсоединяется контентная часть от 1С. Затем расширяется модель атрибутов. И только после этого имеет смысл активно развивать интеграции с маркетплейсами.
PIM не нужен всем. Но если ассортимент растёт, маркетплейсы становятся важным каналом, а контент начинает жить своей жизнью, вопрос уже не в том, нужен ли PIM. Вопрос в том, сколько будет стоить отложенное решение.
