När ni ska koppla ihop ert affärssystem (ERP) med en e-handelsplattform eller digital kundportal är det viktigt att tidigt definiera hur systemen ska samverka. Vilken information ska delas, vilket system ansvarar för vad och hur säkerställer ni att allt fungerar som det ska? Svaren samlas i en kravspecifikation, som ska vara klar innan ni tar in lösningsförslag. Varje krav i den ska ha en ägare, ett testfall och en definition av godkänt resultat.
De flesta integrationsprojekt som drar över tiden gör det av samma skäl: parterna skrev under innan de var överens om vad som skulle byggas, vem som skulle bygga det och vem som ansvarar när det slutar fungera. Plattformsleverantören utgår från sitt API, ERP-leverantören från sitt och implementationspartnern från sin offert. Felhanteringen, övervakningen och ansvaret efter lansering hamnar mellan stolarna, eftersom ingen av de tre har fått frågan.
Enligt Litiums rapport Nordic Digital Commerce in B2B 2026 säljer 81 procent av de nordiska B2B-företagen via digitala kanaler, och 31 procent av intäkterna är digitala. När nästan en tredjedel av intäkterna kommer in digitalt och ska vidare till affärssystemet är kopplingen värd en egen kravspecifikation, skild från den som gäller e-handelsplattformen eller kundportalen i stort.
Hur en integration byggs, med arkitekturval, dataflöden och projektsteg, står i guiden Så integrerar du ERP med en B2B-webbshop 2026. Den här posten handlar om steget före: vilka krav ni ska ha på papper innan avtalet skrivs, och vilka frågor ni ska ställa till plattformsleverantören, ERP-leverantören och implementationspartnern.
1. Skriv varje krav så att det går att testa
Ett krav som "integrationen ska vara skalbar" eller "priser ska synkas i realtid" går inte att godkänna eller underkänna. Leverantören kan svara ja utan att ha lovat något, och ni upptäcker skillnaden först i acceptanstestet.
Ge varje krav fyra uppgifter: en ägare hos er, en prioritet, ett testfall och en definition av godkänt resultat. Kravet om realtid blir då något i stil med: ett avtalspris som ändras i Monitor ska visas för den inloggade kunden inom fem minuter, och det testas genom att ändra priset på tre artiklar för två kunder med olika avtal. Det kravet kan en leverantör svara på, och ni kan kontrollera svaret.
Bevent Rasch, som dubblerade sin orderingång efter lanseringen av sitt digitala säljrum, pekar ut kravspecifikationen som en avgörande framgångsfaktor. Projektledaren Martin Hjalmarsson beskriver det så här: "Om man tror att man har koll på allt, så gå igenom det ett eller två varv till med dina partners. Annars finns det risk att olika parter i projektet har olika bild av vad som ska vara med och inte, något som gör att arbetet kan dra ut på tiden."
Frågor att ställa till varje leverantör:
- Vilka av våra krav löser ni med standardfunktioner, vilka med konfiguration och vilka kräver utveckling?
- Vilka av kraven har ni levererat tidigare mot samma affärssystem och samma version?
- Vem hos er äger kravet under projektet, och vem tar över det efter lansering?
- Hur dokumenteras ett krav som inte går att uppfylla som det är skrivet, med konsekvens, alternativ och beslut?
2. Ange sanningskälla och högsta fördröjning per dataobjekt
Den vanligaste luckan i en kravspecifikation är att dataflödena beskrivs som pilar mellan system. En pil säger inget om vilket system som äger informationen, vem som får ändra den eller hur gammal den får vara när kunden ser den.
Ställ upp en rad per dataobjekt: produkt, pris, lager, order, kund och fakturaunderlag. För varje rad anger ni sanningskälla, vilket system som får ändra värdet, i vilken riktning det skickas, vilken händelse som utlöser en uppdatering och vilken fördröjning ni som mest accepterar. Lägg till en kolumn för vad plattformen ska visa om uppdateringen uteblir, eftersom det är det beteendet kunden möter den dag något går fel.
Själva avvägningarna finns beskrivna i andra poster, så de upprepas inte här. Rollfördelningen mellan affärssystem, PIM (Product Information Management) och orderhantering går vi igenom i Affärssystem för e-handel: 5 saker som faktiskt avgör om det funkar. Saldotyper, synkmetoder och flera lager finns i Hur du synkar ERP och lager inom B2B-e-handel, och prislogiken i guiden om kundspecifik prissättning.
Krav att få besvarade skriftligt:
- Vilket system är sanningskälla för varje fält, och går det att visa per fält i stället för per system?
- Hur identifieras samma kund, artikel och order i båda systemen?
- Vilken faktisk fördröjning har ni uppmätt per flöde hos en jämförbar kund?
- Vad händer när ett värde ändras i båda systemen samtidigt, och hur syns konflikten?
- Hur hanteras nya fält i affärssystemet som plattformen inte känner till?
3. Kräv en felprocess för varje flöde
En demo visar en order som går igenom. Kravspecifikationen behöver beskriva vad som händer med den order som inte gör det, eftersom det är den som avgör hur mycket manuellt arbete integrationen ger upphov till efter lansering.
Skilj på två sorters fel. Ett tillfälligt fel, som en timeout eller ett affärssystem som är nere för underhåll, ska lösas med kontrollerade återförsök utan att någon behöver göra något. Ett datafel, som en order med ett kundnummer som saknas i Jeeves eller en artikel som bytt enhet, går inte att lösa med återförsök. Där måste någon rätta grunddatan, och integrationen ska visa vem och vad.
Det krav som oftast saknas gäller omsändning. När ett meddelande skickas en andra gång får det inte skapa en andra order. Be leverantören visa hur samma order känns igen vid omsändning, och be att få se det i en testmiljö i stället för i en arkitekturbild.
Krav att ställa:
- Vilka feltyper hanteras automatiskt, och vilka kräver en manuell åtgärd?
- Hur många återförsök görs, med vilket intervall, och vad händer när de tar slut?
- Var hamnar en order som inte kan skickas, och vilken status ser kunden under tiden?
- Hur förhindras dubbletter när ett flöde körs om?
- Kan ett enskilt flöde pausas utan att de andra påverkas?
- Vem hos oss får felet, och i vilket gränssnitt åtgärdas det?
4. Ställ krav på övervakning som fångar tysta fel
Ett flöde som kraschar syns samma dag. Ett flöde som fortsätter köra men skickar noll order, eller gårdagens saldo, kan pågå i en vecka innan en kund ringer och frågar. Därför räcker det inte att kräva larm vid tekniska fel.
Kräv att övervakningen visar tre saker per flöde: när det senast lyckades, hur stor fördröjningen är just nu och hur många meddelanden som väntar i kö. Lägg sedan till larm på verksamhetsmönster. Noll order under en vardag, ovanligt många avvisade priser eller lagersaldon som ändras kraftigt över en natt är alla tecken på att något är fel, även om integrationen tekniskt rapporterar att allt gått igenom.
Loggen ska göra det möjligt för kundservice att följa en enskild order genom hela kedjan utan att be en utvecklare om hjälp. Det betyder sökning på ordernummer, kundnummer och artikelnummer, och en rad per steg med tidpunkt, källa, mottagare, status och resultat av eventuella återförsök.
Krav att ställa:
- Vilka avvikelser upptäcks automatiskt, och vilka kräver att någon tittar i en vy?
- Vem får larmet, och inom vilken tid ska det vara kvitterat?
- Kan kundservice själv söka fram en order och se var den står?
- Vilka mätvärden rapporteras löpande efter lansering, och till vem?
- Hur länge sparas loggarna, och hur skyddas kund- och prisuppgifter i dem?
5. Dokumentera ansvaret mellan plattformsleverantör, ERP-leverantör, partner och er själva
En ERP-integration har minst fyra parter: ni som kund, plattformsleverantören, ERP-leverantören och implementationspartnern. När en order fastnar är det sällan uppenbart vems del av kedjan som brustit, och utan en gemensam eskaleringsväg lägger varje part sin tid på att visa att felet ligger hos någon annan.
Ställ upp en ansvarsmatris innan avtalen skrivs. Raderna är arbetsområdena: krav, datamodell, integration, säkerhet, testdata, acceptanstest, driftsättning, övervakning och förvaltning. Kolumnerna är de fyra parterna. I varje ruta står vem som utför, vem som beslutar och vem som ska informeras.
Plattformsleverantören ska kunna beskriva sina API:er, sin datamodell och vilken drift som ingår. I Litiums fall ingår driften i Litium Commerce Cloud, och ERP-integrationerna mot Monitor, Jeeves, Business Central och SAP är byggda och underhållna av Litium eller certifierade partners. Implementationspartnern ska visa hur det omsätts i just er ERP-miljö, era processer och era testfall. Litium har fler än 30 certifierade Solution Partners, och valet av partner påverkar ansvarsfördelningen lika mycket som valet av plattform.
Tre saker går inte att lägga ut. Ni äger prioriteringarna när ett verksamhetskrav krockar med en teknisk begränsning, ni äger kvaliteten på masterdatan i affärssystemet och ni äger besluten om hur ni ska arbeta. Ett projekt där kunden inte har en namngiven ägare för de tre områdena blir beroende av att partnern gissar rätt.
Apex Stainless Fasteners byggde sin lösning tillsammans med partnern Motillo och integrerade den i Bufabkoncernens befintliga system, vilket innebar att ansvaret behövde fördelas mot en koncernmiljö och inte bara mot ett enskilt bolag. BE Group, som arbetar med partnern Exsitec, satte samman en arbetsgrupp med representanter från både Sverige och Finland, så att besluten om vad som skulle vara gemensamt och vad som skulle anpassas per land hade en ägare från början.
Frågor att ställa:
- Vem äger varje masterdataområde hos oss, med namn och inte bara avdelning?
- Vem godkänner en ändring i integrationslogiken, och vem testar den?
- Vem ringer vi när en order fastnar, och vem avgör vems del av kedjan det gäller?
- Vem kontaktar kunden när ett orderflöde är påverkat?
- Vad i integrationen omfattas av plattformens avtal, och vad omfattas av partnerns?
- Hur har ni och partnern arbetat ihop i tidigare projekt mot samma affärssystem?
Den sista frågan är skälet till att plattform och partner bör utvärderas tillsammans. Två leverantörer som var för sig svarar bra kan fortfarande ha en lucka mellan sina avtal.
6. Planera acceptanstest och förvaltning före lansering
Acceptanstestet är det enda tillfället då ni kan underkänna leveransen, och det förutsätter att testfallen bygger på era verkliga processer. Ett test med tre demoartiklar och en testkund visar att tekniken fungerar. Det visar inte att integrationen klarar er affär.
Bygg testfallen på de situationer som är ovanliga men kostsamma: en kund med flera leveransadresser och flera inköpare, en order över kreditgränsen, en artikel som byter försäljningsenhet, en delleverans, en retur och en annullering. Beskriv för varje testfall vad köparen ska se, vad säljaren ska se och vad affärssystemet ska registrera. Använd representativ data ur ert eget affärssystem, eftersom datakvaliteten är en del av det som testas.
Förvaltningen börjar den dag projektgruppen lämnar. Nya artiklar, prisregler, kunder och orderstatusar kommer att kräva ändringar, och affärssystemet kommer att uppgraderas. Bestäm i förväg vem som testar integrationen efter en versionsuppgradering i något av systemen, och vem som bekostar arbetet om den slutar fungera.
Swede-Wheel har nära 2 000 registrerade kunder med tillgång till lagersaldo, kundunika priser och dokumentation i en kundportal integrerad med Monitor, och nästan 40 procent av dem använder tjänsterna regelbundet. Emilia Haglund i kundsupporten beskriver effekten så här: "Att koppla Litiums plattform till Monitor har förenklat allt från kundsupport och administration i enklare frågor till produktdatahantering och har sparat oss enormt mycket tid."
För tillverkande företag som kör Monitor finns också en väg där kopplingen mellan systemen redan är byggd. I Litium Core är portalen och Monitor-kopplingen förkonfigurerade, och Monitor förblir sanningskälla för produkter, priser, lager, kunder och order. Det innebär att ni inte behöver börja från noll med att definiera och utveckla kopplingen mellan systemen. I stället kan ni fokusera kravställningen på era verksamhetsbehov, er produktdata och de processer som är specifika för er. Ansvarsfördelningen, datakvaliteten i Monitor och hur fel ska hanteras behöver ni fortfarande gå igenom, eftersom de frågorna gäller oavsett hur kopplingen är byggd. Kör ni ett annat affärssystem, eller behöver en egen frontend, gäller den fulla plattformen med en implementationspartner.
Krav att ställa:
- Vilka av våra verkliga processer ingår i acceptanstestet, och vem skriver testfallen?
- Vem testar integrationen när affärssystemet eller plattformen uppgraderas?
- Vilken dokumentation lämnas över till förvaltningen, och i vilket skick?
- Hur hanteras behörigheter och kunskap när projektgruppen inte längre arbetar med lösningen?
- Hur följs det upp att integrationen fortfarande möter kraven ett år efter lansering?
Sammanfattning: checklista inför avtal om ERP-integration
Gå igenom listan tillsammans med plattformsleverantören, ERP-leverantören och implementationspartnern innan något avtal skrivs. Varje punkt ska ha ett skriftligt svar, ett testfall och en namngiven ansvarig.
- Varje krav har en ägare, en prioritet, ett testfall och en definition av godkänt resultat.
- Varje dataobjekt har en namngiven sanningskälla och en högsta accepterad fördröjning.
- Varje flöde har en beskriven felprocess som skiljer på tillfälliga fel och datafel.
- Omsändning av ett meddelande kan visas i testmiljö utan att dubbletter skapas.
- Övervakningen larmar både vid tekniska fel och vid avvikande verksamhetsmönster.
- Kundservice kan följa en order genom hela kedjan utan hjälp av en utvecklare.
- En ansvarsmatris fördelar arbetet mellan kund, plattformsleverantör, ERP-leverantör och implementationspartner.
- Acceptanstestet bygger på verkliga processer och data ur ert eget affärssystem.
- Det är bestämt vem som testar integrationen vid versionsuppgraderingar.
Ett lösningsförslag som inte kan besvara de här punkterna konkret är inte nödvändigtvis sämre tekniskt, men ni saknar underlag för att jämföra det med de andra. Be om kompletteringar innan ni går vidare, och låt svaren bli en bilaga till avtalet.
Vanliga frågor om kravspecifikation för ERP-integration
Här svarar vi på de vanligaste frågorna från B2B-företag som ska kravställa kopplingen mellan affärssystemet och e-handelsplattformen eller kundportalen inför en upphandling eller ett plattformsbyte.
Vad är en kravspecifikation för en ERP-integration?
En kravspecifikation för en ERP-integration är ett dokument som beskriver vilken data som ska flytta mellan affärssystemet och e-handelsplattformen eller kundportalen, vilket system som äger den, hur snabbt den ska uppdateras, vad som händer vid fel och vem som ansvarar för varje del. Den används för att jämföra lösningsförslag och blir sedan underlag för acceptanstestet.
När i upphandlingen ska kravspecifikationen vara klar?
Kravspecifikationen bör vara klar innan ni tar in lösningsförslag, så att alla leverantörer svarar på samma frågor. Den behöver inte vara fullständig, men sanningskälla per dataobjekt, högsta accepterad fördröjning och ansvarsfördelning ska finnas med. Gå igenom den ett varv till med de leverantörer ni går vidare med innan avtalet skrivs.
Hur skriver man ett testbart krav på realtid?
Ange högsta accepterade fördröjning i tid, vilken händelse som utlöser uppdateringen och hur kravet ska testas. Skriv till exempel att ett ändrat avtalspris ska synas för den inloggade kunden inom fem minuter, och att det testas med tre artiklar och två kunder med olika avtal. Ordet realtid ensamt går inte att godkänna eller underkänna.
Vem ska äga kravspecifikationen, IT eller verksamheten?
Verksamheten bör äga kraven och IT bör äga hur de går att uppfylla tekniskt. Sälj, kundservice, lager och ekonomi vet vilka fel som kostar mest, och IT vet vad affärssystemet klarar. Utse en person som ansvarar för helheten, och ge varje enskilt krav en namngiven ägare i den funktion som berörs.
Vad ska en ansvarsmatris för en ERP-integration innehålla?
En ansvarsmatris ska ha arbetsområdena som rader och parterna som kolumner. Raderna är krav, datamodell, integration, säkerhet, testdata, acceptanstest, driftsättning, övervakning och förvaltning. Kolumnerna är kund, plattformsleverantör, ERP-leverantör och implementationspartner. I varje ruta anges vem som utför, vem som beslutar och vem som informeras.
Vem ansvarar för integrationen när affärssystemet uppgraderas?
Det ska framgå av avtalet, och det är en av de frågor som oftast saknar svar. Med en standardiserad integration som underhålls av plattformsleverantören eller en certifierad partner ligger ansvaret för att testa och anpassa hos dem. Med en egenutvecklad integration ligger det hos er eller hos den konsult som byggde den.
Vilka fel ska en integration kunna hantera utan manuell insats?
Tillfälliga fel, som en timeout eller ett affärssystem som är nere för underhåll, ska hanteras med automatiska återförsök och en kö som töms när anslutningen är tillbaka. Datafel, som ett kundnummer som saknas eller en artikel med fel enhet, kräver att någon rättar grunddatan. Integrationen ska då visa vad som är fel och vem som ska åtgärda det.
Vilken övervakning ska vi kräva efter lansering?
Kräv att övervakningen visar senaste lyckade synkronisering, aktuell fördröjning och antal meddelanden i kö för varje flöde. Lägg till larm på verksamhetsmönster, till exempel noll överförda order under en vardag eller ovanligt många avvisade priser. Bestäm också vem som får larmet och inom vilken tid det ska vara kvitterat.
Ska plattform och implementationspartner väljas samtidigt?
Ja, de bör utvärderas tillsammans. Plattformen avgör vilka API:er och standardintegrationer som finns, och partnern avgör hur de omsätts i er ERP-miljö och era processer. Fråga hur de har arbetat ihop i tidigare projekt mot samma affärssystem, och kontrollera att det inte finns en lucka mellan plattformens avtal och partnerns.
Behövs en kravspecifikation om integrationen redan är färdigbyggd?
Ja. En färdig integration gör att ni inte behöver börja från noll med att definiera och utveckla kopplingen mellan systemen, men behovet av kravställning finns kvar. Med en förkonfigurerad lösning som Litium Core, där Monitor-kopplingen redan är byggd och Monitor förblir sanningskälla, kan ni fokusera kravspecifikationen på era verksamhetsbehov, er produktdata och de processer som är specifika för er. Ansvarsfördelning, datakvalitet och hur fel ska hanteras behöver ni fortfarande gå igenom.