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