Toote kaal on kirjas varuhaldussüsteemis. Ringlussevõetud materjali osakaal on kirjas retseptisüsteemis. Tarnija sertifikaat asub PDF-failina võrgukettal. Tootepass vajab kõiki kolme andmetüüpi ühes andmekogumis, ja just selles peitubki integratsiooniprojekti olemus, mitte kahe süsteemi ühendamises.
„Suurepärane ERP-integratsioon“ on standardne lubadus, millele järgneb praktikas kolmekuuline projekt. Avaldame oma juhendi, et teie IT-osakond saaks enne lepingu allkirjastamist kontrollida, milliseid andmeid tegelikult küsitakse. Käesolev artikkel näitab, milliseid andmeid tootepass teie süsteemidest vajab, milliste kolme viisi kaudu need meieni jõuavad ja miks see on võimalik kahe nädalaga.
Mida teie ERP tegelikult peab edastama
Tootepassi koostamiseks vajame iga toote kohta:
- põhiandmed - tootenumber, nimetus, variandid, kaal, mõõtmed, pildid
- koostisosade nimekirja andmed - komponendid koos koguste ja ringlusmaterjali osakaaludega
- päritoluandmed - tootmiskoht, partii number, tootmiskuupäev
- keskkonnaandmed - CO2eq ühiku kohta, veetarbimine, energiatarbimine
- tarnijaandmed - kes tarnib millist komponenti (hoolsuskohustuste täitmiseks)
Teie ERP-süsteemis on need andmed teoreetiliselt kõik olemas. Praktikas on need jaotatud 4-7 moodulisse: materjalihaldus, tootmine, kvaliteet, tarnijate andmebaas, mõnikord eraldi moodul keskkonnaandmete jaoks, mõnikord eraldi süsteem retseptide ja koostisnimekirjade jaoks.
Integreerimise küsimus ei ole: „Kas teie ERP edastab andmeid DPP-le?” Küsimus on: „Kuidas koondate andmed viiest allsüsteemist ühtseks andmekogumiks?”
Kolm tõestatud viisi
Viis 1: Andmete hankimine ERP-süsteemist
Toimib hästi kaasaegsete ERP-süsteemidega (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-pakkuja hankib andmed ERP-süsteemi liidese kaudu (tehniliselt OData või REST). Ainult muudatused, kas ajakava järgi või sündmuse poolt käivitatuna.
Eelised: teie poolt on vaja vähe arendustööd, te annate lugemisõiguse, teenusepakkuja ehitab ümberkujundamise.
Puudused: ei tööta vanemate SAP ECC-installatsioonidega ilma täiendava liidese kihita. Vajate selgeid reegleid selle kohta, kes milliseid andmeid lugeda tohib.
2. viis: muudatuste edastamine
Teie ERP teatab igast muudatusest sündmusena (SAP Event Mesh, Apache Kafka või RabbitMQ kaudu), DPP-teenusepakkuja võtab need vastu.
Eelised: peaaegu reaalajas, kasvab koos süsteemiga, süsteemid ei sõltu üksteisest.
Puudused: seadistamine on keeruline ja nõuab infrastruktuuri, mida igal IT-osakonnal pole. Väiksematele ettevõtetele on see enamasti liiga keeruline.
3. viis: olemasoleva integratsioonikihi kasutamine
Teil on juba olemas integratsioonikiht (Mulesoft, Boomi, Informatica, Azure Data Factory) ERP-süsteemi ja väliste süsteemide vahel. See kiht on vahendaja: DPP-teenusepakkuja suhtleb sellega, mitte kunagi otse ERP-süsteemiga.
Eelised: olemasolevaid investeeringuid saab ära kasutada, reeglid jäävad stabiilseks, kolmandatel osapooltel puudub otsene juurdepääs ERP-süsteemile.
Puudused: teie kulud integratsioonikihile kasvavad koos sellega.
Mida me konkreetsetes projektides teisiti teeme
Paljud pakkujad soovivad ühenduda otse teie ERP-süsteemiga. Me lisame põhimõtteliselt vaheetapi: meie liides võtab vastu neutraalse andmevormingu (JSON-skeemi), mille te täidate oma valitud tööriistaga. See tähendab:
- Te saate andmeid ise ette valmistada, kasutades tööriistu, millega teie meeskond on tuttav
- Te saate meid vahetada - neutraalne formaat on ülekantav
- Te saate oma kogu andmebaasi igal ajal tagasi kätte - CSV-, XLSX-, JSON-LD- ja SQL-vormingus ning REST-API kaudu
- Me pakume importimise validaatorit, mis kontrollib teie andmeid enne üleslaadimist
Täielik formaat ja kõik päringud on avalikult kirjeldatud aadressil API dokumentatsioon, OpenAPI-standardile vastava liidese kirjeldusena. Teie IT-osakond saab liidest kontrollida enne lepingu allkirjastamist - sealhulgas näidispäringud, veateated ja autentimise üksikasjad.
Selle lähenemise ajakava praktikas:
- 1.-2. päev: kaardistamise töötuba. Milline ERP-väli vastab millisele DPP-väljale?
- 3.-5. päev: esimesed JSON-eksportimised ERP-süsteemist, läbi meie validaatori.
- 6.-8. päev: vigade kõrvaldamine (puuduvad väljad, ebajärjekindlad koodid).
- 9.-10. päev: esimesed DPP-d on kasutusel.
Kaks nädalat, mitte kolm kuud. Kõige olulisem on kaardistamise töötuba - seal otsustatakse andmete kvaliteedi üle.
Mis võib valesti minna: kõige sagedasemad lõksud
Toote baasandmed mitmes süsteemis: SAP-is on tootenumber, PIM-is on pildid ja turundustekstid, PLM-is on koostisloend. Keegi ei oma terviklikku ülevaadet. Lahendus: määrake enne projekti algust kindlaks, milline süsteem on millise välja puhul juhtiv.
Sertifikaadid PDF-vormingus: tarnijad esitavad GOTS-, OEKO-TEX- või REACH-sertifikaadid PDF-skannina. See ei ole struktureeritud andmeallikas. Lahendus: sertifitseerimisasutused pakuvad üha sagedamini andmete päringut liidese kaudu (OEKO-TEX on selles osas ees, GOTS jääb maha). Või: sisestage andmed käsitsi, kuid lisage kehtivuskuupäev, et DPP-s ei ilmuks aegunud sertifikaate.
Koostise salastatus: eriti kosmeetika-, toidu- ja farmaatsiasektoris on täielik koostis ärisaladus. Kas DPP peaks need avalikustama? Lahendus: ESPR-i kolme tasandi mudel. Avalik on tootekategooria, ametiasutused näevad täielikku koostist. Peaaegu kunagi ei tekita see takistusi, kuid see tuleb varakult selgeks teha.
CO₂-andmed tarnijate kaupa: teie tarnija esitab keskmise väärtuse kogu oma tooteportfelli kohta, mitte iga partii kohta. Lahendus: ajutiselt aktsepteerida, pikemas perspektiivis kohandada tarnelepinguid. ESPR nõuab tootepõhiseid väärtusi alates kindlast kuupäevast, kuid praegune tava on kompromiss.
Kohalikud keeleversioonid: teie ERP-süsteem sisaldab tootenimetusi ainult saksa ja inglise keeles. 27 ELi liikmesriigi jaoks on vaja rohkem. Lahendus: masintõlge koos terminoloogiaandmebaasiga - selle kohta on meil eraldi artikkel.
Küsimused, mida peaksite enne projekti algust endalt küsima
Enne kui saadate pakkumispäringu kolmele pakkujale, vastake sisemiselt järgmistele küsimustele:
- Kui paljudel toodetel/artiklinumbritel peaksid olema DPP-d? (10, 10 000, 1 miljon?)
- Millised süsteemid hoiavad praegu DPP-ga seotud andmeid?
- Milline osakond haldab iga süsteemi?
- Kas teil on integratsioonikiht, mida tuleks kasutada?
- Kas teie ERP-süsteemi kaudu on juba toimiv liides?
Vastused määravad, milline kolmest võimalusest teile sobib.
Vastused määravad, kas projekt kestab kaks nädalat või kuus kuud.
Küsimused selle postituse kohta
Kas REST-liidesest piisab või vajame vahevara?
Liides on piisav. Need kolm mudelit erinevad üksteisest selle poolest, kus teisendus toimub, mitte selle poolest, mida me vastu võtame - meie liides võtab vastu neutraalse JSON-skeemi, olenemata sellest, millega te selle loonud olete. Kaasaegsest ERP-süsteemist pärit pull-andmed, sündmustevoog ja olemasolev integratsioonikiht jõuavad kõik samasse lõpppunkti. Vahevara on mõttekas, kui te seda niikuinii kasutate ja see peab jääma lepinguliseks osapooleks kolmandate osapoolte suhtes. Kui seda praegu pole, siis ärge ostke seda tootepassi jaoks.
Mida otsustatakse kaardistamise töötubades?
Milline ERP-väli muutub vastavaks väljaks - ja milline süsteem on juhtiv allikas, kui mitmes süsteemis on sama väärtus. Töötuba toimub 1. ja 2. päeval ning on kogu projekti otsustav hetk, sest just seal otsustatakse andmete kvaliteedi üle, mitte hiljem koodis. Võtke kaasa need inimesed, kes süsteeme haldavad, mitte ainult need, kes projekti eest vastutavad - põhiandmed, tootmine, kvaliteet ja ostmine asuvad harva ühes osakonnas. Kõik, mis järgneb, st eksportimine, valideerimine ja veaparandus, on lihtsalt käsitöö.
Meie sertifikaadid on olemas ainult PDF-skannidena. Mida me nendega teeme?
Skaneeritud fail ei ole struktureeritud andmeallikas ja seetõttu passi jaoks kasutamatu. On kaks võimalust - sertifitseerimisteenuse osutajad pakuvad üha sagedamini API-päringuid, ja kui neid pole, sisestage väärtused käsitsi, kuid alati koos kehtivuskuupäevaga, et avaldatud passis ei jääks kehtivust kaotanud sertifikaati. Kavandage käsitsi sisestamine korduvaks tööks, mitte ühekordseks ülesandeks.
Kas meie IT-osakond saaks liidese üle vaadata, enne kui me midagi allkirjastame?
Jah. Täielik skeem ja kõik lõpppunktid on kättesaadavad OpenAPI-spetsifikatsioonina aadressil API dokumentatsioon, koos näidispäringute, veavastuste ja autentimise üksikasjadega. Kõik see on kättesaadav ilma müügikõne vajaduseta, seega saab teie integratsioonimeeskond kulusid hinnata juba enne lepingu sõlmimist. Kui teenusepakkuja ei näita selles etapis oma liidest, on ka see omamoodi vastus.
Mis juhtub meie andmetega, kui vahetame teenusepakkujat?
Need on kaasas. Liides võtab vastu neutraalse JSON-skeemi, mitte proprietaarse formaadi, ning kogu teie andmestik väljastatakse CSV-, XLSX-, JSON-LD- ja SQL-vormingus või REST-API kaudu. See ongi eesmärk - formaat, mida te täidate, on ülekantav, seega maksab formaadi vahetamine vaid ekspordi, mitte uue loomise. Esitage igale teenusepakkujale enne kaardistamise töötuba sama küsimus, sest pärast seda on teie väljade nimed tema mudelis olemas.
Kui kaua ühenduse loomine tegelikult aega võtab?
Projektides, mida me toetame, kulub kaks nädalat - kaks päeva kaardistamiseks, kolm päeva kuni esimeste eksporditulemuste saamiseni meie validaatori kaudu, kolm päeva vigade parandamiseks ja kaks päeva kuni esimeste passide avaldamiseni. Pikk tee ei seisne kunagi koodis, vaid selles, mida validaator leiab - puuduvad väljad, ebajärjekindlad kodeeringud, väärtused, mille eest keegi vastutust ei võta. Planeerige need päevad sisse, selle asemel et neid lühendada. Projekt, mis need vahele jätab, avaldab koos andmetega ka lüngad.
Kas peame kõik tooted korraga süsteemi lisama?
Ei. Alustage toodetest, mis vajavad esimesena passimärget, ja allikasüsteemist - neutraalne skeem võtab vastu nii osakataloogi kui ka täieliku kataloogi, ning importimine on korratav, seega uuendavad hilisemad käivitused varusid. See hoiab ka kaardistamise töötoa piisavalt lühikese, et sellega kahe päevaga toime tulla. Hilisem laiendamine on kaardistamisülesanne, mitte uus projekt.
