EDI še vedno poganja proizvodnjo - integrirajte se z njim, ne borite se proti njemu

Ploščice dokumentov na tekočem traku, ki napredujejo od PDF prek EDI in API do ERP

Če dobavljate velikemu trgovcu na drobno ali avtomobilski skupini v Evropi, uporabljate EDI. Ne zato, ker bi kdo obožaval sintakso EDIFACT, temveč zato, ker format izbere stran z večjim nabavnim oddelkom, njihov format pa je bil standardiziran leta 1988. Čakanje, da vam ponudijo REST API, ni strategija.

Kako dejansko izgleda sodobna postavitev EDI

Skrivnost je v tem, da EDI obravnavate kot transportno narečje, ne kot arhitekturo. Znotraj integracije je vse preprost, dobro tipiziran objekt naročila/odpreme/računa; EDIFACT in X12 obstajata le na skrajnem robu, v prevajalnikih, ki so dolgočasni, verzionirani in temeljito testirani s testnimi podatki.

Ta ločitev se izplača na tri načine:

  1. Vključitev novega poslovnega partnerja pomeni nov profil prevajalnika - različico sporočila, posebnosti segmentov, njihovo kreativno uporabo polj s prostim besedilom - ne nove poslovne logike.
  2. Testiranje je mogoče ponoviti. Vsaka kadarkoli prejeta partnerska datoteka je testni primer. Ko se prevajalnik spremeni, skozenj znova poženemo pet let prometa in primerjamo rezultat.
  3. 20 let star ERP in povsem nova spletna trgovina vidita isti objekt naročila, zato naročila EDI in naročila API tečejo skozi en sam cevovod z enim samim naborom pravil.

Nezanimivi deli, ki so pomembni

Potrditve so polovica protokola. Partner, ki v svojem časovnem oknu ne prejme sporočila CONTRL, bo predpostavil, da je naročilo izginilo, in poklical vašo prodajno ekipo. Zakasnitev potrditev nadzorujte enako, kot nadzorujete razpoložljivost - to je metrika, ki jo dejansko občuti nabavni referent vaše stranke.

EDI ni tehnični dolg. Je infrastruktura - kot tirna širina. Z modernizacijo se ga ne znebite; zgradite čiste adapterje in mu pustite, da še naprej zanesljivo počne to, kar počne že štiri desetletja.