B2B-nettbutikk med EDI i bakkant: slik henger det sammen

En B2B-nettbutikk med EDI i bakkant betyr at bestillingene fra direktekundene og EDI-ordrene fra kjedene ender som samme ordretype, i samme system, med de samme produktdataene, lagerbeholdningen og kunderegisteret bak seg. Har du fungerende EDI mot kjedene, er mesteparten av dette baklaget allerede bygget.

Skal du bygge en bestillingsløsning for direktekundene dine, og har allerede EDI mot kjedene, er utgangspunktet bedre enn du tror.

Den vanlige antagelsen er at en B2B-nettbutikk er et nytt prosjekt som kommer i tillegg til EDI-en. I praksis er det ofte motsatt: EDI-en har allerede tvunget deg til å rydde i det som er vanskeligst. Nettbutikken er en ny inngangsdør til et hus du langt på vei har bygget.

Denne artikkelen handler om hvordan de to henger sammen, hva som allerede er på plass, og hva som fortsatt mangler.

Hva betyr det at EDI ligger i bakkant?

Uttrykket brukes om litt av hvert, så det er verdt å presisere.

En B2B-bestillingsløsning består av to lag. Frontlaget er det kunden ser: innlogging, produktkatalog, priser, handlekurv og ordrehistorikk. Baklaget er systemene som gjør bestillingen til en reell ordre: produktdata, lagerbeholdning, kunderegister, prislogikk, ordrehåndtering, fakturering og utveksling mot handelspartnere.

Når vi sier at EDI ligger i bakkant, betyr det at den samme motoren som håndterer kjedeordrene også håndterer portalordrene. Kjeden sender en ORDERS-melding, altså en strukturert innkjøpsordre, og portalen sender en bestilling, men begge ender som samme type ordre, i samme system, med samme data.

Det motsatte, og dessverre det vanlige, er at nettbutikken har sitt eget lille bakland: sin egen prisliste, sin egen produktkatalog og sin egen forståelse av hvem kunden er. Da har du to systemer som later som de er ett.

Hva har EDI-en din allerede bygget?

Dette er den delen få tenker på når de begynner å planlegge en nettbutikk.

For å komme gjennom en kjedes godkjenning måtte du rydde i ting som en nettbutikk også er helt avhengig av:

Produktdataene er strukturert. GTIN på hvert produkt, korrekte enheter, pakningsstørrelser og vekt. Uten dette blir ikke EDI-meldingene godkjent, og uten dette blir heller ikke en nettbutikk brukbar.

Ordren er et objekt, ikke en beskjed. EDI-en tvang fram et ordreløp der en bestilling opprettes strukturert, bekreftes, leveres og faktureres, med referanser mellom hvert steg. Det er nøyaktig det samme løpet en portalordre må inn i.

Lager og leveranse henger sammen med ordren. DESADV, pakkseddelmeldingen, krever at du vet hva som faktisk ble sendt. Det betyr at du har en beholdning som betyr noe.

Fakturaen bygger på ordre- og leveringsdata. Ikke på at noen skriver den fra bunnen.

Du har disiplin på avvik. Kjedene avviser meldinger som ikke stemmer. Det har lært organisasjonen at data må være riktige før de sendes, ikke etterpå.

Det er dette som er det virkelig krevende å bygge. En produsent som starter med nettbutikk uten EDI-erfaring må gjøre hele denne jobben fra bunnen, som regel midt i prosjektet, som regel når det allerede er for sent.

Hva mangler fortsatt for direktesalg?

EDI-en dekker ikke alt, og forskjellene er verdt å kjenne før du bestiller noe.

Byggekloss	Dekket av EDI-en	Hva som gjenstår
Produktdata	Ja: GTIN, enheter, pakningsstørrelser, vekt	Ingenting
Ordreløp med referanser	Ja: opprettet, bekreftet, levert, fakturert	Ingenting
Lagerbeholdning	Ja: DESADV forutsetter reell beholdning	Ingenting
Fakturagrunnlag	Ja: bygger på ordre- og leveringsdata	Ingenting
Disiplin på datakvalitet	Ja: kjedene avviser feil før de slipper gjennom	Ingenting
Kundespesifikke priser	Nei: prisen avtales i en annen prosess	Avtalepris per kunde, trinn og kampanjer
Kundeidentitet	Delvis: kjeder har lokasjonsnummer	Kobling fra portalbruker til samme kundenummer
Kreditt og betaling	Nei	Kredittgrense, forfalte fakturaer, sperret konto
Selvbetjening og roller	Nei: EDI er systemer, ikke mennesker	Ordrehistorikk, gjenbestilling, flere brukere
Status til kunden	Delvis: kjeden får ORDRSP	Samme informasjon i et grensesnitt kunden ser

Kundespesifikke priser. I kjedehandelen er prisen avtalt i en helt annen prosess. I direktesalget må systemet kunne vise riktig avtalepris til riktig kunde ved innlogging, inkludert eventuelle trinn og kampanjer.

Kundeidentitet på tvers. Kjedene identifiseres med lokasjonsnummer. En portalbruker logger inn med e-post. Disse må peke på det samme kundenummeret, ellers får du to historikker for samme kunde. Dette er det samme problemet som oppstår når kundedata lever flere steder, bare med to kanaler i stedet for to systemer.

Kreditt og betalingsbetingelser. B2B-salg er fakturasalg. Løsningen må vite om kunden har kredittgrense, forfalte fakturaer eller sperret konto før ordren slippes gjennom.

Selvbetjening og roller. Kunden skal kunne se egen ordrehistorikk, gjenta tidligere bestillinger og gjerne ha flere brukere med ulike rettigheter. Dette finnes ikke i EDI-verdenen, fordi der er det systemer som snakker, ikke mennesker.

Status tilbake til kunden. En kjede får ORDRSP, en strukturert ordrebekreftelse. En direktekunde må få tilsvarende informasjon i et grensesnitt de faktisk ser.

Felles for disse fem er at de handler om mennesker som logger inn, ikke om systemer som utveksler meldinger. Det er derfor EDI-en ikke dekker dem.

I hvilken rekkefølge bør du bygge?

Her gjør mange den samme feilen: de begynner med det synlige.

En nettbutikk er lett å vurdere. Man ser den, man har meninger om den, og den føles som prosjektet. Baklaget er usynlig og kjedelig, og blir derfor ofte tatt til slutt. Da er det for sent å oppdage at prislogikken ikke finnes noe sted, eller at kunderegisteret har tre versjoner av samme kunde.

En rekkefølge som fungerer bedre:

1. Avklar hvor fasit ligger. For pris, produktdata, lagerbeholdning og kundeidentitet. Ett sted per datatype.
2. Rydd i det som ikke stemmer. Dubletter i kunderegisteret, produkter uten GTIN, priser som bare finnes i et regneark.
3. Bestem hvordan en portalordre skal se ut. Samme ordretype som en EDI-ordre, med samme felter og samme videre behandling.
4. Koble på kreditt- og prislogikken. Før noen ser en skjerm.
5. Bygg frontlaget. Nå er det den enkleste delen.
6. Test hele løpet på ekte data. Fra innlogging til faktura, inkludert et avvik underveis.

Punkt seks blir hoppet over overraskende ofte. En løsning som er testet på pene ordrer, feiler første gang en kunde bestiller et utsolgt produkt.

Hva bør du avklare før du bestiller?

Spørsmål å stille den som skal bygge det, uansett hvem det blir.

1. Blir en portalordre samme ordretype som en EDI-ordre, i samme system?
2. Hvor hentes kundens avtalepris fra, og hvor vedlikeholdes den?
3. Trekker portalen fra den samme lagerbeholdningen som kjedeordrene?
4. Hvordan kobles portalbrukeren til kundenummeret vi allerede bruker?
5. Hvor håndheves kredittgrensen, og hva skjer ved forfalte fakturaer?
6. Hva ser kunden om ordrestatus, og hvor kommer den informasjonen fra?
7. Hvem varsles når en ordre stopper, og hvordan?
8. Hva skjer med løsningen når en kjede endrer implementasjonsguiden sin?

Det siste spørsmålet skiller de som har jobbet med kjedehandel fra de som ikke har det. Kjedene oppdaterer kravene sine, og en løsning som binder front og bak tett sammen uten å ta høyde for det, blir dyr å vedlikeholde.

Kort oppsummert

• En B2B-bestillingsløsning består av et frontlag kunden ser og et baklag som gjør bestillingen til en reell ordre.
• Har du fungerende EDI mot kjedene, har du allerede bygget mesteparten av baklaget: strukturerte produktdata, et ordreløp med referanser, reell lagerbeholdning og disiplin på datakvalitet.
• Det som mangler er som regel kundespesifikke priser, kundeidentitet på tvers av kanaler, kredittkontroll, selvbetjening og status tilbake til kunden.
• Bygg baklaget først. Frontlaget er den enkleste delen når resten er avklart.
• Test hele løpet på ekte data, inkludert et avvik, før lansering.

Spørsmål og svar

Ofte stilte spørsmål B2B-nettbutikk med EDI i bakkant

Her svarer vi på de vanligste spørsmålene vi får fra nye og eksisterende kunder.

Kan vi bruke den samme løsningen til både kjedeordre og direktesalg?

Baklaget kan og bør være felles: produktdata, lager, kunderegister, ordrehåndtering og fakturering. Frontlaget er forskjellig, fordi kjedene sender strukturerte meldinger mens direktekunder logger inn og bestiller selv. Poenget er ikke å ha én kanal, men å ha ett sted der ordrene faktisk lever.

Må vi bytte ERP-system for å få dette til?

Et bytte av ERP-system er ikke nødvendigvis påkrevd. Det avgjørende er om systemet du har kan levere pris, lager og kundedata ut til bestillingsløsningen, og ta imot ordre tilbake i strukturert form. Det er en kartleggingsjobb før det er en systemjobb.

Hva om vi ikke har EDI ennå?

Da må baklaget bygges uansett, og du får ikke drahjelpen som ligger i at kjedene allerede har stilt krav. Skal du senere levere til kjedene, er det verdt å bygge produktdata og ordreløp slik at det tåler et EDI-krav, i stedet for å gjøre jobben to ganger.

Hvor lang tid tar et slikt prosjekt?

Tidsbruken avhenger helt av tilstanden på dataene dine, og det er den ærlige delen av svaret. Er produktkatalogen ryddig og kundene entydige, går det raskt. Er prisene spredt i regneark og kunderegisteret fullt av dubletter, er ryddejobben prosjektet.

Hva er den vanligste feilen?

Å starte med skjermbildene. En nettbutikk kan se ferdig ut lenge før den fungerer, fordi det som avgjør om den fungerer ligger i lag ingen ser.

Skal du se på dette?

Kundan-plattformen dekker EDI, CRM, ordre, lager, fakturering, særavgiftshåndtering og bookingfunksjonalitet, og kombinerer programvare, integrasjoner og operative arbeidsflyter i én plattform. Vi leverer EDI-integrasjoner mot norske kjøperkjeder som Vinmonopolet, ASKO, COOP, REMA, NorgesGruppen, Megaflis og Optimera, følger kundene gjennom hele EDI-onboardingen, og utvikler nettsider, nettbutikker og skreddersydde digitale løsninger for små og mellomstore bedrifter.

Det betyr at kjedehandelen og direktesalget kan planlegges som én løsning i stedet for to prosjekter som skal møtes senere. Vurderer du en bestillingsløsning for direktekundene dine, tar vi gjerne en gjennomgang av hva du allerede har på plass.