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