Waarom EDI-integratie vastzit aan je oude ERP
EDI-koppelingen (Electronic Data Interchange) lijken bij de partner te horen. In de praktijk horen ze bij het systeem dat erachter zit.
Een klant die je een inkooporder stuurt, doet dat in een afgesproken formaat, met afgesproken identificaties, naar een afgesproken endpoint. Die identificaties komen uit je ERP. De artikelnummers, de klantcodes, de afspraken over eenheden en de btw-codes zijn allemaal de woordenschat van jouw systeem, één keer vertaald toen de koppeling werd gebouwd en sindsdien bevroren.
In die vertaling zitten meestal vier dingen:
- Productidentificaties: je artikelnummers gemapt op de eigen catalogusreferenties van de partner, artikel voor artikel
- Partner- en locatiecodes: welke klant, welk afleveradres, welke vestiging, uitgedrukt in codes die je ERP heeft uitgegeven
- Documentstructuur: welke velden verplicht zijn in een order, een verzendbericht of een factuur en in welke volgorde
- Validatieregels: wat de partner afwijst, inclusief toleranties op aantal, prijs en levervenster
Bij de meeste bedrijven staat dat nergens centraal gedocumenteerd. Het zit in de koppeling zelf en in het geheugen van degene die hem bouwde. Dat wordt een probleem zodra het systeem eronder verandert.
Wat er breekt als het ERP eronder verandert
Een nieuw ERP geeft zijn eigen identificaties uit. Artikelnummers veranderen, klantcodes veranderen en het datamodel waarop de oorspronkelijke mapping was gebaseerd, bestaat niet meer.
De fout is zelden spectaculair. Een order komt binnen en wordt afgewezen omdat een veld dat de partner verwacht nu leeg is. Een factuur wordt geaccepteerd en daarna betwist omdat de btw-code anders wordt gemapt. Een verzendbericht gaat de deur uit met een eenheid die de partner leest als dozen in plaats van pallets.
Deze problemen duiken één partner tegelijk op en dat maakt ze duur. Een bedrijf met tientallen EDI-partners krijgt niet één fout. Het krijgt een wachtrij ervan, elk met een andere persoon bij een ander bedrijf die een oplossing moet bevestigen.
Hetzelfde patroon geldt breder voor datamigratie, zoals beschreven in het migreren van ERP- en WMS-data met een integratieplatform. EDI is de variant waarbij iemand buiten je bedrijf akkoord moet gaan voordat er iets wordt opgelost.
Wat het herwerken van EDI-integratie echt kost
Het remappen is niet het dure deel. Een analist bouwt een mapping in een paar uur opnieuw. Wat het bedrijf kost, zit rond dat werk:
- Orders afgewezen aan de kant van de partner: door een ontbrekend veld bereikt de order je systeem nooit en de klant belt jou in plaats van zijn eigen EDI-team
- Facturen betwist in plaats van betaald: een btw-code die anders wordt gemapt, wordt een creditnota, een gesprek met finance en geld dat een maand later binnenkomt
- Je grootste klanten om een gunst gevraagd: EDI-wijzigingen vragen om tests aan partnerzijde, dus een systeemvervanging wordt een verzoek aan de bedrijven waaraan je probeert te verkopen
- Volgende keer hetzelfde werk: mappings die opnieuw worden gebouwd op het nieuwe ERP zitten daar net zo vast aan, dus de volgende vervanging kost hetzelfde
- Vervanging uitgesteld of vermeden: bedrijven met grote EDI-landschappen stellen systeemwijzigingen vaak uit vanwege wat het herwerk hen gaat kosten
Dat laatste is de echte prijs. EDI is dan geen technische verplichting meer, maar een reden om helemaal niet van systeem te wisselen.
Hoe een integratieplatform EDI-integratie afhandelt
Een iPaaS (integration Platform as a Service) geeft een bedrijf één plek waar al zijn systemen samenkomen. Elk systeem koppelt er één keer mee in plaats van rechtstreeks met elkaar en het platform verplaatst de data tussen hen en vormt die om. Bedrijven gebruiken het voor dagelijks werk: orders van de webshop naar het ERP, voorraad terug en verzenddata naar een vervoerder.
EDI draait op dezelfde opzet, met één verschil dat hier telt. De partner koppelt met het platform in plaats van met het ERP. De mapping tussen het formaat van de partner en jouw datamodel staat in het platform, niet in de koppeling, dus wat erachter verandert, verandert niet wat de partner ziet.
Het Alumio-integratieplatform biedt functies die je kunt configureren om EDI-koppelingen stabiel te houden tijdens een ERP-wissel:
- Het endpoint van de partner blijft staan: partners blijven naar dezelfde plek sturen in hetzelfde formaat, dus een vervanging achter het platform vraagt geen wijziging aan partnerzijde
- Mappings zijn zichtbaar en aanpasbaar: een Transformer bevat de vertaling tussen partnerformaten en jouw identificaties, dus remappen naar een nieuw ERP is een configuratiewijziging die je eigen team kan doen
- Beide systemen kunnen tegelijk draaien: stromen kunnen tijdens de overgang naar het oude en het nieuwe ERP wijzen, zodat niemand afhankelijk is van één omschakeldatum
- Je ziet wat elke partner stuurde: berichtlogs laten precies zien wat er binnenkwam en wat er werd teruggestuurd en dat beslecht een geschil met een partner in plaats van het te rekken
Alumio biedt ook een EDI Broker voor bedrijven die de koppeling liever laten beheren dan zelf bouwen. Hetzelfde principe geldt buiten EDI. AGU koppelt zijn Centric ERP via Alumio aan Adobe Commerce en Akeneo in plaats van rechtstreeks, met data die zo is genormaliseerd dat er later andere tools op kunnen worden aangesloten. Nieuwe kanalen kunnen er daarna bij als extra Routes zonder te herbouwen wat al draait.
Wat partneronafhankelijke EDI-integratie je oplevert
EDI wordt meestal behandeld als een verouderde verplichting die je onderhoudt omdat grote klanten erom vragen. Door die kijk komt het als laatste in het plan en als eerste in de vertraging.
Het ERP is evenmin het probleem. Een bedrijf moet het kunnen vervangen als het oude niet meer past en het grootste deel van dat project heeft het zelf in de hand. Wat de beslissing moeilijker maakt dan nodig, is dat het ERP vertalingen bevat voor systemen ver buiten zichzelf: de handelspartners, maar ook de webshop, het magazijn en de vervoerders. Door die vertalingen naar een integratielaag te verplaatsen, worden de twee gescheiden, zodat partners hun endpoint houden en het ERP weer gewoon een ERP is.
Wat het bedrijf krijgt, is een systeemlandschap dat het in zijn eigen tempo kan veranderen, waarin het vervangen van het ERP een project is in plaats van een onderhandeling en waarin EDI-integratie het systeem overleeft waarvoor ze oorspronkelijk is gebouwd.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
