“Besprijekorna ERP integracija” standardno je 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 točno podaci zahtijevaju prije potpisivanja ugovora. Evo što trebate znati prije nego što se upustite u projekt integracije.
Što vaš ERP sustav zapravo mora pružiti
Za izradu DPP-a, za svaki proizvod potrebni su nam sljedeći podaci:
- Osnovni podaci - broj artikla, opis, varijante, težine, dimenzije, slike
- Podaci o popisu materijala - komponente s količinama i udjelom reciklata
- Podaci o podrijetlu - mjesto proizvodnje, broj serije, datum proizvodnje
- Podaci o okolišu - ekvivalent CO₂ po jedinici, potrošnja vode, potrošnja energije
- Podaci o dobavljačima - tko isporučuje koju komponentu (za dužnu skrb)
U teoriji, svi ti podaci dostupni su u vašem ERP sustavu. Međutim, u praksi su ta podaci raštrkana 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 sustav za formulacije.
Pitanje integracije nije: “Dostavlja li vaš ERP podatke DPP-u?” Već: “Kako objediniti podatke iz pet podsustava u jedan koherentan skup podataka?”
Tri isprobana i provjerena obrasca integracije
Obrazac 1: OData / REST pull
Dobro funkcionira s modernim ERP-ovima (SAP S/4HANA Cloud, Dynamics 365, Odoo). Pružatelj DPP-a preuzima podatke putem OData ili REST-a. Postupno, zakazano ili vođeno događajima.
Prednosti: minimalni razvoj s vaše strane; vi pružate vjerodajnice za čitanje, a pružatelj usluge izrađuje transformaciju.
Nedostaci: ne radi s starijim instalacijama SAP ECC bez dodatnog API sloja. Potrebna je kontrola nad zahtjevima za pristup podacima.
Šablona 2: Integracija temeljena na događajima
SAP Event Mesh, Apache Kafka, RabbitMQ. Vaš ERP objavljuje događaje promjena; DPP pružatelj ih konzumira.
Prednosti: gotovo u stvarnom vremenu, elegantno skalabilno, odvojeno.
Nedostaci: Postavljanje je složeno i zahtijeva infrastrukturu koju nema svaki IT odjel. Obično je prekomjerno za manje tvrtke.
Šablona 3: Middleware / ETL
Imate sloj integracije (Mulesoft, Boomi, Informatica, Azure Data Factory) između ERP-a i vanjskih sustava. Srednji sloj djeluje kao sučelje - pružatelj usluga DPP-a komunicira sa srednjim slojem, nikada izravno s ERP-om.
Prednosti: postojeća ulaganja mogu se iskoristiti, upravljanje je stabilno, treće strane nemaju izravan pristup ERP-u.
Nedostaci: troškovi vašeg middlewarea rastu u skladu s time.
Što radimo drugačije u specifičnim projektima
Mnogi pružatelji usluga žele se izravno povezati s vašim ERP-om. Mi uvijek uključujemo posredni korak: naš API prihvaća neutralnu JSON shemu, koju popunjavate alatom 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
- Svoje podatke možete u bilo kojem trenutku dohvatiti u cijelosti - 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
Potpuna shema i sve krajnje točke javno su dokumentirane kao OpenAPI specifikacija na /apidocs. Vaš IT tim može testirati sučelje prije potpisivanja ugovora - uključujući primjere zahtjeva, odgovore o pogreš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?
- 3. do 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 ima broj artikla, PIM ima slike i marketinške tekstove, PLM ima popis materijala. Nitko nema dosljedan pregled. Rješenje: prije početka projekta definirajte koji je sustav “izvor istine” za svako polje.
Potvrde kao PDF-ovi: dobavljači dostavljaju GOTS, OEKO-TEX ili REACH potvrde kao skenirane PDF-ove. To nije strukturirani izvor podataka. Rješenje: certifikacijska tijela sve više nude API upite (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 predstavlja poslovnu tajnu. Trebaju li ih DPP učiniti javnima? 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₂ temeljeni na dobavljačima: Vaš dobavljač pruža prosječnu vrijednost za cijeli svoj portfelj, a ne za svaku seriju. Rješenje: Privremeno prihvatite to; dugoročno prilagodite ugovore s dobavljačima. ESPR zahtijeva vrijednosti specifične za proizvod od određenog datuma, ali trenutna praksa je kompromis.
Vršnje jezične verzije: 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 trima dobavljačima, odgovorite na sljedeća pitanja interno:
- 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 ulaganje u middleware koje biste trebali 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 hoće li projekt trajati dva tjedna ili šest mjeseci.