Jos toimitat tavaraa suurelle vähittäiskauppiaalle tai autoteollisuuskonsernille Euroopassa, käytät EDI:tä. Ei siksi, että kukaan rakastaisi EDIFACT-syntaksia, vaan siksi, että osapuoli, jolla on isompi ostoosasto, valitsee formaatin, ja heidän formaattinsa standardoitiin vuonna 1988. Sen odottaminen, että he tarjoaisivat REST-rajapinnan, ei ole strategia.
Miltä moderni EDI-ratkaisu oikeasti näyttää
Temppu on kohdella EDI:tä kuljetusmurteena, ei arkkitehtuurina. Integraation sisällä kaikki on yksinkertainen, hyvin tyypitetty tilaus-/lähetys-/laskuobjekti; EDIFACT ja X12 elävät vain aivan reunalla, kääntäjissä, jotka ovat ikävystyttäviä, versioituja ja perusteellisesti testattuja tallennetuilla esimerkkitiedostoilla.
Tämä erottelu maksaa itsensä takaisin kolmella tavalla:
- Uuden kauppakumppanin käyttöönotto tarkoittaa uutta kääntäjäprofiilia - sanomaversiota, segmenttien erikoisuuksia, heidän luovaa vapaatekstikenttien käyttöään - ei uutta liiketoimintalogiikkaa.
- Testaus on toistettavissa. Jokainen koskaan vastaanotettu kumppanitiedosto tallennetaan testiesimerkiksi. Kun kääntäjä muuttuu, ajamme viiden vuoden liikenteen sen läpi uudelleen ja vertaamme tulostetta.
- 20 vuotta vanha ERP ja upouusi verkkokauppa näkevät saman tilausobjektin, joten EDI-tilaukset ja API-tilaukset kulkevat saman putken läpi samoilla säännöillä.
Arkiset osat, joilla on väliä
Kuittaukset ovat puolet protokollasta. Kumppani, joka ei saa CONTRL-sanomaansa ajoikkunansa sisällä, olettaa tilauksen kadonneen ja soittaa myyntitiimillesi. Valvo kuittausten viivettä samalla tavalla kuin valvot käytettävyyttä - se on mittari, jonka asiakkaasi ostaja oikeasti kokee.
EDI ei ole teknistä velkaa. Se on infrastruktuuria - kuten raideleveys. Siitä ei päästä eroon modernisoimalla; sen eteen rakennetaan siistit sovittimet ja annetaan sen jatkaa tekemistä, jota se on tehnyt luotettavasti neljä vuosikymmentä.