Produkto svoris nurodytas medžiagų valdymo sistemoje. Perdirbtų medžiagų dalis nurodyta receptūrų sistemoje. Tiekėjo sertifikatas saugomas PDF formatu tinklo diske. Produkto pasui reikalingi visi trys duomenys viename įraše, ir būtent tai yra integracijos projekto esmė, o ne dviejų sistemų sujungimas.
„Sklandi ERP integracija“ - tai standartinis pažadas, po kurio praktikoje seka trijų mėnesių trukmės projektas. Skelbiame savo gaires, kad jūsų IT skyrius prieš pasirašydamas sutartį galėtų patikrinti, kokie duomenys iš tikrųjų bus prašomi. Šiame straipsnyje paaiškinama, kokių duomenų iš jūsų sistemų reikia pasui, kokiais trimis būdais jie mums perduodami ir kodėl tai galima padaryti per dvi savaites.
Ką iš tikrųjų turi pateikti jūsų ERP sistema
Kad būtų sukurtas DPP, mums reikia šių duomenų apie kiekvieną produktą:
- Pagrindiniai duomenys - prekės kodas, pavadinimas, variantai, svoris, matmenys, nuotraukos
- Sudedamųjų dalių sąrašo duomenys - komponentai su kiekiais ir perdirbtų medžiagų dalimis
- Kilmės duomenys - gamybos vieta, partijos numeris, gamybos data
- Aplinkosaugos duomenys - CO2 ekvivalentas vienetui, vandens suvartojimas, energijos suvartojimas
- Tiekėjų duomenys - kas tiekia kokį komponentą (dėl deramo rūpestingumo pareigų)
Teoriškai visi šie duomenys yra jūsų ERP sistemoje. Praktikoje jie paskirstyti 4-7 moduliuose: medžiagų valdymas, gamyba, kokybė, tiekėjų duomenų bazė, kartais atskiras modulis aplinkosaugos duomenims, kartais atskira sistema receptūroms ir sudedamųjų dalių sąrašams.
Integracijos klausimas nėra toks: „Ar jūsų ERP sistema teikia duomenis DPP?“ Jis yra toks: „Kaip sujungti duomenis iš 5 posistemių į vieną nuoseklų duomenų rinkinį?“
Trys patikrinti būdai
1 būdas: duomenų paėmimas iš ERP sistemos
Puikiai veikia su šiuolaikinėmis ERP sistemomis (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP teikėjas gauna duomenis per ERP sąsają (techniniu požiūriu - OData arba REST). Tik pakeitimai, pagal tvarkaraštį arba sukeliami įvykio.
Privalumai: jums nereikia daug kurti - jūs suteikiate skaitymo prieigą, o teikėjas sukuria konversijos sprendimą.
Trūkumai: neveikia su senesnėmis „SAP ECC“ instaliacijomis be papildomo sąsajos sluoksnio. Reikia aiškių taisyklių, kas ir kokius duomenis gali skaityti.
2-asis būdas: pokyčių perdavimas
Jūsų ERP praneša apie kiekvieną pokytį kaip įvykį (per „SAP Event Mesh“, „Apache Kafka“ arba „RabbitMQ“), o DPP teikėjas juos priima.
Privalumai: veikia beveik realiuoju laiku, plečiasi kartu su sistema, sistemos nepriklauso viena nuo kitos.
Trūkumai: konfigūravimas yra sudėtingas ir reikalauja infrastruktūros, kurios neturi kiekvienas IT skyrius. Mažesnėms įmonėms dažniausiai tai yra pernelyg sudėtinga.
3-iasis būdas: esamo integracijos sluoksnio naudojimas
Jūs jau turite integracijos sluoksnį (Mulesoft, Boomi, Informatica, „Azure Data Factory“) tarp ERP ir išorinių sistemų. Šis sluoksnis yra tarpininkas: DPP teikėjas bendrauja su juo, niekada tiesiogiai su ERP.
Privalumai: galima pasinaudoti esamomis investicijomis, taisyklės išlieka stabilios, trečiosios šalys neturi tiesioginės prieigos prie ERP.
Trūkumai: jūsų išlaidos integracijos sluoksniui taip pat didėja.
Ką mes darome kitaip konkrečiuose projektuose
Daugelis tiekėjų nori prisijungti tiesiogiai prie jūsų ERP. Mes iš principo įdiegiame tarpinį etapą: mūsų sąsaja priima neutralų duomenų formatą (JSON schemą), kurį jūs užpildote pasirinktu įrankiu. Tai reiškia:
- Duomenis galite paruošti patys, naudodami įrankius, kuriuos gerai žino jūsų komanda
- galite mus pakeisti - neutralus formatas yra perkeliamas
- bet kuriuo metu galite išgauti visą savo duomenų bazę - CSV, XLSX, JSON-LD ir SQL formatais, taip pat per REST-API
- mes pateikiame importo validatorių, kuris patikrina jūsų duomenis prieš juos įkeliant
Išsamus formatas ir visi užklausimai viešai aprašyti „ API dokumentacija “ kaip sąsajos aprašymas pagal „OpenAPI“. Jūsų IT skyrius gali patikrinti sąsają prieš pasirašant sutartį - įskaitant pavyzdines užklausas, klaidų atsakymus ir autentiškumo patvirtinimo duomenis.
Praktinis šio metodo įgyvendinimo grafikas:
- 1-2 dienos: atitikmenų nustatymo seminaras. Kuris ERP laukas atitinka kurį DPP lauką?
- 3-5 dienos: pirmieji JSON eksportai iš ERP sistemos, patikrinti mūsų validatoriaus pagalba.
- 6-8 dienos: klaidų taisymas (trūkstami laukai, nesuderinami kodai).
- 9-10 dienos: pirmieji DPP duomenys jau veikia.
Dvi savaitės, o ne trys mėnesiai. Svarbiausias momentas yra atitikmenų nustatymo seminaras - būtent ten sprendžiama dėl duomenų kokybės.
Kas gali nepavykti: dažniausios spąstai
Prekių baziniai duomenys keliose sistemose: SAP turi prekės numerį, PIM - nuotraukas ir rinkodaros tekstus, PLM - sudedamųjų dalių sąrašą. Niekas neturi nuoseklaus vaizdo. Sprendimas: prieš pradedant projektą apibrėžkite, kuri sistema yra pagrindinė kiekvienam laukeliui.
Sertifikatai PDF formatu: tiekėjai pateikia GOTS, OEKO-TEX ar REACH sertifikatus kaip nuskaitytus PDF failus. Tai nėra struktūrizuotas duomenų šaltinis. Sprendimas: sertifikavimo įstaigos vis dažniau siūlo galimybę gauti duomenis per sąsają (OEKO-TEX yra pirmaujanti, o GOTS atsilieka). Arba: įvesti duomenis rankiniu būdu, bet nurodant galiojimo datą, kad DPP neatsirastų pasibaigusių sertifikatų.
Receptūros slaptumas: ypač kosmetikos, maisto produktų ir farmacijos srityse: visa receptūra yra įmonės paslaptis. Ar DPP turėtų ją viešai atskleisti? Sprendimas: ESPR trijų lygmenų modelis. Viešai skelbiama produkto kategorija, o valdžios institucijos mato visą receptūrą. Beveik niekada tai nesudaro kliūčių, tačiau tai reikia išsiaiškinti iš anksto.
CO₂ duomenys pagal tiekėjus: jūsų tiekėjas pateikia vidutinę vertę visam savo asortimentui, o ne kiekvienai partijai atskirai. Sprendimas: laikinai tai priimti, o ilgalaikėje perspektyvoje pakoreguoti tiekėjų sutartis. ESPR reikalauja konkrečiam produktui skirtų verčių nuo nustatytos datos, tačiau dabartinė praktika yra kompromisas.
Vietinės kalbinės versijos: jūsų ERP sistemoje yra tik produkto pavadinimas vokiečių ir anglų kalbomis. 27 ES šalims to nepakanka. Sprendimas: mašininis vertimas su terminologijos duomenų baze; apie tai turime atskirą straipsnį.
Klausimai, kuriuos turėtumėte užduoti prieš pradedant projektą
Prieš siųsdami užklausą (RFP) trims tiekėjams, atsakykite į šiuos vidinius klausimus:
- Kiek produktų / prekių kodų turėtų turėti DPP? (10, 10 000, 1 milijonas?)
- Kokios sistemos šiuo metu saugo su DPP susijusius duomenis?
- Koks skyrius administruoja kiekvieną iš šių sistemų?
- Ar turite integracijos sluoksnį, kurį reikėtų panaudoti?
- Ar jau yra veikianti sąsaja su jūsų ERP sistema?
Atsakymai lems, kuris iš trijų būdų jums tinka.
Atsakymai nulemia, ar projektas truks dvi savaites, ar šešis mėnesius.
Klausimai apie šį įrašą
Ar pakanka REST sąsajos, ar mums reikia tarpinės programinės įrangos?
Sąsaja yra pakankama. Šie trys modeliai skiriasi tuo, kur vyksta transformavimas, o ne tuo, ką priimame - mūsų sąsaja priima neutralią JSON schemą, nesvarbu, kuo ją sukūrėte. Duomenų ištraukimas iš šiuolaikinės ERP sistemos, įvykių srautas ir esamas integracijos sluoksnis - visi jie baigiasi tame pačiame galiniame taške. Tarpinė programinė įranga yra naudinga, jei jūs ją jau naudojate ir norite, kad ji liktų sutartimi su trečiosiomis šalimis. Jei jos šiuo metu neturite, nepirkite jos vien dėl produkto paso.
Ką nuspręsiama žemėlapių kūrimo dirbtuvėse?
Koks ERP laukas taps atitikmeniu - ir kuri sistema bus pagrindinis šaltinis, jei kelios sistemos turi tą pačią reikšmę. Seminaras vyks 1-ąją ir 2-ąją dieną ir yra viso projekto esminis momentas, nes būtent ten bus sprendžiama dėl duomenų kokybės, o ne vėliau kodo kūrimo etape. Atsiveskite ne tik už projektą atsakingus asmenis, bet ir tuos, kurie prižiūri sistemas - pagrindinių duomenų, gamybos, kokybės ir pirkimų padaliniai retai kada yra viename skyriuje. Viskas, kas vyksta po to - duomenų eksportavimas, patvirtinimas ir klaidų taisymas - yra praktinis darbas.
Mūsų sertifikatai yra tik PDF formatu (nuskenuoti). Ką su jais daryti?
Skenuotas dokumentas nėra struktūrizuotas duomenų šaltinis, todėl jo negalima naudoti pase. Yra du veiksmingi būdai: sertifikavimo operatoriai vis dažniau siūlo API užklausas, o jei jų nėra, reikšmes įveskite rankiniu būdu, tačiau visada nurodydami galiojimo datą, kad paskelbtame pase neliktų pasibaigusio galiojimo sertifikato. Rankinį būdą planuokite kaip pasikartojantį darbą, o ne kaip vienkartinę užduotį.
Ar mūsų IT skyrius galėtų patikrinti sąsają prieš mums ką nors pasirašant?
Taip. Visas schemos aprašas ir visi galiniai taškai pateikiami kaip OpenAPI specifikacija „ API dokumentacija “ formatu, kartu su pavyzdiniais užklausimais, klaidų atsakymais ir autentiškumo patvirtinimo duomenimis. Nė viena iš šių detalių nėra paslėpta už pardavimo pokalbių, todėl jūsų integracijos komanda gali įvertinti reikalingas sąnaudas dar prieš sudarant sutartį. Jei tiekėjas šioje stadijoje neparodo savo sąsajos, tai taip pat yra atsakymas.
Kas nutinka su mūsų duomenimis, kai keičiame paslaugų teikėją?
Jie prisijungia. Sąsaja priima neutralų JSON schemą vietoj patentuoto formato, o visas jūsų duomenų rinkinys eksportuojamas CSV, XLSX, JSON-LD ir SQL formatais arba per REST API. Tai padaryta sąmoningai - formatas, į kurį įvedate duomenis, yra perkeliamas, todėl perėjimas reikalauja tik eksporto, o ne naujo duomenų bazės kūrimo. Prieš žemėlapių kūrimo seminarą užduokite tą patį klausimą kiekvienam tiekėjui, nes po jo jūsų laukų pavadinimai bus įtraukti į jo modelį.
Kiek laiko iš tikrųjų trunka prijungimas?
Projektai, kuriuos mes koordinuojame, trunka dvi savaites: dvi dienos skiriamos duomenų kartografavimui, trys dienos - iki pirmųjų eksportų per mūsų validatorių, trys dienos - klaidų taisymui, dvi dienos - iki pirmųjų pasų paskelbimo. Ilgiausias etapas niekada nėra kodas, o tai, ką randa validatorius - trūkstami laukeliai, nenuoseklios kodavimo sistemos, reikšmės, už kurias niekas nesijaučia atsakingas. Įtraukite šias dienas į planą, o ne jas trumpinkite. Projektas, kuris jas praleidžia, kartu paskelbia ir trūkumus.
Ar turime susieti visus produktus iš karto?
Ne. Pradėkite nuo produktų, kuriems pirmiausia reikia suderinimo, ir nuo šaltinio sistemos - neutrali schema priima tiek dalinį, tiek pilną katalogą, o importavimas yra pakartojamas, taigi vėlesni ciklai atnaujina atsargas. Dėl to žemėlapių kūrimo seminaras išlieka pakankamai trumpas, kad jį būtų galima užbaigti per dvi dienas. Vėlesnis išplėtimas yra žemėlapių kūrimo užduotis, o ne naujas projektas.
