Анатолій Даньков
CEO
Один постачальник надсилає прайс зі своїми назвами колонок, інший - PDF-каталог, третій - фото товарів окремим листом від файлу з характеристиками, і хтось у вашій команді витрачає наступні два дні, зводячи все це в один SKU, перш ніж товар можна опублікувати.
Рітейлери з великими каталогами працюють із десятками чи сотнями постачальників, і кожен з них форматує, називає й структурує товарні дані по-своєму. PIM може зберігати й збагачувати ці дані, коли вони вже надійшли, але не може зробити вхідні файли однаковими. Розрив закривається вручну: перейменування колонок, пошук зображень, що загубились, повторна перевірка тих самих атрибутів щоразу, коли постачальник надсилає оновлення.
Наша стаття пояснює, що таке онбординг товарних даних постачальників, як він працює і, де ламається зі зростанням кількості постачальників та розміру каталогу.
Онбординг товарних даних постачальників - це процес збору даних про товари від постачальників, перевірки їх на відповідність вимогам каталогу і внесення в системи, які керують товарними записами. Це не тільки передача файлу - це зіставлення полів, валідація й збагачення того, чого бракує.
Термін часто плутають із суміжними, і ця плутанина заважає рітейлеру шукати правильне рішення. Товарні дані постачальника - це конкретно атрибути, зображення й контент, потрібні для продажу товару, а не банківські реквізити чи податкові документи постачальника. Онбординг товарних даних - це процес; портал постачальник, як один зі способів його провести.
Портал постачальника - це платформа, де постачальники самі вносять інформацію, замість надсилання файлів поштою. Якщо шукати цей термін, більшість результатів веде до закупівельного ПЗ - обробки рахунків, інвойсів, податкової документації, бо саме це «портал постачальника» означає в корпоративному софті.
Портали, що працюють із товарними даними, окрема категорія, яку іноді називають системами управління даними постачальників або інструментами онбордингу постачальників. Вони роблять те саме - контрольований доступ, структуроване внесення даних, але для атрибутів, зображень і описів, а не рахунків. Різниця важлива при виборі інструменту: портал для закупівель не перевірить зображення товару й не зіставить категорійне дерево, а портал для товарних даних не обробить платіж.
Збір товарних даних постачальників здається задачею з файлами, і рітейлери зазвичай так і організовують роботу: хтось відкриває кожен файл, звіряє з каталогом, вносить те, чого бракує. Реальна проблема не у файлах. Вона в тому, що жоден постачальник не надсилає дані в тому самому вигляді, і кожну розбіжність має вирішити людина, перш ніж товар з'явиться в каталозі.
Ця робота зростає разом із каталогом. Рітейлер, що онбордить кілька нових SKU на місяць, витримає це навантаження. Той, хто онбордить сотні SKU від десятків постачальників, ні: та сама ручна перевірка повторюється щоразу, для кожного постачальника, у будь-якому форматі, яким він користується.
Ніщо не змушує двох постачальників описувати той самий товар однаково - кожен працює у своїй системі, зі своїм шаблоном і власним уявленням про те, що має містити товарний запис. Один надсилає прайс зі своїми назвами колонок, інший - PDF-каталог, де дані вбудовані в макет, а не в поля, третій - API-фід для залишків, але окремий лист для зображень. Назви атрибутів різняться: «вага» проти «вага товару» проти «вага при відправці», і жодна з них не мапиться на ваше категорійне дерево автоматично.
Великі постачальники додають складності, а не знімають її. Вони можуть пропонувати 200 і більше атрибутів на SKU, розподілених між веб-формами, масовим імпортом, API та FTP, часто в межах одного акаунту. Результат - не одна інтеграційна задача, а стільки, скільки постачальників, кожен зі своїм форматом, бо ніщо не стандартизує це на вході.
Незалежно від платформи, онбординг товарних даних постачальників проходить чотири етапи: дати постачальнику спосіб доступу, зібрати те, що він надсилає, перевірити й покращити це, перенести в системи, які керують каталогом. Деталі різняться, якісь етапи ручні, якісь автоматизовані, але саме пропуск етапу зазвичай ламає процес.
Портал постачальника замінює електронну пошту як точку входу. Замість надсилання файлів на пошту, постачальники входять у спільний інтерфейс з доступом, обмеженим власними товарами, один постачальник не бачить дані чи ціни іншого. Доступ зазвичай починається із запрошення: постачальник отримує захищене посилання, і більшість порталів дозволяють почати вносити дані без створення акаунту чи встановлення чогось додатково.
Доступ зазвичай супроводжується правами: що постачальник може подати, що може редагувати після подачі, чи бачить статус власних записів. Рітейлери з невеликою кількістю постачальників іноді пропускають цей крок і лишаються на пошті - портал стає потрібним, коли кількість постачальників перетворює відстеження «хто що надіслав і коли» на окрему роботу.
Дані надходять у тому форматі, яким постачальник уже користується: прайс, XML- чи CSV-фід, масове завантаження файлу, пряме API-підключення. Робочий процес онбордингу приймає той формат, який постачальник уже виробляє, замість вимоги його змінити, і потім мапить його поля на власну модель атрибутів.
Доступ через API - найшвидший і найнадійніший шлях, коли постачальник його підтримує: оновлення надходять автоматично, без жодного файлу для обробки. Більшість рітейлерів працюють одразу з кількома способами отримання даних, бо рівень технічної зрілості постачальників різниться більше, ніж самі каталоги.
Це крок, який визначає, чи спрацює все наступне. Якість товарних даних перевіряється на відповідність вимогам рітейлера - обов'язкові поля, категорійні атрибути, специфікації зображень - до того, як запис потрапляє в каталог, а не після.
Валідація ловить те, що ручна перевірка пропускає при великому обсязі: порожнє поле ваги, невідповідність категорії, значення атрибута поза очікуваним діапазоном. Записи, що не пройшли перевірку, повертаються постачальнику з поясненням, що виправити, замість того щоб потрапити в каталог із прогалиною, яка спливе пізніше як помилка доставки чи неякісна сторінка товару.
Постачальники рідко надсилають готовий маркетинговий контент. Зазвичай приходить технічна інформація - артикул, специфікація, сирий розмір, і хтось має перетворити це на опис, назву й набір атрибутів, придатних для пошуку.
AI-збагачення автоматизує ту частину роботи, яка підпорядковується патерну: класифікацію товару в потрібну категорію за описом, генерацію значень атрибутів із наявного тексту, позначення того, що досі потребує людини. Це звужує ручну роботу до справді нового контенту, а не кожного SKU, що проходить через систему. Подивіться, як працює AI-збагачення на каталогах із неповними даними постачальника.
Останній крок переносить перевірені, збагачені записи в систему управління товарною інформацією - систему, яка зберігає й розповсюджує товарні дані по всіх каналах продажу. Звідти той самий запис живить сайт, лістинг на маркетплейсі, а для рітейлерів із розподіленою логістикою, і логіку маршрутизації замовлень, яка залежить від точності атрибутів.
Процес, що зупиняється на «зібрано», а не доходить до «доставлено в кожну систему, якій це потрібно», вирішує проблему лише наполовину: дані існують, але їх усе ще треба переносити й синхронізувати вручну.
Чотири кроки вище працюють послідовно, і більшість проблем інтеграції постачальників зводяться до пропуску одного з них, а не до неправильного інструменту. Рітейлер із правильною платформою, але без кроку валідації, все одно отримує поганий каталог. Той, хто має сильну валідацію, але без збагачення, все одно отримує технічно звучні сторінки товарів.
Ручний імпорт товарних даних не масштабуєтьсяРучний імпорт товарних даних працює, коли кілька людей можуть переглянути все, що надходить. Він перестає працювати в момент, коли нові SKU й оновлення від постачальників приходять швидше, ніж команда може їх перевірити вручну, і збій тихий: нічого не ламається, записи просто починають потрапляти в каталог без перевірки.
Обсяг, на якому це ламається, залежить від розміру команди, а не від фіксованої кількості SKU. Незмінний патерн: час на перевірку зростає з кількістю постачальників, а не тільки з розміром каталогу, бо кожен постачальник додає власний формат для перевірки.
Відсутність системи управління даними постачальників за процесомБез системи, що відстежує, що кожен постачальник надіслав, коли і в якому стані, рітейлери втрачають видимість власного пайплайна онбордингу. Ніхто не може впевнено сказати, які постачальники актуальні, які записи очікують перевірки, які SKU опубліковані з відомою прогалиною.
Це відрізняється від відсутності порталу. Рітейлер може мати чистий процес приймання даних і все одно не мати шару управління даними постачальників за ним жодної історії, жодного способу побачити патерни між постачальниками, жодного способу помітити, що ті самі три поля бракують у того самого постачальника щомісяця.
Валідація товарних даних відбувається запізно або не відбувається взагаліНайпоширеніший збій - не пропуск валідації, а її запуск після того, як дані вже опубліковані. Запис потрапляє в каталог, і лише коли з'являється скарга клієнта чи помилка доставки, хтось перевіряє, чи атрибути були правильними спочатку.
Валідація до публікації коштує затримки в кілька хвилин на запис. Валідація після публікації коштує помилки перед клієнтом, ручного виправлення і, для рітейлерів, що маршрутизують замовлення на основі атрибутів каталогу, неправильного рішення з доставки, ухваленого на даних, які ніхто не перевірив.
Не кожен інструмент, що обіцяє вирішити онбординг товарних даних постачальників, підходить для будь-якого масштабу чи задачі. Перш ніж порівнювати платформи, ось критерії, які визначають, чи підходить рішення:
Онбординг товарних даних постачальників охоплює широкий спектр підходів від пошти й прайсів до окремих порталів і онбордингу, вбудованого прямо в PIM. Правильний вибір залежить від того, де саме ламається ваш процес - на зборі, на валідації чи в розриві між ними, а не від довжини списку функцій платформи.
Якщо постачальники досі надсилають файли поштою, почніть із порталу, щоб усі подавали дані однаково. Якщо портал є, але помилки все одно потрапляють у каталог, розрив - у валідації, яка відбувається запізно або не відбувається взагалі. Якщо обидва працюють, але запис усе одно потребує окремого експорту й імпорту для потрапляння в PIM, процес використовує три інструменти там, де могла б бути одна платформа.
Найкращий спосіб перевірити свій підхід - простежити, де саме ламається ваш власний онбординг, або забронювати демо, щоб побачити, як це працює всередині PIM.
Процес збору даних про товари від постачальників, перевірки на відповідність вимогам каталогу і внесення в системи управління товарними записами, не тільки передача файлу, а мапінг, валідація й збагачення, що робить дані придатними для використання.
Комбінацією способів: портал постачальника для структурованої подачі, API-фіди там, де постачальник їх підтримує, файлові завантаження для решти. Важливіший за спосіб отримання те, що відбувається після: мапінг, валідація й затвердження до потрапляння запису в каталог.
Портал - це один інструмент, куди постачальник вносить дані. Онбординг - це весь процес: збір, валідація, збагачення, доставка в системи, що використовують дані. Портал без валідації за ним все одно залишає помилки для ручної перевірки.
Поспілкуйтеся з нашою командою та подивіться, як HootCore інтегрується у ваш існуючий tech stack — від управління товарними даними до обробки замовлень