„Безпроблемна ERP-интеграция“ е стандартно обещание, което на практика води до тримесечен проект. Публикуваме нашето ръководство за API, за да може вашият ИТ-отдел да провери какво всъщност се изисква, преди да подпишете договора. Ето какво трябва да знаете преди да започнете проект за интеграция.
Какво всъщност трябва да предоставя вашата ERP система
За да се създаде DPP, за всеки продукт ни са необходими:
- Базови данни - артикулен номер, наименование, варианти, тегло, размери, изображения
- Данни за спецификацията - компоненти с количества и дял на рециклираните материали
- Данни за произхода - място на производство, номер на партидата, дата на производство
- Данни за околната среда - CO2eq на единица, потребление на вода, потребление на енергия
- Данни за доставчиците - кой доставя кой компонент (за целите на дю дилиджънс)
Теоретично всички тези данни са налични във вашата 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
- Предоставяме валидатор за импортиране, който проверява данните ви преди качването
Пълната схема и всички крайни точки са публично документирани в /apidocs като OpenAPI спецификация. Вашият ИТ екип може да провери интерфейса, преди да бъде подписан договор - включително примерни заявки, отговори при грешки и подробности за удостоверяване.
Времева рамка за този подход на практика:
- Ден 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 система?
Отговорите определят кой от трите модела е подходящ за вас. И те определят дали проектът ще продължи две седмици или шест месеца.