Перебудова eCommerce-операцій у Леруа Мерлен Україна

Виклики

Застарілий PIM гальмував розвиток онлайн-напряму

PIM дійшов до кінця свого життєвого циклу, і каталог був лише однією з речей, які на ньому трималися. На тій самій системі працювали сайт, сервіси публікації, інтеграції з ERP та каналами, а також усі внутрішні процеси роботи з товаром.

Через це будь-яка зміна виходила дорожчою, ніж мала б бути. Розширити модель даних під нову категорію, підключити ще один канал збуту, додати автоматизацію — усе це впиралося в систему, яку вже ніхто не розвивав.

Ризик зростав з кожним релізом. Коли каталог, публікація та інтеграції зав'язані в один контур, зміну в одному місці неможливо викотити, не зачепивши решту.

Зрештою швидкість розвитку всієї платформи впиралася в можливості цієї системи.

Ручна робота з товаром сповільнювала вихід нових позицій

У DIY-каталозі багато технічної інформації. Залежно від категорії товару потрібні розміри, матеріали, сумісність, дані про монтаж, вимоги безпеки — інколи це десятки атрибутів, специфічних саме для цієї групи.

Дані на вході неоднорідні. Значення приходять у різних одиницях і форматах, частина характеристик - суцільним текстом в одному полі, а обов'язкових для категорії атрибутів часто просто немає. ERP при цьому дає облікову частину: артикул, ціну, податкові та складські поля. Того, за чим покупець порівнює товари між собою, там немає.

Решту зводили руками. Контент-спеціалісти приводили одиниці до єдиного стандарту, розбирали текстові значення на окремі атрибути, дораховували те, чого не було у вихідному записі, і переписували ту саму інформацію під кожен формат публікації.

На каталозі понад 40 000 позицій це давалося взнаки:

час на заведення позиції не зменшувався з досвідом, бо кожна нова категорія приносила власний набір атрибутів і власні правила
одну зміну доводилося вносити окремо під кожен канал, і дані в них розходилися
помилку в атрибуті бачили вже на сайті або у вивантаженні, а не на етапі підготовки
якість картки залежала від того, хто саме її готував

Багато рішень щодо каталогу залишалися в головах команди. Досвідчений спеціаліст знав, як трактувати конкретне значення в конкретній категорії, але система цього не запам'ятовувала. Взяти ще людей означало вирішити проблему на місяць-два, бо обсяг роботи ріс разом із каталогом.

Онлайн губився всередині офлайн-процесів

Замовлення обробляли так само, як в офлайні. Онлайн і магазин ішли одним маршрутом, тому ecommerce-команда не мала ні власних SLA, ні можливості поставити інтернет-замовлення в пріоритет.

Аналітика теж давала небагато. Команда не бачила, скільки часу замовлення провело на кожному етапі, де саме воно зависло і чому його зрештою скасували.

Розібратися з конкретним випадком вдавалося. Побачити, де процес ламається системно, ні.

Нова архітектура мала закрити все одразу: роботу з товарними даними, публікацію каталогу, прозорість замовлень і безперервність продажів.

Рішення HootCore

Ми замінили застарілі застосунки для роботи з товаром на єдину систему, яка більше не залежить від попереднього постачальника ПЗ.

У проєкт увійшли PIM, DAM, кастомний CMS, сервіси публікації товарів, OMS, доопрацювання старого сайту та розробка нового.

Товарна інформація в одному місці

HootCore PIM став тим середовищем, де готують усе, що потім бачить покупець. Атрибути, категорії, зв'язки між товарами, описи та вимоги каналів живуть саме тут до того, як щось піде в публікацію.

ERP залишився джерелом основних бізнес-даних, і замінювати його ніхто не збирався. Просто кожна система отримала свою зону: ERP веде операційний облік, HootCore готує ці записи до продажу.

Товар, контент і замовлення в одному контурі

Товарна інформація не живе окремо від усього іншого, тому проєкт вийшов за межі PIM. Медіафайли лишаються прив'язаними до карток, контент сайту має власний процес, дані йдуть у сервіси публікації, а замовлення видно до самої видачі.

Що з чим поєднали:

PIM - товарні структури та все, що бачить покупець
DAM - фото, відео та інші матеріали
CMS - контент сайту
сервіси публікації - передача даних на вітрину
OMS - обробка замовлень і операційна прозорість

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

Від ручних рішень до системних правил

У новому PIM є Rule Engine. Він забирає рішення, які раніше повторювали вручну, і перетворює їх на логіку, яку можна підтримувати. Зараз там понад 1 500 правил: перетворення атрибутів, обчислювані значення, категоризація, перевірки та підготовка даних під конкретні канали.

Рішення все одно ухвалює людина. Але спеціаліст більше не повторює вручну те, що система застосує однаково до тисяч товарів.

Шлях товару від ERP до картки на сайті

Загальний маршрут виглядає так: ERP → HootCore PIM → перевірка і перетворення → сайт та інші канали

Найцікавіше відбувається всередині PIM, до того, як товар стане готовим до публікації.

Перевірка даних на вході з ERP

ERP дає товару облікову основу, і для картки на сайті цього замало. У записі можуть бути артикул, ціна, податкові й складські поля, але не буде тих атрибутів, за якими покупець порівнює товари між собою.

HootCore перевіряє дані одразу на вході, а не тоді, коли помилка вже вилізла на живому сайті. Так помилки ловлять на старті, а не виправляють постфактум.

Перетворення атрибутів через Rule Engine

Дані з джерела часто приходять не в тому вигляді, який потрібен каталогу. Rule Engine дозволяє описати перетворення один раз і застосовувати його до всього каталогу:

звести вихідні значення до внутрішнього стандарту
розкласти вхідні дані по правильних атрибутах
проставити або перевірити те, що специфічне для категорії
вирахувати значення з того, що вже є в картці
застосувати одне перетворення до цілої товарної групи

Коли умови збігаються, система робить те саме щоразу, спеціалісту не треба повторювати це для кожної позиції.

Автоматичний розрахунок значень

Частину полів взагалі не треба заповнювати руками: їх можна порахувати з того, що вже є в записі. Коли формули перенесли в PIM, ці поля почали рахуватися самі. А сама логіка лишилася в системі, а не в голові конкретного спеціаліста.

Одні дані, різні канали

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

HootCore готує дані під кожен канал окремо, але майстер-запис лишається один. Основа зберігається централізовано, а логіка публікації підганяє її під потрібний формат.

Для омніканального рітейлу це принципово. Централізація дає компанії контроль над товарною інформацією, а не обов'язок показувати її однаково всюди.

PIM міграція без зупинки продажів

Замінити PIM у діючому ecommerce - це не те саме, що впровадити його з нуля. На старій системі вже трималися активні картки товарів, інтеграції з ERP, адреси сторінок і накопичена органіка, контент-процеси та обробка замовлень.

Тому безперервність ми закладали в саме технічне рішення.

Спершу тест

Ми підняли тестове середовище, яке повторювало продакшн, і перевірили там новий PIM, інтеграції, поведінку каталогу та публікацію до фінального переходу.

Проблеми вилазили на тесті, а не на живому сайті. А команда клієнта встигла звикнути до нового процесу до того, як він став основним.

Потім поетапний перехід

Запуск ніколи не планували як одне незворотне перемикання. Спочатку перевірили новий PIM з інтеграціями, а старий сайт доопрацювали так, щоб продажі йшли весь час переходу.

Коли основний потік даних підтвердився, з PIM інтегрували вже новий сайт. Завдяки цьому ризик був нижчий, а командам не довелося міняти всі процеси одночасно.

І збереження адрес сторінок

Старі URL ми одразу включили в обсяг робіт. За цими адресами стояли роки пошукової видимості, зовнішні посилання та звички покупців.

Якби ми їх втратили, технічно вдала міграція обернулася б падінням трафіку й продажів. Збереження адрес захистило органіку, яку сайт напрацьовував роками.