B2B e‑handel: plattformer, teknisk stack og integrasjoner (ERP, PIM, EDI)

B2B e‑handel blir sjelden “bare en nettbutikk”. Det handler om kundespesifikke priser, avtaler, store produktkataloger, flere roller per kunde og ordreprosesser som må passe inn i ERP, lager og logistikk. Derfor blir plattformvalg og integrasjoner ofte viktigere enn selve designet.

Innholdsfortegnelse

• Hvorfor B2B skiller seg teknisk fra B2C
• Plattformkategorier: oversikt og når hver passer
• Rask sammenligning av plattformtyper
• Fordeler, ulemper og typiske B2B‑brukstilfeller
• Alt‑i‑ett / managed SaaS
• Enterprise suite / monolitt (for eksempel DynamicWeb‑type posisjonering)
• Shopify / Shopify Plus (ofte levert med partner, f.eks. Appsalon‑type miljø)
• Headless / composable (for eksempel Norce‑type posisjonering)
• Vendoreksempler og hvordan de posisjonerer seg
• Teknisk stack lag‑for‑lag (frontend → hosting)
• Presentasjonslag (frontend)
• Commerce‑motor (katalog, kurv, ordre, pris)
• PIM (Product Information Management)
• CMS (innhold)
• Integrasjons- og API‑lag (middleware)
• Databaser og lagring
• Søk og navigasjon
• Cache og CDN
• Hosting og drift (cloud)
• Observability (logging, metrics, tracing)
• Anbefalte teknologistakker etter modenhet og kompleksitet
• SMB / rask time‑to‑market (managed SaaS)
• Mellomstor B2B (Shopify Plus eller managed headless)
• Enterprise / komplekst landskap (composable + ERP‑sentrisk)
• Integrasjonslandskap: hva må integreres i en B2B‑løsning
• Vanlige systemer og dataflyt
• Integrasjonsmønstre og tekniske alternativer
• Synkron API (request/response)
• Asynkron/event‑drevet integrasjon
• Batch‑integrasjon (fil, nattkjøring)
• EDI
• Punch‑out
• Praktiske implementeringsvalg: connectors, iPaaS eller custom?
• Alternativer og trade‑offs
• Migrasjon og utrulling: steg‑for‑steg plan
• Readiness‑sjekkliste (før dere starter)
• Datamapping som må sitte (ofte undervurdert)
• Utrullingsløp som reduserer risiko
• Testing dere bør planlegge (ikke bare “smoke test”)
• Evaluering og scorecard for shortlist
• Scorecard (kopierbar sjekkliste)
• Ikke‑funksjonelle krav: sikkerhet, compliance, ytelse og SLA
• Sikkerhet og compliance (GDPR, ISO 27001)
• Ytelse og skalerbarhet
• SLA og drift
• Eksempelarkitektur (tekstlig diagram), headless med ERP‑integrasjon
• Estimater: typiske tidslinjer og kostnadsområder
• Konkrete anbefalinger: fra evaluering til pilot
• Sammendrag og handlingspunkter
• Ofte stilte spørsmål (praktiske svar)
• Hvilken e‑handelsplattform passer best for B2B: alt‑i‑ett, Shopify Plus eller composable?
• API vs EDI for ERP‑integrasjon, når bør vi bruke hva?
• Trenger vi PIM for B2B, og hva er gevinstene?
• Hvor lang tid tar en typisk B2B‑migrasjon og hva koster det grovt?
• Hvordan håndterer vi komplekse prisregler og kundespesifikke kataloger?
• Hva betyr API‑first for integrasjoner og for valg av plattform?
• Når bør vi velge en managed SaaS versus bygge composable med mikrotjenester?
• Hvilke non‑functional krav må vi sette som minimum (SLA, GDPR, datalokalisering)?
• Skal vi bruke iPaaS eller en integrasjonspartner med prebuilt connectors?
• Hvordan teste og overvåke integrasjoner i produksjon (observability, retry, alerting)?

Målet her er å gi et praktisk beslutningsgrunnlag for deg som skal velge eller modernisere B2B‑plattform: hvilke plattformtyper som finnes, hvordan en typisk teknisk stack bygges lag for lag. Og hvilke integrasjonsmønstre som faktisk fungerer i drift.

I mange bransjer henger B2B e‑handel tett sammen med samarbeid i verdikjeden (leverandører, grossister, innkjøpssystemer). Hvis du også jobber med samarbeid og partneroppsett mer overordnet, se Hva er B2B‑samarbeid mellom bedrifter? for begreper og rammer.

Hvorfor B2B skiller seg teknisk fra B2C

B2C handler ofte om rask publisering, kampanjer og betaling. B2B handler ofte om styrt tilgang og korrekt data. Typiske krav som driver arkitekturvalg:

• Kundespesifikke priser og avtaler: pris pr kunde, pr avtale, pr volum, pr leveringsadresse, pr produktgruppe.
• Kundespesifikke kataloger: ikke alle kunder skal se alle varer.
• Roller og godkjenning: flere brukere per kunde, med rettigheter og bestillingsflyt (f.eks. attestasjon).
• Store kataloger og varianter: mange attributter, tekniske spesifikasjoner, dokumentasjon og erstatningsprodukter.
• Ordre- og leveringslogikk: del-leveranser, restordre, hent-i-butikk/terminal, prosjektordre, EAN/GLN, referansefelt.
• Integrasjonskrav: ERP er ofte “system of record” for kunder, priser, lager og kreditt. PIM/WMS/CRM kommer i tillegg.
• EDI og punch‑out: enkelte kunder krever handel via innkjøpssystemer, ikke via vanlig checkout.

Konsekvensen er at “plattform” ikke bare er CMS + checkout. Det er en hel teknisk stack med klare eierskap til data: hvem eier produktdata, hvem eier priser, hvem eier ordrestatus.

Plattformkategorier: oversikt og når hver passer

Det finnes ikke ett riktig valg. Men det finnes plattformtyper som passer bedre ved ulike krav til fleksibilitet, integrasjon og tempo.

Rask sammenligning av plattformtyper

Plattformtype	Passer best når	Fordeler	Ulemper / fallgruver
Alt‑i‑ett / managed SaaS (monolitt)	Du vil raskt i gang og kan leve med standard prosesser	Lavere drift, ofte kort tid til marked	Begrensninger i B2B‑prislogikk, integrasjoner kan bli “workarounds”, risiko for låsing til leverandør
Enterprise monolitt / suite	Du vil ha en samlet pakke (commerce + PIM/CMS/marketing) og tung B2B‑funksjonalitet	Mye funksjon i samme plattform, ofte B2B‑features	Større prosjekter, mer styring, kan bli kostbart å endre
Shopify / Shopify Plus	Du vil ha høy fart, stort app‑økosystem, og B2B‑løp innenfor rammer	Svært moden plattform og økosystem	Mer komplekst ved avansert ERP‑styrt pris/katalog, og der checkout/ordre må skreddersys
Headless / composable	Du har komplekse krav og vil bytte ut komponenter over tid	Fleksibelt, API‑drevet, passer godt med PIM/ERP‑sentrisk	Mer arkitektur, mer integrasjon, høyere krav til team og forvaltning
Managed headless (driftet composable)	Du vil ha headless-fordeler, men mindre driftsansvar	Kan gi god balanse mellom kontroll og drift	Avklar ansvarslinjer og SLA nøye (hvem eier hva ved feil)

Fordeler, ulemper og typiske B2B‑brukstilfeller

Alt‑i‑ett / managed SaaS

Når det passer

• SMB/mellomstor B2B med relativt standard katalog og prisregler.
• Behov for rask lansering (pilot) og begrenset IT‑kapasitet.

Fordeler

• Mindre teknisk kompleksitet.
• Drift, oppdateringer og sikkerhet håndteres ofte av leverandør.

Ulemper

• Integrasjoner blir ofte avgjørende, og SaaS‑begrensninger kan styre hele prosjektet.
• Vanskeligere å løse krav som: avansert prislogikk, kundespesifikke kataloger, komplekse ordreflyter.

Enterprise suite / monolitt (for eksempel DynamicWeb‑type posisjonering)

Når det passer

• Du vil ha mye funksjon samlet (commerce + PIM/CMS) og har tydelige prosesser.
• Du har mange produkter, behov for PIM og strukturert innhold.

Fordeler

• Kan redusere antall systemer og integrasjoner.
• Ofte mer “B2B ferdig” enn enklere SaaS.

Ulemper

• Større implementasjon og mer styring.
• Tilpasninger og oppgraderinger må planlegges.

Shopify / Shopify Plus (ofte levert med partner, f.eks. Appsalon‑type miljø)

Når det passer

• Du vil raskt i gang med en robust plattform og aksepterer en del standardisering.
• Du trenger et sterkt økosystem for funksjoner via apper og integrasjoner.

Fordeler

• Høy time‑to‑market.
• Mange ferdige integrasjoner/apper.

Ulemper

• B2B blir fort et spørsmål om riktig dataflyt og riktig “kilde” for pris/katalog.
• Skreddersøm rundt ERP‑styrt handel kan kreve mer utvikling enn man først tror.

Headless / composable (for eksempel Norce‑type posisjonering)

Når det passer

• Du har krav som endrer seg ofte, flere kanaler, eller du vil bygge et fleksibelt landskap.
• ERP/PIM er sterke premissgivere, og commerce er én av flere kanaler.

Fordeler

• Du kan velge “best of breed” for PIM, søk, CMS, checkout, integrasjon.
• Godt egnet for API‑first og event‑drevne integrasjoner.

Ulemper

• Flere komponenter gir mer integrasjon, testing og overvåkning.
• Krever tydelig arkitektur og eierskap i organisasjonen.

Vendoreksempler og hvordan de posisjonerer seg

Under er ikke en fasit, men en praktisk måte å lese leverandørlandskapet på: hva de vanligvis fremhever når de selger til B2B.

• DynamicWeb posisjonerer seg ofte som en suite med commerce og PIM‑muligheter i samme retning, og med fokus på B2B‑scenarier. Se leverandørside: DynamicWeb.
• Norce er typisk tydelig på composable/headless og API‑drevet tilnærming for B2B‑løsninger. Se: Norce B2B.
• Shopify / Shopify Plus vektlegger plattformstabilitet og økosystem. I praksis løses mye B2B‑logikk via riktig app‑valg, integrasjoner og partnerleveranse.
• Mystore retter seg ofte mot virksomheter som vil ha en mer “ferdig” netthandelsplattform med lav terskel. Se: Mystore.
• Salesforce er ofte valgt der commerce knyttes tett opp mot CRM/marketing og større enterprise‑behov, med krav til styring og prosess. Se: Salesforce EU.
• IntegrasjonsPartner posisjonerer seg på integrasjoner som egen disiplin, typisk relevant når ERP/EDI er krevende og du vil ha kontroll på meldingsflyt og drift. Se: IntegrasjonsPartner – integrasjoner.
• Appsalon er et eksempel på et Shopify‑miljø som leverer e‑handel og utvikling rundt plattformen. Se: Appsalon.

Poenget: Leverandører selger ofte “plattform”. Du må oversette det til stack + integrasjoner + forvaltning.

Teknisk stack lag‑for‑lag (frontend → hosting)

En B2B‑stack bør beskrives som lag med tydelige ansvarsområder. Under er en praktisk “kartlegging” du kan bruke i workshop.

Presentasjonslag (frontend)

Typiske valg:

• React/Next.js: ofte brukt for headless og høye krav til ytelse og fleksibilitet.
• Vue/Nuxt: tilsvarende egnet for headless.
• Plattformstyrt frontend (i monolitter/SaaS): raskere, men mindre fleksibelt.

B2B‑spesifikke hensyn:

• Innlogging før priser og produkter.
• “Quick order”, opplasting av handleliste, SKU‑søk.
• Konto/rolle‑styring og kjøpsgodkjenning.

Commerce‑motor (katalog, kurv, ordre, pris)

Her ligger typisk:

• Produkt- og variantlogikk (eller kobling til PIM).
• Prisvisning og rabatter (ofte delvis fra ERP).
• Ordreopprettelse, betalingsflyt (eller faktura/kreditt).

Praktisk råd: Avklar tidlig hvem som eier pris:

• Hvis ERP eier pris, må commerce ha en robust strategi for caching og fallback.
• Hvis commerce eier pris, må ERP få tilbake “riktig sannhet” for fakturering og margin.

PIM (Product Information Management)

PIM blir raskt viktig i B2B når du har:

• Mange attributter per produkt.
• Flere språk, markeder eller kanaler.
• Teknisk dokumentasjon og strukturert datakvalitet.

PIM brukes ofte til:

• Beriking (tekster, dokumenter, bilder, attributter).
• Klassifisering, varianter, kompatibilitet.
• Publisering til nettbutikk og andre kanaler.

CMS (innhold)

Selv i B2B trengs innhold:

• Produktsider (guides, dokumentasjon).
• Bransjesider og landingssider.
• Support‑innhold, nedlastninger, sertifikater.

I headless‑oppsett er headless CMS vanlig. I suiter/monolitter ligger CMS gjerne “inne i plattformen”.

Integrasjons- og API‑lag (middleware)

Dette er ofte den virkelige kjernen i B2B:

• API‑gateway og autentisering.
• Transformasjon av data mellom ERP/PIM/WMS/commerce.
• Køer, retry og overvåkning.

Teknologivalg (eksempler):

• API‑lag: Node.js/.NET/Java (avhenger av organisasjon).
• Webhooks + kø: RabbitMQ/Kafka (event‑drevet).
• iPaaS (integrasjonsplattform): raskere oppsett, men må vurderes opp mot låsing og kost.

Databaser og lagring

Vanlige alternativer:

• PostgreSQL / MySQL: typisk for transaksjonelle data (ordre, kunder).
• MongoDB: kan passe for fleksible dokumentmodeller (variasjon), men vurder nøye ved transaksjonskrav.
• Objektlagring (filer/dokumenter): produktark, datablad, bilder.

Søk og navigasjon

For store kataloger blir søk en egen komponent:

• Facetter, synonym, “did you mean”, SKU‑optimalisering.
• Relevans og tilgangsstyring (ikke alle ser alt).

Cache og CDN

For ytelse i B2B er dette ofte “must have”:

• Redis: cache for prisoppslag, sesjoner, katalogfragmenter.
• CDN: statisk innhold, bilder, frontend‑assets.

Hosting og drift (cloud)

Valg styres ofte av:

• Krav til drift/forvaltning (internt vs leverandør).
• GDPR, datalagring i EU og kundekrav.
• Trafikkmønster og tilgjengelighetskrav.

Eksempler:

• AWS/GCP: fleksibilitet og tjenester for event‑drevet integrasjon.
• Vercel/liknende: effektiv frontend‑drift for Next.js (må vurderes opp mot datalokalisering og integrasjoner).

Observability (logging, metrics, tracing)

B2B‑handel feiler ofte i integrasjoner, ikke i UI. Minimum:

• Sentral logging (feil, payload‑størrelser, responstid).
• Metrics (kø‑lengde, feilmeldinger, retry‑rate).
• Tracing mellom tjenester (hvor stopper ordren?).

Anbefalte teknologistakker etter modenhet og kompleksitet

Under er tre “oppskrifter” som ofte fungerer i praksis. Ikke som produktanbefaling, men som struktur.

SMB / rask time‑to‑market (managed SaaS)

Typisk stack

• Plattform med innebygd hosting og standard frontend.
• Enkel integrasjon til ERP (ofte ordre + lager + pris).
• Minimum PIM (evt. lett PIM hvis katalogen vokser).

Passer når

• Du kan standardisere prosess.
• Du vil teste kanal med en pilotkundegruppe.

Viktig å avklare

• Hvordan pris og kundekatalog håndteres.
• Begrensninger i roller og godkjenning.

Mellomstor B2B (Shopify Plus eller managed headless)

Typisk stack

• Commerce: Shopify/Shopify Plus eller tilsvarende.
• Frontend: standard tema eller headless frontend (Next.js) ved behov.
• Integrasjon: iPaaS eller partnerbygd middleware.
• PIM: hvis produktdata er komplekse eller dere har flere kanaler.

Passer når

• Dere trenger fart og et sterkt økosystem.
• Dere tåler at enkelte B2B‑prosesser må tilpasses plattformens måte å jobbe på.

Viktig å avklare

• Prisstrategi (real‑time vs batch vs cache).
• Ordre‑ og kredittflyt mot ERP.

Enterprise / komplekst landskap (composable + ERP‑sentrisk)

Typisk stack

• Frontend: Next.js/Nuxt.
• Commerce‑motor: composable/headless.
• PIM: dedikert PIM som eier produktberiking.
• Integrasjon: message bus (Kafka/RabbitMQ) + API‑gateway + tydelige domener.
• ERP (f.eks. Microsoft Dynamics 365/Business Central): eier kunder, kreditt, priser, lager og ordrelogikk (varierer).

Passer når

• Dere har flere markeder/brands, flere salgskanaler, eller tung B2B‑logikk.
• Dere vil kunne bytte komponenter uten total replatforming.

Viktig å avklare

• Domeneansvar og masterdata.
• Streng styring av API‑kontrakter og versjonering.

Integrasjonslandskap: hva må integreres i en B2B‑løsning

B2B‑prosjekter lykkes ofte eller feiler på dataflyten. Lag en liste over systemer og konkret data per system.

Vanlige systemer og dataflyt

System	Typiske data inn i nettbutikk	Typiske data ut fra nettbutikk
ERP (Dynamics 365/Business Central m.fl.)	Kunder, avtaler, pris, rabatt, lager, kreditt, leveringsbetingelser	Ordre, ordrelinjer, kundeoppdateringer (noen ganger), returer (avhengig av prosess)
PIM	Produkter, varianter, attributter, medier, dokumenter, klassifisering	Publiseringsstatus, evt. feedback på datakvalitet
CRM	Kundeinfo, segment, kontaktdata, aktivitet	Leads/forespørsler, ordre-/omsetningssignal
WMS	Lagerbeholdning, plukkstatus, sporingsinfo	Plukkordre / forsendelsesordre (ofte via ERP)
Betaling	(B2B kan være faktura/kreditt) token/autorisasjon	Transaksjonsstatus, avstemming
Frakt/transportør	Fraktpriser, leveringsalternativer, sporing	Bookinger, label, status
EDI	Bestillinger/ordrebekreftelser, pakkseddel, faktura	Ordre, bekreftelser, statusmeldinger
Punch‑out	Katalog og pris til innkjøpssystem	Handlekurv tilbake til kunde

Praktisk råd: Dokumentér hvilke felter som er kritiske i B2B (EAN/GTIN, UNSPSC, GLN, kundenummer, referansefelt, leveringsadressehierarki).

Integrasjonsmønstre og tekniske alternativer

Det er sjelden nok med “en API‑integrasjon”. B2B trenger flere mønstre samtidig.

Synkron API (request/response)

Bruk når

• Brukeren må få svar der og da: pris, tilgjengelighet, fraktalternativ.

Fordeler

• Oppdatert informasjon i sanntid.

Ulemper

• Avhengighet: ERP‑nedetid = dårlig nettbutikk.
• Risiko for treghet ved tunge prisregler.

Typisk tiltak

• Cache (Redis) + timeout + fallback (sist kjente verdi) for ikke‑kritiske kall.

Asynkron/event‑drevet integrasjon

Bruk når

• Data kan komme litt senere: produktoppdateringer, lagerbatch, ordrestatus, kundesynk.

Fordeler

• Robusthet: kø + retry gir stabil drift.
• Skalerer bedre.

Ulemper

• Krever mer arkitektur og overvåkning.
• “Eventually consistent” kan skape forvirring hvis ikke UX er tydelig.

Batch‑integrasjon (fil, nattkjøring)

Bruk når

• Data endrer seg sjelden, eller volumet er stort og tolererer forsinkelse (f.eks. full produktkatalog).

Fordeler

• Enkelt å komme i gang.

Ulemper

• Ikke egnet for dynamisk pris/lager for store kunder.
• Feil kan bli oppdaget sent.

EDI

Bruk når

• Kunden krever standard meldingsformat og prosess (ordre, ordrebekreftelse, faktura).
• Dere har etablerte EDI‑prosesser i bransjen.

Fordeler

• Standardisert for mange enterprise‑kunder.
• Godt for formelle dokumentflyter.

Ulemper

• Tregere endringer, mer mapping, mer drift.
• Mindre fleksibelt enn API for nye behov.

Punch‑out

Bruk når

• Kundens innkjøpssystem skal styre handleopplevelsen, men dere skal levere katalog og pris.

Viktig å avklare

• Hvordan priser og avtaler eksponeres.
• Sikkerhet (SSO, token‑utveksling) og revisjonsspor.

Praktiske implementeringsvalg: connectors, iPaaS eller custom?

Her er en enkel måte å vurdere “hvordan” dere bør integrere.

Alternativer og trade‑offs

Tilnærming	Fordeler	Ulemper	Passer best når
Ferdige connectors / native integrasjoner	Raskere oppstart, ofte billigere i prosjekt	Kan dekke 80% men ikke 100%, kan være begrenset	Standard prosess og vanlig ERP‑oppsett
iPaaS / integrasjonsplattform	God oversikt, mappingverktøy, ofte overvåkning innebygd	Løpende lisens, kompetanse på plattform, mulig låsing	Mange integrasjoner og behov for rask endring
Custom API/middleware (egen kode)	Full kontroll, kan optimaliseres for B2B‑regler og ytelse	Mer utvikling og forvaltning, krever moden drift	Kompleks domenelogikk, strenge SLA‑krav, mange spesialcase

Praktisk tommelfingerregel

• Hvis dere har få integrasjoner og standard behov: start med connector/iPaaS.
• Hvis dere har pris/katalog som er konkurransefaktor og mye særlogikk: bygg et tydelig middleware‑lag, selv om det koster mer.

Migrasjon og utrulling: steg‑for‑steg plan

Migrasjon i B2B er ofte en kombinasjon av dataflytting, ny logikk og ny organisering.

Readiness‑sjekkliste (før dere starter)

• Har dere definert masterdata (ERP vs PIM vs commerce)?
• Har dere ryddet i:
• kundestruktur (organisasjoner, avdelinger, leveringsadresser)
• produktstruktur (varianter, enheter, pakninger)
• prisregler (hvilke avtaler gjelder hvor)
• Er integrasjonsbehov dokumentert per prosess:
• “vis pris”, “legg i kurv”, “opprett ordre”, “ordrestatus”, “retur”
• Er SLA/ytelseskrav satt (f.eks. maks responstid på prisoppslag)?
• Har dere avklart GDPR og datalagring (EU‑krav, underleverandører)?

Datamapping som må sitte (ofte undervurdert)

• Produkter: ID/SKU, enheter (stk/krt/pall), alternativer, dokumenter.
• Kunder: kundenummer, hierarki, roller, kredittrammer.
• Priser: prislister, rabatter, kontrakter, valuta, mva-regler.
• Ordre: linjetyper, fraktlinjer, gebyr, referansefelt, leveringsbetingelser.

Utrullingsløp som reduserer risiko

• Pilot: én kundegruppe, begrenset katalog, “happy path” for ordre.
• Parallelldrift: gammel og ny løsning lever samtidig for utvalgte kunder.
• Trinnvis migrasjon: flytt først katalog, deretter kunder/priser, så ordre/retur.
• Cutover‑plan: tydelig tidspunkt, frysperiode, backout/rollback.

Testing dere bør planlegge (ikke bare “smoke test”)

• Integrasjonstester (API‑kontrakter, mapping, feilkoder).
• End‑to‑end tester (innlogging → pris → ordre → ERP → status).
• Lasttest (store kataloger, mange samtidige prisoppslag).
• Feilscenarier (ERP nede, kø full, timeouts, duplikate ordre).

Evaluering og scorecard for shortlist

Bruk scorecardet under i en workshop. Vekt kriteriene etter hva som er kritisk for dere.

Scorecard (kopierbar sjekkliste)

Kriterium	Spørsmål dere må svare på	Vurdering (1–5)	Notater
Tid til marked	Kan vi lansere en pilot på 6–12 uker?
B2B‑funksjon	Roller, godkjenning, kundekatalog, quick order
Pris og avtaler	Støtter den prisregler uten “spesialhack”?
Integrasjoner	ERP/PIM/CRM/WMS/EDI: finnes det mønstre og erfaring?
API‑first	Åpne APIer, webhooks, versjonering, rate limits
Skalerbarhet/ytelse	Store kataloger, cache‑strategi, søk
Sikkerhet/compliance	GDPR, datalagring i EU, tilgangsstyring, logging
Partnernettverk	Finnes det implementatører og support i markedet?
TCO	Lisens + drift + integrasjon + videreutvikling
Vendor lock‑in	Hvor dyrt er det å bytte ut komponenter senere?

Ikke‑funksjonelle krav: sikkerhet, compliance, ytelse og SLA

B2B‑kunder forventer ofte mer dokumentasjon og kontroll enn B2C.

Sikkerhet og compliance (GDPR, ISO 27001)

Konkrete minstekrav å spesifisere:

• Databehandleravtale og oversikt over underleverandører.
• Dataplassering (EU/EØS) hvis det er krav fra kunder eller interne retningslinjer.
• Kryptering i transitt (TLS) og i hvile (der det er relevant).
• Tilgangsstyring:
• SSO/OAuth der det passer
• MFA for admin
• Rollebasert tilgang for kundebrukere
• Revisjonsspor (hvem gjorde hva, og når), spesielt ved godkjenning.

ISO 27001 er ofte et kundekrav i enterprise‑segmentet. Hvis leverandør eller driftspartner har sertifiseringer, bør det dokumenteres i innkjøpsprosessen (uten at du antar at det finnes).

Ytelse og skalerbarhet

Typiske flaskehalser i B2B:

• Prisoppslag mot ERP.
• Søk i store kataloger.
• Generering av kundespesifikke lister.

Praktiske tiltak:

• CDN for statisk innhold og bilder.
• Redis for pris/tilgjengelighet med korte TTL‑er og tydelig fallback.
• Asynkrone jobber for tunge oppgaver (import, beriking, indeksbygging).
• Rate limiting og kø‑basert beskyttelse mot “pris‑storm” ved store kunder.

SLA og drift

Avklar tidlig:

• Hvem overvåker integrasjonene 24/7 (eller i arbeidstid)?
• Hva er “kritisk nedetid” (bestilling stopper) vs “degradert” (pris litt treg)?
• RTO/RPO (gjenopprettingstid og datatap‑toleranse) hvis dere har strenge krav.

Eksempelarkitektur (tekstlig diagram), headless med ERP‑integrasjon

Dette er en typisk dataflyt for B2B der ERP er master for pris/kunder, og PIM er master for produktberiking.

Komponenter

• Frontend (Next.js)
• Commerce API (headless commerce)
• Middleware / integrasjonslag
• ERP (f.eks. Dynamics 365 / Business Central)
• PIM
• Kø (RabbitMQ/Kafka)
• Cache (Redis)
• Søk (egen tjeneste)

Flyt (forenklet)

1. Bruker logger inn i frontend → token/SSO valideres i commerce.
2. Frontend henter kundekontekst (kundeID, rolle, avtaler) fra commerce.
3. Produktliste:

• Commerce henter produktdata fra PIM (synkronisert/batch) og søker via søketjeneste.

1. Pris og tilgjengelighet:

• Frontend/commerce spør middleware om pris/lager for kunde + handlekurv.
• Middleware sjekker Redis først (cache).
• Cache miss → middleware kaller ERP API.
• Middleware normaliserer svar og lagrer kortvarig i Redis.

1. Ordreplassering:

• Commerce oppretter ordreutkast.
• Commerce sender “OrderCreated” event til kø.
• Middleware plukker event, validerer og oppretter ordre i ERP.

1. Ordrestatus:

• ERP sender statusendringer (API/webhook/batch) til middleware.
• Middleware publiserer event tilbake til commerce, som viser status til kunden.

1. Feilhåndtering:

• Hvis ERP er nede ved prisoppslag: vis cached pris med tydelig merking, eller blokker kjøp for kritiske kunder.
• Hvis ERP er nede ved ordre: behold ordre i kø med retry + varsling til drift.

Denne flyten gjør at dere kan skalere og feilsikre uten at ERP må tåle “nettbutikk‑trafikk” direkte.

Estimater: typiske tidslinjer og kostnadsområder

Tall varierer mye. Under er intervaller som ofte brukes i planlegging, gitt at dere har avklart scope og tilgang til APIer. Se på dette som grove planleggingsintervaller, ikke tilbud.

Leveranse	Typisk tidsintervall	Avhenger mest av
Enkel ERP‑connector (ordre + kundesynk)	4–10 uker	ERP‑API‑kvalitet, felter, testmiljø, avvik
Pris og lager (kundespesifikt) med caching	6–12 uker	Prislogikk, volum, ytelseskrav, fallback
PIM‑innføring (grunnoppsett + første kanal)	4–12 uker	Datakvalitet, modellering, berikingsprosess
Full migrasjon for mellomstor B2B	3–9 måneder	Antall integrasjoner, pris/katalog‑kompleksitet, test og utrulling
Enterprise composable med flere markeder	6–18 måneder	Styring, domener, sikkerhet, endringsledelse

Kostnadsdrivere (TCO) dere bør synliggjøre

• Lisens (plattform + evt. iPaaS + søk/PIM).
• Implementasjon (integrasjon, data, frontend, UX).
• Drift/overvåkning (SLA, vakt, logging).
• Videreutvikling (prisregler endres, nye kunder krever nye flyter).

Konkrete anbefalinger: fra evaluering til pilot

En pilot som går bra er ofte den beste “salgsprosessen” internt.

• Velg én kundegruppe med representativt behov, men begrens kompleksiteten.
• Definer MVP tydelig:
• innlogging
• kundespesifikk katalog/pris
• ordre til ERP
• ordrestatus tilbake
• Sett KPI‑er:
• andel ordre digitalt
• feilrate i integrasjon
• responstid på pris/lager
• kundesupport-henvendelser per ordre
• Avtal driftsansvar før produksjon:
• hvem eier integrasjoner
• hvem følger opp feil
• hvor raskt skal feil løses

Sammendrag og handlingspunkter

B2B e‑handel handler mest om dataflyt og kontroll, ikke bare publisering.

• Velg plattformtype etter hvor mye dere må skreddersy pris, katalog og arbeidsflyt.
• Beskriv løsningen som en stack: frontend, commerce, PIM, integrasjon, ERP, cache, søk, drift.
• Prioriter integrasjonsmønstre som tåler virkeligheten: kø, retry, overvåkning og caching.
• Reduser risiko med pilot, parallelldrift og tydelig datamapping.
• Bruk scorecardet til å rangere alternativer etter deres faktiske behov, ikke leverandørens standarddemo.

Ofte stilte spørsmål (praktiske svar)

Hvilken e‑handelsplattform passer best for B2B: alt‑i‑ett, Shopify Plus eller composable?

Det kommer an på hvor “spesiell” B2B‑logikken deres er. Hvis dere kan standardisere mye og vil raskt ut, fungerer alt‑i‑ett eller Shopify/Shopify Plus ofte bra. Hvis kundespesifikke priser, kataloger og prosesser er komplekse og endrer seg ofte, er composable/headless ofte et tryggere valg på sikt (men krever mer arkitektur og forvaltning).

API vs EDI for ERP‑integrasjon, når bør vi bruke hva?

Bruk API når dere trenger sanntid (pris, lager, status) og vil endre flyt raskt. Bruk EDI når kundene krever standard dokumentflyt (ordre, ordrebekreftelse, faktura) eller bransjen deres er EDI‑tung. Mange ender med begge: API for nettbutikkopplevelse, EDI for utvalgte storkunder.

Trenger vi PIM for B2B, og hva er gevinstene?

Hvis dere har mange produkter, varianter og attributter, eller flere kanaler/markeder, gir PIM ofte stor effekt: bedre datakvalitet, raskere publisering, færre feil og enklere integrasjon mot nettbutikk og andre kanaler. Har dere få produkter og enkel struktur, kan dere utsette PIM. Men planlegg for det hvis katalogen vokser.

Hvor lang tid tar en typisk B2B‑migrasjon og hva koster det grovt?

En mellomstor migrasjon tar ofte 3–9 måneder. Men integrasjoner og prislogikk kan flytte det i begge retninger. Kost varierer for mye til å gi ett tall uten scope. Men det er vanlig at integrasjoner, test og datarensing blir en større del enn mange tror. Be om estimat per integrasjon og per kritisk prosess (pris, ordre, status), ikke bare “plattformpris”.

Hvordan håndterer vi komplekse prisregler og kundespesifikke kataloger?

Start med å definere hvor pris skal beregnes: ERP, commerce eller en egen pris‑tjeneste. I B2B er ERP ofte kilden. Men dere bør bruke caching (Redis) og ha fallback‑strategi for å unngå at ERP blir flaskehals. Kundespesifikke kataloger løses typisk via tilgangsregler (segment/avtale) og indeksering i søk, slik at brukeren bare kan finne produkter de faktisk har rett til.

Hva betyr API‑first for integrasjoner og for valg av plattform?

API‑first betyr at funksjonene er tilgjengelige og stabile via APIer (og gjerne webhooks/events), ikke bare i et admin‑grensesnitt. Det gjør det enklere å bygge headless, koble på PIM/ERP. Og automatisere prosesser. Sjekk spesielt: autentisering, rate limits, versjonering og kvalitet på dokumentasjon.

Når bør vi velge en managed SaaS versus bygge composable med mikrotjenester?

Velg managed SaaS når dere vil redusere drift og kan leve med plattformens prosesser. Velg composable når dere har mange integrasjoner, behov for fleksibilitet, eller når commerce bare er én del av et større digitalt landskap. Mikrotjenester er ikke et mål i seg selv. Det viktige er robust integrasjon og tydelig eierskap til data.

Hvilke non‑functional krav må vi sette som minimum (SLA, GDPR, datalokalisering)?

Minstekrav bør beskrive: databehandlerrolle og underleverandører (GDPR), hvor data lagres (EU/EØS hvis nødvendig), tilgangsstyring (SSO/MFA), logging og revisjonsspor. Og en enkel SLA med responstid/oppetid. I tillegg: plan for overvåkning og feilhåndtering av integrasjoner.

Skal vi bruke iPaaS eller en integrasjonspartner med prebuilt connectors?

Hvis dere trenger rask fremdrift og har mange standardintegrasjoner, kan iPaaS eller connectors være riktig. Hvis dere har mye spesiallogikk, høy feilkost eller strenge SLA‑krav, er en integrasjonspartner eller egen middleware ofte tryggere. Vurder også kompetanse: hvem skal drifte og endre integrasjonene om 12 måneder?

Hvordan teste og overvåke integrasjoner i produksjon (observability, retry, alerting)?

Ha minst: sentral logging, dashboards for feilrate og responstid. Og varsler ved kø‑oppbygging eller mange retries. Bygg idempotens (håndter duplikate events) og bruk “dead letter queue” for meldinger som ikke lar seg prosessere automatisk. Logg nok til å feilsøke uten å lagre mer persondata enn nødvendig.