„Sklandi ERP integracija“ - tai standartinis pažadas, kurį praktikoje paprastai lydi tris mėnesius trunkantis projektas. Mes skelbiame savo API vadovą, kad jūsų IT skyrius dar prieš pasirašydamas sutartį galėtų patikrinti, kokie duomenys iš tikrųjų bus užklausomi. Štai ką turėtumėte žinoti prieš pradėdami integracijos projektą.
Ką iš tikrųjų turi pateikti jūsų ERP sistema
Kad būtų sukurta 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
- Aplinkos duomenys - CO2 ekvivalentas vienetui, vandens suvartojimas, energijos suvartojimas
- Tiekėjų duomenys - kas tiekia kokią sudedamąją dalį (dėl deramo patikrinimo)
Teoriškai visi šie duomenys yra jūsų ERP sistemoje. Praktiškai jie yra išskirstyti po 4-7 modulius: medžiagų vadyba (MM), gamyba (PP), kokybė (QM), tiekėjai (LFA1), kartais atskiras EHS modulis aplinkosaugos duomenims, kartais PLM sistema receptūroms.
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 integracijos modeliai
1 modelis: OData / REST-Pull
Puikiai veikia su šiuolaikinėmis ERP sistemomis (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP teikėjas gauna duomenis per OData arba REST. Palaipsniškai, pagal planą arba reaguojant į įvykius.
Privalumai: jums reikia mažai programavimo darbo, jūs pateikiate skaitymo kredencialus, o teikėjas sukuria transformaciją.
Trūkumai: neveikia su senesnėmis SAP ECC instaliacijomis be papildomo API sluoksnio. Jums reikalingas duomenų prieigos prašymų valdymas.
2-asis modelis: Įvykių pagrįsta integracija
„SAP Event Mesh“, „Apache Kafka“, „RabbitMQ“. Jūsų ERP sistema skelbia pakeitimų įvykius, o DPP teikėjas juos apdoroja.
Privalumai: beveik realiuoju laiku, elegantiškai mastelio keičiama, atsieta.
Trūkumai: konfigūravimas yra sudėtingas ir reikalauja infrastruktūros, kurios neturi kiekvienas IT skyrius. Mažesnėms įmonėms dažniausiai yra pernelyg sudėtinga.
Modelis 3: Tarpinė programinė įranga / ETL
Tarp ERP ir išorinių sistemų turite integracijos sluoksnį („Mulesoft“, „Boomi“, „Informatica“, „Azure Data Factory“). Tarpinė programinė įranga yra tarpininkas - DPP teikėjas bendrauja su tarpine programine įranga, niekada tiesiogiai su ERP.
Privalumai: galima pasinaudoti esamomis investicijomis, valdymas stabilus, trečiosios šalys neturi tiesioginės prieigos prie ERP.
Trūkumai: jūsų tarpinės programinės įrangos išlaidos didėja proporcingai.
Ką mes darome kitaip konkrečiuose projektuose
Daugelis tiekėjų nori prisijungti tiesiogiai prie jūsų ERP. Mes iš principo įdiegiame tarpinį žingsnį: mūsų API priima neutralią JSON schemą, kurią galite užpildyti pasirinktu įrankiu. Tai reiškia:
- Duomenis galite paruošti patys, naudodami įrankius, kuriuos gerai išmano jūsų komanda
- Galite mus pakeisti - neutralus formatas yra perkeliamas
- Visą savo duomenų bazę bet kada galite išgauti - CSV, XLSX, JSON-LD ir SQL formatais, taip pat per REST-API
- Mes pateikiame importo validatorių, kuris patikrina jūsų duomenis prieš juos įkeliant
Pilna schema ir visi galiniai taškai yra viešai dokumentuoti /apidocs kaip OpenAPI specifikacija. Jūsų IT skyrius gali patikrinti sąsają prieš pasirašant sutartį - įskaitant pavyzdinius užklausimus, klaidų atsakymus ir autentiškumo patvirtinimo duomenis.
Laiko grafikas, taikant šį metodą praktikoje:
- 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 jame nusprendžiama dėl duomenų kokybės.
Kas gali nepavykti: dažniausios klaidos
Prekių pagrindiniai 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 „tiesos šaltinis“ (Source of Truth) kiekvienam laukui.
Sertifikatai PDF formatu: Tiekėjai pateikia GOTS, OEKO-TEX arba REACH sertifikatus kaip nuskaitytus PDF failus. Tai nėra struktūrizuotas duomenų šaltinis. Sprendimas: sertifikavimo operatoriai vis dažniau siūlo API užklausas (OEKO-TEX pirmauja, o GOTS atsilieka). Arba: įvesti rankiniu būdu, bet nurodant galiojimo datą, kad DPP sistemoje 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ą. Tai beveik niekada nesudaro kliūčių, tačiau šį klausimą 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 priskirtų 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 naudojant terminologijos duomenų bazę; šia tema turime atskirą straipsnį.
Klausimai, kuriuos turėtumėte užduoti prieš pradedant projektą
Prieš siunčiant užklausą (RFP) trims tiekėjams, atsakykite į šiuos klausimus viduje:
- 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 investiciją į tarpinę programinę įrangą, kurią reikėtų panaudoti?
- Ar virš jūsų ERP sistemos jau veikia API sluoksnis?
Atsakymai lems, kuris iš trijų modelių jums tinka. Be to, jie nulems, ar projektas truks dvi savaites, ar šešis mėnesius.