Pesha e produktit regjistrohet në menaxhimin e materialeve. Proporcioni i materialit të ricikluar regjistrohet në sistemin e formulimit. Certifikata e furnizuesit ruhet si PDF në një disk rrjeti. Pasaporta e produktit kërkon të treja informacionet në një regjistër të vetëm të të dhënave, dhe pikërisht kjo është thelbi i projektit të integrimit - jo thjesht lidhja e dy sistemeve.
‘Integimi i pandërprerë i ERP-së’ është një premtim standard që, në praktikë, shoqërohet me një projekt tre-mujor. Ne po publikojmë udhëzuesin tonë në mënyrë që departamenti juaj i IT-së të mund të verifikojë se cilat të dhëna kërkohen me të vërtetë para nënshkrimit të kontratës. Ky artikull shpjegon se cilat të dhëna kërkon pasaporta nga sistemet tuaja, tre mënyrat në të cilat na dërgohet, dhe pse kjo mund të arrihet brenda dy javësh.
Çfarë duhet të sigurojë në të vërtetë sistemi juaj ERP
Për të krijuar një DPP, na nevojiten të dhënat e mëposhtme për çdo produkt:
- Të dhëna themelore - numri i artikullit, përshkrimi, variantet, peshat, dimensionet, imazhet
- Të dhënat e listës së materialeve - komponentët me sasi dhe përmbajtje të ricikluar
- Të dhënat e origjinës - vendi i prodhimit, numri i serisë, data e prodhimit
- Të dhënat mjedisore - CO₂eq për njësi, konsum i ujit, konsum i energjisë
- Të dhënat e furnizuesit - kush furnizon cilin komponent (për kërkesat e kujdesit të duhur)
Në teori, të dhënat e gjitha këto janë të disponueshme në sistemin tuaj ERP. Në praktikë, megjithatë, ato janë të shpërndara në 4 deri në 7 module: menaxhimi i materialeve, prodhimi, cilësia, të dhënat kryesore të furnitorit, ndonjëherë një modul i veçantë për të dhënat mjedisore, dhe ndonjëherë një sistem i dedikuar për formulimet dhe listat e materialeve.
Pyetja në lidhje me integrimin nuk është: ‘A furnizon ERP-ja juaj të dhëna për një DPP?’ Por është: ‘Si i bashkoni të dhënat nga pesë nënsisteme në një grup të dhënash koherent?’
Tre qasje të provuara dhe të testuara
Qasje 1: Marrja e të dhënave nga ERP-ja
Funksionon mirë me ERP-të moderne (SAP S/4HANA Cloud, Dynamics 365, Odoo). Ofruesi i DPP-së merr të dhënat përmes ndërfaqes së ERP-së (teknikisht OData ose REST). Merren vetëm ndryshimet, qoftë në mënyrë të planifikuar, qoftë të nxitura nga një ngjarje.
Përparësitë: kërkohet zhvillim minimal nga ana juaj; ju siguroni akses leximi, dhe ofruesi merret me konvertimin.
Të metat: nuk funksionon me instalimet më të vjetra të SAP ECC pa një shtresë shtesë ndërfaqeje. Ju nevojiten rregulla të qarta që përcaktojnë se kush është i autorizuar të lexojë të dhënat përkatëse.
Opsioni 2: Dërgimi i ndryshimeve
ERP-ja juaj raporton çdo ndryshim si një ngjarje (përmes SAP Event Mesh, Apache Kafka ose RabbitMQ), dhe ofruesi DPP i pranon ato.
Përparësitë: pothuajse në kohë reale, shkallëzohet me biznesin tuaj, sistemet nuk janë të varur nga njëri-tjetri.
Disavantazhet: Vendosja është komplekse dhe kërkon infrastrukturë që jo çdo departament IT e ka. Zakonisht e tepruar për kompanitë më të vogla.
Opsioni 3: Përdorni shtresën ekzistuese të integrimit
Ju tashmë keni një ### shtresë integrimi(Mulesoft, Boomi, Informatica, Azure Data Factory) midis ERP-së dhe sistemeve të jashtme. Kjo shtresë vepron si ndërmjetës: ofruesi DPP komunikon me të, kurrë drejtpërdrejt me ERP-në.
Përparësitë: investimet ekzistuese mund të shfrytëzohen, rregullat mbeten të qëndrueshme, dhe palët e treta nuk kanë akses të drejtpërdrejtë në ERP.
Të metat: kostot tuaja për shtresën e integrimit rriten për pasojë.
Çfarë bëjmë ndryshe në projekte specifike
Shumë ofrues duan të lidhen drejtpërdrejt me ERP-në tuaj. Ne gjithmonë përfshijmë një hap ndërmjetës: ndërfaqja jonë pranon një format neutral të të dhënave (një skemë JSON), të cilin e plotësoni duke përdorur një mjet sipas zgjedhjes suaj. Kjo do të thotë:
- Ju mund të përgatisni vetë të dhënat, duke përdorur mjetet me të cilat ekipi juaj është i njohur
- Mund të ndryshoni ofruesit - formati neutral është i bartshëm
- Mund të merrni të gjithë bazën tuaj të të dhënave në çdo kohë - si CSV, XLSX, JSON-LD dhe SQL, si dhe përmes REST API
- Ne ofrojmë një validues importi që kontrollon të dhënat tuaja para ngarkimit
Formati i plotë dhe të gjitha kërkesat janë dokumentuar publikisht në Dokumentacioni i API-së si një specifikim ndërfaqeje në përputhje me OpenAPI. Ekipi juaj i IT-së mund të rishikojë ndërfaqen para se të nënshkruhet një kontratë - duke përfshirë kërkesat shembull, përgjigjet e gabimeve dhe detajet e autentifikimit.
Kronologjia për këtë qasje në praktikë:
- Ditët 1 deri në 2: Punëtori për përputhjen e të dhënave. Cili fushë i ERP-së i korrespondon cilës fushë të DPP-së?
- Ditët 3 deri në 5: Eksportet fillestare JSON nga ERP-ja, të përpunuara nga validatori ynë.
- Ditët 6 deri 8: Zgjidhja e problemeve (fusha të munguara, kodim i papajtueshëm).
- Ditët 9 deri 10: DPP-të e para hyjnë në funksion.
Dy javë, jo tre muaj. Thelbi i çështjes është punëtoria e hartimit - aty përcaktohet cilësia e të dhënave.
Çfarë shkon keq: gabimet më të zakonshme
Të dhënat bazë të produktit nëpër sisteme të shumta: SAP ka numrin e artikullit, PIM ka imazhet dhe tekstet e marketingut, PLM ka fletën e materialit. Askush nuk ka një pasqyrë të qëndrueshme. Zgjidhja: para se të fillojë projekti, përcaktoni se cili sistem është burimi kryesor për secilin fushë.
Certifikatat si PDF: furnizuesit ofrojnë certifikata GOTS, OEKO-TEX ose REACH si PDF të skanuara. Kjo nuk është një burim të dhënash të strukturuara. Zgjidhja: Trupat e certifikimit gjithnjë e më shumë ofrojnë mundësinë për të marrë të dhëna përmes një ndërfaqeje (OEKO-TEX po udhëheq, ndërsa GOTS mbetet prapa). Si alternativë, fusni të dhënat manualisht, por përfshini datën e skadencës për t’u siguruar që asnjë certifikatë e skaduar të mos shfaqet në DPP.
Konfidencialiteti i formulimit: veçanërisht në kozmetikë, ushqim dhe farmaceutikë, formulimi i plotë është një sekret tregtar. A duhet t’i bëjë publike DPP-ja? Zgjidhja: Modeli me tre nivele i ESPR-së. Kategoria e produktit është e disponueshme publikisht; autoritetet rregullatore mund të shohin formulimin e plotë. Kjo pothuajse kurrë nuk është një pengesë, por duhet të sqarohet në një fazë të hershme.
Të dhënat e CO₂-së sipas furnizuesit: Furnizuesi juaj jep një vlerë mesatare për të gjithë portofolin e tij, jo për çdo seri. Zgjidhja: Pranoni këtë përkohësisht; rregulloni kontratat me furnizuesit afatgjatë. ESPR kërkon vlera specifike për produktin nga një datë e caktuar, por praktika aktuale është një kompromis.
Versione gjuhësh lokale: Sistemi juaj ERP përmban vetëm emrin e produktit në gjermanisht dhe anglisht. Për 27 vendet e BE-së, ju nevojiten më shumë. Zgjidhja: Përkthim me makinë duke përdorur një bazë të dhënash terminologjike; ne kemi një artikull të veçantë për këtë.
Pyetjet që duhet t’i bëni para projektit
Para se të dërgoni një RFP te tre furnizues, përgjigjuni pyetjeve të mëposhtme brenda kompanisë:
- Sa produkte/numra artikujsh duhet të kenë DPP? (10, 10,000, 1 milion?)
- Cilat sisteme aktualisht mbajnë të dhëna të rëndësishme për DPP?
- Cili departament menaxhon secilin prej këtyre sistemeve?
- A keni një shtresë integrimi që duhet të përdoret?
- A ekziston tashmë një ndërfaqe përmes ERP-së suaj?
Përgjigjet do të përcaktojnë se cili nga tre qasjet është i duhuri për ju.
Përgjigjet do të përcaktojnë nëse një projekt zgjat dy javë apo gjashtë muaj.
Pyetje rreth këtij postimi
A është ndërfaqja REST e mjaftueshme, apo na nevojitet middleware?
Ndërfaqja është e mjaftueshme. Të tre modelet ndryshojnë në vendin ku ndodh transformimi, jo në atë që pranojmë - ndërfaqja jonë pranon një skemë neutrale JSON, pavarësisht se si e keni gjeneruar. Një tërheqje nga një sistem ERP modern, një rrjedhë ngjarjesh dhe një shtresë integrimi ekzistuese përfundojnë të gjitha në të njëjtin pikë përfundimtare. Vlen të përdoret middleware nëse tashmë po përdorni ndonjë dhe ai do të mbetet ndërfaqja kontraktuale me palët e treta. Nëse aktualisht nuk keni asnjë, mos blini asnjë vetëm për pasaportën e produktit.
Çfarë do të vendoset në punëtorinë e hartëzimit?
Cili fushë ERP korrespondon me cilën fushë pass - dhe cili sistem është burimi kryesor kur disa sisteme mbajnë të njëjtin vlerë. Punëtoria zhvillohet në Ditën 1 dhe 2 dhe është thelbi i të gjithë projektit, sepse vendimet për cilësinë e të dhënave merren atje dhe jo më vonë në kod. Sigurohuni të sillni me vete njerëzit që mirëmbajnë sistemet, jo vetëm ata që janë përgjegjës për projektin - të dhënat master, prodhimi, cilësia dhe prokurimi rrallëherë janë të gjitha në të njëjtin departament. Gjithçka që pason - eksportet, validimi dhe zgjidhja e problemeve - është thjesht çështje ekspertize teknike.
Certifikatat tona janë të disponueshme vetëm si skanime PDF. Çfarë duhet të bëjmë me to?
Një skanim nuk është një burim të dhënash të strukturuara dhe për këtë arsye është i papërdorshëm për pasaportën. Ka dy mënyra për të vepruar - autoritetet e certifikimit gjithnjë e më shumë ofrojnë kërkesa API, dhe kur këto nuk janë të disponueshme, fusni vlerat manualisht, por gjithmonë përfshini datën e skadencës në mënyrë që asnjë certifikatë e skaduar të mos mbetet në një pasaportë të publikuar. Trajto procesin manual si një detyrë të përsëritshme, jo si një punë njëherëshe.
A mund të kontrollojë departamenti ynë i IT-së ndërfaqen para se të nënshkruajmë ndonjë gjë?
Po. Skema e plotë dhe të gjitha pikat e fundme janë të disponueshme si specifikim OpenAPI në Dokumentacioni i API-së, së bashku me kërkesa shembull, përgjigje gabimesh dhe detaje autentifikimi. Asgjë nga kjo nuk i nënshtrohet diskutimeve të shitjeve, kështu që ekipi juaj i integrimit mund të vlerësojë përpjekjen e nevojshme para se të nënshkruhet një kontratë. Nëse një ofrues nuk e zbulon API-në e tij në këtë fazë, kjo në vetvete është një përgjigje.
Çfarë ndodh me të dhënat tona kur ndryshojmë ofruesin?
Janë në bord. Ndërfaqja pranon një skemë JSON neutrale në vend të një formati pronësor, dhe i gjithë inventari juaj eksportohet si CSV, XLSX, JSON-LD dhe SQL, ose përmes REST API. Kjo është me qëllim - formati që plotësoni është i bartshëm, kështu që për të ndryshuar ofruesin mjafton një eksport, në vend që të rindërtoni gjithçka nga e para. Pyetni çdo ofrues të njëjtën pyetje para punëtorisë së hartimit, sepse më pas emrat e fushave tuaja do të përfshihen në modelin e tyre.
Sa kohë duhet në të vërtetë për të krijuar një lidhje?
Në projektet që mbështesim, procesi zgjat dy javë: dy ditë hartimi, tre ditë deri te eksportet e para përmes validatorit tonë, tre ditë për korrigjimin e gabimeve dhe dy ditë deri te publikimi i raporteve të para. Pjesa më e gjatë e punës nuk është kodi vetë, por ajo që validatori zbulon - fusha të munguara, kodim të papajtueshëm dhe vlera për të cilat askush nuk ndjehet përgjegjës. Sigurohuni t’i lini këto ditë, në vend që t’i shkurtërroni. Një projekt që i anashkalon ato përfundon duke publikuar gjithashtu boshllëqet.
A duhet t'i lidhim të gjitha produktet njëherësh?
Jo. Filloni së pari me produktet që kërkojnë një pass dhe me një sistem burimor - skema neutrale pranon një katalog të pjesshëm po aq lehtë sa një të plotë, dhe importet janë të përsëritshme, kështu që ekzekutimet e mëvonshme do të përditësojnë inventarin. Kjo gjithashtu e mban punëtorinë e hartëzimit mjaft të shkurtër për t’u përfunduar brenda dy ditësh. Zgjerimi i saj më pas është një detyrë hartëzimi, jo një projekt i ri.
