TRUSTED BY
:quality(75)){kind=logo}
Plattformen är vald, designen är godkänd, lanseringsdatumet står i kalendern. Och så fastnar allt i kopplingen mot affärssystemet. Igen.
De flesta e-handelsprojekt kraschar inte i frontend. De kraschar i integrationslagret.
Du har sett det. Projektet rullar enligt plan tills någon ska koppla produktdata, lager och order mot ERP:et — och plötsligt är tre veckors buffert uppäten. Det är inte otur. Det är ett mönster.
ERP-integrationen är osynlig i en pitch. Ingen demar ett orderflöde mot affärssystemet på en mässa. Det betyder att den nästan alltid prioriteras ned i planeringen — och dyker upp som ett problem först under test, när tidplanen redan är komprimerad.
Siffrorna är obekväma. Mellan 55 och 75 procent av ERP-projekt missar sina ursprungliga mål, och vanligaste orsaken till förseningar är tekniska problem som uppstår sent i processen [källa: https://kpcteam.com/kpposts/unveiling-the-erp-conundrum-why-55-75-of-erp-projects-fail]. När integrationer inte identifieras tidigt så ytar de under testfasen — där rework och oplanerade kostnader är som dyrast [källa: https://www.shopify.com/uk/enterprise/blog/failed-erp-implementation].
Problemet är konceptuellt, inte tekniskt. Team behandlar integrationen som ett rör mellan två system. Den är snarare en översättning mellan två olika sätt att se på världen — affärssystemets transaktionsmodell mot e-handelns kundupplevelse.
När vi gör en teknisk genomlysning av en haverad integration är det nästan alltid samma tre saker som återkommer:
1. Man synkar allt, hela tiden. Full synk av hela produktkatalogen var femtonde minut, oavsett om något ändrats. Det fungerar med 2 000 artiklar och faller ihop vid 200 000. Synka deltan, inte hela världen.
2. ERP:et får vara sanningskälla för fel saker. Affärssystemet äger pris, lager och order — bra. Men när det också ska äga produktbeskrivningar, bilder och kategoriträd blir varje innehållsändring ett IT-ärende. Skilj på transaktionsdata och presentationsdata.
3. Ingen äger felhanteringen. Vad händer när en order inte når ERP:et? Om svaret är "den försvinner" eller "någon ser det i loggen om en vecka" har du ingen integration. Du har en tidsinställd bomb. Idempotens, retries och dödsbrevkö är inte nice-to-have.
Det fjärde felet — som egentligen ligger bakom de andra tre — är att man bygger integrationen en gång och sedan rör den aldrig igen.
Swedish Lorry Parts är ett B2B-bolag med ett stort sortiment av reservdelar, där produktdata och tillgänglighet måste stämma exakt mot affärssystemet. För den typen av verksamhet är en stabil ERP–e-handelsintegration inte en feature — det är förutsättningen för att över huvud taget kunna handla online.
Vi har sett hur starka kopplingar mellan affärssystem och e-handel förbättrar effektiviteten i den här typen av sortiment. [BEKRÄFTA: specifika resultat/siffror för Swedish Lorry Parts] Poängen är generell. När lager, pris och leveranstid kommer korrekt från källan slipper kundtjänst släcka bränder, och kunden slipper beställa något som inte finns.
Det som gör skillnad är inte vilket ERP de kör. Det är att integrationen är byggd för att hantera verkligheten — partiella fel, säsongstoppar och sortiment som ändras dagligen.
Här ligger den verkliga skiljelinjen. Den monolitiska modellen behandlar integrationen som en kostnad du betalar en gång vid lansering. Den pre-composed modellen behandlar den som en levande modul som ska underhållas, versionshanteras och bytas ut.
Callisto bygger på Norce Commerce, som är konstruerat för det här. Norce Commerce Connect är ett dedikerat integrationsramverk för stora dataimporter, batch-bearbetning och just ERP-kopplingar — order, lager, fakturor och leveransnotor — över REST och med OAuth2 [källa: https://docs.norce.io/developer-portal/system-integration/calling-norce-commerce-connect]. Produktdata och order mot affärssystemet hanteras alltså i ett lager som är byggt för uppgiften, inte hopsnickrat vid sidan av.
Det API-first-tänket ger tre konkreta fördelar:
Byt en del utan att riva resten. Byter du ERP rör du integrationsmodulen — inte hela e-handeln.
Versionshantering och test. En modul med tydliga kontrakt går att testa isolerat. Ett hopkok av punkt-till-punkt-skript gör det inte.
Skalbarhet utan omskrivning. Deltasynk och köbaserad orderhantering tål volym på ett sätt som schemalagda totalsynkar aldrig gör.
Skillnaden mellan dessa två modeller är skillnaden mellan ett projekt som lever och ett som ärver teknisk skuld från dag ett.
Innan du skriver en rad integrationskod — eller godkänner en offert som påstår sig täcka detta — gå igenom det här:
1. Vem äger vilken data? Skriv ner exakt vilket system som är sanningskälla för pris, lager, order, produkttext och bild.
2. Vad är synkfrekvensen — och är det delta eller full? Definiera per dataslag, inte som en generell inställning.
3. Vad händer vid fel? Beskriv konkret flödet för en misslyckad order. Finns retries, idempotens och en kö?
4. Hur testas integrationen isolerat? Om svaret kräver att hela plattformen är uppe är kopplingen för hårt bunden.
5. Vad kostar det att byta ERP om tre år? Om svaret är "vi bygger om allt" har du valt fel arkitektur.
Kan du inte svara på dessa fem frågor är det inte plattformen som är din risk. Det är integrationen.
1. Behandla ERP-integrationen som projektets högsta risk från dag ett — inte som en detalj i slutfasen.
2. Skilj transaktionsdata från presentationsdata, och låt rätt system äga rätt sak.
3. Synka deltan, bygg för fel, och gör felhanteringen till någons uttalade ansvar.
4. Välj en arkitektur där integrationen är en utbytbar modul — inte en gång gjuten i betong.
Den mest underskattade frågan i ett e-handelsprojekt är inte "vilken plattform?". Det är "vad händer med ordern om affärssystemet säger nej klockan 14:32 en fredag?". Har du inget bra svar — då vet du var nästa projekt riskerar att dö.
Vi har byggt de här flödena tidigare, och vi gör det gärna med dig.
:quality(75))
Adán Hultgren
Chief Growth Officer
Vill du ta ditt e-handelsföretag till nästa nivå eller har du frågor om våra tjänster? Tveka inte att kontakta oss.
