Integrera ERP och CRM med rätt ägare för varje uppgift
Peter Nilsson
Er säljare ringer en kund och öppnar avtalspriset i CRM. Kunden accepterar offerten, men ordern i affärssystemet visar redan ett annat pris. Nu behöver säljaren och ekonomi reda ut vilket pris som gäller och vem som lovat vad.
Affärssystemet fungerar som lagerkontoret. Där finns uppgifterna om artiklar, kostnader, tillgänglighet och leveranser. CRM är säljarens anteckningsbok med kundkontakter, önskemål och överenskommelser. Enligt SCB:s definitioner av affärssystem och CRM delar affärssystem information mellan interna funktioner, medan CRM hanterar kundinformation, kontakter, köpvanor och intressen.
En integration mellan affärssystem och CRM börjar därför med ägarskap för olika datadomäner. Ni behöver bestämma vilken källa som gäller när systemen visar olika uppgifter. Den källan är master för uppgiften. Sambandet mellan e-handel och affärssystem blir särskilt viktigt när samma pris också visas på webben. Kartläggningen behöver ange vilka uppgifter som ska delas, riktningen och besluten som måste vara fattade före byggstart.

Vilka dataflöden som ska gå i vilken riktning
Fördelningen nedan är ett förslag att pröva mot era arbetsflöden. Frekvenserna behöver anpassas efter hur länge verksamheten kan acceptera en gammal uppgift.
Affärssystemet är master för kundidentitet, organisationsnummer och juridiskt namn, som går till CRM via API vid varje ändring. Betalningsvillkor och kreditstatus går samma väg, via API eller daglig synkronisering. Artiklar, artikelnummer och grunddata skickas från affärssystemet till CRM och webb som en händelse när de ändras. Priser och kundspecifika avtalspriser går till CRM och portal som en daglig ögonblicksbild med tidsstämpel, och lagersaldot som en tidsstämplad ögonblicksbild med fast intervall. Fakturaunderlag och betalningshistorik läses dagligen.
Ordrar och orderstatus har affärssystemet som master men går i båda riktningarna, som händelser med idempotensnyckel. CRM är master för kundämnen, aktiviteter och säljstatus, som går till affärssystemet som en händelse när affären vinns. Kontaktattribut och samtycke ägs också av CRM och skickas vid behov, med ändringslogg.
Låt affärssystemet äga juridisk kundidentitet, betalningsvillkor och kreditstatus. Detsamma gäller artikeldata, prislogik och bokade ordrar. Ekonomi behöver kunna ansvara för uppgifterna som styr fakturering och betalning.
CRM kan äga kundämnen, aktiviteter och säljstatus. Kontaktattribut och samtyckesuppgifter behöver egna regler för ändring, behörighet och gallring. Att CRM är master för en kontaktuppgift innebär aldrig att alla mottagande system ska få hela kontaktkortet.
Utse master per uppgift. Ett helt kundkort behöver sällan ha en enda ägare.
Den gemensamma kundnyckeln bör omfatta organisationsnummer och internt kund-ID. Koppla också fakturaadresser och leveransadresser till rätt kundrelation. Adresserna hjälper er skilja leveransställen åt, men bör inte ensamma avgöra vilken juridisk kund en order tillhör.
Validera organisationsnummer och normalisera formatet före matchning. Ta bort formateringsskillnader enligt en dokumenterad regel och hantera saknade värden separat. Poster som inte går att matcha säkert behöver granskas innan historik förs över.
Anta att en koncern har kundkort för moderbolaget, en filial och ett äldre dubblettkort. Om integrationen matchar på företagsnamn kan filialens köp hamna under moderbolagets säljkontakt. Säljaren upptäcker då felet genom en missvisande omsättningssiffra.
En order kan börja i CRM och ändå ha affärssystemet som master. Säljaren skickar ett orderförslag som affärssystemet validerar och bokar. Därefter går ordernummer, godkända belopp och status tillbaka till CRM.
Varje flöde behöver slutligen en namngiven verksamhetsägare. Den personen avgör hur en avvikelse ska rättas. Teknikansvarig behöver kunna hitta felet, medan verksamhetsägaren måste kunna avgöra vilken uppgift som ska gälla.
Fem sätt att koppla affärssystem och CRM och när de räcker
Manuell export och import av fil passar när ni har få kunder och en kort övergångsperiod. Det går snabbt att starta, men dubbelregistreringar och fel kan passera obemärkt. Nattlig filsynkronisering fungerar för små volymer och uppgifter som ändras långsamt, och filerna är lätta att felsöka. Risken är att säljarna arbetar med gårdagens priser och lagersaldon.
En direkt API-koppling passar ett begränsat systemlandskap med få flöden och ger snabba uppdateringar för valda uppgifter, men varje ny koppling ökar underhållet. En meddelandekö med händelser passar när många flöden har flera mottagare. Den hanterar avbrott och återförsök och kräver styrning av meddelandeformat och versioner. En färdig standardkoppling kan minska införandearbetet med förtestade flöden, så länge era system och processer ryms i den. Särskilda processer kan falla utanför omfattningen.
Välj efter antalet flöden, accepterad fördröjning och förmågan att förvalta kopplingen. En integrationsplattform kan hjälpa när flera system delar uppgifter. Vår genomgång av integrationsplattformar och deras användningsområden ger ett underlag för den avvägningen.
En meddelandekö kräver att någon bestämmer hur meddelanden ska se ut och hur fel ska hanteras. Varje meddelande bör bära korrelations-ID, tidsstämpel och schemaversion. Återförsök bör ske med successivt längre väntetid så att ett överbelastat system hinner återhämta sig.
Orderflöden behöver idempotensnycklar. Anta att affärssystemet bokar ordern men svaret försvinner vid ett avbrott. När CRM skickar igen måste mottagaren känna igen beställningen och återge den befintliga ordern. En återförsöksfunktion är säker först när mottagaren kan hantera samma meddelande igen.
Pris och lager kan publiceras som händelser eller tidsstämplade ögonblicksbilder. Kunduppgifter och orderändringar kräver dessutom konfliktregler och revisionshistorik. Då går det att följa vilken ändring som accepterades och varför.
Ett manuellt e-postmeddelande med en bifogad fil är ingen automatiserad datadelning. Filen behöver en kontrollerad importkedja för att fungera som ett tillförlitligt flöde.
Strukturerade meddelanden gör det lättare att jämföra beteenden före och efter en uppgradering. Daglig avstämning av antal och belopp kompletterar den tekniska övervakningen. Välj metod för varje dataflöde, eftersom order och historiska fakturauppgifter kan tåla olika lång väntan.
Var nyttan och riskerna i vardagen syns först
Utan en fungerande koppling kan säljaren se gammal kundhistorik medan ekonomi ser den senaste betalningen. En fakturafråga kräver då att någon söker i båda systemen. Avtalspriset kan också saknas i offerten trots att ekonomi redan har registrerat det.
När flödena fungerar kan säljaren se order, betalningsstatus och relevant historik i samma vy. Godkända avtalspriser kan användas när offerten skapas. Dubbelregistreringarna minskar när en accepterad uppgift får följa med genom arbetsflödet.

Samma spridning gör felaktiga grunduppgifter farliga. En felaktig kundkoppling kan föra fel köphistorik till säljarens vy, kundportalen och analysunderlaget. En integration som tappar meddelanden utan larm kan samtidigt få användarna att lita på ofullständiga uppgifter.
Anta att samma bolag har dubbla kundkort som olika säljare använder. När ordrarna samlas i en gemensam vy syns plötsligt motstridiga betalningsvillkor. Teamet behöver då reda ut registerfelet och bestämma hur framtida kundkort ska skapas.
Låt osäkra kundmatchningar gå till granskning innan historiken sprids till fler mottagare.
Frågan blir mer angelägen när sammanförda uppgifter används av AI. Enligt SCB:s officiella statistik använde 35 procent av svenska företag med minst tio anställda AI under 2025, en ökning med 10 procentenheter från 2024. För en AI-funktion som föreslår nästa erbjudande behöver kundens identitet, giltiga pris och tillgängliga artiklar stämma överens.
Mer realtid gör aldrig felaktiga masterdata korrekta. Snabbare överföring kan få ett felaktigt pris att nå fler användare tidigare. Därför behöver ni spara källhänvisning, giltighetstid och versionsuppgift för information som används i automatiserade beslut.
Behörigheter måste också följa med när uppgifter kombineras. En säljare kan behöva se betalningsstatus utan att få tillgång till alla ekonomiska detaljer. Planera mänsklig kontroll för förslag som påverkar pris, kredit eller kundens åtagande.
Dimensionera strukturen så att fler datakällor kan anslutas med samma definitioner. Det behöver inte betyda att allt byggs från början. Börja med tydliga begrepp för kund, artikel, order och giltigt pris så att nästa mottagare kan använda dem.
Mätetal som visar om integrationen minskar datasilor
Följande är en föreslagen uppföljningsrutin efter go-live. Anpassa intervallen när ni vet var avvikelserna uppstår och hur snabbt de behöver hanteras.
Följ matchningsgraden för kundposter varje vecka, alltså hur många kundkort som kopplas korrekt via organisationsnummer och kund-ID. Följ andelen misslyckade meddelanden dagligen, eftersom den visar om uppgifter riskerar att saknas. Mät fördröjningen från bokad order till CRM varje månad med stickprov. Räkna de manuella korrigeringarna varje månad för att se om användarna rättar återkommande fel. Stäm av antal och belopp mellan affärssystem och CRM dagligen, med larm vid avvikelse.
Ett mottaget meddelande kan innehålla fel kundreferens eller ett belopp med fel innebörd. Därför behöver teknisk övervakning kompletteras med verksamhetstester. Låt en säljare och en ekonom granska samma kundförlopp från offert till betalning.
SCB:s föreskrift om företagens digitala arbetssätt omfattar analys av transaktionsdata och kunddata samt elektronisk delning med externa parter. Föreskriften tar också upp CRM som molntjänst. Det gör användning, driftmodell och ansvar relevanta att dokumentera tillsammans.
Ett godkänt verksamhetstest ska visa att användaren kan fatta rätt beslut med uppgifterna i sin vy. Skriv acceptanskriterier som går att prova. Säljchefen ska exempelvis kunna analysera order och kunduppgifter tillsammans. Relevant information ska kunna delas med externa parter utan att obehöriga uppgifter följer med.
Anta att omsättningen per kund i CRM avviker från ekonomins rapport. Kontrollera då period, valuta, kreditnotor och vilka orderstatusar som ingår. En daglig avstämning kan fånga skillnaden innan någon använder siffran i en ledningsrapport.
Datatäckning, uppdateringsfrekvens och spårbarhet behöver egna godkännanden. Det ska framgå vilka poster som ingår och hur gamla uppgifterna får vara. Användaren bör också kunna se när uppgiften senast uppdaterades.
Tröskelvärden måste sättas utifrån era egna data. Kalla preliminära gränser för tumregler tills ni har mätt och prövat dem. Ange samtidigt vem som tar emot larmet, när personen agerar och hur korrigeringen dokumenteras.
Vad upplägget kräver och när en enklare lösning räcker
En koppling mellan CRM och affärssystem kräver en ansvarig för kunddata och ett beslut om vilket system som äger varje uppgift. Rensa kundregistret före den första överföringen och avsätt tid för tester av undantag, till exempel kreditspärrar, returer och ändrade leveransadresser.
Säljare och ekonomi behöver också veta vilka fält de kan ändra och var de begär rättning när en uppgift hämtas från ett annat system. Avsätt tid för att lära ut de nya arbetssätten.
Automatisera de flöden där väntan eller manuell hantering faktiskt hindrar arbetet.
Om nästan all försäljning hanteras i ett och samma system kan en kontrollerad exportrutin räcka, särskilt vid låga volymer och få kundspecifika avtalspriser. Utse en ansvarig, dokumentera kontrollerna och lägg in en återkommande avstämning.
SCB:s statistik om systemanvändning gäller företag med minst tio anställda och kan delas upp efter storlek, näringsgren och region. Mindre företag kan arbeta annorlunda. Välj därför upplägg utifrån organisationens behov och hur medarbetarna använder uppgifterna.
I en koncern behöver ni också klargöra hur dataansvaret fungerar mellan bolag. Dokumentera vilka bolag och regioner som använder respektive system, om kundnummer är gemensamma eller lokala och vem som godkänner ändringar.
Bestäm förvaltningsansvaret före driftsättning. Vägledning om systemintegration och ansvar mellan system kan hjälpa er att avgränsa arbetet. Ta med versionsuppföljning, kompatibilitetstester och felrättningar i er bedömning av den totala ägandekostnaden.
Glanser Care är ett avtalat ansvar till fast månadskostnad som omfattar versionsuppföljning, kompatibilitet vid uppgraderingar, underhåll av integrationerna mot affärssystemet och buggrättning. Bedöm ändå om ert dataflöde kräver en integration eller kan hanteras med en tydlig rutin.
Tre frågor till leverantören innan ni väljer koppling
Vilket system är master för kundidentiteten och hur normaliseras organisationsnummer före matchning? Be leverantören visa hur ett moderbolag, ett leveransställe och ett dubblettkort skiljs åt. Svaret avslöjar om matchningen bygger på dokumenterade regler eller osäkra antaganden om företagsnamn.
Hur skyddas en order mot att skapas igen efter ett avbrott, och används idempotensnycklar? Be om en demonstration där ordern bokas men bekräftelsen aldrig når avsändaren. Svaret visar om lösningen kan hantera återförsök utan att ekonomi får en extra order.
Hur mäts avvikelser mellan affärssystem och CRM, vem äger larmet efter go-live och vad händer vid uppgradering? Be leverantören beskriva hur ett fel följs från larm till rättad post. Svaret avslöjar vilket ansvar som faktiskt finns när systemen ändras. Ett vagt svar är en signal att be om ett konkret exempel från ett liknande projekt.
Ett starkt underlag bör innehålla mer än en bild över systemens anslutningar. Ni behöver kunna följa ett meddelande, se hur en avvikelse hanteras och förstå vem som fattar beslut. Kontrollera även att testfallen och ansvaret ingår i den avtalade omfattningen.
Den tekniskt ansvariga kan förklara format och återförsök. Verksamhetsägaren behöver samtidigt godkänna hur pris, kundidentitet och orderstatus används. Båda perspektiven behöver finnas med när ni bedömer svaren.
Kartlägg dataflödena innan ni väljer koppling
Ta en offert med avtalspris som testfall. Följ den från kundens första uppgift till offerten som säljaren använder, och notera var någon behöver kontrollera eller komplettera information manuellt. Det visar vilka flöden som bör prioriteras och om synkroniseringen fungerar i det dagliga arbetet.
Börja med en genomgång tillsammans med sälj, ekonomi och IT. Låt dem granska ett konkret fel, till exempel ett betalningsvillkor som har ändrats i fel system. Bestäm hur felet ska upptäckas, vem som rättar uppgiften och hur ni kontrollerar att den korrigerade informationen når rätt plats. Dokumentera också testfall och vem som ansvarar för dem när lösningen ändras.
Prova därefter flödet med testdata. Kontrollera att avtalspriset visas rätt i offerten, att en ändring inte skrivs över av en annan källa och att ett avbrott inte leder till dubbla transaktioner. Följ hela kedjan, från registrering till användning, och låt berörda roller godkänna resultatet.
I en 72-timmarsanalys 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.

Om Peter Nilsson
Peter Nilsson skriver om integrationer och produktinformation, med fokus på hur affärssystem, PIM och webb kan dela samma data utan dubbelarbete.

Master data management som styr era gemensamma data
Master data management förklarat: vad det är, hur MDM, PIM och affärssystem samverkar och vilka beslut ni behöver fatta innan ni börjar.
Peter Nilsson
Agentic commerce börjar i er produktdata och behörighet
Vad agentic commerce kräver av er produktdata, era priser och era orderregler.
Niclas Frid
Produktkonfigurator i B2B: vad ni bör veta före valet
Produktkonfigurator för B2B: typer, koppling till PIM, ERP och prissättning samt vad implementeringen kräver av er.
Peter Nilsson