Teža izdelka je navedena v sistemu za upravljanje z materialom. Delež recikliranih surovin je naveden v sistemu receptur. Certifikat dobavitelja je v obliki PDF na omrežnem disku. Produktni pas potrebuje vse tri podatke v enem samem zapisu, in prav v tem je bistvo integracijskega projekta, ne pa v povezavi dveh sistemov.
»Brezhibna integracija ERP« je standardna obljuba, ki ji v praksi sledi trimesečni projekt. Objavljamo naš vodnik, da lahko vaša IT-služba pred podpisom pogodbe preveri, katere podatke dejansko zahtevamo. Ta članek prikazuje, katere podatke iz vaših sistemov potrebuje potrdilo, na kakšne tri načine pridejo do nas in zakaj je to mogoče v dveh tednih.
Kaj mora vaš ERP dejansko zagotoviti
Da bi nastalo potrdilo o izdelku (DPP), potrebujemo za vsak izdelek:
- Osnovne podatke - številko artikla, poimenovanje, variante, teže, mere, slike
- podatke o sestavnih delih - komponente s količinami in deleži recikliranih materialov
- podatke o poreklu - kraj proizvodnje, številka serije, datum proizvodnje
- okoljske podatke - CO2eq na enoto, poraba vode, poraba energije
- podatke o dobaviteljih - kdo dobavlja katero komponento (za izpolnjevanje obveznosti skrbnega ravnanja)
V vašem ERP-sistemu so ti podatki teoretično vsi na voljo. V praksi so razporejeni v 4 do 7 modulih: upravljanje z materialom, proizvodnja, kakovost, baza dobaviteljev, včasih ločen modul za okoljske podatke, včasih pa samostojen sistem za recepte in sezname sestavnih delov.
Vprašanje integracije ni: »Ali vaš ERP sistem posreduje podatke v DPP?« Temveč: »Kako združite podatke iz 5 podsistemov v enoten nabor podatkov?«
Trije preizkušeni načini
Način 1: Pridobivanje podatkov iz ERP sistema
Dobro deluje s sodobnimi ERP-ji (SAP S/4HANA Cloud, Dynamics 365, Odoo). Ponudnik DPP pridobi podatke prek vmesnika ERP-ja (tehnično OData ali REST). Le spremembe, po časovnem razporedu ali sprožene z dogodkom.
Prednosti: malo razvoja z vaše strani, vi zagotovite dostop za branje, ponudnik pa poskrbi za pretvorbo.
Slabosti: ne deluje s starejšimi namestitvami SAP ECC brez dodatnega vmesniškega sloja. Potrebujete jasna pravila, kdo sme brati katere podatke.
Način 2: Posredovanje sprememb
Vaš ERP vsako spremembo prijavi kot dogodek (prek SAP Event Mesh, Apache Kafka ali RabbitMQ), ponudnik DPP pa jih sprejme.
Prednosti: skoraj v realnem času, prilagaja se rasti, sistemi niso odvisni drug od drugega.
Slabosti: Nastavitev je zahtevna in zahteva infrastrukturo, ki je nima vsak IT-oddelek. Za manjša podjetja je to večinoma pretirano.
Način 3: Uporaba obstoječega integracijskega sloja
Med ERP-jem in zunanjimi sistemi že imate integracijski sloj (Mulesoft, Boomi, Informatica, Azure Data Factory). Ta sloj predstavlja vmesnik: ponudnik DPP komunicira z njim, nikoli neposredno z ERP-jem.
Prednosti: obstoječe naložbe se lahko izkoristijo, pravila ostajajo nespremenjena, tretje osebe nimajo neposrednega dostopa do ERP-sistema.
Slabosti: vaši stroški za integracijski sloj se povečujejo.
Kaj v konkretnih projektih počnemo drugače
Mnogi ponudniki se želijo neposredno povezati z vašim ERP-sistemom. Mi načeloma vgradimo vmesni korak: naš vmesnik sprejme nevtralni podatkovni format (shemo JSON), ki ga napolnite z orodjem po vaši izbiri. To pomeni:
- Podatke lahko pripravite sami, z orodji, s katerimi je vaša ekipa seznanjena
- nas lahko zamenjate - nevtralni format je prenosljiv
- lahko kadarkoli ponovno pridobite celoten nabor podatkov - v oblikah CSV, XLSX, JSON-LD in SQL ter prek REST-API
- zagotovimo validator za uvoz, ki vaše podatke preveri pred naložitvijo
Celotna specifikacija formata in vsa poizvedovanja so javno dokumentirana na /apidocs v obliki opisa vmesnika po standardu OpenAPI. Vaša IT-služba lahko vmesnik preveri še pred podpisom pogodbe - vključno s primerljivimi poizvedbami, odgovori na napake in podrobnostmi o avtentifikaciji.
Časovni okvir tega pristopa v praksi:
- 1. do 2. dan: Delavnica mapiranja. Katero polje v ERP-ju ustreza kateremu polju v DPP-ju?
- 3. do 5. dan: Prvi izvozi v formatu JSON iz ERP-ja, preverjeni z našim validatorjem.
- 6. do 8. dan: odpravljanje napak (manjkajoča polja, neskladne kodiranje).
- 9. do 10. dan: prvi DPP-ji so v živo.
Dva tedna, ne tri mesece. Ključni moment je delavnica za mapiranje - tam se odloča o kakovosti podatkov.
Kaj lahko gre narobe: najpogostejše pasti
Osnovni podatki o izdelkih v več sistemih: SAP ima številko artikla, PIM ima slike in marketinška besedila, PLM pa ima seznam sestavnih delov. Nihče nima celovite slike. Rešitev: pred začetkom projekta opredelite, kateri sistem je vodilni za posamezno polje.
Certifikati v formatu PDF: dobavitelji dostavljajo certifikate GOTS, OEKO-TEX ali REACH kot skenirane PDF-datoteke. To ni strukturiran vir podatkov. Rešitev: certifikacijski organi vse pogosteje ponujajo poizvedbo prek vmesnika (OEKO-TEX je v vodstvu, GOTS zaostaja). Ali pa: ročno vnašajte podatke, vendar z datumom veljavnosti, da se v DPP ne pojavijo potekli certifikati.
Zaupnost sestave: zlasti v kozmetiki, prehrambni industriji in farmaciji: celotna sestava je poslovna skrivnost. Naj jih DPP objavi? Rešitev: tristopenjski model ESPR. Javno je na voljo kategorija izdelka, pristojni organi pa vidijo celotno sestavo. To skoraj nikoli ni ovira, vendar je treba to pojasniti že v zgodnji fazi.
Podatki o CO₂ na podlagi dobaviteljev: vaš dobavitelj navede povprečno vrednost za celoten portfelj, ne pa za posamezno serijo. Rešitev: začasno sprejeti, dolgoročno pa prilagoditi dobaviteljske pogodbe. ESPR zahteva vrednosti za posamezne izdelke od določenega datuma naprej, vendar je trenutna praksa kompromis.
Lokalne jezikovne različice: Vaš ERP vsebuje le ime izdelka v nemščini in angleščini. Za 27 držav EU potrebujete več. Rešitev: strojno prevajanje s terminološko bazo podatkov; o tem imamo ločen članek.
Vprašanja, ki si jih morate zastaviti pred začetkom projekta
Preden pošljete povpraševanje (RFP) trem ponudnikom, si notranje odgovorite na naslednja vprašanja:
- Koliko izdelkov/artiklov naj ima DPP? (10, 10 000, 1 milijon?)
- Kateri sistemi danes hranijo podatke, pomembne za DPP?
- Kateri oddelek upravlja posamezne sisteme?
- Ali imate integracijsko plast, ki bi jo bilo treba uporabiti?
- Ali obstaja že delujoč vmesnik prek vašega ERP-sistema?
Odgovori določajo, kateri od treh pristopov je za vas najprimernejši. Prav tako določajo, ali bo projekt trajal dva tedna ali šest mesecev.
Vprašanja v zvezi s tem prispevkom
Ali zadostuje vmesnik REST ali potrebujemo vmesno programsko opremo?
Vmesnik je zadosten. Trije vzorci se razlikujejo glede na to, kje poteka preoblikovanje, ne pa glede na to, kaj sprejemamo - naš vmesnik sprejema nevtralno shemo JSON, ne glede na to, s čim ste jo ustvarili. Prenos podatkov iz sodobnega ERP-sistema, tok dogodkov in obstoječa integracijska plast se vsi končajo na istem končnem točki. Uporaba vmesne programske opreme se splača, če jo že uporabljate in če naj ta ostane pogodbena obveznost do tretjih oseb. Če je danes ni, je za produktni potni list ne kupujte.
O čem se odloča na delavnici o kartiranju?
Katero polje v sistemu ERP bo postalo referenčno polje - in kateri sistem je glavni vir, če več sistemov vsebuje isto vrednost. Delavnica poteka 1. in 2. dan in je ključni del celotnega projekta, saj se tam odloča o kakovosti podatkov in ne šele kasneje v kodi. Prinesite s seboj osebe, ki vzdržujejo sisteme, ne le tiste, ki so odgovorne za projekt - osnovni podatki, proizvodnja, kakovost in nabava redko sodijo v en oddelek. Vse, kar sledi, torej izvoz podatkov, validacija in odpravljanje napak, je že le še izvedba.
Naši certifikati so na voljo le v obliki skeniranih PDF-datotek. Kaj naj naredimo z njimi?
Skenirani dokument ni strukturiran vir podatkov in je zato za potni list neuporaben. Obstajata dva načina - ponudniki certifikatov vedno pogosteje ponujajo poizvedbe prek API-ja, kjer pa te niso na voljo, vnesite vrednosti ročno, vendar vedno z datumom veljavnosti, da v objavljenem potnem listu ne ostane noben potekel certifikat. Ročni postopek načrtujte kot ponavljajoče se delo, ne kot enkratno opravilo.
Ali lahko naša IT-služba preveri vmesnik, preden kaj podpišemo?
Da. Celotna shema in vsi končni točki so na voljo kot specifikacija OpenAPI na naslovu /apidocs, skupaj s primernimi zahtevki, odgovori na napake in podrobnostmi o avtentifikaciji. Nič od tega ni skrito za pogovori o prodaji, zato lahko vaša ekipa za integracijo oceni obseg dela, še preden je sklenjena pogodba. Če ponudnik v tej fazi ne razkrije svojega vmesnika, je tudi to odgovor.
Kaj se zgodi z našimi podatki, če zamenjamo ponudnika?
Podatke prenesejo. Vmesnik sprejema nevtralno shemo JSON namesto lastniškega formata, vaši celotni podatki pa se izvozijo v oblikah CSV, XLSX, JSON-LD in SQL ali prek REST-API. To je namerno - format, v katerega vnašate podatke, je prenosljiv, zato zamenjava zahteva le izvoz in ne novega ustvarjanja. Vsakemu ponudniku pred delavnico o mapiranju postavite isto vprašanje, saj bodo po njej vaša imena polj vključena v njegov model.
Kako dolgo dejansko traja priključitev?
V projektih, ki jih spremljamo, traja dva tedna - dva dneva za kartiranje, tri dni do prvih izvozov prek našega validatorja, tri dni za odpravljanje napak, dva dneva do objave prvih potnih listov. Dolga pot ni nikoli v kodi, ampak v tem, kar odkrije validator - manjkajoča polja, neenotna kodiranja, vrednosti, za katere se nihče ne čuti odgovoren. Načrtujte te dni, namesto da jih skrajšujete. Projekt, ki jih preskoči, objavi tudi te vrzeli.
Ali moramo vse izdelke dodati v sistem naenkrat?
Ne. Začnite s proizvodi, za katere je najprej potreben profil, in z izvorno bazo podatkov - nevtralna shema sprejme tako delni kot popoln katalog, uvozi pa so ponovljivi, kar pomeni, da poznejši izvajanji posodobijo zaloge. Tako ostane delavnica mapiranja dovolj obsežna, da jo je mogoče zaključiti v dveh dneh. Kasnejša razširitev je naloga mapiranja, ne pa nov projekt.
