Тежина производа се евидентира у систему управљања материјалима. Удео рециклираног материјала се евидентира у формулационом систему. Сертификат добављача се чува као PDF на мрежном диску. Пасош производа захтева све три информације у једном запису података, и управо се о томе ради у пројекту интеграције - не само о повезивању два система.
“Беспрекорна интеграција ERP система” је стандардно обећање које се у пракси прати тромесечним пројектом. Објављујемо наш водич како би ваш ИТ одсек могао да провери које су податке заправо потребне пре потписивања уговора. Овај чланак објашњава које податке пасош захтева од ваших система, три начина на које нам се он шаље и зашто се то може остварити за две недеље.
Шта ваш ERP систем заправо треба да обезбеди
За креирање ДПП-а, за сваки производ нам је потребно следеће:
- Основni подаци - шифра артикла, опис, варијанте, тежине, димензије, слике
- Подаци о листи материјала - компоненте са количинама и рециклираним садржајем
- Подаци о пореклу - место производње, број серије, датум производње
- Еколошки подаци - CO₂ еквивалент по јединици, потрошња воде, потрошња енергије
- Подаци о добављачу - ко испоручује коју компоненту (за потребе дужне пажње)
У теорији, сви ови подаци су доступни у вашем ERP систему. Међутим, у пракси су распоређени у 4 до 7 модула: управљање материјалом, производња, квалитет, матични подаци о добављачима, понекад посебан модул за еколошке податке и понекад посебан систем за формуле и листе материјала.
Питање у вези са интеграцијом није: “Да ли ваш ERP систем испоручује податке DPP-у?” Већ: “Како да обједините податке из пет подсистема у један кохерентан скуп података?”
Три испробана и проверена приступа
Приступ 1: Преузимање података из ERP-а
Ради добро са савременим ERP системима (SAP S/4HANA Cloud, Dynamics 365, Odoo). Провајдер DPP-а преузима податке преко интерфејса ERP-а (технички OData или REST). Преузимају се само измене, било по распореду или по покретању догађајем.
Предности: минималан развој потребан је са ваше стране; ви обезбеђујете приступ за читање, а провајдер се брине о конверзији.
Недостаци: не функционише са старијим инсталацијама SAP ECC без додатног интерфејс слоја. Потребна су вам јасна правила која регулишу ко је овлашћен да приступи којим подацима.
Опција 2: Прослеђивање промена
Ваш ЕРП пријављује сваку промену као догађај (преко 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 система, ток догађаја и постојећи слој интеграције завршавају на истом крајњем месту. Вреди користити middleware ако већ користите неки и желите да он остане уговорни интерфејс са трећим странама. Ако тренутно немате ниједан, не купујте ниједан посебно за пасош производа.
Шта ће бити одлучено на радионици за мапирање?
Које ERP поље одговара којем пољу мастер података - и који систем је ауторитативни извор када више система има исту вредност. Радионица се одржава првог и другог дана и представља срж целог пројекта, јер се одлуке о квалитету података доносе тамо, а не касније у коду. Обавезно доведите људе који одржавају системе, а не само оне задужене за пројекат - мастер подаци, производња, квалитет и набавка ретко спадају у исти одсек. Све што следи - извози, валидација и решавање проблема - једноставно је питање техничке стручности.
Наши сертификати су доступни само као PDF скенови. Шта да радимо са њима?
Скен није структуриран извор података и стога је немогуће користити га за пропусницу. Постоје два начина да се настави - провајдери сертификата све више нуде API упите, а где они нису доступни, можете ручно унети вредности, али увек наведите датум истека рока важења како бисте осигурали да ниједан истекли сертификат не остане у објављеној пропусници. Сматрајте ручни процес понављајућим задатком, а не једнократним послом.
Може ли наш ИТ одељење да провери интерфејс пре него што потпишемо било шта?
Да. Целокупна шема и сви крајњи пунктови доступни су као OpenAPI спецификација у API документацији, заједно са примерima захтева, одговорима на грешке и детаљима аутентификације. Ништа од овога није предмет продајне презентације, па ваш тим за интеграцију може проценити колико посла је потребно пре закључења уговора. Ако провајдер у овој фази не открије свој API, то само по себи представља одговор.
Шта се дешава са нашим подацима када променимо провајдера?
Они су укључени. Интерфејс прихвата неутралну JSON шему уместо власничког формата, а ваш цео инвентар се извози као CSV, XLSX, JSON-LD и SQL, или преко REST API-ја. Ово је намерно тако - формат који попуњавате је преносив, па прелазак провајдера захтева само извоз, а не поновно креирање свега испочетка. Поставите исто питање сваком провајдеру пре радионице за мапирање, јер ће након тога називи ваших поља бити укључени у њихов модел.
Колико заправо времена је потребно да се успостави веза?
У пројектима које подржавамо, процес траје две недеље: два дана мапирања, три дана до првих извоза преко нашег валидатора, три дана за решавање проблема и два дана до објављивања извештаја првог пролаза. Дуга фаза никада није сам код, већ оно што валидатор открије - недостајућа поља, недоследно кодирање и вредности за које се нико не осећа одговорним. Обавезно предвидите ове дане уместо да их скраћујете. Пројекат који их прескочи на крају ће објавити и те празнине.
Да ли морамо да повежемо све производе одједном?
Не. Прво почните са производима који захтевају пас и са изворним системом - неутрална шема прихвата делимични каталог подједнако лако као и комплетан, а увози су поновљиви, тако да ће наредне обраде ажурирати инвентар. Ово такође чини радионицу за мапирање довољно кратком да се заврши за два дана. Њено проширење након тога је задатак мапирања, а не нови пројекат.
