EDI driver stadig fremstillingsindustrien - integrer med det, kæmp ikke imod det

Dokumentbrikker på et transportbånd, der bevæger sig fra PDF til EDI til API til ERP

Hvis du leverer til en stor detailkæde eller automotive-koncern i Europa, bruger du EDI. Ikke fordi nogen elsker EDIFACT-syntaks, men fordi parten med den største indkøbsafdeling vælger formatet, og deres format blev standardiseret i 1988. At vente på, at de tilbyder et REST-API, er ikke en strategi.

Sådan ser en moderne EDI-opsætning faktisk ud

Tricket er at behandle EDI som en transportdialekt, ikke en arkitektur. Inde i integrationen er alt et almindeligt, veltypet order-/forsendelses-/fakturaobjekt; EDIFACT og X12 findes kun helt ude i kanten, i translatorer der er kedelige, versionerede og grundigt testet på optagne eksempelfiler.

Den adskillelse betaler sig på tre måder:

  1. At onboarde en ny handelspartner betyder en ny translatorprofil - beskedversion, segment-særheder, deres kreative brug af fritekstfelter - ikke ny forretningslogik.
  2. Test kan afspilles igen. Hver eneste partnerfil, der nogensinde er modtaget, fungerer som testeksempel. Når en translator ændres, kører vi fem års trafik igennem den igen og diff'er output.
  3. Det 20 år gamle ERP-system og den splinternye webshop ser det samme ordreobjekt, så EDI-ordrer og API-ordrer flyder gennem én pipeline med ét sæt regler.

De ugalante dele, der betyder noget

Kvitteringer er halvdelen af protokollen. En partner, der ikke modtager sin CONTRL-besked inden for sit tidsvindue, vil antage, at ordren er forsvundet, og ringe til dit salgsteam. Overvåg kvitteringsforsinkelse på samme måde, som du overvåger oppetid - det er den måling, din kundes indkøbsmedarbejder rent faktisk mærker.

EDI er ikke teknisk gæld. Det er infrastruktur - ligesom sporvidde. Man slipper ikke af med det gennem modernisering; man bygger rene adaptere og lader det blive ved med at gøre det, det har gjort pålideligt i fire årtier.