Varför din EDI-integration är bunden till ditt gamla ERP-system
EDI-kopplingar (Electronic Data Interchange) ser ut att tillhöra partnern. I praktiken tillhör de det system som finns bakom dem.
En kund som skickar en inköpsorder till dig skickar den i ett överenskommet format, med överenskomna identifierare, till en överenskommen slutpunkt. Identifierarna kommer från ditt ERP-system. Artikelnummer, kundkoder, enhetskonventioner och momskoder är ditt systems vokabulär, översatt en gång när kopplingen byggdes och fryst sedan dess.
I den översättningen ingår oftast fyra saker:
- Produktidentifierare: dina artikelnummer mappade mot partnerns egna katalogreferenser, artikel för artikel
- Partner- och platskoder: vilken kund, vilken leveransadress, vilken filial, uttryckt i koder som ditt ERP-system har utfärdat
- Dokumentstruktur: vilka fält som är obligatoriska i en order, en leveransavisering eller en faktura och i vilken ordning
- Valideringsregler: vad partnern avvisar, inklusive toleranser för kvantitet, pris och leveransfönster
I de flesta företag finns inget av detta dokumenterat på ett ställe. Det finns i själva kopplingen och i minnet hos den som byggde den. Det blir ett problem i samma stund som systemet under förändras.
Vad som går sönder när ERP-systemet under byts
Ett nytt ERP-system utfärdar egna identifierare. Artikelnummer ändras, kundkoder ändras och den datamodell som den ursprungliga mappningen byggde på finns inte längre.
Felet är sällan dramatiskt. En order kommer in och avvisas eftersom ett fält som partnern förväntar sig nu är tomt. En faktura godkänns och bestrids sedan eftersom momskoden mappas annorlunda. En leveransavisering går ut med en enhet som partnern läser som kartonger i stället för pallar.
Felen dyker upp en partner i taget, och det är det som gör dem dyra. Ett företag med dussintals EDI-partner får inte ett fel. Det får en kö av dem, där varje fel kräver att en annan person på ett annat företag bekräftar en rättelse.
Samma mönster gäller datamigrering i stort, vilket beskrivs i migrering av ERP- och WMS-data med en integrationsplattform. EDI är varianten där någon utanför ditt företag måste godkänna innan något rättas.
Vad det verkligen kostar att göra om en EDI-integration
Ommappningen är inte den dyra delen. En analytiker bygger om en mappning på några timmar. Det som kostar företaget ligger runt det arbetet:
- Ordrar som avvisas hos partnern: ett saknat fält gör att ordern aldrig når ditt system, och kunden jagar dig i stället för sitt eget EDI-team
- Fakturor som bestrids i stället för betalas: en momskod som mappas annorlunda blir en kreditnota, ett samtal med ekonomi och pengar som kommer in en månad senare
- Dina största kunder ombedda om en tjänst: EDI-ändringar kräver tester hos partnern, så ett systembyte blir en begäran till just de företag du försöker sälja till
- Samma arbete nästa gång: mappningar som byggs om mot det nya ERP-systemet är lika hårt bundna till det, så nästa byte kostar lika mycket
- Bytet skjuts upp eller undviks: företag med stora EDI-landskap skjuter ofta upp systembyten på grund av vad omarbetet kommer att kosta
Det sista är det verkliga priset. EDI slutar vara en teknisk skyldighet och blir ett skäl att aldrig byta system.
Så hanterar en integrationsplattform EDI-integration
En iPaaS (integration Platform as a Service) ger ett företag en plats där alla dess system kopplas ihop. Varje system ansluts en gång i stället för direkt till de andra, och plattformen flyttar och omformar data mellan dem. Företag använder den för vardagligt arbete: ordrar från webbshoppen till ERP-systemet, lager tillbaka och leveransdata till en transportör.
EDI fungerar enligt samma upplägg, med en skillnad som spelar roll här. Partnern ansluter till plattformen i stället för till ERP-systemet. Mappningen mellan partnerns format och din datamodell ligger i plattformen, inte i kopplingen, så att byta det som finns bakom ändrar inte det partnern ser.
Integrationsplattformen Alumio har funktioner som kan konfigureras för att hålla EDI-kopplingarna stabila genom ett ERP-byte:
- Partnerns slutpunkt ligger kvar: partnerna fortsätter skicka till samma ställe i samma format, så ett byte bakom plattformen kräver ingen ändring hos partnern
- Mappningar är synliga och redigerbara: en Transformer innehåller översättningen mellan partnerformat och dina identifierare, så ommappning mot ett nytt ERP-system är en konfigurationsändring som ditt eget team kan göra
- Båda systemen kan köras samtidigt: flöden kan peka mot både det gamla och det nya ERP-systemet under övergången, så ingen är beroende av ett enda bytesdatum
- Du ser vad varje partner skickade: meddelandeloggar visar exakt vad som kom in och vad som skickades tillbaka, vilket avgör en tvist med en partner i stället för att förlänga den
Alumio erbjuder också en EDI Broker för företag som hellre vill få kopplingen hanterad än bygga den själva. Samma princip gäller utanför EDI. AGU kopplar sitt Centric ERP till Adobe Commerce och Akeneo via Alumio i stället för direkt, med data som normaliserats så att fler verktyg kan anslutas senare. Nya kanaler kan sedan läggas till som extra Routes utan att det som redan körs byggs om.
Vad en partneroberoende EDI-integration ger dig
EDI behandlas oftast som en ärvd skyldighet som underhålls eftersom stora kunder kräver det. Den synen är anledningen till att det hamnar sist i planen och först i förseningarna.
ERP-systemet är inte heller problemet. Ett företag ska kunna byta ut det när det gamla inte längre passar, och det mesta av det projektet har företaget själv kontroll över. Det som gör beslutet svårare än det borde vara är att ERP-systemet till slut innehåller översättningar för system långt utanför sig självt: handelspartnerna, men också webbshoppen, lagret och transportörerna. Att flytta de översättningarna till ett integrationslager skiljer de två åt, så att partnerna behåller sin slutpunkt och ERP-systemet återigen bara är ett ERP-system.
Det företaget får är ett systemlandskap som det kan förändra i sin egen takt, där ett ERP-byte är ett projekt i stället för en förhandling och där EDI-integrationen överlever det system den ursprungligen byggdes för.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
