Så delar ni ansvaret mellan e-handel och affärssystem

En säljare lovar leverans på en artikel som ser tillgänglig ut i kundportalen, men kundservice ser ett annat saldo i affärssystemet och webben visar ett tredje.

Det brukar börja som små avvikelser. Sedan blir det ett mönster, särskilt när flera kanaler delar på samma data och ingen har tydligt ansvar för vad som är master. I företagens e-handel bedrev 36,7 procent av företag med minst tio anställda e-handelsförsäljning under 2024 enligt SCB, och större bolag drev den delen av affären betydligt oftare än små.

Så ser en vanlig svensk e-handelskedja ut i praktiken

Därför behöver kedjan beskrivas från början till slut. Affärssystemet håller grunddata. PIM förädlar produktinnehåll. E-handelsplattformen visar det mot kund. Portalerna ger inloggad självservice med avtal, orderstatus och dokument.

När ansvarsfördelningen är oklar uppstår det som äter tid i drift. Någon uppdaterar artikeltexter på fel ställe. Någon prisfil kommer in för sent. Någon order måste stämmas av manuellt. Följdfelen, med rättelser och avstämningar, tar ofta mer tid än själva synken.

Det syns också i svensk statistik. Företag med minst tio anställda omsatte 2 718 miljarder kronor via webbförsäljning och EDI under 2024, enligt SCB:s företagsstatistik, och även konsumentledet är omfattande enligt Svensk Handels E-handelsindikator för helåret 2024. När kanalerna redan bär så mycket affärsvolym blir datakvalitet en central del av driften.

Artikelnummer och ekonomiska attribut bör ha sitt master i affärssystemet och synkas vid ändring och vid publicering till PIM, e-handel och portal. Produkttexter och bilder bör ägas i PIM och skickas vidare vid publicering till e-handel och portal. Pris och avtal bör styras från affärssystemet och föras över vid ändring eller enligt schema till e-handel och portal. Lagersaldo bör också ägas i affärssystemet och synkas tätt, eller händelsestyrt för kritiska artiklar, till e-handel och portal. Order och orderstatus kan ha olika master beroende på flöde, men behöver skickas direkt eller i batch till lager, ekonomi och kundservice.

Vad affärssystem, PIM, e-handel och portal faktiskt gör

I många projekt blandas rollerna ihop redan i kravställningen. Då blir varje integration tyngre än den behöver vara, och fel uppstår ofta först när flera team försöker äga samma fält. En bättre modell börjar med att varje system får ett tydligt ansvar.

Affärssystemet håller det som måste vara rätt för att affären ska fungera. Det gäller artikelnummer, lagersaldo, inköpspris och ekonomiska attribut. PIM håller produktinnehållet som ska publiceras i flera kanaler, alltså beskrivningar, bilder, språk, tekniska specifikationer och relationer. E-handelsplattformen visar katalog, kundvagn, kassan och presentation. Portalen hanterar inloggning, kundunika villkor, dokument och självservice.

En artikel skapas först i affärssystemet. Där finns ekonomi, lagerlogik och grunden till sortimentet. Sedan skickas produktdata till PIM, där marknadsanpassad text, media och språk läggs till. Efter det publiceras informationen till webb, kundportal och återförsäljarportal.

Det är ofta här projekt går fel i onödan. När PIM får bära ekonomiska fält blir redaktörsarbetet riskabelt. När affärssystemet får bära hela produktberättelsen blir innehållet stelt. När e-handelsplattformen får lagra för mycket logik blir uppgraderingar besvärliga.

För ett tillverkande bolag i Sverige är gränsen därför ganska enkel. Affärssystemet ska äga de värden som styr transaktioner. PIM ska äga det som styr presentation och kanalpublicering. Plattformen ska visa och ta emot order. Portalen ska ge åtkomst till rätt innehåll för rätt kund.

Integrationslagret ska förmedla, validera och logga. Om samma regel behöver finnas i tre system har designen redan tappat riktning.

Det blir tydligt i svensk e-handel. Kanalerna kombineras ofta, så integrationen måste tåla flera vägar ut. Därför fungerar tydlig ansvarsfördelning bättre än att försöka flytta allt till en enda applikation. När verksamheten mäter nytta behöver ni följa om fel minskar, manuella korrigeringar försvinner och orderflödet blir enklare att driva. I praktiken syns det ofta tydligast i hur ERP och integrationer hänger ihop i ett styrt flöde.

Fyra integrationsmönster som styr hela kedjan

När ett projekt går från pilot till drift brukar samma fyra flöden återkomma. Det gäller produktdata, priser och avtal, lagersaldo och orderflöden. Resten är variationer på de mönstren.

Produktdata ska nästan alltid styras centralt. Artikelnummer, enheter, varianter och tekniska attribut ska inte uppdateras på flera håll. När samma fält redigeras i webbplattformen och i affärssystemet får ni förr eller senare en artikel som är rätt i ena kanalen och fel i den andra.

Det vanliga felet är att produkttexter blandas ihop med masterdata. Då blir ändringar svåra att testa. En rubrikändring kan råka påverka prislogik eller exportformat. Det är onödigt och svårt att felsöka.

Prislistor ska hämtas från systemet som äger affärsvillkoren. Läggs de dubbelt i plattformen blir det snabbt oklart vilken version som gäller. Det gäller särskilt när kundunika priser och avtal behöver vara synliga i portal eller inloggat läge.

Här är manuell hantering nästan alltid dyrare än den ser ut. En felaktig rabatt skadar marginalen. En sen prisuppdatering skadar förtroendet. En lokal korrigering skapar bara fler undantag nästa gång.

Lagersaldo kräver mer eftertanke än produkttext. För vissa sortiment räcker batchöverföring. För andra behöver synken vara tät eller händelsestyrd. Det beror på hur snabbt artiklar säljer och hur stor risk en felaktig visning innebär.

Det som brister i praktiken är ofta toleransen för avvikelser över tid. Om saldot får avvika för länge ser kunden en vara som redan är slut. Då börjar supporten ta samtal som borde ha undvikits.

Orderflödet måste klara mer än att skicka vidare en beställning. Bekräftelse, plock, faktura och retur ska kunna röra sig genom kedjan utan dubbelregistrering. Annars lägger ekonomin tid på avstämning och kundservice på efterhandsförklaringar.

Här blir integrationens kvalitet väldigt konkret. Antingen följer ordern med hela vägen eller så fastnar den i ett mellanläge som kräver mänsklig handpåläggning. Det senare låter litet i uppstarten och blir dyrt i drift.

Läs mer om hur ett styrt integrationsflöde byggs upp.

Välj rätt nivå av realtid

Många beställare utgår från att allt ska gå direkt. Det låter tryggt. Realtid är rätt för vissa lagersaldon och kundunika orderflöden, men överdriven snabbhet skapar också fler felkällor.

Produkttexter, bilder och strukturerade beskrivningar behöver sällan pressas igenom i realtid. Där fungerar stabil överföring bättre. Samma sak gäller prislistor som styrs av planerade uppdateringar. Ni vinner ofta mer på kontroll än på millisekunder.

Det här syns tydligt i vardagen. Ju fler små ändringar som skickas direkt, desto svårare blir felsökningen när något avviker. Då måste någon avgöra vilken version som vann, och varför.

Lagersaldo på kritiska artiklar behöver tätare uppdatering. Detsamma gäller orderflöden där kundunika villkor eller snäva leveranstider ingår. Där kostar en sen uppdatering ofta mer än en extra integrationshändelse.

En bra tumregel är enkel. Synka snabbt där ett fel skadar affären direkt. Synka lugnare där innehållet främst beskriver sortimentet. Det ger lägre komplexitet och bättre kontroll.

Därför blir en gemensam datamodell en konkurrensfråga

Affärskunder jämför leverantörer utifrån tydlighet, tillgänglighet och hur enkelt det är att göra rätt beställning. När produktdata, pris och leveransvillkor håller ihop blir det lättare att inge förtroende genom hela köpresan. När uppgifterna spretar ökar osäkerheten direkt, särskilt när kunden ska jämföra flera alternativ för samma behov.

Jämförelsen sker dessutom allt oftare över landsgränser. Andelen svenska konsumenter som e-handlade från utlandet var 23 procent i augusti 2025 enligt Svensk Handels augustirapport, och i novemberrapporten hade andelen stigit till 27 procent. Även affärskunder har nära till alternativ när informationen hos en leverantör brister.

Det betyder att produktdata, pris och leveransvillkor måste hålla ihop där kunden jämför. Om lagersaldot är osäkert eller produktinformationen är spretig väljer kunden en leverantör som upplevs tydligare.

Det spelar ingen roll hur snygg integrationen ser ut i projektmötet. Om en produkt saknar rätt enhet, om priset inte matchar eller om leveranstiden är osäker, då blir upplevelsen svag direkt. Kunden ser resultatet av era systemval utan att bry sig om era systemnamn.

Det är därför en gemensam produkt- och ordermodell blir ett affärsbeslut. När modellen är tydlig går det att återanvända samma innehåll i webb, portal och återförsäljarflöden utan att bygga om varje gång.

Det här hänger nära ihop med struktur i produktdata, särskilt när flera kanaler ska läsa samma information men visa den olika.

Så förändrar en produktiserad leverans tid, pris och risk

När leveransen byggs av färdiga, testade komponenter blir kalkylen tydligare. Att börja med återanvändbara byggblock ger en annan styrning än att börja varje integration från noll. Färdiga funktionsblock gör också att samma grund kan användas igen när ni bygger vidare.

Glanser arbetar med ett Funktionsbibliotek där funktioner och integrationer levereras i tre nivåer, Standard, Anpassad och Kundunik. Den kundunika delen isoleras så att den inte påverkar resten vid uppgraderingar. För projekt där integrationer ska följa med över tid betyder det att scope och ansvar blir tydligare från början.

När arbetet delas upp i återanvändbara funktioner slipper ni förhandla om varje liten koppling. Det gör estimatet mer begripligt och minskar risken för att en förändring i en kanal sprider sig till andra delar. Det är särskilt viktigt i miljöer där affärssystemet styr flera flöden samtidigt.

Vi arbetar med Litium, Optimizely och Magento och är Premium Solution Partner till Litium. För integrationsfrågor mot affärssystem som Business Central, Monitor och Jeeves går det att bygga vidare på samma grund i stället för att starta om. Det sparar framför allt osäkerhet när lösningen ska vidareutvecklas efter go-live.

Leveransmodellen beskrivs mer utförligt i vårt whitepaper om att gå från projekt till produkt.

Det fungerar bäst när ni vill börja med en lösning och bygga vidare på samma grund. Det fungerar också bra när ni har flera kanaler som ska dela produkt- och orderdata. Då blir återanvändning av funktioner en praktisk fördel.

Det passar sämre om varje kanal måste ha helt egen logik i varje steg. Då blir det svårt att hålla komponenter kompatibla över tid. Det är bättre att vara rak med det från början än att låtsas att allt går att paketera.

Kompatibilitet och produktansvar är en del av TCO

Många kalkyler stannar vid införandet. Det är fel slutpunkt. Den stora kostnaden ligger ofta i förvaltning, uppgraderingar och i det som händer när integrationen bryts av en ny release.

När en e-handelsplattform eller ett affärssystem uppgraderas måste kopplingar och funktioner fortsätta fungera. Om ansvar saknas får kunden ofta ta nästa offert i stället för att få ett kontrollerat versionssteg. Det gör TCO svår att styra.

Glanser Care är ett avtalat ansvar till fast månadskostnad. Det omfattar versionsuppföljning, kompatibilitet genom uppgraderingar och buggrättning, utan ny offert vid uppgradering. Den typen av åtagande ändrar kalkylen eftersom förvaltning då blir planerad och förutsägbar.

Det är också där många projekt blir dyrare än väntat. Ofta händer det när ingen äger lösningen över tid. Då blir varje release ett nytt litet projekt med egen risk.

Vad upplägget kräver och vad ni bör fråga

Det här upplägget kräver att ni äger er produktdata ordentligt. Det kräver också att ni accepterar att delar av funktionaliteten levereras i färdiga block. Då blir lösningen lättare att förvalta och enklare att bygga vidare på.

Det passar sämre om er affär bygger på helt oregelbunden logik i varje kanal. Det passar också sämre om ingen i organisationen äger masterdata i affärssystemet. Utan det ansvaret blir integrationen bara ett nytt lager av otydlighet.

Tre frågor att ställa leverantören

Hur hanterar ni kompatibilitet vid nästa plattforms- och affärssystemuppgradering? Svaret visar snabbt om leverantören har en modell för långsiktigt ansvar eller främst arbetar från projekt till projekt.

Hur är ert funktionsbibliotek prissatt och uppdaterat? Svaret visar om återanvändning faktiskt ger styrbar kostnad och tydlig vidareutveckling över tid.

Hur mäter ni att integrationen faktiskt förbättrar verksamheten? Svaret visar om leverantören följer upp affärsnytta i drift eller stannar vid att leverera teknik.

Om ni vill se hur ett nuläge, en funktionsspecifikation och en komplett kostnadsbild kan tas fram utan att börja i ett stort projekt, använd Glanser 72h-analys. Ni avsätter två timmar för ett möte och får inom 72 timmar en inventering av funktionalitet och integrationer, en funktionsspecifikation, en prototyp och en komplett kostnadsbild med tidsplan, kostnadsfritt och med ert underlag som utgångspunkt.