Composable commerce lönar sig där ni kan äga gränssnitten

En ny kundportal kan verka som ett avgränsat projekt. Sedan visar det sig att produktdata ligger i flera system, priser hämtas från affärssystemet och orderflödet följer en annan logik. När varje kanal utvecklas i egen takt blir plattformsvalet en fråga om ansvar och förändringskostnad.

Composable commerce kan hjälpa er att ändra en del av handelsmiljön i taget. Men varje fristående komponent kräver integration, förvaltning och en tydlig ägare. Här går vi igenom hur ni kan bedöma nyttan, välja en rimlig grad av modularitet och räkna in kostnaderna efter go-live.

Därför behöver ni kontroll över era kanaler

Ni kanske redan har en webbshop, ett affärssystem och en separat lösning för produktinformation. Nu vill säljavdelningen ha en kundportal, marknadsteamet behöver en produktwebb och återförsäljarna efterfrågar egna orderflöden. Varje initiativ låter avgränsat, men funktionerna bygger ofta på samma priser, produktdata och lagerinformation.

Digital försäljning är redan en stor del av affären för många bolag. Enligt SCB bedrev 36,7 procent av svenska företag med minst tio anställda e-handelsförsäljning under 2024.

För er blir den praktiska frågan hur ni kan anpassa en kanal eller funktion när behovet förändras. En ny kundportal bör exempelvis kunna använda samma produkt- och prisdata som webbshopen. Om varje förbättring samtidigt kräver omfattande ändringar i hela handelsmiljön blir förändringen dyr att samordna.

Composable commerce är ett möjligt arbetssätt för att dela upp ansvaret. Ni kan behålla fungerande delar och frikoppla den funktion som skapar ett tydligt hinder. Nyttan beror på om ni kan hantera integrationerna och förvaltningen som följer med beslutet.

Composable commerce är en arkitekturprincip

Composable commerce beskriver hur ni delar upp handelstekniken i avgränsade komponenter. En komponent kan hantera produktinformation, en annan sök och presentation, och en tredje köpflöde eller portal. Komponenterna samverkar genom definierade gränssnitt, ofta API:er.

Tänk på en digital affär som en kedja av ansvarsområden. Produktdata behöver en tydlig källa. En frontend behöver presentera informationen. En handelsmotor kan hantera transaktionen, medan affärssystemet äger affärens artikel-, pris-, lager- och orderdata. Ni ska kunna beskriva vad varje del ansvarar för och vad den får förvänta sig av de andra.

I en mer sammanhållen plattform ligger flera funktioner nära varandra. Det kan göra driften enklare när katalog, kunddata, checkout och administration utvecklas i ungefär samma takt. En fristående arkitektur gör det lättare att ändra enskilda delar, men ni får fler gränser att förvalta och testa.

API:er i sig gör inte en lösning composable. Om komponenterna delar oklara datamodeller eller om flera system tror att de äger samma uppgift får ni en frikoppling på papperet, men fortsatt samordning i vardagen. Definiera därför vilket system som är källa för varje viktig uppgift. Det systemet blir den styrande källan för uppgiften.

När ni bedömer en komponent, se efter om ansvaret går att avgränsa, om dataflödet går att följa och om delen kan ändras utan att skapa oväntade fel i andra led. Förklaringen av hur olika handelsplattformar används kan ge en praktisk utgångspunkt för att skilja plattformsval från arkitekturval.

Komponenterna följer kundens digitala resa

Följ en kundresa från produktinformation till order. PIM kan samla produktdata som benämningar, attribut och innehåll. Sök och frontend använder informationen för att hjälpa kunden hitta och förstå rätt produkt. Kundportaler och återförsäljarportaler visar sedan innehåll och funktioner som passar respektive användarroll.

Affärssystemet kan fortsätta vara källa för priser, lager och order. Handelslösningen hämtar uppgifter som behövs för att presentera erbjudandet och ta emot beställningen. När ordern skickas tillbaka behöver flödet ha regler för bekräftelse, felhantering och återförsök.

Ta en återförsäljare som loggar in för att se sitt sortiment. Grundläggande produktdata kan vara gemensam, medan kundens avtalade pris, tillgänglighet och orderhistorik hämtas med hänsyn till kundrelationen. Den kanoniska produktmodellen beskriver varans gemensamma egenskaper. Kundspecifika villkor hör hemma i dataflöden där behörighet och affärsregler hanteras.

Komponenterna fungerar bäst när de delar en tydlig datamodell och när varje integration har en ansvarig. Bestäm hur ni upptäcker ett misslyckat prisflöde och vem som hanterar det. Följ upp synkronisering och orderhändelser, så att fel blir synliga innan de skapar problem för kunden.

Det är även viktigt att styra vilka system som får ändra en uppgift. Om lagerstatus uppdateras på flera håll behöver ni veta vilken källa som gäller när värdena skiljer sig. Modularitet ger handlingsutrymme, men den löser inte oenighet om dataägande.

Välj nivån av modularitet efter behovet

Börja med det hinder ni vill undanröja. Om plattformen fungerar och funktionerna förändras sällan kan ni behålla den och förbättra de delar som behöver uppmärksamhet. Det ger er färre leverantörsrelationer och mindre integrationsarbete att följa upp.

En hybridmodell passar när en avgränsad domän bromsar verksamheten. Ni kan exempelvis frikoppla PIM eller lägga till en särskild portal, samtidigt som övriga handelsflöden ligger kvar. Då behöver ni definiera hur produktdata eller kundinformation överförs och vem som hanterar fel mellan systemen.

Full composable-arkitektur blir relevant när flera domäner behöver utvecklas oberoende och organisationen kan äga gränssnitten över tid. Varje ny tjänst tillför licenser, integrationer, övervakning och versionshantering. TCO-kalkylen behöver därför omfatta drift och intern samordning, utöver utvecklingskostnaden.

Det minsta rimliga steget är ofta det som löser ett konkret problem utan att skapa fler löpande uppgifter än organisationen kan ta hand om. Jämför därför scenarier med samma kostnadsgränser: licenser, integrationer, test, incidenthantering och kompetens för den löpande förvaltningen.

Vinsten kommer från kortare väntetider och bättre självservice

En produktwebb kopplad till affärssystemet kan visa relevanta produkter och tillgänglighet utifrån kundens behov. En kundportal kan låta köpare hitta orderinformation och hantera återkommande ärenden själva. En återförsäljarportal kan visa rätt sortiment och villkor för varje partner.

När varje kanal använder en gemensam modell för produktdata blir det lättare att hålla informationen konsekvent. PIM kan samla attribut och innehåll, medan webb, portaler och återförsäljarflöden visar informationen på olika sätt. Det förutsätter att någon äger datakvaliteten och har mandat att rätta fel.

Bredare självservice hjälper inte om kunden möter felaktiga produkter, priser eller lageruppgifter. Innan ni lägger till en funktion bör ni följa informationen från källan till kanalen och fastställa vem som ansvarar för varje led. Då kan ni avgöra om hindret finns i användarupplevelsen, datan eller integrationen.

Glanser bygger lösningar av färdigutvecklade, testade och kompatibla funktioner och integrationer genom Funktionsbiblioteket. Omfattningen och priset fastställs för varje funktion före arbetet. Funktionerna finns i nivåerna Standard, Anpassad och Kundunik. En Kundunik funktion isoleras så att den inte påverkar resten vid uppgraderingar.

Kunden kan börja med en lösning och bygga vidare på samma grund. Det passar när ni vill avgränsa nästa steg, men förutsätter att verksamheten fattar beslut om funktionernas ansvar och prioritet.

En digital kundportal kan vara en lämplig första modul när kundernas återkommande ärenden tar tid från sälj eller kundservice. Bedöm nyttan utifrån vilka uppgifter kunden faktiskt kan genomföra själv och vilken information portalen måste kunna lita på.

Så binder ni Litium till affärssystemet

Innan ni bygger något behöver ni veta vilket system som avgör vad gäller produkter, priser, lager och order. Tilldela varje datatyp en ägare och dokumentera vilka kanaler som läser eller skriver informationen. Det minskar risken för dubbla regler i frontend och affärssystem.

Definiera sedan integrationskontrakt för varje dataflöde. Ett kontrakt beskriver informationen som skickas, vem som skickar den och vad som ska ske när mottagaren inte kan behandla den. För produkter kan ni exempelvis ange vilka attribut som krävs innan en artikel publiceras. För order behöver ni kunna spåra mottagning och hantera återförsök utan att skapa dubbla beställningar.

Business Central, Monitor och Jeeves är exempel på affärssystem som kan anslutas till Litium. För att hålla frontend enkel bör affärsregler och synkronisering hanteras i ett integrationslager eller i standardiserade adapterfunktioner. Bestäm också hur fel visas för driftansvariga och hur de kan rättas utan att skapa nya order eller skriva över giltiga värden.

Plattformen förändras också över tid. Litiums release notes visar hur ofta nya versioner kommer, och varje version behöver testas mot era integrationer.

Integrationer kräver löpande produktansvar med versionsuppföljning och kompatibilitet genom uppgraderingar. Beskrivningen av integrationer mot affärssystem kan hjälpa er att reda ut vilka dataflöden som behöver ingå i er plan.

När modulariteten blir dyrare än plattformen

Varje fristående tjänst ger er ett extra gränssnitt att övervaka, en version att följa och ett beroende att felsöka. När få personer ansvarar för tekniken kan flera leverantörsrelationer göra planering och incidenthantering svårare. Om en sammanhållen plattform klarar era behov kan den vara enklare att driva och billigare att förvalta.

Composable commerce förbättrar inte automatiskt prestanda. Fler separata tjänster kan öka svarstiden och skapa fler punkter där fel stoppar kundresan. Om ni delar upp arkitekturen behöver varje komponent ha tydliga driftskrav, uppföljning och en plan för återhämtning.

Cache kan minska behovet av att hämta samma produktinformation från källsystemet vid varje besök. Realtidsanrop bör reserveras för uppgifter där aktualitet påverkar beslutet, som kundspecifika priser eller orderstatus. Vid tillfälliga fel kan systemet behöva använda senast verifierade information eller tydligt meddela att uppgiften inte går att visa.

Räkna in test, övervakning, felhantering och ansvar för leverantörernas versioner i er TCO. Om de kostnaderna saknas kan en låg inköpskostnad ge en missvisande bild av den totala förvaltningen. En beskrivning av Glanser Care visar hur ett avtalat produktansvar kan omfatta kompatibilitet och buggrättning efter go-live.

Tre frågor att ställa leverantören

Vem ansvarar för att integrationerna fungerar när Litium eller affärssystemet uppgraderas? Svaret visar om ansvaret följer med efter go-live eller om varje uppgradering blir en ny offert.

Hur testas kompatibiliteten innan en ny version når produktion? Svaret visar om det finns en rutin eller om felen upptäcks av era kunder.

Vilka kostnader ingår efter go-live och vilka hamnar hos ert team? Svaret visar hur mycket av förvaltningen ni själva behöver bemanna.

Införandet kräver tydliga beslut och ert underlag

Kartlägg först nuläget. Följ produktdata, priser, lager och order genom systemen och notera var ansvar eller dataägande är oklart. Välj sedan den kanal eller domän som skapar störst hinder för verksamheten.

Fastställ datamodeller, integrationsgränser och vilka funktioner som ingår innan utvecklingen börjar. Ta med test, felhantering, förvaltning och produktansvar i omfattningen. Då kan ni bygga en grund som löser ett konkret behov och utöka den när nästa affärsskäl finns.

Vi genomför en 72-timmarsanalys när ni bedömer ett befintligt nuläge eller planerar kostnad och omfattning. Ni avsätter två timmar för mötet och får inom 72 timmar en inventering av funktionalitet och integrationer, en funktionsspecifikation, en prototyp samt en komplett kostnadsbild med tidsplan. Analysen är kostnadsfri och underlaget tillhör er.