„Suurepärane ERP-integratsioon“ on tüüpiline lubadus, millele järgneb praktikas kolmekuuline projekt. Avaldame oma API-juhendi, et teie IT-osakond saaks enne lepingu allkirjastamist kontrollida, milliseid andmeid tegelikult küsitakse. Siin on see, mida peaksite enne integratsiooniprojekti teadma.
Mida teie ERP tegelikult peab pakkuma
DPP loomiseks vajame iga toote kohta:
- Põhiandmed - tootenumber, nimetus, variandid, kaal, mõõtmed, pildid
- Komponentide 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 (due diligence’i jaoks)
Teie ERP-s on need andmed teoreetiliselt kõik olemas. Praktikas on need jaotatud 4-7 mooduli vahel: materjalihaldus (MM), tootmine (PP), kvaliteet (QM), tarnijad (LFA1), mõnikord eraldi EHS-moodul keskkonnaandmete jaoks, mõnikord PLM-süsteem retseptide jaoks.
Integreerimise küsimus ei ole: „Kas teie ERP-süsteem edastab andmeid DPP-le?” Küsimus on: „Kuidas koondate andmed viiest allsüsteemist ühtseks andmekogumiks?”
Kolm tõestatud integratsioonimudelit
Mudel 1: OData / REST-Pull
Toimib hästi kaasaegsete ERP-süsteemidega (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-teenusepakkuja võtab andmeid OData või RESTi kaudu. Inkrementaalne, planeeritud või sündmusepõhine.
Eelised: vähe arendustööd teie poolt, teie annate lugemisõigused, teenusepakkuja ehitab ümberkujunduse.
Puudused: ei tööta vanemate SAP ECC-installatsioonidega ilma täiendava API-kihita. Vajate andmejuurdepääsutaotluste haldamist.
Mudel 2: Sündmusepõhine integratsioon
SAP Event Mesh, Apache Kafka, RabbitMQ. Teie ERP avaldab muudatussündmusi, DPP-teenusepakkuja tarbib neid.
Eelised: peaaegu reaalajas, elegantselt skaleeritav, lahtisidestatud.
Puudused: seadistamine on keeruline ja nõuab infrastruktuuri, mida igal IT-osakonnal pole. Väiksematele ettevõtetele enamasti liiga keeruline.
Mudel 3: vahevara / ETL
Teil on integratsioonikiht (Mulesoft, Boomi, Informatica, Azure Data Factory) ERP-süsteemi ja väliste süsteemide vahel. Vahevara on vahendaja - DPP-teenusepakkuja suhtleb vahevaraga, mitte kunagi otse ERP-süsteemiga.
Eelised: olemasolevaid investeeringuid saab ära kasutada, juhtimine on stabiilne, kolmandatel osapooltel puudub otsene juurdepääs ERP-süsteemile.
Puudused: teie vahendustarkvara kulud suurenevad proportsionaalselt.
Mida me konkreetsetes projektides teisiti teeme
Paljud pakkujad soovivad ühenduda otse teie ERP-süsteemiga. Me lisame põhimõtteliselt vaheetapi: meie API aktsepteerib neutraalset JSON-skeemi, mille te saate täita oma valitud tööriistaga. See tähendab:
- saate andmeid ise ette valmistada, kasutades tööriistu, millega teie meeskond on tuttav
- saate meid vahetada - neutraalne formaat on ülekantav
- saate kogu oma andmebaasi igal ajal tagasi kätte - CSV-, XLSX-, JSON-LD- ja SQL-vormingus ning REST-API kaudu
- Pakume importimise validaatorit, mis kontrollib teie andmeid enne üleslaadimist
Täielik skeem ja kõik lõpppunktid on avalikult dokumenteeritud /apidocs all OpenAPI-spetsifikatsioonina. Teie IT-osakond saab liidest enne lepingu allkirjastamist kontrollida - sealhulgas näidispäringuid, veateateid ja autentimise üksikasju.
Selle lähenemisviisi rakendamise ajakava praktikas:
- 1.-2. päev: kaardistamise töötuba. Milline ERP-väli vastab millisele DPP-väljale?
- 3.-5. päev: esimesed JSON-eksportid ERP-süsteemist, läbi meie validaatori.
- 6.-8. päev: vigade parandamine (puuduvad väljad, ebajärjekindlad koodid).
- 9.-10. päev: esimesed DPP-d on kasutusel.
Kaks nädalat, mitte kolm kuud. Võtmekohaks on kaardistamise töötuba - seal otsustatakse andmete kvaliteedi üle.
Mis võib valesti minna: kõige sagedasemad lõksud
Toote põhiandmed mitmes süsteemis: SAP-is on tootenumber, PIM-is on pildid ja turundustekstid, PLM-is on komponentide nimekiri. Keegi ei oma terviklikku ülevaadet. Lahendus: määrake enne projekti algust kindlaks, milline süsteem on millise välja puhul „tõe allikas“ (Source of Truth).
Sertifikaadid PDF-vormingus: tarnijad esitavad GOTS-, OEKO-TEX- või REACH-sertifikaadid PDF-skannina. See ei ole struktureeritud andmeallikas. Lahendus: sertifitseerimisasutused pakuvad üha enam API-päringuid (OEKO-TEX on siin esirinnas, GOTS jääb maha). Või: sisestage andmed käsitsi, kuid koos kehtivuskuupäevaga, 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 kolmetasandiline mudel. Avalik on tootekategooria, ametiasutused näevad täielikku retsepti. Peaaegu kunagi ei ole see takistuseks, kuid see tuleb varakult selgeks teha.
Tarnijapõhised CO₂-andmed: teie tarnija esitab keskmise väärtuse kogu oma tooteportfelli kohta, mitte iga partii kohta eraldi. 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 peaks olema DPP-d? (10, 10 000, 1 miljon?)
- Millised süsteemid sisaldavad praegu DPP-ga seotud andmeid?
- Milline osakond haldab iga süsteemi?
- Kas teil on olemas middleware-investeering, mida tuleks ära kasutada?
- Kas teie ERP-süsteemi kohal on juba toimiv API-kiht?
Vastused määravad, milline kolmest mudelist teile sobib. Samuti määravad need, kas projekt kestab kaks nädalat või kuus kuud.