Тежината на производот се евидентира во управувањето со материјали. Пропорцијата на рециклиран материјал се евидентира во системот за формулација. Сертификатот на добавувачот се зачувува како PDF на мрежен диск. Пасошот на производот бара сите три информации во една единствена евиденција, и токму тоа е целта на проектот за интеграција - не само поврзување на два система.
“Беспрекорна ERP интеграција” е стандардно ветување кое, во пракса, е проследено со тримесечен проект. Го објавуваме нашиот водич за да може вашето ИТ-одделение да провери кои податоци се навистина потребни пред да го потпише договорот. Оваа статија објаснува кои податоци пасошот ги бара од вашите системи, трите начини на кои ни се испраќаат и зошто ова може да се постигне за две недели.
Што всушност треба да обезбеди вашиот ERP систем
За да создадеме ДПП, ни се потребни следниве податоци за секој производ:
- Основни податоци - број на артикал, опис, варијанти, тежини, димензии, слики
- Податоци за спецификација на материјали - компоненти со количини и рециклирана содржина
- Податоци за потекло - локација на производство, број на серија, датум на производство
- Еколошки податоци - CO₂-еквивалент по единица, потрошувачка на вода, потрошувачка на енергија
- Податоци за добавувачи - кој ја снабдува која компонента (за барањата за должна грижа)
Во теорија, сите овие податоци се достапни во вашиот ЕРП-систем. Меѓутоа, во пракса, тие се распределени во 4 до 7 модули: управување со материјали, производство, квалитет, основни податоци за добавувачи, понекогаш посебен модул за еколошки податоци и понекогаш посветен систем за формулации и пресметки на материјали.
Прашањето во врска со интеграцијата не е: “Дали вашиот ERP систем испорачува податоци до DPP?” Туку: “Како ги спојувате податоците од пет потсистеми во еден кохерентен сет на податоци?”
Три испробани и проверени пристапи
Пристап 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 како спецификација на API во согласност со OpenAPI. Вашиот ИТ тим може да го прегледа API-то пред да се потпише договорот - вклучувајќи примероци на барања, одговори за грешки и детали за автентикација.
Временска рамка за овој пристап во пракса:
- Денови 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 треба да го објави? Решение: Троен модел на ESPR. Категоријата на производот се објавува јавно; регулаторните тела можат да ја видат целата формулација. Ова речиси никогаш не претставува пречка, но мора да се разјасни во рана фаза.
Податоци за CO₂ врз основа на добавувачи: Вашиот добавувач обезбедува просечна вредност за целото свое портфолио, а не по серија. Решение: Прифатете го ова привремено; приспособете ги договорите со добавувачите на долг рок. ESPR бара вредности специфични за производот од одреден краен рок, но тековната пракса е компромис.
Локални верзии на јазик: Вашиот ERP систем го содржи името на производот само на германски и англиски јазик. За 27-те земји на ЕУ, потребни ви се повеќе. Решение: машински превод со помош на база на термини; имаме посебна статија за ова.
Прашања што треба да ги поставите пред да го започнете проектот
Пред да испратите RFP до три добавувачи, одговорете на следниве прашања интерно:
- Колку производи/бројки на артикли треба да имаат DPP? (10, 10.000, 1 милион?)
- Кои системи моментално содржат податоци релевантни за DPP?
- Кој оддел управува со секој од овие системи?
- Дали имате слој за интеграција што треба да се искористи?
- Дали веќе постои интерфејс преку вашиот ЕРП?
Одговорите ќе одредат кој од трите пристапа е вистинскиот за вас. И тие ќе одредат дали проектот ќе трае две недели или шест месеци.
Прашања за оваа објава
Дали REST интерфејсот е доволен или ни треба мидлвејр?
Интерфејсот е доволен. Трите шаблони се разликуваат по тоа каде се одвива трансформацијата, а не по тоа што прифаќаме - нашиот интерфејс прифаќа неутрална JSON-шема, без разлика како сте ја генерирале. Повлекување од модерен ERP, поток на настани и постоечки интеграциски слој сите завршуваат на истиот краен пункт. Вреди да се користи middleware ако веќе користите некој и тој треба да остане договорниот интерфејс со трети страни. Ако денес немате ништо такво, не купувајте го само за пасошот на производот.
Што ќе се одлучи на работилницата за мапирање?
Кое поле во ERP соодветствува на кое поле со основни податоци - и кој систем е авторитетен извор кога повеќе системи ја чуваат истата вредност. Работилницата се одржува на 1-ви и 2-ри ден и е клучна за целиот проект, бидејќи одлуките за квалитетот на податоците се носат таму, а не подоцна во кодот. Осигурајте се да ги доведете луѓето кои ги одржуваат системите, а не само оние одговорни за проектот - мајсторските податоци, производството, квалитетот и набавката ретко се дел од истиот оддел. Сè што следува - извози, валидација и решавање на проблеми - е прашање на техничка експертиза.
Нашите сертификати се достапни само како PDF скенови. Што треба да правиме со нив?
Скенирањето не е структуриран извор на податоци и затоа е неискористиво за пасот. Постојат два начина за постапување - сертификатните органи сè повеќе нудат API-пребарувања, а каде што тие не се достапни, внесете ги вредностите рачно, но секогаш вклучете го датумот на истекување за да се осигурате дека во објавениот пас нема да остане ниту еден истечен сертификат. Сфатете го рачниот процес како повторлива задача, а не како еднократна работа.
Може ли нашиот ИТ-оддел да го провери интерфејсот пред да потпишеме било што?
Да. Целосната шема и сите крајни точки се достапни како OpenAPI спецификација на /apidocs, заедно со примероци на барања, одговори при грешки и детали за автентикација. Ништо од ова не е предмет на продажни преговори, па вашиот тим за интеграција може да ја процени потребната работа пред да се склучи договор. Ако давателот не го открие својот API во оваа фаза, тоа само по себе е одговор.
Што се случува со нашите податоци кога ќе го смениме провајдерот?
Тие се приклучија. Интерфејсот прифаќа неутрална JSON-шема наместо сопствен формат, а целиот ваш инвентар се извезува како CSV, XLSX, JSON-LD и SQL, или преку REST API. Ова е намерно - форматот што го пополнувате е пренослив, па префрлувањето на провајдери вклучува само извоз, наместо да морате да го градите сè од почеток. Поставете им на сите провајдери истото прашање пред работилницата за мапирање, бидејќи имињата на вашите полиња потоа ќе бидат вклучени во нивниот модел.
Колку навистина трае поврзувањето?
Во проектите што ги поддржуваме, процесот трае две недели: два дена за мапирање, три дена до првите извози преку нашиот валидатор, три дена за решавање на проблеми и два дена до објавувањето на првите извештаи од прегледот. Вистинската пречка никогаш не е самиот код, туку она што го открива валидаторот - недостасувачки полиња, неконзистентно кодирање и вредности за кои никој не се чувствува одговорен. Осигурајте се дека ќе ги предвидите овие денови, наместо да ги скратувате. Проект што ќе ги прескокне ќе ги објави и тие празнини.
Дали мораме да ги поврземе сите производи одеднаш?
Не. Прво започнете со производите што бараат пасош и со изворен систем - неутралната шема прифаќа делумен каталог исто толку лесно како и целосен, а увозните операции се повторливи, така што следните извршувања ќе го ажурираат инвентарот. Ова исто така ја одржува работилницата за мапирање доволно кратка за да се заврши за два дена. Нејзиното проширување потоа е задача за мапирање, а не нов проект.
