Byte av affärssystem kräver er etappplan

Ni har fått en offert på ett nytt affärssystem. Ekonomiavdelningen äger projektet och leverantören har föreslagit ett lanseringsdatum. Samtidigt hämtar webben priser från det gamla systemet, lagret skickar saldon och kundportalen visar öppna order.

Ert byte av affärssystem behöver därför en etappplan som omfattar hela orderkedjan. Varje etapp ska lämna efter sig godkända kontroller och ett tydligt beslut. Annars riskerar ni att upptäcka kanalernas beroenden först när kunderna börjar beställa.

Etapperna som styr ert byte av affärssystem

Börja med att ge styrgruppen mandat att stanna projektet. En grind fungerar först när någon kan neka nästa steg. Projektledaren samlar underlaget, processägarna godkänner verksamhetens resultat och styrgruppen beslutar om pengar och fortsatt arbete.

Använd fem grindar med konkreta utträdeskrav. Vid varje grind beslutar styrgruppen om projektet fortsätter, omplaneras eller stoppas. Godkänd datakvalitet och dokumenterade avvikelser ska följa med genom hela programmet. En kvarstående avvikelse behöver en ansvarig person och ett beslutat sätt att hantera följderna.

Förstudien ger en baslinje för processer, data, integrationer, kostnad och nytta. Dokumentera hur arbetet går till i dag, inklusive manuella rättningar, väntetider och beroenden mellan avdelningar. För godkänt utträde krävs en signerad baslinje och en budgetreserv för rensning, test, utbildning och parallell drift.

Lösningsdesignen fastställer målarkitektur och prioriterade flöden. Avgör vilka arbetssätt som ska följa med och vilka som ska ändras. För godkänt utträde krävs en dokumenterad datamodell, fastställt ägarskap och migreringsregler.

Integrationsprovet följer hela kedjan från beställning till återrapporterad orderstatus, inklusive flöden mot webb, EDI, PIM och portal. För godkänt utträde ska felen ligga under beslutad tolerans och återförsök fungera.

Användaracceptansen prövar verkliga order, priser och behörigheter. Personer från verksamheten genomför sina arbetsuppgifter och processägarna godkänner arbetsflödet. En demonstration med leverantörens exempeldata räcker som introduktion, men lämnar era undantag oprövade.

Produktionsrepetitionen prövar en produktionslik körning och möjligheten att gå tillbaka. För godkänt utträde krävs signerad avstämning av ekonomi, lager och order samt en testad återgångsplan. En godkänd grind ska gå att granska i efterhand, så spara testunderlag, avvikelser och namnet på den som godkände resultatet.

I Riksrevisionens granskning av strategiska digitaliseringsprojekt blev 44 procent av de genomförda eller pågående projekten försenade, medan genomförda projekt i genomsnitt kostade cirka 21 procent mer än ursprunglig budget. Siffrorna gäller offentlig sektor. De ger ingen prognos för ert bolag.

En reserv på den nivån kan användas som diskussionsunderlag, men behöver prövas mot era faktiska risker. Budgetera uttryckligen för datarensning, integrationstest, utbildning, tidsbegränsad parallell drift och förändringsledning. Ange också vem som får använda reserven.

Bestäm mätpunkterna före införandet: orderprecision, lagerprecision, fakturagenomloppstid, integrationsfel och faktisk användning. Då kan processägarna jämföra utfallet med utgångsläget. När flera bolag berörs är en avgränsad pilot ofta en bättre start, förutsatt att gemensamma flöden kan hållas ihop under övergången.

Kartlägg flödena innan ni väljer system

Ekonomi kan äga investeringen samtidigt som inköp och försäljning behöver göra huvuddelen av förändringsarbetet. Därför ska varje berörd processägare beskriva sitt flöde före systemvalet. Annars får leverantören en kravbild där bokföringen är detaljerad och orderkedjan lämnas öppen.

Enligt Tillväxtverkets enkät Företagens villkor och verklighet 2023 använde 55,3 procent digitalisering i stor utsträckning för administration. Motsvarande andel var 32,6 procent för inköp och 22,5 procent för försäljning.

Skillnaderna säger något viktigt om förberedelserna. Ett väl digitaliserat ekonomiflöde kan finnas bredvid ett inköpsflöde som fortfarande kräver kalkylblad. Båda behöver få plats i kravställningen, men de behöver olika stöd vid införandet.

Låt processägarna beskriva en verklig affär från början till slut. Följ kundens identitet, avtalade rabatt, artikelnummer, enhet, momskod och leveransvillkor. Markera var någon skriver in samma uppgift igen och var någon måste tolka ett undantag.

För varje informationsmängd ska ni ange vilket system som är källa. Kundregistret kan ha en källa, produktbeskrivningarna en annan och prisberäkningen en tredje. Skriv även vem som får ändra uppgifterna och hur ändringen når mottagarna.

Molnleverans behöver ingå i samma genomgång. Enligt SCB:s statistikportal köpte 72 procent av svenska företag med minst tio anställda molntjänster 2025. Siffran gäller molntjänster generellt och säger inget om molnbaserade affärssystem.

Molnleverans kan minska er egen serverdrift. Ni behöver fortfarande besluta hur data exporteras, vem som administrerar behörigheter och vem som provar uppgraderingar.

Avsluta kartläggningen med en flödesförteckning som processägarna signerar. Den ska innehålla källa, mottagare, undantag, ansvar och godkännandekrav. Bifoga ett exempel på den information som faktiskt skickas.

Ett lågt licenspris kan annars följas av omfattande arbete i webb och portal. Det händer när samma kunduppgift behöver tolkas olika i varje kanal. En gemensam informationsmodell ger er bättre förutsättningar att bedöma hela kostnaden före avtal.

Order och lager måste fungera i era kanaler

En kund lägger en beställning med avtalat pris. Portalen bekräftar ordern, men affärssystemet avvisar artikelns enhet. Om felet saknar ansvarig kan kunden tro att leveransen är bokad medan orderavdelningen saknar ett giltigt underlag.

Enligt SCB:s statistik om företagens it-användning bedrev 36,7 procent av svenska företag med minst tio anställda e-handel via webb och/eller EDI under 2024. För dessa företag påverkar ett byte av affärssystem direkt vad kunden ser i beställningsflödet.

Upprätta ett integrationskontrakt per flöde. Kontraktet beskriver vad avsändaren lovar, vad mottagaren godtar och vad som händer när något går fel. Det ska gå att använda både vid utveckling och vid felsökning efter lanseringen.

För artikeldata behöver kontraktet definiera identitet, enhet och aktiveringsstatus. För priser behöver det beskriva kundkoppling, valuta, rabatt och giltighetstid. Lagerflödet behöver skilja mellan fysiskt saldo och den mängd kunden faktiskt får beställa. Ordern till affärssystemet behöver kvittens, dubblettskydd och felhantering. Orderstatusen tillbaka behöver en överenskommen betydelse för varje status, delleveranser och en bestämd uppdateringsordning.

Ange riktning, överföringsfrekvens och tillåten fördröjning för varje flöde. Dokumentera också felkön: vem får larmet, vem rättar grundfelet och vem skickar om meddelandet. En automatisk avisering hjälper först när mottagaren har mandat att agera.

Samma regler behöver fungera i kundportal, återförsäljarportal, reservdelsportal och eventuella EDI-flöden. I genomgången av e-handel och affärssystem är kopplingen mellan försäljningskanal och orderhantering central. Kundens bekräftelse behöver motsvara det som verksamheten kan leverera.

Prova vad kunden ser när ett beroende system är otillgängligt. Bestäm om beställningen ska stoppas, sparas eller tas emot med tydligt förbehåll.

Produktinformation som berikas i PIM ska kunna distribueras till webb och portaler med samma artikelidentitet. Samtidigt behöver varje kanal kunna visa rätt sortiment och rätt behörighet.

Ett fungerande gränssnitt är därför bara början på provningen. Kontrollera också hur orderavdelningen upptäcker ett avvisat meddelande och hur kunden får besked. Den kedjan avgör om ett tekniskt fel blir ett hanterbart ärende eller en borttappad beställning.

Migrera data i tre kontrollerade körningar

Underskattad datamigrering blir särskilt besvärlig när affärssystemet ska utbyta information med webb, PIM och portaler. Ett fält kan gå att importera tekniskt och ändå få fel betydelse. En artikel som tidigare såldes per förpackning kan exempelvis tolkas som en styckartikel.

Börja med ett systemregister och en fältmappning för artikel, kund, leverantör, pris, lager, order och ekonomi. Klassificera fälten som masterdata, transaktionsdata, historik eller härledda värden. Sätt ägare, format, valideringsregel och källa före första uttaget.

Planera tre kontrollerade körningar: provuttag, full testmigrering och produktionsrepetition. Provuttaget prövar mappning och datakvalitet. Testmigreringen prövar hela datamängden, medan produktionsrepetitionen även prövar tidsåtgång och arbetsordning.

Efter varje körning ska verksamheten kontrollera resultatet med affärsrapporter och kontrollsummor. Ett tekniskt besked om lyckad import säger inget om lagervärdet eller öppna order. Spara avstämningen så att nästa körning kan jämföras med samma underlag.

För masterdata ska aktiva artiklar ha unik nyckel, godkänd enhet och giltig prisrelation. Kund- och leverantörsregister ska sakna dubbletter och ha giltiga identiteter och rätt behörigheter. Kontrollera att kundunika priser, rabatter och momskoder stämmer med källan.

För transaktionsdata ska lagersaldot stämma mellan källa och mål efter varje körning, och öppna order och delleveranser ska följa med utan dubbletter. Ekonomin kräver en signerad avstämning mot rapporter i båda systemen. Historik ska ha begriplig kontext i målet eller omfattas av ett dokumenterat arkivbeslut.

Sätt toleranserna innan testen börjar. Aktiva artiklar ska ha entydiga nycklar och giltiga enheter. Differenser i order och lager behöver kunna förklaras med dokumenterade regler, exempelvis en beslutad hantering av avslutade poster.

Prova sedan avsiktliga fel. Skicka samma order igen, fördröj ett meddelande och ändra en post medan överföringen pågår. Kräv att integrationen kan göra återförsök utan att skapa dubbla affärshändelser, det som kallas idempotens.

Rätta grundregistret där uppgiften ägs. En tillfällig rättning i importfilen behöver dokumenteras och återföras, annars återkommer felet vid nästa körning.

Vanliga kontrollpunkter är dubbletter, olika artikelnummer, saknade enheter, felaktiga momskoder och historik utan begriplig koppling till affären. Äldre data behöver ibland arkiveras med sökbar åtkomst. Beslutet ska ange vem som behöver uppgifterna och hur de ska hittas.

Parallell drift behöver ett slutvillkor. Riksrevisionens rapport om strategiska digitaliseringsprojekt beskriver projekt där kvarvarande parallella system ökade licens- och driftkostnaderna. Planera därför avvecklingen redan när den tillfälliga lösningen godkänns.

Testa lanseringen och våga stanna

Under repetitionsnatten ska teamet följa en körplan som redan är skriven. Varje aktivitet behöver ansvarig, startvillkor och ett verifierbart resultat. Nya migreringsskript under själva produktionssättningen gör det svårt att veta vad som faktiskt har provats.

Före bytet behöver ekonomi besluta vilka perioder som ska vara stängda. Masterdata fryses enligt överenskomna regler och kanalerna får besked om när gamla orderflöden upphör. Kundservice behöver kunna förklara eventuella begränsningar för kunderna.

Före frysning stämmer ekonomi och informationsägare av perioder, masterdata och den sista ordinarie överföringen. Under bytet ansvarar migreringsansvarig för att saldo och öppna order laddas i beslutad ordning. När integrationerna startar följer integrationsansvarig ett känt orderunderlag genom hela kedjan. Före öppning signerar processägarna avstämningen av ekonomi, lager och order. Efter öppning följer förvaltningsansvarig felköer, kundärenden och användning.

Använd provbeställningar som speglar era svåraste vardagsfall. Ta med kundunikt pris, delleverans, kredit och en EDI-order om ni använder kanalen. Kontrollera både resultatet i affärssystemet och beskedet till kunden.

Återgångsplanen behöver omfatta affärshändelser som redan lämnat systemen. En order kan ha skickats till lagret eller bekräftats till kund. Ange hur dessa händelser identifieras och vem som avgör om de ska fullföljas eller återföras.

Öppna inte kanalerna medan teamet fortfarande diskuterar vem som äger en kritisk differens.

Upplägget kräver processägare som kan avsätta tid. Någon behöver äga masterdata och någon måste kunna stoppa lanseringen även när leverantörer och interna team är bokade. Ledningen behöver skydda den tiden mot ordinarie arbetsuppgifter.

En samtidig koncernlansering passar dåligt när bolagen använder olika artikelidentiteter eller saknar gemensamma godkännandekrav. En avgränsad pilot ger då bättre möjlighet att prova arbetsordningen. Den kräver samtidigt en plan för informationsutbytet mellan gammal och ny lösning.

Efter öppningen behöver förvaltningen följa faktiska arbetsuppgifter. Kontrollera om användarna arbetar i det nya flödet eller återgår till egna filer. Koppla varje återkommande omväg till en ansvarig som kan ändra arbetssättet eller rätta funktionen.

Lås integrationsansvaret innan ni skriver på

När systemen börjar uppgraderas i olika takt prövas avtalet på riktigt. Affärssystemet kan ändra ett gränssnitt medan webb och PIM ligger kvar på tidigare versioner. Er genomgång av ansvaret för integrationer mot affärssystemet behöver därför omfatta hela tiden efter lanseringen.

Ställ frågan vem som äger integrationerna när systemen uppgraderas i olika takt. Be om en namngiven roll, en testordning och en väg för felanmälan. Svaret visar om någon ansvarar för hela informationsflödet när införandeprojektet har avslutats.

Begär ansvarsfördelning, provningsplan, avtalsomfattning och en förteckning över anpassningar, så att ni kan avgöra vem som samordnar felsökningen, vilka flöden som provas före uppgradering, vad som utlöser tillägg och vilka beroenden som behöver hanteras separat.

Fortsätt med frågan hur en ny version provas mot order, pris och lager, och om provningen ingår i avtalet. Ett användbart svar beskriver testmiljö, exempelorder och godkännare. Det visar om förvaltningen är budgeterad och om verksamheten behöver boka egen tid.

Be också leverantören beskriva hur ett misslyckat prov hanteras. Ni behöver veta om uppgraderingen skjuts upp, hur felet prioriteras och vem som samordnar berörda parter. Ett allmänt löfte om kompatibilitet ger för lite stöd när tidplanerna krockar.

Ett tydligt avtal beskriver både vem som rättar felet och vem som håller ihop arbetet tills flödet fungerar igen.

Avsluta med frågan vad som händer med era specialanpassningar vid uppgradering och om de ligger isolerade från övriga funktioner. Svaret visar hur mycket arbete som följer med varje ny version. Begär att beroenden och begränsningar dokumenteras före beställningen.

Ett byte kan nå go-live och ändå lämna ett dyrt versionsberoende efter sig. Därför behöver ni bedöma hur lösningen går att förändra när avtalet väl är tecknat. Den bedömningen kräver konkreta exempel från er egen orderkedja.

Ett avgränsat underlag ger er kostnadsbilden före beslut

Ett beslutsunderlag behöver skilja mellan det nya affärssystemet och förändringarna i era digitala kanaler. Kostnaden påverkas av vilka funktioner som kan behållas, vilka kopplingar som ändras och hur ansvaret fördelas. För en användbar jämförelse behöver leverantörerna räkna på samma omfattning, annars jämför ni tre olika projekt.

Vi på Glanser tar långsiktigt produktansvar för webb, produktwebb, PIM och portaler. Lösningarna byggs av Funktionsbiblioteket, där varje funktion redan är byggd, testad och prissatt innan arbetet börjar. Funktionerna finns i tre nivåer: Standard används som den är, Anpassad konfigureras efter er affärslogik och Kundunik isoleras så att den inte påverkar resten vid uppgraderingar.

För Litium och Business Central finns en färdig koppling i Funktionsbiblioteket. Omfattningen behöver ändå stämmas av mot era prisregler och undantag, och det är där kostnadsbilden kan skilja sig mellan kunder.

Glanser Care är ett avtalat ansvar till fast månadskostnad som omfattar versionsuppföljning, kompatibilitet genom uppgraderingar, underhåll av integrationerna mot affärssystemet och buggrättning. Uppgraderingar kräver ingen ny offert.

Vårt upplägg kräver att ni utser en processägare för integrationerna. Verksamhetens regler och prioriteringar behöver fortfarande beslutas av er.

Om ni vill bygga egen utvecklingskompetens och själva äga varje tekniskt vägval kan ett annat arbetssätt passa bättre. Detsamma gäller när merparten av behoven kräver fristående specialutveckling. Passformen behöver prövas innan ni binder er till en leveransmodell.

Ta med den interna arbetstiden i kalkylen. I genomgången av tre poster som saknas i er TCO-kalkyl hör reserven och arbetet efter införandet hemma i samma beslutsbild. För era kopplingar mot affärssystemet behöver underlaget ange både införande och fortsatt ansvar.

Ni kan få ett avgränsat underlag för hur er nuvarande webb, e-handel eller portal påverkas av bytet. I en 72-timmarsanalys av er befintliga lösning avsätter ni två timmar och får inom 72 timmar en inventering av funktioner och integrationer, en funktionsspecifikation, en prototyp och en komplett kostnadsbild med tidsplan, kostnadsfritt.