“Besprijekorna ERP integracija” je standardno obećanje koje se u praksi prateći tromjesečnim projektom. Objavljujemo naš API priručnik kako bi vaš IT tim mogao provjeriti koja se podaci zapravo zahtijevaju prije potpisivanja ugovora. Evo šta trebate znati prije nego što se upustite u projekt integracije.
Šta vaš ERP sistem zapravo treba da pruži
Da bismo kreirali DPP, za svaki proizvod nam je potrebno sljedeće:
- Osnovni podaci - šifra artikla, opis, varijante, težine, dimenzije, slike
- Podaci o listi materijala - komponente sa količinama i recikliranim sadržajem
- Podaci o porijeklu - mjesto proizvodnje, broj serije, datum proizvodnje
- Ekološki podaci - ekvivalent CO₂ po jedinici, potrošnja vode, potrošnja energije
- Podaci o dobavljačima - ko isporučuje koju komponentu (za dužnu pažnju)
U teoriji, svi ovi podaci su dostupni u vašem ERP sistemu. Međutim, u praksi su ovi podaci raspoređeni na 4 do 7 modula: Upravljanje materijalima (MM), Proizvodnja (PP), Upravljanje kvalitetom (QM), Upravljanje dobavljačima (LFA1), ponekad zaseban EHS modul za podatke o okolišu i ponekad PLM sistem za formulacije.
Pitanje integracije nije: ‘Da li vaš ERP isporučuje podatke DPP-u?’ Već: ‘Kako objediniti podatke iz pet podsistema u jedan koherentan skup podataka?’
Tri isprobana i provjerena obrasca integracije
Obrazac 1: OData / REST pull
Dobro radi sa modernim ERP sistemima (SAP S/4HANA Cloud, Dynamics 365, Odoo). Pružalac DPP-a preuzima podatke putem OData ili REST-a. Inkrementalno, zakazano ili vođeno događajima.
Prednosti: minimalni razvoj je potreban s vaše strane; vi pružate vjerodajnice za čitanje, a pružatelj usluga gradi transformaciju.
Nedostaci: ne radi sa starijim instalacijama SAP ECC bez dodatnog API sloja. Potreban vam je nadzor nad zahtjevima za pristup podacima.
Šablon 2: Integracija zasnovana na događajima
SAP Event Mesh, Apache Kafka, RabbitMQ. Vaš ERP objavljuje događaje promjena; DPP provajder ih prima.
Prednosti: gotovo u stvarnom vremenu, elegantno skalabilno, razdvojeno.
Nedostaci: Postavljanje je složeno i zahtijeva infrastrukturu koju nema svaki IT odjel. Obično je prekomjerno za manje kompanije.
Šablon 3: Middleware / ETL
Imate sloj integracije (Mulesoft, Boomi, Informatica, Azure Data Factory) između ERP-a i vanjskih sistema. Middleware djeluje kao sučelje - DPP provajder komunicira s middlewareom, a nikada direktno s ERP-om.
Prednosti: postojeća ulaganja se mogu iskoristiti, upravljanje je stabilno, treće strane nemaju direktan pristup ERP-u.
Nedostaci: Troškovi vašeg middlewarea rastu u skladu s tim.
Šta radimo drugačije u specifičnim projektima
Mnogi pružaoci usluga žele se direktno povezati s vašim ERP-om. Mi uvijek uključujemo posrednički korak: naš API prihvata neutralnu JSON shemu, koju vi popunjavate pomoću alata po vašem izboru. To znači:
- Podatke možete pripremiti sami, koristeći alate s kojima je vaš tim upoznat
- Možete mijenjati pružatelje usluga - neutralni format je prenosiv
- Svoj cjelokupni skup podataka možete dohvatiti u bilo kojem trenutku - kao CSV, XLSX, JSON-LD i SQL, kao i putem REST API-ja
- Pružamo validator uvoza koji provjerava vaše podatke prije učitavanja
Kompletna shema i sve krajnje tačke javno su dokumentovane kao OpenAPI specifikacija na /apidocs. Vaš IT tim može testirati interfejs prije potpisivanja ugovora - uključujući primjere zahtjeva, odgovore o greškama i detalje o autentifikaciji.
Vremenski okvir za ovaj pristup u praksi:
- 1. do 2. dan: Radionica o mapiranju. Koje ERP polje odgovara kojem DPP polju?
- Dani 3 do 5: Početni JSON izvoz iz ERP-a, koji se provodi kroz naš validator.
- Dani 6 do 8: Rješavanje problema (nedostajuća polja, nedosljedno kodiranje).
- Dani 9 do 10: Prvi DPP-ovi ulaze u rad.
Dvije sedmice, a ne tri mjeseca. Suština je radionica o mapiranju - tu se određuje kvalitet podataka.
Šta može poći po zlu: najčešće zamke
Osnovni podaci o proizvodima u više sistema: SAP sadrži broj artikla, PIM slike i marketinške tekstove, a PLM sadrži listu materijala. Niko nema dosljedan pregled. Rješenje: prije početka projekta, definirajte koji je sistem “izvor istine” za svako polje.
Certifikati kao PDF-ovi: dobavljači dostavljaju GOTS, OEKO-TEX ili REACH certifikate kao skenirane PDF-ove. Ovo nije strukturirani izvor podataka. Rješenje: Akreditaciona tijela sve više nude API upite (OEKO-TEX predvodi, dok GOTS zaostaje). Alternativno: unesite podatke ručno, ali uključite datum isteka roka važenja kako biste osigurali da se u DPP-u ne pojave istekli certifikati.
Povjerljivost formulacije: posebno u kozmetici, hrani i farmaceutskoj industriji, potpuna formulacija je poslovna tajna. Treba li ih DPP učiniti javnim? Rješenje: Trošlani model ESPR-a. Kategorija proizvoda je javno dostupna; regulatorna tijela mogu vidjeti potpunu formulaciju. To gotovo nikada nije prepreka, ali se mora razjasniti u ranoj fazi.
Podaci o CO₂ zasnovani na dobavljačima: Vaš dobavljač pruža prosječnu vrijednost za cijeli svoj portfelj, a ne po seriji. Rješenje: Privremeno prihvatiti ovo; dugoročno prilagoditi ugovore s dobavljačima. ESPR zahtijeva vrijednosti specifične za proizvod od određenog datuma, ali trenutna praksa je kompromis.
Verzije na lokalnim jezicima: Vaš ERP sistem sadrži naziv proizvoda samo na njemačkom i engleskom jeziku. Za 27 zemalja EU potrebne su vam i druge. Rješenje: Mašinsko prevođenje pomoću baze terminologije; o tome imamo zaseban članak.
Pitanja koja trebate postaviti prije projekta
Prije nego što pošaljete RFP (Zahtjev za prijedlog) trima dobavljačima, odgovorite na sljedeća pitanja interno:
- Koliko proizvoda/brojeva artikala treba imati DPP-ove? (10, 10.000, 1 milion?)
- Koji sistemi trenutno sadrže podatke relevantne za DPP?
- Koji odjel upravlja svakim od ovih sistema?
- Imate li ulaganje u middleware koje treba iskoristiti?
- Postoji li već API sloj iznad vašeg ERP-a?
Odgovori će odrediti koji od tri modela je pravi za vas. I odredit će da li će projekat trajati dvije sedmice ili šest mjeseci.