B2B-portal: erp system og programvareutvikling

En B2B-bestillingsportal lar godkjente kunder se sin egen katalog og sine priser, legge inn og gjenta bestillinger og følge dokumenter, alt synkronisert med et erp system. Avgrens omfanget i faser: kontoer, priser og bestillinger kommer først, betaling og godkjenninger følger etter. En portal som forsøker å lansere alt på én gang, blir som regel forsinket og lite brukt.

Hva er en B2B-bestillingsportal?

En B2B-bestillingsportal er en profilert nettkanal der godkjente distributører og bedriftskunder logger inn og handler selv: De blar i katalogen som er tilgjengelig for kontoen deres, ser avtalte priser, oppretter eller gjentar en bestilling og finner dokumentene som hører til kontoen, som tilbud, bestillinger, fakturaer, kreditnotaer og leveranser. ERP-systemet er kildesystemet; portalen er vinduet inn til det, med regler for hva hver konto kan se og gjøre.

Det er nyttig å skille portalen fra tre nærliggende løsninger den ofte forveksles med:

En nettbutikk. Utsalgspriser, åpen registrering og kortbetaling. En distributørportal er det motsatte: Tilgang gis per konto, prisene er avtalte, og betaling følger avtalte vilkår i stedet for en betaling ved utsjekking.

Et kundeområde på et markedsføringsnettsted. Nyttig for nedlastinger og supportsaker, men uten katalog-, pris- og bestillingslogikk fjerner det ikke én eneste telefonsamtale til salgsavdelingen.

En PDF-prisliste på e-post. Slik de fleste distributører arbeider før de får en portal: korrekt den dagen den sendes, utdatert uken etter og umulig å søke i per konto.

Det som gjør dette til et prosjekt og ikke bare et nettsted, er integrasjonen: Katalogen, prislistene, kredittstatusen og de åpne dokumentene ligger allerede i systemer som driver virksomheten. Portalen må samsvare med dem for hver konto, valuta og hvert tidspunkt. Derfor behandler avsnittene nedenfor dette som et sentralt spørsmål om omfang, ikke som en teknisk detalj. De fleste skuffende portalprosjekter feilet på denne samordningen, ikke på design.

Funksjonstabell: må ha, bør ha, senere

Leverandørenes funksjonssider lister opp alt på én gang. Faseinndeling gjør det mulig å levere den første versjonen. Tabellen sorterer de vanligste funksjonene etter hva første versjon trenger, hva den andre vanligvis legger til, og hva som kan vente til dere har bruksdata:

Tabell A: funksjon | formål | fase (1/2/3) | ERP-avhengighet

Funksjon	Formål	Fase	ERP-avhengighet
Kundekontoer og innlogging	Hver distributør ser bare sine egne data	1	Kontoer og kontaktpersoner
Prislister per konto	Avtalte priser, prisgrupper eller trinnpriser per konto	1	Prislister og prisgrupper
Katalog med synlighet per konto	Produkter hver konto kan kjøpe, med dokumenter og bilder	1	Produktregister, regler for konto og produkt
Hurtigbestilling og gjenbestilling	Artikkelnumre, CSV eller opplastingsfelt, gjenta siste bestilling	1	Produktregister, regler for minsteordre
Overføring av bestilling til ERP	Bestillingen blir et ERP-dokument, ikke en e-post	1	Bestillings-API eller integrasjonskanal
Bestillingsstatus og dokumentvisning	Fakturaer, kreditnotaer og leveranser vises per konto	2	Dokumentarkiv eller økonomisystem
Tilbud og konvertering fra tilbud til bestilling	Prisforespørsel, godkjenning og konvertering til bestilling	2	Tilbudsdokumenter i ERP-systemet
Kredittgrenser og betalingsvilkår	Vis kontoens status og vilkår; blokker innsending utenfor reglene	2	Kredittdata og vilkår i ERP-systemet
Betaling i portalen	Betal fakturaer eller bestillinger på nett	3	Betalingsformidler og avstemming mot ERP
Roller for bestillingsgodkjenning	Innkjøper foreslår, godkjenner frigir, med grenser per rolle	3	Godkjenningsdata eller arbeidsflyt i portalen
Flerspråklig katalog og dokumenter	Handelsspråk per marked eller konto	3	Produktoversettelser, dokumentmaler
Sporing og leveringsvarsler	Leveringsstatus uten å ringe salgsavdelingen	3	Logistikk- eller fraktdata

Fase 1 er lanseringen som endrer arbeidsmåten: Når en distributør kan logge inn, se prisene sine, gjenta forrige måneds bestilling og få den inn i ERP-systemet, begynner telefon- og regnearkarbeidet å forsvinne av seg selv. Fase 2 og 3 legger til økonomi- og styringslagene. Før programvaren kan håndtere dem, må virksomheten ta beslutninger om kreditt, økonomi og godkjenning.

Integrasjon med ERP-system og CRM

Integrasjonen avgjør om portalen blir et speil av virksomheten eller en brosjyre med innlogging. Fire spørsmål må besvares skriftlig før dere velger arkitektur:

Synkroniseringsretning. Grunndata – kontoer, produkter, priser og vilkår – går fra ERP-systemet til portalen. Bestillinger, tilbudsforespørsler og betalinger går tilbake. Alt annet trenger en tydelig ansvarlig: Hvem kan endre en pris, og hvor lagres endringen?

Synkroniseringsfrekvens. Nattlig satsvis synkronisering, jevnlig oppdatering gjennom dagen eller nær sanntid. En realistisk regel er at priser og kredittstatus krever hyppigere synkronisering enn produktbilder. En blandet strategi er derfor vanlig: kritiske data oftere, kataloginnhold sjeldnere.

Håndtering av feil. Hva gjør portalen når ERP-systemet er nede eller en post ikke består valideringen: Legger den den i kø, avviser den eller viser den sist kjente status med et tydelig varsel? Stille feil er årsaken til at en distributør bestiller til forrige ukes pris. Da blir det deres tvist, ikke distributørens.

Avstemming. Hvordan vet dere at hver portalbestilling ble til nøyaktig ett ERP-dokument, uten duplikater, mangler eller delvis konverterte poster? Svaret er en driftsrapport noen leser daglig de første månedene. Dette er også en av godkjenningstestene nedenfor.

To utrullingsmønstre dekker de fleste prosjekter. Den ERP-native løsningen bygger portalen som en utvidelse av ERP-systemets egne funksjoner. Det minimerer antallet systemer som må samordnes, men arver ERP-systemets begrensninger i brukergrensesnittet. Plattformløsningen bruker en handelsplattform – Shopify og lignende systemer er vanlige eksempler i leverandørmateriell – og kobler den til ERP-systemet via mellomvare eller koblinger. Denne løsningen gir større fleksibilitet i brukergrensesnittet og et velkjent administrasjonsgrensesnitt, men legger til enda et system som må holdes synkronisert. Siden om skreddersydd kontra standard ERP går grundigere inn i spørsmålet om å bygge eller kjøpe, mens sjekklisten for leverandørforespørsler gjør begge alternativene om til spørsmål dere kan poengsette i et tilbud.

Flerspråklige kataloger og flere valutaer

Eksportører møter begge spørsmålene tidlig, og det er billigere å ta stilling til dem nå enn å bygge dem inn senere.

Språk. Katalogen trenger oversettelser av produktnavn, kategorier og dokumenter. Kontostrukturen trenger en språkinnstilling per konto, slik at portalen ikke ber den samme kjøperen velge språk ved hvert besøk. To praktiske punkter: Avgjør hvem som har ansvar for oversettelsene og hvor ofte de oppdateres. En halvoversatt katalog gir et dårligere inntrykk enn en katalog bare på engelsk for kjøperen som legger merke til det. Avgjør også om dokumenter (tilbud, fakturaer) skal følge grensesnittspråket eller bruke språket økonomisystemet krever. Det siste er ikke et teknisk spørsmål: En faktura på feil språk er et regnskapsproblem.

Valutaer. Priser avtalt i én valuta skal vises i den valutaen uansett hvor besøkende befinner seg. Å blande visningsvalutaer med avtalte valutaer skaper tvister. Hvis en konto handler i flere valutaer, må regelen ligge i ERP-dataene, ikke i portalinnstillingene. Portalen må aldri finne opp en valutakonvertering.

Begge temaene påvirker faseplanen: En eksportør som selger til tre markeder, kan lansere fase 1 på språkene disse markedene faktisk bruker i bestillingene, og legge til flere katalogspråk etter hvert som markedet krever det. Den generelle regelen for språk på kommersielle nettsteder – én ansvarlig, én kildefil, én oppdateringsmåte – er beskrevet på siden om internettmarkedsføring, og gjelder på samme måte for en portalkatalog.

Sikkerhet og roller

En portal gir tilgang til kommersielle data. Derfor handler designspørsmålene om tilgang:

Tilgang gis, brukere registrerer seg ikke selv. Teamet deres oppretter hver konto med utgangspunkt i en ERP-konto. Alternativet, åpen registrering med et godkjenningstrinn, inviterer til støy og gjør det uklart hvem som faktisk er kunde.

Rollebaserte tillatelser. En innkjøper kan opprette og sende inn bestillinger innenfor en grense; en godkjenner kan frigi dem; en lesetilgangsbruker kan bare lese dokumenter. Grenser per rolle er en del av de kommersielle vilkårene, ikke en teknisk detalj. De angir hvem hos kunden som kan forplikte virksomheten.

Kontoseparasjon. Den alvorligste feiltypen for denne typen produkt er at én distributør ser en annens priser eller dokumenter. Synlighet for data per konto må testes uttrykkelig. Det er også en av godkjenningstestene nedenfor.

Revisjonsspor. Hvem la inn bestillingen, hvem godkjente den, hvem endret en pris og når – lagret som data, ikke som loggfiler noen må overtales til å lese. Handelstvister avgjøres oftere ved hjelp av dette sporet enn av hukommelsen.

Identitet og enkel pålogging. For større distributører er enkel pålogging (SSO) mot deres egen katalog et vanlig krav som det lønner seg å avgrense sent, ikke tidlig. De fleste kontoer klarer seg fint med invitasjoner og passord helt til hovedkontoret ber om føderert pålogging.

Databeskyttelse. Kundedata i portalen omfattes av de samme pliktene virksomheten allerede har for kunderegistrene sine. For virksomhet i Tyrkia gjelder KVKK-rammeverket, og for europeiske kunder GDPR. Dette behandles grundig på siden om utkontraktering i sammenheng med samarbeid med en utviklingspartner.

Skreddersøm eller plattform

Valget handler ikke om skreddersøm kontra standardløsning i abstrakt forstand, men om hvilket lag dere faktisk kjøper.

Tabell B: alternativ | dette får dere | dette må dere håndtere | passer når

Alternativ	Dette får dere	Dette må dere håndtere	Passer når
ERP-native portal	Ett kildesystem, konsistente priser og kredittdata, færre grensesnitt	ERP-systemets funksjoner begrenser brukergrensesnitt og mobilitet; ERP-systemets utgivelsessykluser styrer portalen	ERP-systemet er moderne, portalmodulen dekker det meste av fase 1, og intern IT kan administrere den
Handelsplattform + ERP-kobling	Velkjent administrasjon, godt brukergrensesnitt og mobilopplevelse, raskt katalogarbeid	Et ekstra system som må holdes synkronisert, vedlikehold av koblingen, to oppgraderingsløp	Kjøpsopplevelsen er like viktig som dataene, og noen har langsiktig ansvar for integrasjonen
Skreddersydd portal	Nøyaktig tilpasning til de kommersielle reglene, også de uvanlige som kjennetegner handelen deres	Fullt ansvar for sikkerhet, ytelse, oppgraderinger og hele livssyklusen	Prosessen skiller faktisk virksomheten fra andre, og ingen plattform støtter den. Test dette ved å spørre om en standardfunksjon pluss en prosessendring ville være nok

De fleste eksportører velger det midterste alternativet første gang. Feilen er å behandle det som det billige alternativet: En kobling er et produkt som må vedlikeholdes, og kostnaden kommer tilbake. Beslutningsrammeverket for dette spørsmålet – konfigurere, kjøpe eller bygge – behandles grundig på siden om skreddersydd kontra standard ERP. Denne siden legger til den portalspesifikke testen: Uansett hva dere velger, må prislister per konto og overføring av bestillinger til ERP-systemet kunne dokumenteres som korrekte. Velg alternativet som gjør dette mulig med lavest løpende kostnad.

Trinnvis lansering og godkjenningstester

En portallansering kan mislykkes i det stille når «det fungerer» betyr «demoen fungerte». Hver fase bør ha skriftlige godkjenningstester som kjøres med virkelige kontoer og data:

Katalogsynlighet per konto. Logg inn som to forskjellige distributører. Hver av dem skal se nøyaktig sitt eget produktutvalg og ikke kunne spore noe fra den andres. Test dette med vilje, ikke ta det for gitt.

Korrekte priser. For et utvalg kontoer og artikler skal portalprisen være lik ERP-prisen, inkludert reglene bak den (prisgruppe, trinn eller avtale). Dette beskytter det kommersielle forholdet. Feil pris i en portal er verre enn feil pris i et tilbud, fordi kunden har sett den som en stående avtale.

Bestillingsintegritet. En bestilling fra portalen skal bli til nøyaktig ett ERP-dokument med riktige artikler, antall, enheter og priser, og avstemmingsrapporten skal vise den. Test også feilsituasjonen: En bestilling som blokkeres av en regel, skal forklare dette tydelig i stedet for å feile i det stille.

Status og dokumenter. En faktura og en levering som er registrert i ERP-systemet, skal vises i riktig kontos portal med riktig status innenfor avtalt synkroniseringstid.

Vilkår og grenser. Kreditt- og betalingsvilkår per konto skal vises riktig. Hvis reglene tilsier at en bestilling skal blokkeres eller merkes, skal den blokkeres eller merkes. Test grensetilfellene, ikke bare de enkle tilfellene.

De daglige arbeidsvanene. Gjenbestilling, hurtigbestilling med artikkelnummer og søk skal testes med produktlistene til to virkelige distributører, ikke med demokatalogen. Bruken står og faller på disse tre arbeidsflytene, og det koster lite sammenlignet med utviklingen å teste dem ordentlig.

Rekkefølgen på lanseringen er like viktig som testene: Begynn med ett pilotmarked eller noen få kontoer, ta inn tilbakemeldingene og åpne deretter for flere. Alternativet – å kunngjøre lanseringen for alle distributører samme dag – gjør de uunngåelige rettelsene de første ukene til et tap av tillit. Distributører som oppdager feil priser den første uken, går ofte tilbake til telefonbestillinger i månedsvis. Pilotprinsippet er det samme som beskrives for programvareprosjekter på siden om utkontraktering, og evalueringsrutinene for teamene som bygger portaler, finnes i sjekklisten for leverandørforespørsler.

Ofte stilte spørsmål

Trenger vi et ERP-system først?

Ikke et nytt, men dere trenger et pålitelig sted for grunndata: kontoer, produkter, prislister og vilkår. Hvis disse bare finnes i regneark, vil portalen automatisere regnearkfeilene for hver konto. Det er verre enn å fortsette med telefon. Da er den fornuftige rekkefølgen å rydde opp i dataene først, ofte i et eksisterende ERP-system som brukes for lite, og deretter innføre portalen. Siden om Odoo for handelsbedrifter behandler beslutningen fra ERP-siden.

Kan kundene ha egne prislister?

Ja. Priser per konto er selve kjernen i denne typen produkt, ikke et tillegg: prisgrupper, trinnpriser eller individuelle avtaler, alt lagret i ERP-systemet og vist per konto. Insister på at portalen aldri beregner priser selv. Den viser det ERP-systemet inneholder, og hver pris en distributør ser, kan spores til en avtale teamet deres har inngått.

Hvordan godkjennes bestillinger?

Vanligvis på to nivåer. I kundens organisasjon styrer kunden godkjenningen: En innkjøper foreslår, en godkjenner frigi bestillingen, eventuelt innenfor bestemte grenser. Portalen kan håndtere disse rollene i fase 3. I deres egen organisasjon kommer bestillingen inn i ERP-systemet og følger den vanlige behandlingen. Portalen erstatter ikke kontrollene i salgsavdelingen; den fjerner dobbeltregistreringen og telefonsamtalene rundt dem.

Kan portalen håndtere flere språk?

Ja, og det bør den, men avklar omfanget for hver fase. Katalogoversettelser, språkvalg per konto og oversatte dokumenter er tre ulike oppgaver. Lanser fase 1 på språkene de aktive markedene bruker i bestillingene, og legg til resten når det finnes reell etterspørsel. Styringen av dette – én ansvarlig for oversettelsene og én oppdateringsmåte – er omtalt i avsnittet om flere språk ovenfor.

Hvem eier dataene?

Det gjør dere. Kontoer, priser, bestillinger, dokumenter og historikk forblir virksomhetens data i ERP-systemet. Dette bør stå i avtalen med den som bygger portalen: tilgang til driftstjenester, kildekode eller konfigurasjon og eksport av data ved avslutning må spesifiseres. Siden om utkontraktering dekker immaterielle rettigheter og vilkår for avslutning i den bredere sammenhengen rundt utviklingsavtaler.

Hvordan innfører vi portalen for distributørene?

Begynn med kontoene som bestiller mest, inviter dem personlig og ta med tre ting i den første meldingen: innloggingen deres, den synlige prislisten og navnet på én person de kan ringe. Følg deretter med på det som faktisk viser om portalen tas i bruk, ikke antall innlogginger, men andelen gjenbestillinger som kommer gjennom portalen. Det er normalt å bruke begge kanaler i noen uker: Bestill i portalen og bekreft på telefon. Det tar slutt når portalen har dokumentert riktige priser og dokumenter, som er grunnen til godkjenningstestene ovenfor.

Kilder og standarder

Det typiske funksjonssettet som beskrives her (kontoer, prislister per konto, gjenbestilling, fakturaer og kreditnotaer, synlighet per konto, roller med grenser, betalingsvilkår og betalingsformidlere) bygger på funksjonslister leverandører oppgir for B2B-bestillingsportaler generelt. Denne siden lover ingen resultater, kostnader eller tidsrammer.
Utrullingsmønstrene (ERP-native portal og handelsplattform som Shopify synkronisert med ERP via mellomvare eller koblinger) beskrives som de to vanligste løsningene. Det hevdes ikke at det finnes et partnerskap med noen plattformleverandør.
Påstander om prosess og styring bygger på sidene på dette nettstedet: skreddersydd kontra standard ERP, sjekkliste for leverandørforespørsler, Odoo for handelsbedrifter og IT-utkontraktering fra Türkiye (plikter knyttet til databeskyttelse, immaterielle rettigheter, vilkår for avslutning og pilotutforming).
Siden inneholder ingen kundecaser, portalbudsjetter eller prosjektvarigheter. Omfang, faser og kommersielle vilkår fastsettes per prosjekt i tilbudet.

Relaterte sider

Programvareutvikling · Skreddersydd kontra standard ERP · Sjekkliste for leverandørforespørsler · Odoo ERP for handelsbedrifter · Internettmarkedsføring · Be om et tilbud