Välj e-handelsplattform utifrån vad som händer efter köpet

En ny e-handelsplattform kan se färdig ut vid go-live. Sedan kommer den första prisändringen, en delvis leveransbar order eller en uppgradering, och plötsligt behöver någon rätta lagerstatus, flytta order manuellt eller kontrollera att rätt pris faktiskt visas.

Det är ofta först i den vardagen som plattformens verkliga kvalitet blir tydlig. När data måste justeras för hand mellan PIM, affärssystem och webb uppstår kostnaderna i drift, inte i demon.

Ett plattformsval behöver därför bedömas utifrån hela kedjan. Design och funktioner spelar roll, men integrationsförmåga, produktansvar och förvaltning avgör om lösningen håller när verksamheten förändras.

Marknaden kräver mer än en webshop

Svensk e-handel återgick till tillväxt under 2024 efter två år av nedgång. Enligt PostNords E-barometer för helåret 2024 uppgick nettoomsättningen till 140 miljarder kronor, vilket var en ökning med 5 procent jämfört med 2023.

Den storleken förändrar beslutsbilden. En e-handelsplattform hanterar ofta mer än en butiksvy. Den behöver bära produktinformation, priser, lager, kundspecifika villkor, order, betalning och leveransinformation genom flera system.

SCB visar samma utveckling från företagssidan. Under 2024 bedrev 36,7 procent av svenska företag med minst tio anställda e-handel via webb eller EDI. Webbhandel användes av 31,2 procent, medan 11,2 procent använde EDI och 5,7 procent använde båda kanalerna, enligt Statistiska centralbyråns statistik om it-användning i företag.

När e-handeln blir en del av den löpande omsättningen får fel i lager, pris eller order större följder. Därför bör ni kartlägga inköp, produktdata, försäljning, leverans och efterservice innan ni jämför funktioner. En snygg webshop kan vara början på lösningen, men den kan inte ensam bära hela affärsflödet.

Integrationer som bär hela kedjan

En e-handelsplattform utan stabila kopplingar blir snabbt en manuell arbetsplats. Medarbetare korrigerar produktfält, kontrollerar lager och flyttar order mellan system. Varje extra handpåläggning skapar en risk som växer med sortimentet och antalet kanaler.

PIM bör vara den samlade källan för produktinformation. Där hanterar ni namn, beskrivningar, attribut, bilder, dokument och kategorisering. Plattformen publicerar sedan validerade uppgifter till webb, produktwebb, kundportal och återförsäljarportal.

Affärssystemet har en annan uppgift. Det bör normalt styra priser, lager, orderstatus och ekonomisk återkoppling. När en kund ser lagerstatus på webben behöver uppgiften komma från samma verklighet som sälj och lager använder.

I en punkt-till-punkt-modell kopplas systemen direkt till varandra. Det kan vara snabbt att starta, men förändringar blir svårare att överblicka. En ändring i ett fält kan kräva justeringar på flera ställen.

En mer samlad integrationsmodell definierar hur data ska röra sig mellan systemen. Då kan ni styra vilka fält som är obligatoriska, hur fel loggas och vilken källa som äger varje uppgift. Det kräver mer analys tidigt, men ger bättre kontroll när fler kanaler tillkommer.

Hos Glanser beskriver vi arbetet med affärssystem och integrationer med fokus på produkter, priser, lager och order. Samma princip gäller oavsett plattform. Informationsägarskap och felhantering kommer före listan över tekniska anslutningar.

Hur produktansvar minskar risken

Många projekt ser färdiga ut vid go-live, men då börjar den mest krävande delen. Sortiment ändras, nya kundgrupper tillkommer och plattformen uppgraderas. Om varje förändring kräver en ny diskussion om teknik och omfattning blir budgeten snabbt svår att styra.

Ett produktansvarigt upplägg börjar med återanvändbara funktioner. Glanser använder ett Funktionsbibliotek med färdigutvecklade, testade och kompatibla funktioner och integrationer. De levereras i nivåerna Standard, Anpassad och Kundunik.

Standard passar när verksamheten kan använda en etablerad funktion. Anpassad nivå justerar beteendet inom en definierad ram. Kundunik funktion isoleras så att den inte påverkar resten av lösningen vid uppgraderingar. Det är en teknisk princip, men också en kostnadsfråga.

När en funktion har fast omfattning och fast pris före utvecklingsstart blir beslutet enklare att förankra. Ni kan koppla arbetet till ett konkret behov, exempelvis kundspecifika priser, en reservdelsportal eller publicering av produktdokument.

Det upplägget kräver att kunden beskriver processer och prioriteringar tydligt. Ett Funktionsbibliotek ersätter inte beslut om datakvalitet, behörigheter eller ansvar mellan avdelningar. Däremot minskar det behovet av att bygga samma grundfunktion flera gånger.

För produktinformation behöver ni därför definiera både modell och ägarskap. Arbetet med PIM hos Glanser visar varför struktur i produktdata behöver planeras tillsammans med publiceringen.

Ni kan börja med en lösning och bygga vidare på samma grund. Det passar när sortiment, bolag eller kanaler ska växa stegvis. Ett annat arbetssätt kan passa bättre om ni har få produkter, enkla orderflöden och liten förändringstakt. Då kan en mindre standardiserad lösning vara mer rimlig.

Affärssystemet styr verkligheten

En plattformsdemo visar sällan vad som händer när verkliga transaktioner rör sig genom systemen. Därför bör ni kräva en konkret genomgång av fyra flöden, produkt, pris, lager och order. Varje flöde behöver en tydlig källa, en definierad riktning och en plan för fel.

Produkter kan komma från PIM eller affärssystemet, beroende på hur organisationen arbetar. Priser behöver ofta följa avtalsregler, prislistor och kampanjlogik. Lagerstatus måste visa vad som faktiskt kan säljas. Ordern behöver sedan återföras så att ekonomi, lager och kundservice ser samma händelse.

Börja med en prisändring. Den ska nå plattformen på ett kontrollerat sätt och synas rätt innan kunden slutför köpet. Testa därefter en order som bara kan levereras delvis, eftersom den situationen ofta avslöjar brister i statuslogik och kundkommunikation.

Gå sedan igenom en ersättningsprodukt och ett saknat obligatoriskt attribut. Plattformen behöver kunna stoppa eller märka felaktig data innan den blir synlig. Loggning ska visa vad som misslyckades, när det hände och vem som kan åtgärda det.

Glanser har färdigprissatta integrationer till Business Central, Monitor och Jeeves. De byggs som testade komponenter med fast omfattning. För er innebär det att ni kan bedöma anslutningen utifrån definierade fält och flöden, inte utifrån en allmän formulering om att systemen kan integreras.

Begär också en tydlig ansvarsmatris. Den ska visa vem som äger produktdata, vem som hanterar fel och vem som ändrar en integration när affärsreglerna ändras. Utan det blir tekniken fungerande på papperet men otydlig i drift.

Portaler breddar försäljningsvägarna

En e-handelsplattform behöver ibland ge olika kundgrupper olika vägar genom samma affär. En kundportal kan visa orderhistorik, fakturor, leveranser och kundunika priser. En återförsäljarportal kan prioritera sortiment, material och ordervillkor. En reservdelsportal behöver hjälpa kunden att hitta rätt del och förstå kompatibilitet.

Självservice fungerar när plattformen hämtar rätt information från rätt källa. Kunden ska kunna se sin orderstatus utan att kundservice manuellt söker fram uppgiften. Säljaren ska kunna arbeta med kundrelationen utan att administrera varje återkommande beställning.

Produktwebben kan fungera som en synkad yta mellan PIM och externa kanaler. När produktdata, dokument och attribut styrs från en gemensam modell minskar risken för olika beskrivningar på olika platser.

Det kräver en modell som skiljer gemensamma fält från kategorispecifika uppgifter. Byggprodukter kan behöva mått och enheter. Reservdelar kan behöva kompatibilitet och ersättningsrelationer. Samma grund kan återanvändas, men reglerna behöver vara tydliga.

Hos Glanser samlas lösningar för portaler där webb, kundportal och återförsäljarportal kan ingå i samma sammanhang. Det ger en bättre grund för gemensamma behörigheter, produktdata och orderflöden.

Portaler passar när återkommande ärenden tar tid från sälj eller kundservice. De passar sämre när processerna fortfarande är oklara eller när informationen bakom självservicen inte är tillförlitlig. Börja därför med de ärenden som har tydliga regler och hög frekvens.

Plattformsbytet som kostnadsgrop

Ett plattformsbyte prissätts ofta som licens plus implementation. Den kalkylen missar arbetet efter go-live, särskilt när plattformen och affärssystemet utvecklas i olika takt.

En uppgradering kan påverka API-anrop, datamodeller, behörigheter och orderlogik. Om ingen har ett avtalat ansvar upptäcker ni kanske problemet först när en release redan ska ut. Då blir felsökningen akut och kostnaden svårare att styra.

Räkna på mer än projektets startkostnad. Ta med förvaltning, versionsuppföljning, test, buggrättning, dokumentation och anpassningar när era processer förändras. Lägg också in kostnaden för intern tid, eftersom produktägare, sälj, IT och ekonomi behöver delta. Det ger en bättre bild av den totala kostnaden över tid.

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. Kunden behöver fortfarande prioritera förbättringar och bidra med verksamhetskunskap, men ansvarslinjen blir tydligare.

Förvaltning passar särskilt när plattformen hanterar order, kundvillkor och flera integrationer. Om lösningen är liten och sällan förändras kan ett mer begränsat upplägg räcka. Det viktiga är att ni väljer med öppna ögon och dokumenterar vad som händer när något går fel.

Kontrollera också vad som räknas som buggrättning. Ett fel i en befintlig funktion bör hanteras på ett annat sätt än en ny regel eller ett nytt kundflöde. Den gränsen behöver vara begriplig innan avtalet börjar gälla.

Frågor som avslöjar leverantörens nivå

Be leverantören beskriva vad som händer med era integrationer vid nästa plattformsuppgradering. Fråga vem som testar, vem som åtgärdar kompatibilitetsproblem och vad som ingår i den avtalade kostnaden. Svaret visar om ansvaret fortsätter efter go-live.

Be sedan om en konkret modell för produktdata när ni får fler bolag eller kanaler. Fråga vem som äger gemensamma attribut, hur lokala avvikelser hanteras och hur ändringar publiceras. Svaret avslöjar om lösningen kan växa med en gemensam grund eller kräver separata specialflöden.

Den tredje frågan gäller förvaltning. Be leverantören skilja mellan buggrättning, versionsarbete och vidareutveckling. Fråga också vilka delar som faktureras separat och hur ni får insyn i arbetet.

Bra svar innehåller ansvar, avgränsningar och konkreta exempel. Otydliga svar betyder ofta att den verkliga TCO:n ännu inte är synlig.

Ta nästa steg med 72h-analys

Om ni överväger ett plattformsbyte behöver ni först förstå nuläget. Samla era viktigaste funktioner, integrationer och återkommande problem. Ta med representanter från verksamhet, IT och ekonomi, eftersom kostnaden ofta uppstår mellan avdelningarnas gränser.

I en 72-timmarsanalys avsätter ni två timmar för ett möte. Inom 72 timmar får ni en inventering av funktionalitet och integrationer, en funktionsspecifikation, en prototyp och en komplett kostnadsbild med tidsplan. Underlaget är kostnadsfritt och blir ert.

Det ger er ett konkret beslutsunderlag för plattformsbyte, kostnad och estimat innan budgeten låses.