Težina proizvoda se evidentira u sistemu za upravljanje materijalima. Udio recikliranog materijala se evidentira u sistemu za formulacije. Certifikat dobavljača se pohranjuje kao PDF na mrežnom disku. Proizvodni pasoš zahtijeva sva tri podatka u jednom zapisu, a upravo se o tome radi u projektu integracije - ne samo o povezivanju dva sistema.
“Besprijekorna ERP integracija” je standardno obećanje koje se u praksi prateći tromjesečnim projektom. Objavljujemo naš vodič kako bi vaše IT odjeljenje moglo provjeriti koja su podaci zapravo potrebna prije potpisivanja ugovora. Ovaj članak objašnjava koje podatke pasoš zahtijeva od vaših sistema, tri načina na koje nam se šalje i zašto se to može postići za dvije sedmice.
Šta vaš ERP sistem zapravo treba da pruži
Da bismo kreirali DPP, za svaki proizvod nam je potrebno sljedeće:
- Osnovni podaci - broj 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ču - ko isporučuje koju komponentu (za potrebe dužne pažnje)
U teoriji, svi ovi podaci su dostupni u vašem ERP sistemu. Međutim, u praksi su raspoređeni u 4 do 7 modula: Upravljanje materijalima, Proizvodnja, Kvalitet, Glavni podaci o dobavljačima, ponekad zaseban modul za ekološke podatke, a ponekad i namjenski sistem za formulacije i popise materijala.
Pitanje u vezi s integracijom nije: ‘Da li vaš ERP sistem isporučuje podatke DPP-u?’ Već: ‘Kako objediniti podatke iz pet podsistema u jedan koherentan skup podataka?’
Tri isprobana i provjerena pristupa
Pristup 1: Preuzimanje podataka iz ERP-a
Dobro funkcioniše sa modernim ERP sistemima (SAP S/4HANA Cloud, Dynamics 365, Odoo). Pružalac usluga DPP-a preuzima podatke putem ERP interfejsa (tehnički OData ili REST). Preuzimaju se samo izmjene, bilo na zakazanoj osnovi ili pokrenute događajem.
Prednosti: minimalan razvoj je potreban s vaše strane; vi pružate pristup za čitanje, a provajder se brine o konverziji.
Nedostaci: ne radi sa starijim SAP ECC instalacijama bez dodatnog sloja interfejsa. Potrebna su vam jasna pravila koja regulišu ko ima dozvolu da čita koje podatke.
Opcija 2: Prosljeđivanje promjena
Vaš ERP prijavljuje svaku promjenu kao događaj (putem SAP Event Mesh, Apache Kafka ili RabbitMQ), a DPP provajder ih prima.
Prednosti: gotovo u stvarnom vremenu, prilagođava se vašem poslovanju, sistemi nisu međusobno zavisni.
Nedostaci: Postavljanje je složeno i zahtijeva infrastrukturu koju nema svaki IT odjel. Obično je prekomjerno za manje kompanije.
Opcija 3: Korištenje postojećeg sloja integracije
Već imate sloj ### integracije(Mulesoft, Boomi, Informatica, Azure Data Factory) između ERP-a i vanjskih sistema. Ovaj sloj djeluje kao posrednik: DPP provajder komunicira s njim, a nikada direktno s ERP-om.
Prednosti: postojeća ulaganja se mogu iskoristiti, pravila ostaju stabilna i treće strane nemaju direktan pristup ERP-u.
Nedostaci: vaši troškovi za sloj integracije se shodno tome povećavaju.
Šta radimo drugačije u specifičnim projektima
Mnogi pružaoci usluga žele se direktno povezati s vašim ERP-om. Uvijek uključujemo posrednički korak: naš interfejs prihvata 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
- Možete u bilo kojem trenutku 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 dokumentovani na /apidocs kao opis API-ja u skladu sa standardom OpenAPI. Vaš IT tim može pregledati API prije potpisivanja ugovora - uključujući primjere zahtjeva, odgovore na greške i detalje o autentifikaciji.
Vremenski okvir za ovaj pristup u praksi:
- Dani 1 do 2: Radionica o mapiranju. Koje ERP polje odgovara kojem DPP polju?
- Dani 3 do 5: Početni JSON izvoz iz ERP-a, obrađen našim validatorom.
- 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 za mapiranje - 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 ima broj artikla, PIM ima slike i marketinške tekstove, PLM ima listu materijala. Niko nema cjelovit pregled. Rješenje: prije početka projekta, definirajte koji je sistem primarni izvor za svako polje.
Certifikati kao PDF-ovi: dobavljači dostavljaju GOTS, OEKO-TEX ili REACH certifikate kao skenirane PDF-ove. To nije strukturirani izvor podataka. Rješenje: Certifikacijska tijela sve više nude mogućnost preuzimanja podataka putem sučelja (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, prehrani i farmaciji, 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 je rijetko prepreka, ali se mora razjasniti u ranoj fazi.
Podaci o CO₂ po osnovu dobavljača: 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 nadalje, 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 ponudu) trima dobavljačima, interno odgovorite na sljedeća pitanja:
- Koliko proizvoda/brojeva artikala treba imati DPP? (10, 10.000, 1 milion?)
- Koji sistemi trenutno sadrže podatke relevantne za DPP?
- Koji odjel upravlja svakim od ovih sistema?
- Imate li sloj integracije koji bi se trebao iskoristiti?
- Postoji li već interfejs putem vašeg ERP sistema?
Odgovori će odrediti koji od tri pristupa je pravi za vas. I odredit će da li će projekat trajati dvije sedmice ili šest mjeseci.
Pitanja o ovoj objavi
Da li je REST interfejs dovoljan ili nam je potreban middleware?
Interfejs je dovoljan. Tri obrasca se razlikuju po tome gdje se transformacija odvija, a ne po onome što dobijamo - naš interfejs prihvata neutralnu JSON shemu, bez obzira na to kako ste je generisali. Povlačenje iz modernog ERP sistema, tok događaja i postojeći sloj integracije svi završavaju na istom krajnjem odredištu. Middleware se isplati koristiti ako ga već imate i želite da ostane ugovorni interfejs sa trećim stranama. Ako ga trenutno nemate, nemojte ga kupovati posebno za pasoš proizvoda.
Šta će biti odlučeno na radionici o mapiranju?
Koje ERP polje odgovara kojem polju osnovnih podataka - i koji sistem je autoritativni izvor kada više sistema sadrži istu vrijednost. Radionica se održava prvog i drugog dana i predstavlja srž cijelog projekta, jer se odluke o kvalitetu podataka donose tamo, a ne kasnije u kodu. Obavezno dovedite ljude koji održavaju sisteme, a ne samo one zadužene za projekat - osnovni podaci, proizvodnja, kvaliteta i nabavka 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 su dostupni samo kao PDF skenovi. Šta da radimo s njima?
Skenerisani dokument nije strukturirani izvor podataka i stoga je neupotrebljiv za propusnicu. Postoje dva načina za nastavak: pružaoci usluga certificiranja sve više nude API upite, a tamo gdje oni nisu dostupni, vrijednosti možete unijeti ručno, ali uvijek navedite datum isteka kako biste osigurali da nijedan istekli certifikat ne ostane u objavljenoj propusnici. Tretirajte ručni proces kao ponavljajući zadatak, a ne kao jednokratni posao.
Može li naš IT odjel provjeriti sučelje prije nego što potpišemo išta?
Da. Kompletna shema i svi krajevi (endpointi) dostupni su kao OpenAPI specifikacija na /apidocs, zajedno sa primjerima zahtjeva, odgovorima na greš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.
Šta se dešava s našim podacima kada promijenimo provajdera?
Svi su uključeni. Sučelje prihvata neutralnu JSON shemu umjesto vlasničkog formata, a vaš cijeli inventar se izvozi kao CSV, XLSX, JSON-LD i SQL ili putem REST API-ja. Ovo je namjerno tako - 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 nakon toga vaša imena polja biti uključena u njihov model.
Koliko zapravo treba da se uspostavi veza?
U projektima koje podržavamo, proces traje dvije sedmice: dva dana mapiranja, tri dana do prvih izvoza putem našeg validatora, tri dana ispravljanja grešaka i dva dana do objavljivanja prvih izvještaja o prolazu. Dugoročni zadatak nikada nije sam kod, već ono što Validator otkrije - nedostajuća polja, nedosljedno kodiranje i vrijednosti za koje se niko ne osjeća odgovornim. Obavezno predvidite ove dane, umjesto da ih skratite. Projekat koji ih preskoči na kraju objavljuje i praznine.
Moramo li povezati sve proizvode odjednom?
Ne. Prvo počnite s proizvodima koji zahtijevaju dozvolu i sa izvorom podataka - neutralna shema prihvata djelomični katalog jednako lako kao i potpuni, a uvozi su ponovljivi, pa će naknadne izvršne sesije ažurirati inventar. Ovo također održava radionicu mapiranja dovoljno kratkom da se završi za dva dana. Njezino proširenje nakon toga je zadatak mapiranja, a ne novi projekt.
