
Anatoliy Dankov
CEO

В компаніях де є ERP, саме ця система поступово стає де-факто сховищем продуктових даних. На старті це виглядає логічно: вся інформація про товари вже в одній системі, додаткова інфраструктура не потрібна.
Проблеми з'являються пізніше, коли каталог росте, додаються нові канали, маркетплейси, багатомовний контент і складні атрибути. У цей момент ERP починає виконувати задачі, для яких вона не створювалась.
ERP і PIM вирішують різні класи задач і працюють з різними типами даних. Питання не «яку систему обрати», а де повинні жити різні типи продуктових даних і як правильно побудувати взаємодію між системами.
ERP створювався для управління операційними процесами - фінансами, складом, закупівлями, логістикою. Його модель даних оптимізована під транзакції: замовлення, рух запасів, фінансові проводки. SAP, Microsoft Dynamics, Oracle NetSuite, 1С - всі вони вирішують цю задачу добре.
PIM створювався для іншого класу задач - збір, збагачення і дистрибуція продуктового контенту по каналах. Його модель даних оптимізована під опис товару: атрибути, медіа, варіанти, локалізації, канальні версії.
Обидві системи містять дані про товар, але з різною моделлю зберігання і різними споживачами на виході. ERP знає скільки товару є і скільки він коштує. PIM знає що це за товар і як його представити покупцю на конкретному каналі. Це не дублювання - це два різні контракти даних в одній архітектурі.
Основна помилка в дискусії «ERP vs PIM», компанії порівнюють ці системи на рівні функцій, а не архітектури.
ERP оперує фіксованими структурами тому що це критично для операційної стабільності. Фінансова транзакція не може мати «гнучку схему», вона повинна бути передбачуваною і консистентною. Саме ця стабільність - сильна сторона ERP. І вона ж стає обмеженням коли бізнес намагається вести в ERP продуктовий контент.
eCommerce каталог живе за іншими правилами. Продуктові дані постійно змінюються: нові атрибути, вимоги маркетплейсів, локалізації, медіафайли, SEO-поля, канальні формати. Каталог перестає бути статичною таблицею SKU і перетворюється на динамічну контентну систему. Кожна така зміна в ERP - це залежність від IT і черга на розробку.
Саме під цей клас задач і з'явився окремий тип систем - PIM. Питання в тому наскільки ефективно ERP здатна масштабувати управління каталогом в сучасному eCommerce середовищі.
Коли компанії кажуть що ERP «не тягне каталог» — вони описують симптоми, а не причину. Повільне додавання нових товарів, ручна підготовка фідів для маркетплейсів, неможливість змінити структуру атрибутів без розробника. За всіма цими симптомами стоїть одне архітектурне рішення - жорстка модель даних.
Кожна зміна в структурі каталогу в ERP - це потенційний вплив на суміжні операційні процеси. Тому навіть проста задача, додати новий атрибут або змінити ієрархію категорій, перетворюється на IT-проєкт з оцінкою ризиків і чергою на розробку.
Окремий випадок - варіанти продукту і медіафайли. ERP зберігає кожен варіант як окремий SKU без продуктової ієрархії, немає поняття сімейства продукту з дочірніми варіантами. Управління цифровими активами в прив'язці до каналу ERP або не вирішує взагалі, або вирішує через обхідні схеми які дорого підтримувати.
Результат передбачуваний: команди або спрощують каталог до рівня який ERP може зберегти, або нарощують кастомізації які з часом стають дорожчими в підтримці ніж сама система.
PIM не виник як альтернатива ERP, він виник тому що певний клас задач з управління продуктовим контентом не має архітектурного рішення всередині ERP. Спроби його туди запхати завжди закінчуються однаково, кастомізацією яка дорожчає з кожним новим каналом.
ERP вирішує ці задачі через кастомізацію, і кожна нова кастомізація додає вартість підтримки. PIM вирішує їх через конфігурацію, без розробки і без ризику зламати операційні процеси.
Дублювання виникає не при інтеграції ERP і PIM, воно виникає без PIM.
Без спеціалізованої системи управління каталогом контент-менеджер вивантажує дані з ERP, доповнює вручну в Excel і завантажує на сайт. Потім повторює те саме для маркетплейсу, в іншому форматі. Потім для наступного каналу. Кожен канал - окремий ручний процес з окремою таблицею яку потрібно підтримувати актуальною.
Це і є дублювання. Не між системами, а між людьми і каналами.
При інтеграції ERP і PIM кожен тип даних вводиться рівно один раз і в тій системі яка за нього відповідає. Операційні дані - в ERP. Продуктовий контент - в PIM. Канали отримують актуальні дані автоматично.
Питання не в кількості систем. Питання в тому скільки разів одні й ті самі дані обробляються вручну перед тим як потрапити до покупця. Чим більше каналів, тим дорожче коштує відсутність PIM. Не в теорії, в годинах роботи команди щодня.
HootCore - AI платформа яка поєднує PIM, OMS і CMS з нативною інтеграцією в існуючий ERP-стек. Підключається до поточної архітектури без зупинки операційних процесів і без заміни того що вже працює.
Якщо ваш каталог росте і ERP починає створювати обмеження, запишіться на демо або дізнайтесь більше про платформу:

Давайте обговоримо, як HootCore може вписатися у ваш стек та допомогти масштабуватися без хаосу