Težina proizvoda bilježi se u sustavu za upravljanje materijalima. Udio recikliranog materijala bilježi se u sustavu za formulacije. Certifikat dobavljača pohranjuje se kao PDF na mrežnom pogonu. Proizvodna iskaznica zahtijeva sva tri podatka u jednom zapisu, a upravo se o tome radi u projektu integracije - ne samo o povezivanju dva sustava.
“Besprijekorna ERP integracija” standardno je obećanje koje se u praksi prati tromjesečnim projektom. Objavljujemo naš vodič kako bi vaš IT tim mogao provjeriti koja su podatke zapravo potrebna prije potpisivanja ugovora. Ovaj članak objašnjava koje podatke putovnica zahtijeva od vaših sustava, tri načina na koje nam se šalju i zašto se to može postići u dva tjedna.
Što vaš ERP sustav zapravo treba pružiti
Za izradu DPP-a za svaki proizvod zahtijevamo sljedeće:
- Osnovni podaci - broj artikla, opis, varijante, težine, dimenzije, slike
- Podaci o popisu materijala - komponente s količinama i udjelom recikliranog sadržaja
- Podaci o podrijetlu - mjesto proizvodnje, broj serije, datum proizvodnje
- Ekološki podaci - ekvivalent CO₂ po jedinici, potrošnja vode, potrošnja energije
- Podaci o dobavljačima - tko isporučuje koju komponentu (za potrebe dužne skrbi)
U teoriji, svi su ti podaci dostupni u vašem ERP sustavu. U praksi su, međutim, raspoređeni na 4 do 7 modula: upravljanje materijalima, proizvodnja, kvaliteta, osnovni podaci o dobavljačima, ponekad zaseban modul za podatke o okolišu i ponekad namjenski sustav za recepte i popise materijala.
Pitanje u vezi s integracijom nije: “Dostavlja li vaš ERP podatke DPP-u?” Već: “Kako objediniti podatke iz pet podsustava u jedan koherentan skup podataka?”
Tri isprobana i provjerena pristupa
Pristup 1: Preuzimanje podataka iz ERP-a
Dobro funkcionira s modernim ERP-ovima (SAP S/4HANA Cloud, Dynamics 365, Odoo). Pružatelj usluga DPP-a preuzima podatke putem sučelja ERP-a (tehnički OData ili REST). Preuzimaju se samo promjene, bilo na zakazanoj osnovi ili pokrenute događajem.
Prednosti: minimalni razvoj s vaše strane; vi osiguravate pristup za čitanje, a pružatelj usluge se brine o konverziji.
Nedostaci: ne radi s starijim instalacijama SAP ECC bez dodatnog sloja sučelja. Potrebna su jasna pravila koja uređuju tko je ovlašten čitati koje podatke.
Opcija 2: Prosljeđivanje promjena
Vaš ERP sustav prijavljuje svaku promjenu kao događaj (putem SAP Event Mesh, Apache Kafka ili RabbitMQ), a DPP pružatelj usluga ih prima.
Prednosti: gotovo u stvarnom vremenu; prilagodljiv vašim potrebama; sustavi nisu međusobno ovisni.
Nedostaci: Postavljanje je složeno i zahtijeva infrastrukturu koju nema svako IT odjeljenje. Obično je prekomjerno za manje tvrtke.
Opcija 3: Korištenje postojećeg sloja integracije
Već imate sloj integracije (Mulesoft, Boomi, Informatica, Azure Data Factory) između ERP-a i vanjskih sustava. Taj sloj djeluje kao posrednik: DPP pružatelj usluga komunicira s njim, a nikada izravno s ERP-om.
Prednosti: postojeća ulaganja mogu se iskoristiti, pravila ostaju stabilna i treće strane nemaju izravan pristup ERP-u.
Nedostaci: vaši troškovi za sloj integracije povećavaju se u skladu s tim.
Što radimo drugačije u određenim projektima
Mnogi pružatelji usluga žele se izravno povezati s vašim ERP-om. Uvijek uključujemo posrednički korak: naš sučelje prihvaća neutralni format podataka (JSON shemu), koji 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
- U bilo kojem trenutku možete dohvatiti cijeli svoj skup podataka - 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
Kompletan format i svi upiti javno su dokumentirani na /apidocs, kao opis API-ja u skladu s OpenAPI-jem. Vaš IT tim može pregledati API prije potpisivanja ugovora - uključujući primjere zahtjeva, odgovore na pogreške i detalje o autentifikaciji.
Vremenski okvir za ovaj pristup u praksi:
- 1. - 2. dan: Radionica o mapiranju. Koje ERP polje odgovara kojem DPP polju?
- 3. - 5. dan: Početni JSON izvoz iz ERP-a, proveden kroz naš validator.
- 6. do 8. dan: Rješavanje problema (nedostajuća polja, nedosljedno kodiranje).
- 9. i 10. dan: Prvi DPP-ovi ulaze u rad.
Dva tjedna, a ne tri mjeseca. Suština je radionica o mapiranju - ondje se određuje kvaliteta podataka.
Što može poći po zlu: najčešće zamke
Osnovni podaci o proizvodima u više sustava: SAP sadrži broj artikla, PIM slike i marketinške tekstove, a PLM popis materijala. Nitko nema cjelovit pregled. Rješenje: prije početka projekta definirajte koji je sustav primarni izvor za svako polje.
Potvrde u PDF formatu: dobavljači dostavljaju GOTS, OEKO-TEX ili REACH potvrde kao skenirane PDF datoteke. To nije strukturirani izvor podataka. Rješenje: Certifikacijska tijela sve više nude mogućnost dohvaćanja podataka putem sučelja (OEKO-TEX predvodi, dok GOTS zaostaje). Alternativno, unesite podatke ručno, ali uključite datum isteka roka kako biste osigurali da se u DPP-u ne pojave istekli certifikati.
Tajnost sastava: osobito u kozmetici, prehrani i farmaciji, potpuni sastav je poslovna tajna. Trebaju li ih DPP učiniti javnima? Rješenje: ESPR-ov model s tri razine. Kategorija proizvoda dostupna je javnosti; regulatorna tijela mogu vidjeti cjelovitu formulaciju. To je rijetko prepreka, ali se mora razjasniti u ranoj fazi.
Podaci o CO₂ po dobavljaču: Vaš dobavljač pruža prosječnu vrijednost za cijeli svoj portfelj, a ne za svaku seriju. Rješenje: Privremeno prihvatite to; dugoročno izmijenite ugovore s dobavljačima. ESPR zahtijeva vrijednosti specifične za proizvod od određenog datuma, ali trenutna praksa je kompromis.
Vršnje verzije na lokalnim jezicima: Vaš ERP sustav sadrži naziv proizvoda samo na njemačkom i engleskom jeziku. Za 27 zemalja EU-a trebate više. Rješenje: strojni prijevod pomoću baze terminologije; o tome imamo zaseban članak.
Pitanja koja biste trebali postaviti prije projekta
Prije nego što pošaljete RFP (Zahtjev za ponudu) trima dobavljačima, internim putem odgovorite na sljedeća pitanja:
- Koliko proizvoda/brojeva artikala treba imati DPP-ove? (10, 10.000, 1 milijun?)
- Koji sustavi trenutno sadrže podatke relevantne za DPP?
- Koji odjel upravlja svakim od tih sustava?
- Imate li sloj integracije koji bi se trebao iskoristiti?
- Postoji li već sučelje putem vašeg ERP-a?
Odgovori će odrediti koji od tri pristupa je pravi za vas. I odredit će hoće li projekt trajati dva tjedna ili šest mjeseci.
Pitanja o ovoj objavi
Je li REST sučelje dovoljno ili nam je potreban middleware?
Interfejs je dovoljan. Tri obrasca se razlikuju po tome gdje se transformacija odvija, a ne po onome što prihvaćamo - naš interfejs prihvaća neutralnu JSON shemu, bez obzira na to kako ste je generirali. Povlačenje iz modernog ERP sustava, tok događaja i postojeći sloj integracije svi završavaju na istom krajnjem točku. Middleware se isplati koristiti ako ga već imate i ako on treba ostati ugovorni sučelje s trećim stranama. Ako ga trenutno nemate, nemojte kupovati nikakav samo zbog pasparta proizvoda.
Što će se odlučiti na radionici o mapiranju?
Koje ERP polje odgovara kojem polju osnovnih podataka - i koji je sustav mjerodavan izvor kada više sustava sadrži istu vrijednost. Radionica se održava prvog i drugog dana i predstavlja srž cijelog projekta, jer se odluke o kvaliteti podataka donose tamo, a ne kasnije u kodu. Obavezno dovedite ljude koji održavaju sustave, a ne samo one zadužene za projekt - osnovni podaci, proizvodnja, kvaliteta i nabava rijetko su svi dio istog odjela. Sve što slijedi - izvozi, validacija i otklanjanje poteškoća - jednostavno je stvar tehničke stručnosti.
Naši certifikati dostupni su samo kao PDF skenovi. Što bismo s njima trebali učiniti?
Skener nije strukturirani izvor podataka i stoga je neupotrebljiv za putovnicu. Postoje dva načina za nastavak - ovlašteni certifikacijski tijela sve više nude API upite, a tamo gdje oni nisu dostupni, unesite vrijednosti ručno, ali uvijek uključite datum isteka kako u objavljenoj putovnici ne bi ostali neispravni certifikati. Tretirajte ručni postupak kao ponavljajući zadatak, a ne jednokratni posao.
Može li naš IT odjel provjeriti sučelje prije nego što potpišemo išta?
Da. Cjelovita shema i sve krajnje točke dostupne su kao OpenAPI specifikacija na /apidocs, zajedno s primjerima zahtjeva, odgovorima na pogreške i detaljima o autentifikaciji. Ništa od ovoga nije predmet prodajne rasprave, pa vaš tim za integraciju može procijeniti potreban trud prije sklapanja ugovora. Ako pružatelj u ovoj fazi ne otkrije svoj API, to samo po sebi daje odgovor.
Što se događa s našim podacima kada promijenimo pružatelja usluga?
Pristali su. Sučelje prihvaća neutralnu JSON shemu umjesto vlasničkog formata, a cijeli vaš inventar izvozi se u CSV, XLSX, JSON-LD i SQL ili putem REST API-ja. To je namjerno - format koji popunjavate je prenosiv, pa promjena pružatelja usluga jednostavno zahtijeva izvoz umjesto ponovne izgradnje svega od nule. Postavite isto pitanje svakom pružatelju usluga prije radionice o mapiranju, jer će se vaša imena polja tada uključiti u njihov model.
Koliko zapravo dugo treba da se uspostavi veza?
U projektima koje podržavamo treba dva tjedna - dva dana mapiranja, tri dana do prvih izvoza putem našeg validatora, tri dana za otklanjanje poteškoća i dva dana do objave izvještaja o prvom prolazu. Dugoročni zadaci nikada se ne svode na sam kod, već na ono što Validator otkrije - nedostajuća polja, nedosljedno kodiranje i vrijednosti za koje se nitko ne osjeća odgovornim. Obavezno predvidite te dane, umjesto da ih skratite. Projekt koji ih preskoči na kraju će objaviti i te praznine.
Moramo li povezati sve proizvode odjednom?
Ne. Prvo započnite s proizvodima koji zahtijevaju prolaz i sa izvorom sustava - neutralna shema prihvaća djelomični katalog jednako lako kao i potpuni, a uvozi su ponovljivi, pa će naknadne izvršne sesije ažurirati inventar. Time je radionica mapiranja dovoljno kratka da se dovrši u dva dana. Svako daljnje proširenje je zadatak mapiranja, a ne novi projekt.
