Teža izdelka je navedena v sistemu za upravljanje z materialom. Delež recikliranega materiala je naveden v sistemu receptur. Certifikat dobavitelja je v obliki PDF na omrežnem disku. Produktni potni list 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 potrebujemo. Ta članek prikazuje, katere podatke iz vaših sistemov potrebuje potrdilo, na katere 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 - številka artikla, poimenovanje, različice, 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 sistem DPP?«, ampak: »Kako združite podatke iz 5 podsistemov v enoten sklop 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 o tem, 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če integracijske plasti
Med ERP-jem in zunanjimi sistemi že imate integracijsko plast (Mulesoft, Boomi, Informatica, Azure Data Factory). Ta plast predstavlja vmesnik: ponudnik DPP komunicira z njo, 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 format podatkov (shemo JSON), ki ga napolnite z orodjem po vaši izbiri. To pomeni:
- Pripravo podatkov lahko opravite sami, z orodji, ki jih vaša ekipa pozna
- 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
Celoten format in vsa poizvedovanja so javno opisana v Dokumentacija API-ja kot opis vmesnika v skladu z OpenAPI. Vaša IT-služba lahko vmesnik preveri še pred podpisom pogodbe - vključno s primerjalnimi poizvedbami, odgovori na napake in podrobnostmi o avtentifikaciji.
Časovni okvir tega pristopa v praksi:
- 1. do 2. dan: delavnica za mapiranje. Katero polje ERP-ja ustreza kateremu polju DPP-ja?
- 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 oznake).
- 9. do 10. dan: prvi DPP-ji so v živo.
Dva tedna, ne tri mesece. Ključni trenutek je delavnica za mapiranje - tam se odloča o kakovosti podatkov.
Kaj 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 doslednega pregleda. 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 ospredju, GOTS pa 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 navaja povprečno vrednost za celoten portfelj, ne pa po posameznih serijah. Rešitev: začasno sprejeti, dolgoročno pa prilagoditi dobaviteljske pogodbe. ESPR zahteva vrednosti, specifične 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 primeren.
Odgovori 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 Dokumentacija API-ja, skupaj s primernimi poizvedbami, odgovori na napake in podrobnostmi o avtentifikaciji. Nič od tega ni skrito za pogajanji 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.
