Så vet ni när ni behöver ett extranät

Ett extranät är ett avgränsat nätverk för utvalda externa parter, till exempel kunder, återförsäljare och servicepartners.

En återförsäljare ringer och vill se sina egna prislistor. Ni skickar en PDF med e-post. Veckan efter ringer en annan och får en fil där en annan kunds rabatt ligger kvar.

Gränsen mellan intranät, extranät och kundportal syns sällan i en demonstration. Den syns när någon byter roll, när priset i portalen inte stämmer med affärssystemet och när ni ska uppgradera. Den här artikeln går igenom den gränsen och vad det kostar att hålla åtkomsten ren över tid.

Intranät, extranät och kundportal

Tänk er personalrummet, butiksfönstret och försäljningsrummet bakom ett lås. Intranätet är personalrummet. Där loggar anställda in och ser rutiner, interna dokument och intern kommunikation. Åtkomsten sker oftast inte från öppet internet. Kopplingen går mot interna filer och personalsystem.

Den publika webbplatsen är butiksfönstret. Alla kan titta. Ingen behöver ett konto för att se det som är menat för alla.

Extranätet är försäljningsrummet. Bara inbjudna gäster släpps in. De är utvalda externa parter, som kunder, återförsäljare och servicepartners. De når lösningen från internet. Där ligger prislistor, avtal, dokument och orderstatus. Bakom ligger behörighetsdata och utvalda delar av affärssystemet.

En kundportal är en tillämpning som byggs ovanpå ett extranät. I portalen loggar kunder in, och ofta återförsäljare med egna konton. De ser orderhistorik, skickar offertförfrågningar, beställer reservdelar och sköter annan självservice. Åtkomsten sker från internet. Order, priser och lager hämtas från affärssystemet.

Placera ert eget behov i en av de tre formerna innan ni väljer funktioner. Behöver bara anställda se materialet är det ett intranät. Behöver utvalda externa parter se avtal och orderstatus är det ett extranät. Behöver kunden själv lägga order och följa status är det en kundportal på den grunden.

Användningsområden där extranätet tar över ett flöde

Fem flöden täcker det mesta vi ser hos bolag med återförsäljare, service och projekt.

I orderflödet loggar återförsäljaren in med eget kundnummer. Personen lägger order och ser lager och egna prislistor. Affärssystemet äger pris, lager och order.

I reservdelsportalen loggar servicepartners och installatörer in. De söker artikelnummer och beställer reservdelar. Artikeldata kommer från produktinformationssystemet. Lagersaldot kommer från affärssystemet.

För kundspecifika dokument loggar kunder med avtal in. De hämtar certifikat, datablad och avtal. Dokumentlagret styr behörigheten via kundnummer.

I offertflödet skickar kunden en förfrågan och följer status. Säljaren ser samma ärende. Offerten ligger i CRM eller i affärssystemet.

I projektdelning loggar externa konsulter och entreprenörer in. De delar underlag per projekt. Här räcker ett dokumentlager. Ingen koppling till affärssystemet behövs.

E-post och delade filer blir ofta första steget, eftersom de redan finns. Risken kommer när samma underlag skickas till fel mottagare, eller när en gammal prislista lever kvar i någons inkorg.

Ett och samma extranät kan rymma flera flöden. Varje flöde behöver egen behörighet. En installatör som får se återförsäljarens nettopriser har fått fel rum, även om inloggningen fungerar.

Hos ett bolag med flera återförsäljare i olika länder brukar orderflödet flyttas först. Reservdelar, dokument och offerter kan vänta tills ordern landar rätt. Hur en digital kundportal tar över just det flödet är värt att läsa innan ni ritar fler rum.

Integrationer avgör vilka siffror kunden faktiskt ser

Ett extranät äger sällan sina data. Produktattribut och media ägs ofta av produktinformationssystemet. Pris, lager och order ägs av affärssystemet. Extranätet visar en tidsstämplad kopia. Skillnaden mellan kopia och källa är det som skapar fel.

Artikelattribut och media förs över vid varje ändring i källan. Ett fel ger fel text eller fel bild i flera kanaler samtidigt. Kundspecifika priser förs över vid varje prisändring, och ett fel pris ger fel order till fel kund. Lagersaldo förs över enligt den synkroniseringsrytm ni valt. Ett saldo som visar en vara som inte finns ger order på tomma hyllor.

Order och orderstatus förs över vid varje orderhändelse. Ett tappat meddelande ger dubblettorder eller felaktig status. Kundkontakt och roll kommer från CRM eller identitetslagret och uppdateras vid varje ändring i kundrelationen. Ett fel där visar dokument och priser för fel juridisk enhet.

Orderflödet i sig är kort. Kunden lägger ordern i portalen. Ordern skickas till affärssystemet. Bekräftelsen går tillbaka. Orderstatusen uppdateras i portalen.

Mät från start hur lång tid synkroniseringen tar, hur många meddelanden som avvisas, hur många dubblettorder som uppstår och hur stor andel av transaktionerna som måste rättas manuellt. Utan de talen vet ni inte om självservicen minskar arbetet eller bara flyttar det.

Ställ frågan om varje kopplings rytm tidigt. Rytmen för lagersaldo är en avvägning mellan färskhet och belastning. Saldo kan ofta ligga några minuter efter om ordern ändå kontrolleras i affärssystemet innan den bekräftas. Pris bör ligga tätare, eftersom kunden fattar köpbeslutet på den siffran.

Färdiga kopplingar mot affärssystem och produktinformation finns i vårt funktionsbibliotek, till fast omfattning. En ERP-integration som ni kan beskriva rad för rad är lättare att förvalta än en kopia med okänd ålder.

Behörigheten måste hänga med hela livscykeln

Säg att en inköpare byter företag och fortfarande ser det gamla företagets offerter. Åtkomsten ska då kunna tas bort i samma rutin som när rollen ändras. Ingen ska behöva lägga ett ärende till en utvecklare för att stänga en vy.

Integritetsskyddsmyndigheten rekommenderar att ni först gör en behovs- och riskanalys per roll och sedan ger varje användare en individuell behörighet. Åtkomsten begränsas till det som behövs för arbetsuppgifterna, enligt principen behöver veta. Olika nivåer behövs också för att skilja vanliga användare från administratörer.

En kund, en återförsäljare och en servicepartner ska inte dela vy. Samma inloggning ska inte ge samma prislistor, samma orderhistorik och samma reservdelsinformation. Koppla varje konto till rätt juridisk enhet, med kundnumret som källa i affärssystemet och rollen som källa i identitetslagret.

Tre händelser måste fungera utan speciallösningar. En ny kontakt kommer in och får bara sin roll. En roll ändras och den gamla vyn tas bort samma dag. Någon lämnar kunden och kontot stängs. Varje steg ska gå att utföra i administratörsgränssnittet, utan att någon redigerar databasen för hand.

Delegerad administration betyder att kunden själv hanterar sina användare. Det sparar tid hos er. Ni måste ändå kunna se vem som godkände kontot, vilken roll det fick och när det senast användes. Annars vet ni inte vem som släppte in en före detta anställd.

Granska roller med prisdata kvartalsvis och låt säljledningen signera listan. Då finns en namngiven ansvarig som bekräftar att åtkomsten fortfarande är rätt, och granskningen blir ett återkommande beslut med en tydlig ägare.

Säkerhetskraven börjar utanför inloggningssidan

Ett konto för öppna datablad får inte också öppna avtalen. Myndigheten för samhällsskydd och beredskap anger att externt åtkomliga tjänster bör placeras i ett eller flera nätverkssegment med extra skydd, där åtgärder ska upptäcka ett angrepp och hantera följderna.

Samma vägledning säger att informationssystem med behov av utökat skydd alltid ska använda flerfaktorsautentisering. Bedöm kravet utifrån vilken information användaren når.

Dela ytorna medvetet. Publik produktinformation kan ligga på en lägre nivå, medan kundspecifika priser, orderdata, avtal och teknisk dokumentation kräver den högre.

För offentliga aktörer tillkommer tillgänglighet. DIGG beskriver att digitala tillgänglighetskrav gäller extranät som publicerats den 23 september 2019 eller senare, och att äldre extranät omfattas när de genomgår en omfattande översyn. För privata bolag är lagkraven annorlunda. Den praktiska följden är densamma: självservice som reservdelsbeställning och orderhistorik måste gå att använda, felmeddelanden ska vara tydliga och formulär ska gå att nå med tangentbord.

Skriv kravbilden innan ni väljer funktioner. Den bör nämna nätverkssegment, upptäckt av angrepp, vem som tar larmet och hur en incident hanteras. Den bör också säga hur nivåerna kontrolleras igen när en integration, version eller behörighetsmodell ändras, eftersom det sällan syns i en demo. Då blir säkerhet en arkitekturfråga med kontrollpunkter.

Vad upplägget kräver och när ett extranät är fel val

Portalen blir en ny inkorg med inloggning om det saknas en intern ägare, en behörighetsmatris som säljledning och IT beslutar tillsammans eller rena kunddata med stabila kundnummer. Samma tre saker avgör om åtkomsten fortfarande är ren ett år efter go-live.

Förvaltningen ingår i kostnaden. Versionsuppgraderingar påverkar både funktioner och behörighetsmodell. Glanser Care är löpande förvaltning med fortsatt ansvar efter go-live: versionsuppföljning, kompatibilitet genom plattforms- och ERP-uppgraderingar och felrättningar. Hur den förvaltningen hänger ihop med en composable commerce\-grund är värt att läsa om ni redan har flera system i kedjan.

Den enklare vägen är ofta rätt fram till en tydlig gräns. Delad dokumentlagring med personlig åtkomst räcker när mottagarna är få och dokumenten är samma för alla. En nedladdningsbar prislista per kundgrupp räcker så länge priserna ändras sällan. Manuell orderhantering räcker när volymen ryms i en arbetsdag. Gränsen passeras när behörigheter ändras oftare än rutinen hinner med, eller när kunder med olika priser ska möta samma inloggade yta.

Ett extranät är fel val när beställningarna redan fungerar via ett fåtal återkommande kunder och personlig service. SCB visar att 30 procent av företag med minst tio anställda tog emot beställningar via egen webbplats eller app 2024. Kanalen är alltså inte universell.

Mät andelen order via portalen, antalet serviceärenden, tiden till offert och kostnaden per aktiv användare innan ni beslutar. En portal visar också vad kunderna söker efter, vad de köper och var de fastnar. Kan ni inte namnge talen har ni ingen nytta att jämföra med den enklare vägen.

Tre frågor att ställa till leverantören

Be om tre svar innan ni jämför funktioner.

Hur hanteras en användare som byter företag, vem godkänner ändringen och hur snabbt tas åtkomsten bort? Ett undvikande svar visar att livscykeln bara finns i presentationen. Ni vill höra en rutin för registrering, ändring och avregistrering, med en namngiven ägare.

Vilka system är källa för pris, lager och order, och hur ofta uppdateras data i portalen? Svaret visar om portalen är en kopia med okänd färskhet. Ni vill höra källsystem, händelse och rytm för varje datatyp.

Vilka loggar finns, vilka supportroller kan läsa kunddata och vad händer vid en incident? Svaret visar om avtalet reglerar leverantörens åtkomst eller bara funktionerna. Ni vill höra vem som kan öppna administrationskonsolen, hur privilegierade konton tidsbegränsas och vilka händelser som sparas.

Be om svaren skriftligt innan ni jämför skärmbilder. En demonstration visar ett lyckat flöde med testdata. De tre svaren visar om flödet fortfarande är rent ett år efter go-live.

Välj åtkomst och datakälla innan ni väljer portal

Ta beslutet i den här ordningen, internt, innan ni ställer frågorna till en leverantör.

Välj först ett enda flöde som ska flyttas från e-post. Orderflödet eller reservdelsbeställningen är ofta tillräckligt. Skriv sedan ner vilka roller som ska se vilka data. Skriv vilket system som är källa för varje datatyp. Först därefter blir de tre frågorna era kriterier när ni jämför funktioner.

En lösning kan börja med en contentwebb, en produktwebb eller en komplett kundportal. Alla tre byggs på samma strukturerade grund och samma koppling till affärssystemet. Ni kan alltså börja smalt och bygga vidare utan att byta datakälla.

Dokumentation, certifikat och guider kan kopplas till de produkter kunden har köpt. Det är ett naturligt första steg i självservice, eftersom kunden redan vet vilken maskin eller vilken artikel det gäller. Pris och order kan komma i nästa steg, när kundnumren är rena och behörigheten har en ägare.

På Glanser bygger vi kundportaler där roll, datakälla och förvaltning bestäms innan funktionerna läggs till. På sidan för kundportal och självservice ser ni hur självservice byggs upp från ett avgränsat flöde, med samma grund om ni senare lägger till order, reservdelar eller dokument. Gå dit och jämför ert eget flöde med den ordningen innan ni ber om en demonstration.