Вага продукту вказана в модулі управління матеріалами. Частка вторинної сировини вказана в системі рецептур. Сертифікат постачальника зберігається у форматі PDF на мережевому диску. Паспорт продукту потребує всіх трьох даних в одному записі, і саме в цьому полягає суть інтеграційного проєкту, а не в з’єднанні двох систем.
«Безшовна інтеграція ERP» - це стандартна обіцянка, за якою на практиці слідує тримісячний проєкт. Ми публікуємо наш посібник, щоб ваша ІТ-служба могла перевірити, які саме дані насправді запитуються, ще до підписання договору. Ця стаття показує, які дані з ваших систем потрібні для паспорта, якими трьома шляхами вони надходять до нас і чому це можна зробити за два тижні.
Що насправді має надавати ваша ERP-система
Для створення паспорта продукту (DPP) нам потрібні для кожного продукту:
- Основні дані - номер артикулу, назва, варіанти, вага, розміри, зображення
- Дані специфікації - компоненти з кількістю та часткою вторинної сировини
- Дані про походження - місце виробництва, номер партії, дата виробництва
- Екологічні дані - CO₂eq на одиницю, споживання води, споживання енергії
- Дані про постачальників - хто постачає який компонент (для виконання обов’язків щодо належної ретельності)
Теоретично всі ці дані є у вашій ERP-системі. На практиці вони розподілені між 4-7 модулями: управління матеріалами, виробництво, якість, база даних постачальників, іноді - окремий модуль для екологічних даних, іноді - окрема система для рецептур і специфікацій.
Питання інтеграції полягає не в тому , чи «передає ваша ERP-система дані до DPP», а в тому, «як об’єднати дані з 5 підсистем у єдиний цілісний набір даних?»
Три перевірені способи
Спосіб 1: Отримання даних із ERP-системи
Добре працює з сучасними ERP-системами (SAP S/4HANA Cloud, Dynamics 365, Odoo). Постачальник DPP отримує дані через інтерфейс ERP (технічно - OData або REST). Тільки зміни, за розкладом або викликані певною подією.
Переваги: мінімальні зусилля з вашого боку - ви надаєте доступ для читання, а постачальник реалізує перетворення.
Недоліки: не працює зі старими версіями SAP ECC без додаткового рівня інтерфейсу. Потрібні чіткі правила щодо того, хто має право читати які дані.
Спосіб 2: Передача змін
Ваша ERP-система повідомляє про кожну зміну як про подію (через SAP Event Mesh, Apache Kafka або RabbitMQ), постачальник DPP її приймає.
Переваги: майже в режимі реального часу, масштабується, системи не залежать одна від одної.
Недоліки: налаштування є складним і вимагає інфраструктури, якою не володіє кожен ІТ-відділ. Для невеликих компаній це зазвичай надмірна міра.
Спосіб 3: Використання наявного інтеграційного шару
У вас уже є інтеграційний шар (Mulesoft, Boomi, Informatica, Azure Data Factory) між ERP та зовнішніми системами. Цей шар є посередником: постачальник DPP взаємодіє саме з ним, а не безпосередньо з ERP.
Переваги: можна використовувати наявні інвестиції, правила залишаються стабільними, треті сторони не мають прямого доступу до ERP.
Недоліки: ваші витрати на рівень інтеграції зростають.
Чим ми відрізняємося у конкретних проєктах
Багато постачальників хочуть підключитися безпосередньо до вашої ERP-системи. Ми завжди вбудовуємо проміжний етап: наш інтерфейс приймає нейтральний формат даних (схему JSON), який ви заповнюєте за допомогою інструменту на ваш вибір. Це означає:
- Ви можете самостійно готувати дані, використовуючи інструменти, з якими знайома ваша команда
- Ви можете замінити нас - нейтральний формат є переносимим
- Ви можете в будь-який час витягнути весь свій масив даних - у форматах CSV, XLSX, JSON-LD та SQL, а також через REST-API
- Ми надаємо валідатор імпорту, який перевіряє ваші дані перед завантаженням
Повний опис формату та всіх запитів публічно доступний за посиланням /apidocs у вигляді документації інтерфейсу відповідно до стандарту OpenAPI. Ваша ІТ-служба може перевірити інтерфейс до підписання договору - включаючи зразки запитів, відповіді про помилки та деталі автентифікації.
Терміни реалізації цього підходу на практиці:
- 1-2-й день: семінар із маппінгу. Яке поле ERP відповідатиме якому полю DPP?
- 3-5-й день: перші експорти у форматі JSON із ERP, перевірені нашим валідатором.
- 6-8-й день: усунення помилок (відсутні поля, невідповідності у кодуванні).
- 9-10-й день: перші DPP запущені в роботу.
Два тижні, а не три місяці. Ключовим моментом є семінар з маппінгу - саме там вирішується питання якості даних.
Що може піти не так: найпоширеніші пастки
Базові дані про продукцію в декількох системах: у SAP - артикули, у PIM - зображення та маркетингові тексти, у PLM - специфікації. Ніхто не має цілісної картини. Рішення: ще до початку проєкту визначте, яка система є провідною для кожного поля.
Сертифікати у форматі PDF: постачальники надають сертифікати GOTS, OEKO-TEX або REACH у вигляді відсканованих PDF-файлів. Це не є структурованим джерелом даних. Рішення: організації, що проводять сертифікацію, дедалі частіше пропонують запит через інтерфейс (OEKO-TEX лідирує, GOTS відстає). Або: вводити дані вручну, але із зазначенням терміну дії, щоб у DPP не з’являлися сертифікати з вичерпаним терміном дії.
Конфіденційність рецептури: особливо у косметичній, харчовій та фармацевтичній галузях: повна рецептура є комерційною таємницею. Чи має DPP оприлюднювати їх? Рішення: трирівнева модель ESPR. Публічно доступна категорія продукту, а органи влади бачать повний склад. Це майже ніколи не стає перешкодою, але питання потрібно з’ясувати на ранньому етапі.
Дані щодо викидів CO₂ на основі інформації від постачальників: ваш постачальник надає середнє значення для всього свого асортименту, а не для кожної партії. Рішення: тимчасово прийняти це, а в довгостроковій перспективі скоригувати договори з постачальниками. ESPR вимагає значень для конкретних продуктів, починаючи з певної дати, але поточна практика є компромісом.
Місцеві мовні версії: Ваша ERP-система містить лише назви товарів німецькою та англійською мовами. Для 27 країн ЄС вам потрібно більше. Рішення: машинний переклад із використанням термінологічної бази даних; ми підготували окрему статтю з цього приводу.
Питання, які слід поставити перед початком проєкту
Перш ніж надсилати запит на пропозицію (RFP) трьом постачальникам, дайте відповіді на такі внутрішні запитання:
- Скільки товарів/артикулів мають мати DPP? (10, 10 000, 1 мільйон?)
- Які системи на сьогодні містять дані, що стосуються DPP?
- Який відділ управляє кожною з цих систем?
- Чи є у вас інтеграційний шар, який слід використовувати?
- Чи існує вже діючий інтерфейс через вашу ERP-систему?
Відповіді на ці запитання визначають, який із трьох підходів підходить саме вам. А також вони визначають, чи триватиме проект два тижні чи шість місяців.
Питання щодо цього допису
Чи достатньо REST-інтерфейсу, чи нам потрібне проміжне програмне забезпечення?
Інтерфейс цілком достатній. Ці три шаблони відрізняються тим, де відбувається трансформація, а не тим, що ми приймаємо - наш інтерфейс приймає нейтральну схему JSON, незалежно від того, як ви її створили. Запит із сучасної ERP-системи, потік подій та існуючий інтеграційний шар - усі вони закінчуються на одній і тій самій кінцевій точці. Використання проміжного програмного забезпечення доцільне, якщо ви вже використовуєте його і хочете, щоб воно залишалося частиною договору з третіми сторонами. Якщо його зараз немає, не купуйте його спеціально для сертифіката продукту.
Що вирішується під час семінару з маппінгу?
Яке поле ERP відповідає якому полю пасу - і яка система є основним джерелом, якщо кілька систем містять одне й те саме значення. Семінар проводиться на 1-му та 2-му днях і є ключовим моментом усього проєкту, оскільки саме там приймаються рішення щодо якості даних, а не пізніше під час написання коду. Запросіть на семінар тих, хто обслуговує системи, а не лише тих, хто відповідає за проект - відділи бази даних, виробництва, якості та закупівель рідко об’єднані в одному підрозділі. Усе, що буде далі - експорт даних, валідація та усунення помилок - це вже практична робота.
Наші сертифікати є лише у вигляді сканованих PDF-файлів. Що нам з ними робити?
Скан-копія не є структурованим джерелом даних і тому непридатна для використання в паспорті. Є два способи: оператори сертифікації дедалі частіше пропонують запити через API, а там, де їх немає, вводьте значення вручну, але завжди вказуйте дату дії, щоб у опублікованому паспорті не залишився сертифікат із вичерпаним терміном дії. Плануйте ручний спосіб як регулярну роботу, а не як одноразове завдання.
Чи може наш ІТ-відділ перевірити цей інтерфейс, перш ніж ми щось підпишемо?
Так. Повна схема та всі кінцеві точки доступні у вигляді специфікації OpenAPI за адресою /apidocs, разом із прикладами запитів, відповідями на помилки та деталями автентифікації. Ніщо з цього не приховано за переговорами щодо продажу, тож ваша команда з інтеграції може оцінити обсяг роботи ще до укладення договору. Якщо постачальник не демонструє свій інтерфейс на цьому етапі, це також є певною відповіддю.
Що станеться з нашими даними, якщо ми змінимо постачальника послуг?
Вони підходять. Інтерфейс приймає нейтральну схему JSON замість пропрієтарного формату, а всі ваші дані виводяться у форматах CSV, XLSX, JSON-LD та SQL або через REST-API. Це зроблено навмисно - формат, який ви заповнюєте, є переносимим, тож зміна вимагає лише експорту, а не створення нової бази. Поставте кожному постачальнику однакове запитання перед семінаром з маппінгу, адже після цього назви ваших полів будуть присутні в його моделі.
Скільки часу насправді займає підключення?
У проектах, які ми супроводжуємо, два тижні - два дні на маппінг, три дні до перших експортів через наш валідатор, три дні на усунення помилок, два дні до опублікування перших паспортів. Найдовший шлях - це ніколи не код, а те, що знаходить валідатор: відсутні поля, неоднакові коди, значення, за які ніхто не бере на себе відповідальність. Заплануйте ці дні, замість того щоб скорочувати їх. Проєкт, який пропускає ці етапи, публікує разом із даними й ці прогалини.
Чи потрібно підключати всі продукти одночасно?
Ні. Почніть з продуктів, для яких спочатку потрібен «паспорт», та з вихідної системи - нейтральна схема приймає як частковий каталог, так і повний, а імпорт можна повторювати, тож наступні запуски оновлюють перелік. Це також дозволяє зберегти обсяг семінару з маппінгу настільки невеликим, що його можна пройти за два дні. Подальше розширення - це завдання з маппінгу, а не новий проєкт.
