Produkta svars ir norādīts materiālu pārvaldības sistēmā. Pārstrādāto materiālu īpatsvars ir norādīts receptūru sistēmā. Piegādātāja sertifikāts PDF formātā atrodas tīkla diskā. Produkta pasē visiem trim datiem jābūt vienā datu ierakstā, un tieši tajā slēpjas integrācijas projekta būtība, nevis divu sistēmu savienošanā.
„Vienota ERP integrācija” ir standarta solījums, kam praksē seko trīs mēnešu ilgs projekts. Mēs publicējam šo rokasgrāmatu, lai jūsu IT nodaļa pirms līguma parakstīšanas varētu pārbaudīt, kādi dati faktiski tiek pieprasīti. Šis raksts parāda, kādi dati pasē ir nepieciešami no jūsu sistēmām, kādi ir trīs veidi, kā tie nonāk pie mums, un kāpēc to var paveikt divu nedēļu laikā.
Ko jūsu ERP sistēmai faktiski ir jāsniedz
Lai izveidotu produktu pasi, mums par katru produktu ir nepieciešams:
- pamatdati - preces numurs, nosaukums, varianti, svars, izmēri, attēli
- detaļu saraksta dati - komponenti ar daudzumiem un otrreizējo izejvielu daļu
- izcelsmes dati - ražošanas vieta, partijas numurs, ražošanas datums
- vides dati - CO2eq uz vienību, ūdens patēriņš, enerģijas patēriņš
- piegādātāju dati - kurš piegādā kuru komponentu (pienākumu izpildei attiecībā uz pienācīgu rūpību)
Teorētiski visi šie dati ir pieejami jūsu ERP sistēmā. Praktiski tie ir sadalīti 4 līdz 7 moduļos: materiālu pārvaldība, ražošana, kvalitāte, piegādātāju datu bāze, dažreiz atsevišķs modulis vides datiem, dažreiz atsevišķa sistēma receptūrām un detaļu sarakstiem.
Integrācijas jautājums nav: «Vai jūsu ERP sistēma sniedz datus DPP?» Tas ir: «Kā jūs apvienojat datus no 5 apakšsistēmām vienā saskaņotā datu kopumā?»
Trīs pārbaudīti veidi
1. veids: Datu ieguve no ERP sistēmas
Labi darbojas ar modernām ERP sistēmām (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP pakalpojuma sniedzējs iegūst datus, izmantojot ERP saskarni (tehniski - OData vai REST). Tiek iegūtas tikai izmaiņas - saskaņā ar grafiku vai pēc kāda notikuma.
Priekšrocības: jums ir nepieciešams mazs attīstības darbs - jūs piešķirat lasīšanas piekļuvi, bet pakalpojuma sniedzējs veic datu pārveidošanu.
Trūkumi: nedarbojas ar vecākām SAP ECC instalācijām bez papildu saskarnes slāņa. Jums ir nepieciešami skaidri noteikumi par to, kam ir atļauts lasīt konkrētos datus.
2. veids: izmaiņu pārsūtīšana
Jūsu ERP katru izmaiņu paziņo kā notikumu (izmantojot SAP Event Mesh, Apache Kafka vai RabbitMQ), un DPP pakalpojuma sniedzējs to saņem.
Priekšrocības: gandrīz reāllaikā, sistēma attīstās līdzi, sistēmas nav savstarpēji atkarīgas.
Trūkumi: konfigurēšana ir sarežģīta un prasa infrastruktūru, kāda nav katrai IT nodaļai. Mazākiem uzņēmumiem parasti pārspīlēta.
3. veids: esošā integrācijas slāņa izmantošana
Jums jau ir integrācijas slānis (Mulesoft, Boomi, Informatica, Azure Data Factory) starp ERP un ārējām sistēmām. Šis slānis ir starpnieks: DPP pakalpojuma sniedzējs sazinās ar to, nekad tieši ar ERP.
Priekšrocības: var izmantot esošās investīcijas, noteikumi paliek nemainīgi, trešajām personām nav tiešas piekļuves ERP sistēmai.
Trūkumi: jūsu izmaksas par integrācijas slāni palielinās.
Kā mēs rīkojamies konkrētos projektos
Daudzi pakalpojumu sniedzēji vēlas tieši savienoties ar jūsu ERP sistēmu. Mēs principā ieviešam starpposmu: mūsu saskarne pieņem neitrālu datu formātu (JSON shēmu), kuru jūs aizpildāt ar jūsu izvēlētu rīku. Tas nozīmē:
- Jūs varat veikt datu sagatavošanu paši, izmantojot rīkus, ar kuriem jūsu komanda ir pazīstama
- jūs varat mūs aizstāt - neitrālais formāts ir pārnesams
- jūs jebkurā brīdī varat atgūt visu savu datu krājumu - CSV, XLSX, JSON-LD un SQL formātā, kā arī izmantojot REST-API
- mēs nodrošinām importēšanas validatoru, kas pārbauda jūsu datus pirms augšupielādes
Pilnīgs formāts un visi vaicājumi ir publiski aprakstīti API dokumentācija kā saskarnes apraksts saskaņā ar OpenAPI. Jūsu IT nodaļa var pārbaudīt saskarni, pirms tiek parakstīts līgums - ieskaitot paraugvaicājumus, kļūdu atbildes un autentifikācijas detaļas.
Laika grafiks, izmantojot šo pieeju praksē:
- 1.-2. diena: kartēšanas darbseminārs. Kura ERP lauka atbilst kādam DPP laukam?
- 3.-5. diena: pirmie JSON eksporti no ERP sistēmas, izmantojot mūsu validatoru.
- 6.-8. diena: kļūdu novēršana (trūkstoši lauki, nekonsekventa kodēšana).
- 9.-10. diena: pirmie DPP ir pieejami.
Divas nedēļas, nevis trīs mēneši. Izšķirošais moments ir kartēšanas darbseminārs - tajā tiek lemts par datu kvalitāti.
Kas var noiet greizi: visbiežāk sastopamās lamatas
Produktu pamatdati vairākās sistēmās: SAPsistēmā ir preces numurs, PIM sistēmā - attēli un mārketinga teksti, PLM sistēmā - detaļu saraksts. Nevienam nav vienota priekšstata. Risinājums: pirms projekta sākšanas noteikt, kura sistēma ir vadošā katram laukam.
Sertifikāti PDF formātā: piegādātāji iesniedz GOTS, OEKO-TEX vai REACH sertifikātus kā PDF skenējumus. Tas nav strukturēts datu avots. Risinājums: sertifikācijas organizācijas arvien biežāk piedāvā datu pieprasīšanu caur saskarnes interfeisu (OEKO-TEX ir līderis, GOTS atpaliek). Vai arī: ievadīt datus manuāli, bet norādot derīguma termiņu, lai DPP neparādītos sertifikāti, kuru derīguma termiņš ir beidzies.
Receptūras konfidencialitāte: īpaši kosmētikas, pārtikas un farmācijas nozarē - pilnā receptūra ir uzņēmuma noslēpums. Vai DPP tai jāpadara to publiski pieejamu? Risinājums: ESPR trīs līmeņu modelis. Publiski pieejama ir produktu kategorija, bet iestādes redz pilnu sastāvu. Tas gandrīz nekad nav šķērslis, taču tas ir jānoskaidro jau agrīnā stadijā.
CO₂ dati, pamatojoties uz piegādātāju informāciju: jūsu piegādātājs norāda vidējo rādītāju visam savam produktu klāstam, nevis katrai partijai atsevišķi. Risinājums: pagaidām to pieņemt, bet ilgtermiņā pielāgot piegādātāju līgumus. ESPR prasa produktu specifiskus rādītājus, sākot no noteiktas dienas, taču pašreizējā prakse ir kompromiss.
Vietējās valodu versijas: jūsu ERP sistēmā ir tikai produktu nosaukumi vācu un angļu valodā. 27 ES valstīm ir nepieciešams vairāk. Risinājums: mašīntulkojums ar terminoloģijas datubāzi; par to mums ir atsevišķs raksts.
Jautājumi, kurus jums vajadzētu uzdot pirms projekta uzsākšanas
Pirms nosūtāt pieprasījumu piedāvājumu (RFP) trim piegādātājiem, atbildiet uz šiem jautājumiem iekšēji:
- Cik daudziem produktiem/preču numuriem ir jābūt DPP? (10, 10 000, 1 miljons?)
- Kādas sistēmas šobrīd glabā DPP nozīmīgos datus?
- Kura nodaļa pārvalda katru no šīm sistēmām?
- Vai jums ir integrācijas slānis, kas būtu jāizmanto?
- Vai jau ir darbojošs interfeiss, kas savienots ar jūsu ERP sistēmu?
Atbildes noteiks, kurš no trim risinājumiem jums ir piemērots.
Atbildes nosaka, vai projekts ilgs divas nedēļas vai sešus mēnešus.
Jautājumi par šo ierakstu
Vai pietiek ar REST saskarni, vai mums ir nepieciešama starpprogrammatūra?
Saskarnes ir pietiekamas. Šie trīs modeļi atšķiras ar to, kur notiek transformācija, nevis ar to, ko mēs pieņemam - mūsu saskarne pieņem neitrālu JSON shēmu neatkarīgi no tā, ar ko jūs to esat izveidojuši. Datu ieguve no modernas ERP sistēmas, notikumu plūsma un esošais integrācijas slānis - visi tie nonāk vienā un tajā pašā galapunktā. Starpprogrammatūra ir lietderīga, ja jūs to jau izmantojat un ja tā ir paredzēta līgumiskām saistībām ar trešajām personām. Ja šobrīd tādas nav, neiegādājieties to tikai produkta sertifikāta dēļ.
Ko izlemj kartēšanas darbnīcā?
Kura ERP lauka vērtība kļūst par atbilstošo lauka vērtību - un kura sistēma ir galvenais avots, ja vairākas sistēmas satur vienu un to pašu vērtību. Darbseminārs notiks 1. un 2. dienā, un tas ir visa projekta izšķirošais moments, jo tieši tur tiek pieņemti lēmumi par datu kvalitāti, nevis vēlāk programmēšanas procesā. Lūdzu, uzaiciniet dalībniekus, kuri uztur sistēmas, nevis tikai tos, kuri ir atbildīgi par projektu - pamatdati, ražošana, kvalitāte un iepirkumi reti atrodas vienā nodaļā. Viss, kas seko pēc tam, proti, eksportēšana, validēšana un kļūdu novēršana, ir praktisks darbs.
Mūsu sertifikāti ir pieejami tikai kā PDF skenējumi. Ko mums ar tiem darīt?
Skenējums nav strukturēts datu avots un tādēļ nav izmantojams pasē. Ir divi veidi, kā to izdarīt - sertifikācijas pakalpojumu sniedzēji arvien biežāk piedāvā API pieprasījumus, un, ja tādu nav, ievadiet vērtības ar rokām, taču vienmēr norādot derīguma termiņu, lai publicētajā pasē nepaliktu nekāds sertifikāts, kura derīguma termiņš ir beidzies. Plānojiet manuālo metodi kā atkārtotu darbu, nevis kā vienreizēju uzdevumu.
Vai mūsu IT nodaļa var pārbaudīt saskarni, pirms mēs kaut ko parakstām?
Jā. Pilnā shēma un visi galapunkti ir pieejami kā OpenAPI specifikācija vietnē API dokumentācija, kopā ar paraugpieprasījumiem, kļūdu atbildēm un autentifikācijas informāciju. Nekas no tā nav pieejams tikai pēc pārdošanas sarunas, tādējādi jūsu integrācijas komanda var novērtēt nepieciešamo darba apjomu, pirms līgums ir noslēgts. Ja pakalpojuma sniedzējs šajā posmā neparāda savu saskarni, arī tas ir atbilde.
Kas notiek ar mūsu datiem, ja mēs mainām pakalpojuma sniedzēju?
Tie tiek pārnesti. Saskarnes vietā, lai izmantotu patentētu formātu, tā pieņem neitrālu JSON shēmu, un visi jūsu dati tiek izvadīti CSV, XLSX, JSON-LD un SQL formātā vai izmantojot REST API. Tas ir apzināti - formāts, kuru jūs aizpildāt, ir pārnesams, tādējādi pāreja prasa tikai eksportēšanu, nevis jaunas datu bāzes izveidi. Uzdot katram pakalpojuma sniedzējam to pašu jautājumu pirms kartēšanas darbnīcas, jo pēc tam jūsu lauku nosaukumi tiks iekļauti viņa modelī.
Cik ilgi patiesībā ilgst pieslēgšanās?
Projektiem, kurus mēs atbalstām, tas aizņem divas nedēļas - divas dienas datu kartēšanai, trīs dienas līdz pirmajiem eksportiem, izmantojot mūsu validatoru, trīs dienas kļūdu novēršanai, divas dienas līdz pirmajiem publicētajiem pasēm. Garākais ceļš nekad nav kods, bet gan tas, ko atrod validators - trūkstoši lauki, nevienveidīgi kodējumi, vērtības, par kurām neviens nejūtas atbildīgs. Iekļaujiet šīs dienas plānā, nevis tās saīsiniet. Projekts, kas tās izlaiž, publicē arī šīs nepilnības.
Vai mums visi produkti jāpievieno vienlaikus?
Nē. Sāciet ar produktiem, kuriem vispirms nepieciešama atbilstība, un ar avota sistēmu - neitrālā shēma pieņem gan daļēju katalogu, gan pilnu katalogu, un importēšana ir atkārtojama, tādējādi turpmākie cikli atjaunina krājumus. Tādējādi kartēšanas darbs paliek pietiekami neliels, lai to varētu paveikt divās dienās. Turpmākā paplašināšana ir kartēšanas uzdevums, nevis jauns projekts.
