Тежина производа се евидентира у систему управљања материјалом. Удео рециклираног материјала се евидентира у формулационом систему. Сертификат добављача се чува као 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-ја
- Пружамо валидатор увоза који проверава ваше податке пре отпремања
Цео формат и сви упити су јавно документовани на Документација АПИ-ја као спецификација 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 спецификација на Документација АПИ-ја, заједно са примерima захтева, одговорима на грешке и детаљима аутентификације. Ништа од овога није предмет продајне презентације, па ваш тим за интеграцију може проценити колико посла је потребно пре закључења уговора. Ако пружалац услуга у овој фази не открије свој API, то само по себи представља одговор.
Шта се дешава са нашим подацима када променимо провајдера?
Они су укључени. Интерфејс прихвата неутралну JSON шему уместо власничког формата, а ваш цео инвентар се извози као CSV, XLSX, JSON-LD и SQL, или преко REST API-ја. Ово је намерно тако - формат који попуњавате је преносив, па прелазак провајдера захтева само извоз, а не поновно креирање свега испочетка. Поставите исто питање сваком провајдеру пре радионице за мапирање, јер ће након тога називи ваших поља бити укључени у њихов модел.
Колико заправо времена је потребно да се успостави веза?
У пројектима које подржавамо, процес траје две недеље: два дана мапирања, три дана до првих извоза преко нашег валидатора, три дана за решавање проблема и два дана до објављивања извештаја првог пролаза. Дуга фаза никада није сам код, већ оно што валидатор открије - недостајућа поља, недоследно кодирање и вредности за које се нико не осећа одговорним. Обавезно предвидите ове дане уместо да их скраћујете. Пројекат који их прескочи на крају ће објавити и те празнине.
Да ли морамо да повежемо све производе одједном?
Не. Прво почните са производима који захтевају пас и са изворним системом - неутрална шема прихвата делимични каталог подједнако лако као и комплетан, а увози су поновљиви, тако да ће наредне обраде ажурирати инвентар. Ово такође чини радионицу за мапирање довољно кратком да се заврши за два дана. Њено проширење након тога је задатак мапирања, а не нови пројекат.
