»Brezhibna integracija ERP« je standardna obljuba, ki ji v praksi sledi trimesečni projekt. Objavljamo naš priročnik za API, da lahko vaša IT-služba še pred podpisom pogodbe preveri, kaj se dejansko zahteva. Tukaj je tisto, kar morate vedeti pred začetkom integracijskega projekta.
Kaj mora vaš ERP dejansko zagotoviti
Da bi lahko ustvarili DPP, potrebujemo za vsak izdelek:
- Osnovne podatke - številko artikla, poimenovanje, variante, težo, mere, slike
- Podatke o seznamu sestavnih delov - 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 skrbno preverjanje)
V vašem ERP-ju so ti podatki teoretično vsi na voljo. V praksi pa so razporejeni v 4 do 7 modulih: upravljanje z materialom (MM), proizvodnja (PP), kakovost (QM), dobavitelji (LFA1), včasih ločen modul EHS za okoljske podatke, včasih sistem PLM za recepture.
Vprašanje integracije ni: »Ali vaš ERP sistem posreduje podatke sistemu DPP?« Temveč: »Kako združite podatke iz 5 podsistemov v enoten nabor podatkov?«
Trije preizkušeni integracijski vzorci
Vzorec 1: OData / REST-Pull
Dobro deluje s sodobnimi ERP-ji (SAP S/4HANA Cloud, Dynamics 365, Odoo). Ponudnik DPP pridobiva podatke prek OData ali REST. Postopno, načrtovano ali na podlagi dogodkov.
Prednosti: malo razvoja z vaše strani, vi zagotovite pooblastila za branje, ponudnik pa izvede preoblikovanje.
Slabosti: ne deluje s starejšimi namestitvami SAP ECC brez dodatnega API-sloja. Potrebujete upravljanje zahtevkov za dostop do podatkov.
Vzorec 2: Integracija na podlagi dogodkov
SAP Event Mesh, Apache Kafka, RabbitMQ. Vaš ERP objavlja dogodke sprememb, ponudnik DPP pa jih porablja.
Prednosti: skoraj v realnem času, elegantno skalabilno, ločeno.
Pomanjkljivosti: Nastavitev je zahtevna in zahteva infrastrukturo, ki je nima vsak IT-oddelek. Za manjša podjetja je to večinoma pretirano.
Vzorec 3: Middleware / ETL
Med ERP-jem in zunanjimi sistemi imate integracijski sloj (Mulesoft, Boomi, Informatica, Azure Data Factory). Middleware je vmesnik - ponudnik DPP komunicira z middlewareom, nikoli neposredno z ERP-jem.
Prednosti: obstoječe naložbe se lahko izkoristijo, stabilno upravljanje, tretje osebe nimajo neposrednega dostopa do ERP-ja.
Slabosti: vaši stroški za middleware se povečujejo sorazmerno.
Kaj v konkretnih projektih počnemo drugače
Mnogi ponudniki se želijo neposredno povezati z vašim ERP-jem. Mi načeloma vgradimo vmesni korak: naš API sprejema nevtralno shemo JSON, ki jo napolnite z orodjem po vaši izbiri. To pomeni:
- Podatke lahko pripravite sami, z orodji, s katerimi je vaša ekipa seznanjena
- Lahko nas zamenjate - nevtralni format je prenosljiv
- Celotno zalogo lahko kadarkoli ponovno pridobite - v oblikah CSV, XLSX, JSON-LD in SQL ter prek REST-API
- Priložimo validator za uvoz, ki vaše podatke preveri pred nalaganjem
Celotna shema in vsi končni točki so javno dokumentirani pod /apidocs kot specifikacija 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 o mapiranju. Katero polje v ERP-sistemu ustreza kateremu polju v DPP?
- 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 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 dosledne slike. Rešitev: pred začetkom projekta opredelite, kateri sistem je »vir resnice« za katero 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 poizvedbe prek API-ja (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 na začetku.
Podatki o CO₂ na podlagi dobaviteljev: vaš dobavitelj navaja 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 naložbo v middleware, ki bi jo bilo treba izkoristiti?
- Ali obstaja že delujoča API-plast nad vašim ERP-jem?
Odgovori določajo, kateri od treh vzorcev je za vas primeren. In določajo, ali bo projekt trajal dva tedna ali šest mesecev.