Ni behöver en styrd ERP-integration

En prislista ändras i affärssystemet på förmiddagen. Samtidigt lägger en kund en order på webben utifrån det gamla priset. Kundservice ser en uppgift, sälj en annan och lagret en tredje. Ingen enskild avvikelse ser stor ut, men tillsammans blir de ett dyrt driftproblem.

Samma sak händer när lagerstatus publiceras för sent, när en utfasad produktvariant ligger kvar i webbshoppen eller när en order fastnar i manuell hantering mellan portal och ERP. Felet ser ofta tekniskt ut på ytan, men orsaken är vanligtvis större än så. Det handlar om vilket system som äger vilken data, hur förändringar får slå igenom och vem som ansvarar när flödet bryts.

Det är därför ERP-integration inte bara är en fråga om anslutning. För företag avgör den om webb, kundportal och interna processer faktiskt utgår från samma produkt-, pris-, lager- och orderdata över tid.

Er webb och er verksamhet måste dela samma verklighet

När digitala kanaler och affärssystem inte är synkade märks det snabbt i kundupplevelsen. En kund ser ett pris på webben, men får ett annat i orderbekräftelsen. En säljare lovar leverans utifrån ett lagersaldo som redan har förändrats. Ekonomi behöver reda ut differenser som aldrig borde ha uppstått från början. Problemen uppstår inte bara i gränssnittet mot kunden, utan i samspelet mellan försäljning, lager, kundservice och administration.

Det går att bygga en välfungerande innehållssajt utan tät koppling till kärnsystemen. Men så snart webbplatsen ska bära orderflöden, kundunika priser, lagersaldo eller inloggade portalfunktioner räcker det inte med att systemen är anslutna till varandra på pappret. De måste också vara överens om vad data betyder, när den uppdateras och hur fel fångas upp. Annars blir dubbelregistrering, manuella korrigeringar och undantagshantering en del av vardagen.

I praktiken är den viktigaste frågan sällan om en integration går att få upp tekniskt. Den viktiga frågan är om den går att styra och förvalta när prislogik, produktstruktur, kanalstrategi och orderprocesser förändras. Därför bör webb och affärssystem ses som delar av samma styrkedja, inte som två separata projekt. Det gäller särskilt i kundportaler där användaren förväntar sig att se samma information som interna team arbetar med. ERP-integration blir därmed en styrningsfråga lika mycket som en teknikfråga. Om ansvar, ägarskap och datadefinitioner är otydliga kommer avvikelserna förr eller senare att synas i kundresan.

Försäljning med kundunika villkor ställer högre krav

Svenska företag använder redan affärssystem i hög grad. År 2023 använde 58,6 procent av svenska företag ERP-programvara för att dela information mellan funktionella områden, medan andelen var 67,3 procent i Danmark, 56,9 procent i Finland och 43,3 procent i EU totalt, enligt Eurostat. Det betyder inte att informationsflödena redan fungerar väl mellan alla kanaler. Det betyder att många företag redan har en central källa som måste kopplas rätt mot webb, PIM, kundportal, BI och andra system.

Samtidigt skiljer sig användningen tydligt mellan olika företagsstorlekar. Eurostat redovisar att 38 procent av små företag i EU använde ERP 2023, medan 86 procent av stora företag gjorde det, en skillnad på 48 procentenheter enligt Eurostats nyhet. För större företag innebär det ofta fler bolag, fler varumärken, fler prislistor och fler försäljningskanaler som behöver dela data utan att olika delar av organisationen bygger sina egna sanningar.

I svensk handel tillkommer ofta krav som gör enkla standardlösningar otillräckliga. Det kan handla om kundunika prislistor, återförsäljarkonton, olika lagersaldon per plats, sortiment som skiljer sig mellan marknader och order som ska behandlas olika beroende på kanal eller kundtyp. När webb, portal och intern försäljning inte använder samma masterdata uppstår inte bara merarbete, utan också oklarhet kring vem som faktiskt har ändrat vad och varför.

SCB visar också att 36,7 procent av svenska företag med minst tio anställda bedrev e-handel under 2024, och att 31,2 procent sålde via webben medan 11,2 procent använde EDI och 5,7 procent använde båda metoderna, enligt SCB:s statistiknyhet om it-användning i företag 2025. Det visar varför samma affärsdata ofta måste bära flera tekniska flöden samtidigt. En webborder, en portalbeställning och en EDI-order kan vara olika på ytan, men de måste ändå bottna i samma artikeldata, samma prislogik och samma kundinformation.

Det är därför integrationsarbete i verksamheter så ofta handlar om affärsregler, ansvar och processdesign. Tekniken behöver stödja den faktiska försäljningen, inte tvinga verksamheten att anpassa sig till ett för enkelt upplägg för integrationer mellan webb och affärssystem.

Arkitekturen påverkar kostnad, kontroll och förändringstakt

När företag planerar ERP-integration återkommer i praktiken tre huvudmönster. Det första är punkt-till-punkt, där varje kanal kopplas direkt mot affärssystemet eller mot ett annat enskilt system. Det andra är ett gemensamt integrationslager, ofta beskrivet som middleware, där flera system ansluter till samma mellanhand. Det tredje gäller hur flödena körs, antingen i batch med periodiska uppdateringar eller i realtid när data måste vara direkt uppdaterad.

Punkt-till-punkt kan vara snabbt att få på plats i början. Om ni bara har en webbplats och ett affärssystem kan det verka som den enklaste vägen. Problemet kommer när fler kanaler, varumärken eller portaler ska anslutas. Varje ny koppling skapar ytterligare ett beroende som måste förstås, testas och underhållas. När prislogik ändras eller lagerstruktur byggs om behöver flera relationer uppdateras samtidigt. Med tiden blir det dyrt att bära, inte för att själva anslutningen är omöjlig utan för att varje kanal riskerar att börja tolka data på sitt eget sätt.

Ett gemensamt integrationslager ger oftast bättre kontroll när flera kanaler ska använda samma datagrund. Där kan validering, transformation, logik och felhantering återanvändas mellan olika webbplatser, portaler och interna system. Det ställer högre krav på modellering och styrning från början, men gör det lättare att förvalta lösningen när organisationen växer eller processerna förändras. Om affärssystemet är källa för pris, lager och orderstatus blir det enklare att låta andra kanaler hämta rätt data via kontrollerade kontrakt i stället för att varje kanal bygger sin egen tolkning. Läs mer i vårt whitepaper om ERP-first integrationsstrategi.

Valet mellan batch och realtid bör också utgå från affärsbehovet. Batchflöden passar där stora datamängder kan uppdateras vid bestämda tidpunkter utan att användaren påverkas direkt, till exempel vid delar av produktberikning eller vissa nattliga synkroniseringar. Realtidsflöden passar där kunden eller säljaren förväntar sig omedelbar respons, till exempel vid prisfrågor, orderläggning, kreditkontroll eller visning av tillgänglighet. Realtid är inte automatiskt bättre i alla lägen. Det kräver tydliga regler, högre övervakning och en mer robust hantering av fel och återförsök.

Det avgörande är därför inte att välja den arkitektur som verkar modernast, utan den som ger er bäst balans mellan dataaktualitet, förvaltningsbarhet och förändringstakt. Ju fler kanaler som ska dela samma affärsdata, desto viktigare blir ett integrationsupplägg som går att styra centralt.

Interoperabilitet kräver mer än att systemen kan prata med varandra

Digg beskriver interoperabilitet som förmågan att tillhandahålla eller ta del av data genom system som interagerar med varandra, och pekar på att båda systemen måste följa samma standarder för datautbyte, till exempel öppna API:er och maskinellt överförbara format. För ett företag som ska koppla samman ERP, webb, portal och kringliggande system räcker det därför inte att anslutningen fungerar rent tekniskt. Systemen måste också dela förståelse för datans struktur, betydelse och användning.

Diggs modell är användbar eftersom den delar upp interoperabilitet i fyra nivåer. Teknisk interoperabilitet handlar om att anslutningen faktiskt fungerar mellan systemen. Syntaktisk interoperabilitet handlar om att formatet går att läsa och tolka korrekt. Semantisk interoperabilitet handlar om att samma begrepp verkligen betyder samma sak, till exempel enhet, valuta, moms, rabattstruktur, kundnummer eller lagerstatus. Organisatorisk interoperabilitet handlar om ansvar, ägarskap, processer och beslutsgångar mellan de människor och funktioner som arbetar med systemen.

Om en av dessa nivåer brister kan ett flöde se korrekt ut, men ändå bli fel i praktiken. En produkt kan överföras i rätt format men med fel enhet. Ett lagersaldo kan visas utan tekniska fel men avse fel lagerplats. Ett pris kan vara korrekt i källsystemet men fel i webbkanalen eftersom rabatten tolkas olika i två datamodeller. Det är därför API-styrning och integrationsstyrning måste ses som löpande förvaltningsarbete, inte som ett engångsprojekt.

För svenska företag betyder detta att ERP-integration behöver byggas på tydliga definitioner av masterdata och tydliga kontrakt mellan system. Det är först när ni vet vilket system som äger kund, pris, lager, produkt och orderstatus som ni kan få en lösning som håller över tid.

Det som fungerar över tid är spårbarhet och möjlighet att köra om

Digg lyfter också fram vikten av öppna, etablerade och förvaltade format samt behovet av testning och riskanalys i API-arbete. I praktiken betyder det att en robust ERP-integration behöver flera egenskaper som ibland glöms bort när fokus ligger för mycket på första leveransen. Det gäller inte minst när ni ska sätta upp flöden med ett tydligt källsystem och samtidigt skapa ett upplägg som går att följa, testa och justera över tid.

För det första behöver ni stabila identifierare. Artiklar, kunder, priser, orderrader och andra centrala objekt måste gå att känna igen på samma sätt genom hela flödet, även när data rör sig mellan flera system. Om identifierare byts, återanvänds fel eller mappas otydligt blir det svårt att lita på spårbarheten.

För det andra behöver ni versionshantering. API:er, fält och kontrakt förändras över tid, och utan en tydlig versioneringsmodell riskerar en uppdatering i ett system att slå sönder ett fungerande flöde i ett annat. Det gäller särskilt när flera webbplatser eller portaler använder samma datakälla men på olika sätt.

För det tredje behöver ni tydlig loggning. Det måste gå att följa vad som kom från källsystemet, vilka transformationer som gjordes, när de gjordes och vad mottagaren faktiskt tog emot. Utan sådan loggning blir felanalys tidskrävande och ofta beroende av enskilda personer med mycket systemkunskap.

För det fjärde behöver ni flöden som går att köra om utan att skapa dubbleringar eller nya fel. Om ett prisflöde avbryts eller en orderöverföring misslyckas måste det finnas ett kontrollerat sätt att återställa, korrigera och skicka om. Många integrationsprojekt fungerar så länge allt går rätt till, men visar sina svagheter när avvikelser uppstår. Det är just där den verkliga kvaliteten prövas.

När dessa delar finns på plats blir integrationen inte bara mer tekniskt robust. Den blir också lättare att förvalta, enklare att revidera och tryggare att använda i verksamheter där flera avdelningar är beroende av samma data.

Standard och kundunika lösningar är ett val mellan enkelhet och frihet

Färdigpaketerade integrationer kan göra kostnaden mer förutsägbar och minska beroendet av egen specialutveckling. De löser inte varje behov automatiskt, men de ger ofta en tydligare grund för ansvar, testning och uppgraderingar. För företag som vill få ordning på återkommande integrationsbehov är det ofta en fördel att börja i standardiserade mönster där funktion, omfattning och ägarskap redan är definierade.

Samtidigt finns det lägen där standard inte räcker. I många verksamheter finns särskild prissättning, ovanliga orderregler, koncernstrukturer, marknadsspecifika flöden eller gamla systemlandskap som gör att en kundunik lösning behövs. Då får ni mer frihet att anpassa lösningen till verksamheten, men också ett större ansvar för modellering, testning och framtida förvaltning.

Det här är i grunden ett byte mellan snabbhet och frihet. En standardiserad lösning är oftast snabbare att införa och lättare att uppgradera. En kundunik lösning kan träffa verksamhetens behov mer exakt, men kräver tydligare ägarskap och större disciplin när förändringar ska göras. Om specialanpassningar byggs utan tydliga kontrakt riskerar de dessutom att sprida sig till resten av plattformen och göra framtida ändringar dyrare.

Det är därför klokt att skilja mellan sådant som verkligen är affärskritiskt och sådant som bara känns invant internt. När en avvikelse är affärskritisk bör den byggas med tydlig isolering, tydlig ansvarsfördelning och tydlig plan för uppgraderingar. När den inte är det är det ofta bättre att hålla sig närmare standard och vinna i förvaltningsbarhet över tid.

Frågor ni bör ställa innan projektet startar

Börja med att fråga leverantören vilket system som är master för pris, lager, kund och order. Svaret visar om leverantören har en genomtänkt datamodell eller bara erbjuder en teknisk koppling mellan två ändpunkter.

Fråga också hur versionsändringar i ERP, webbplattform eller integrationslager hanteras utan att webb eller portal behöver byggas om varje gång. Svaret visar hur mogen leverantörens förvaltningsmodell är och hur stora framtida följdkostnader ni riskerar att få.

Ni bör även fråga vem som bär ansvaret om en uppgradering påverkar ett flöde som redan är i drift. Svaret visar om ansvar är avtalsmässigt och praktiskt förankrat, eller om risken i själva verket skjuts tillbaka till er som kund.

Så hanterar Glanser ERP-integrationer

Glanser arbetar med ERP-integrationer som en långsiktig förvaltningsfråga, inte bara som ett införandeprojekt. Det märks bland annat i Funktionsbiblioteket, där lösningar levereras med fast omfattning och fast pris i nivåerna Standard, Anpassad och Kundunik. Tanken är att ge företag en tydligare grund för kostnad, ansvar och vidareutveckling, samtidigt som kundunika delar hålls isolerade så att de inte stör resten av plattformen vid framtida uppgraderingar.

I praktiken arbetar Glanser med fasta kopplingar mot Business Central, Monitor och Jeeves. Det handlar ofta om att synka produkter, priser, lager och order på ett sätt som går att förvalta över tid, snarare än att bara skapa en första teknisk anslutning.

Till detta kommer Glanser Care, där ansvar för uppgraderingar, kompatibilitet och löpande underhåll kan hanteras till en fast månadskostnad i stället för genom nya offertprocesser vid varje förändring. Det gör det lättare att bedöma totalekonomi över tid och minskar risken att en i grunden fungerande integration blir dyr att bära när systemlandskapet utvecklas.

På sidan om ERP och integrationer hittar ni hur Glanser kopplar ihop webb och affärssystem, vilka ERP-stöd som finns och hur upplägget för förvaltning ser ut.