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