“Saumlaus ERP-samþætting” er staðlað loforð sem, í reynd, er fylgt eftir með þriggja mánaða verkefni. Við erum að birta API Playbook okkar svo að upplýsingatækniteymi ykkar geti athugað hvaða gögn eru raunverulega óskað eftir áður en samningurinn er undirritaður. Hér er það sem þið ættuð að vita áður en þið hefjið samþættingarverkefni.
Hvað ERP-kerfið þitt þarf í raun að bjóða upp á
Til að búa til DPP þurfum við eftirfarandi fyrir hverja vöru:
- Aðalupplýsingar - vörunúmer, lýsing, afbrigði, þyngd, víddir, myndir
- Efnisyfirlitsgögn - íhlutir með magni og endurunnu efni
- Upprunagögn - framleiðslustaður, lotunúmer, framleiðsludagur
- Umhverfisgögn - CO₂-jafngildi á einingu, vatnsnotkun, orkunotkun
- Birgðagögn - hver er birgir hvers íhlutar (fyrir áhættumat)
Í kenningunni eru öll þessi gögn tiltæk í ERP-kerfinu þínu. Í framkvæmd er þetta gögn þó dreift á 4 til 7 einingar: Efnisstjórnun (MM), framleiðsla (PP), gæðastjórnun (QM), birgjarstjórnun (LFA1), stundum sérstök EHS-eining fyrir umhverfismál og stundum PLM-kerfi fyrir uppskriftir.
Spurningin um samþættingu er ekki: “Veitir ERP-kerfið þitt gögn til DPP?” Hún er: “Hvernig sameinarðu gögnin úr fimm undirkerfum í samræmt gagnasafn?”
Þrjár reyndar og prófaðar samþættingarmynstur
Mynstur 1: OData / REST pull
Virkar vel með nútímalegum ERP-kerfum (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-veitandinn sækir gögn í gegnum OData eða REST. Stigvaxandi, fyrirfram ákveðin eða atburðastýrð.
Kostir: lágmarksþróun krafist af þinni hálfu; þú veitir aðgangsheimildir til lestrar og veitandinn byggir upp umbreytinguna.
Ókostir: virkar ekki með eldri SAP ECC-uppsetningum án viðbótar API-lags. Þú þarft stjórnun á beiðnum um gagnsaðgang.
Mynstur 2: Viðburðamiðuð samþætting
SAP Event Mesh, Apache Kafka, RabbitMQ. ERP-kerfið þitt birtir breytingaviðburði; DPP-veitandinn neytir þeirra.
Kostir: Næstum rauntími, stigstærð á snjallan hátt, óháð.
Ókostir: Uppsetningin er flókin og krefst innviða sem ekki öll upplýsingatæknideildir hafa. Venjulega ofviða fyrir minni fyrirtæki.
Mynstur 3: Miðlægur hugbúnaður / ETL
Þú ert með samþættingarlag (Mulesoft, Boomi, Informatica, Azure Data Factory) milli ERP-kerfisins og ytri kerfa. Miðlægur hugbúnaðurinn virkar sem viðmótið - DPP-veitandinn á samskipti við miðlæga hugbúnaðinn, aldrei beint við ERP-kerfið.
Kostir: Hægt er að nýta núverandi fjárfestingar, stjórnsýsla er stöðug, enginn beinn aðgangur þriðja aðila að ERP-kerfinu.
Ókostir: Kostnaðurinn við milliforritið eykst í réttu hlutfalli.
Hvað við gerum öðruvísi í tilteknum verkefnum
Margir þjónustuveitendur vilja tengjast ERP-kerfinu þínu beint. Við innleiðum alltaf millistig: API-ið okkar tekur við hlutlausu JSON-skema, sem þú fyllir út með verkfæri að eigin vali. Þetta þýðir:
- Þú getur undirbúið gögnin sjálfur, með þeim verkfærum sem teymið þitt þekkir
- Þú getur skipt um þjónustuaðila - hlutlaust sniðmát er flytjanlegt
- Þú getur sótt öll gagnasöfn þín hvenær sem er - sem CSV, XLSX, JSON-LD og SQL, sem og í gegnum REST API
- Við bjóðum upp á innflutningsstaðfestara sem athugar gögnin þín áður en þeim er hlaðið upp
Heildarskemað og allir endapunktar eru opinberlega skjalfestir sem OpenAPI-tilgreining á /apidocs. IT-teymið þitt getur prófað viðmótið áður en samningur er undirritaður - þar á meðal sýnibeiðnir, villusvör og auðkenningargögn.
Tímarammi fyrir þessa nálgun í framkvæmd:
- Dagar 1 til 2: Kortlagningarvinnustofa. Hvaða ERP-reitur samsvarar hvaða DPP-reiti?
- Dagar 3 til 5: Upphafleg JSON-útflutningur úr ERP-kerfinu, keyrður í gegnum gildisskoðara okkar.
- Dagar 6 til 8: V villuleit ( vantar reiti, ósamræmd kóðun).
- Dagarnir 9 til 10: Fyrstu DPP-arnir fara í loftið.
Tvær vikur, ekki þrír mánuðir. Kjarni málsins er kortlagningarvinnustofan - þar er gæðagetu gagna ákvarðað.
Aðalvörugögn í mörgum kerfum: SAP hefur vörunúmerið, PIM hefur myndirnar og markaðstextana, PLM hefur efnisyfirlitið. Enginn hefur samræmda yfirsýn. Lausn: Áður en verkefnið hefst, skilgreinið hvaða kerfi er “uppspretta sannleikans” fyrir hvert reiti.
Vottorð sem PDF-skrár: Birgjar útvega GOTS-, OEKO-TEX- eða REACH-vottorð sem skannaðar PDF-skrár. Þetta er ekki uppbyggður gagnagrunnur. Lausn: Vottunarstofnanir bjóða sífellt meira upp á API-fyrirspurnir (OEKO-TEX er í fararbroddi en GOTS dregst aftur úr). Eða: slá þau inn handvirkt, en skrá gildistímann til að tryggja að engin útrunnin vottorð birtist í DPP.
Trúnaður upplýsinga um innihaldsefni: Sérstaklega í snyrtivörum, matvælum og lyfjum er fullkomið innihaldsefnasamsetningin viðskiptaleyndarmál. Ætti DPP að gera þær opinberar? Lausn: Þriggja þrepa líkan ESPR. Vöruflokkurinn er almenningi aðgengilegur; eftirlitsaðilar geta skoðað fullkomna uppskriftina. Þetta er nánast aldrei hindrun, en þarf að skýra snemma á ferlinu.
CO₂-gögn byggð á birgjum: Birgirinn þinn gefur upp meðalgildi fyrir allt vörusafnið sitt, en ekki fyrir hverja lotu. Lausn: Samþykkja þetta tímabundið; aðlaga birgjasamninga til lengri tíma. ESPR krefst vörutengdra gilda frá tilteknum skiladegi, en núverandi framkvæmd er málamiðlun.
Staðbundnar tungumálsútgáfur: ERP-kerfið þitt inniheldur aðeins vörunafnið á þýsku og ensku. Fyrir 27 ESB-lönd þarftu fleiri. Lausn: Vélþýðing með hugtakatöku; við höfum sérstaka grein um þetta.
Spurningar sem þú ættir að spyrja fyrir verkefnið
Áður en þú sendir út RFP (tilboðsbeiðni) til þriggja birgja, svaraðu eftirfarandi spurningum innanhúss:
- Hversu mörgum vörum/vörunúmerum ætti að hafa DPP? (10, 10.000, 1 milljón?)
- Hvaða kerfi geyma nú gögn sem tengjast DPP?
- Hvert deildarstjórnarsvið sér um hvert þessara kerfa?
- Eruð þið með fjárfestingu í milliforritun (middleware) sem ætti að nýta?
- Er API-lag þegar til staðar ofan á ERP-kerfinu ykkar?
Svörin munu ákvarða hvaða þriggja líkana hentar ykkur best. Og þau munu ákvarða hvort verkefnið taki tvær vikur eða sex mánuði.