Master data management som styr era gemensamma data

Kundposten i affärssystemet har rätt organisationsnummer. I CRM:et står samma bolag med en namnform som ingen rättat sedan senaste omorganisationen. I kundportalen ligger en kontaktperson som slutat för länge sedan.

Varje post är riktig i sitt eget system. Tillsammans ger de tre olika svar på samma fråga, och ni märker det först när en offert går ut med fel pris eller en faktura hamnar hos en adress som inte längre används.

Det ni behöver är ett beslut per uppgift: vilket system som får ändra värdet, vem som godkänner ändringen och när den får föras vidare till webb, portal och analys. Den här texten handlar om hur ni sätter det beslutet, och om när ni kan låta bli.

Master data management är styrning av gemensamma uppgifter

Masterdata är de uppgifter som flera system måste använda likadant. Kunder, produkter, leverantörer och den egna organisationen hör dit, eftersom affärssystemet, webbplatsen, portalen och analysen bygger sina svar på dem.

Master data management är styrmodellen runt de uppgifterna. Den består av gemensamma definitioner, en utpekad källa per uppgift, en namngiven ägare per attribut och regler för när en ändring får föras vidare. Tänk er en gemensam adressbok där varje rad har en ansvarig person och en regel för hur den får ändras.

Många register skapar inte automatiskt gemensamma uppgifter. Där sitter förklaringen till att två avdelningar kan svara olika på vad kunden heter, vilket segment den tillhör och vilket pris den har. Varje avdelning förvaltar sin egen kopia, och kopiorna glider isär i takt med att verksamheten ändras.

Så här ser spridningen ut när tre system beskriver samma kund.

MDM är en styrmodell först och ett systemval sedan. Nästa fråga är vilket system som äger vilken data, och den frågan har ett konkret svar.

Tre system som ofta blandas ihop i samma projekt

Affärssystemet är källan för artikelnummer, grunddata, prislogik, lager och order, eftersom transaktionerna vilar på dem. Det gäller oavsett om ni kör Business Central, Monitor eller Jeeves. Flyttar ni prislogiken någon annanstans börjar fakturor och plocklistor att leva egna liv.

PIM är platsen där texter, attribut, bilder och datablad berikas en gång och sedan publiceras till webbplatser, portaler och återförsäljarkanaler. Här sitter redaktionellt arbete som ingen ekonomiavdelning ska behöva göra om för varje kanal.

MDM täcker den bredare uppsättningen masterdata över systemen och sätter de regler som de andra två följer. Lagret avgör vem som får ändra, vad som gäller som godkänd version och hur en ändring får spridas.

Förvirringen uppstår för att alla tre rymmer produktdata, men för olika syften. Samma artikel kan därför finnas i tre beskrivningar utan att någon har gjort fel. Ett vanligt fall: en produkt har måttet registrerat i millimeter i affärssystemet och i centimeter i webbutiken. Ingen av uppgifterna är felaktig i sig. Kombinationen blir fel så fort en kund jämför en ritning med produktsidan.

Räkna igenom en ändring från början till slut. Ekonomin ändrar artikelnummer och prislogik i affärssystemet. Produktteamet berikar text, mått, bild och datablad i PIM och publicerar bara den godkända versionen. Produktwebb, kundportal eller återförsäljarportal läser artikelnummer och pris från affärssystemet och text och bild från PIM. Skiljer sig måttet mellan kanalerna saknas en källa per attribut, och då sitter felet i organisationen. Vi har skrivit mer om hur datamodellen för produktinformation hänger ihop med artikeldata från affärssystemet.

Ett bolag behöver inte ett system som äger allt. Det behöver ett namn per attributgrupp och en källa som de andra systemen accepterar.

Vem som äger varje attribut avgör om datan håller

Artikelnumret ändras i affärssystemet av den som är ekonomi- eller artikelansvarig. Det är unikt och ändras bara med godkännande. Tekniska egenskaper som mått, material och kompatibilitet ändras i PIM av produktteamet, med värdet hämtat från en godkänd källa som en ritning eller ett datablad. Kommersiella villkor och prislogik ägs av ekonomi och försäljning i affärssystemet och publiceras till webben först efter godkännande där.

Kundens kontaktuppgifter ändras i kundregistret eller CRM av säljansvarig, och varje ändring loggas med datum och användare. För personuppgifter i kundregistret ansvarar juridik och dataskyddsansvarig, med lagring och gallring enligt avtal och lag. Publicerade produktbilder och dokument ägs av marknadsavdelningen i PIM, och bara den godkända versionen med giltighetsdatum publiceras. Dubblettregler för kunder ligger i MDM-lagret hos dataförvaltaren, och en sammanslagning kräver godkännande från postens ägare.

Fördelningen är ett exempel som behöver stämmas av mot er egen organisation. Det viktiga är att varje attribut har ett system, en roll och en regel, och att de tillsammans täcker det som kanalen faktiskt visar.

Ägarskap per attribut är svårare än ägarskap per system. Ett affärssystem kan vara källa för ett fält medan PIM är källa för ett annat, och båda syns i samma produktvy. Utan en utpekad ägare per fält blir varje ändring en förhandling, och den som förhandlar starkast vinner.

Kraven ökar när datakällorna blir fler. Bland svenska företag 2025 var farhågor om överträdelser av dataskydd och integritet det vanligaste hindret för AI-användning, 49,1 procent, jämfört med 41,8 procent 2024, enligt SCB:s statistik om it-användning i företag. Fler källor höjer kravet på proveniens, ändringslogg, åtkomstregler och ansvar mellan systemägare.

Mekaniken är enkel att bygga och lätt att glömma bort. När prislogiken ändras i ett system och inte i de andra visar ändringsloggen vem som ändrade vad och när. Vid en felaktig integration behöver ni kunna återställa en post till föregående version utan att köra om hela importen, och stoppa eller återkalla felaktig data innan den når kanalerna. För nordiska koncerner med decentraliserade bolag och flera affärssystem dyker problemet oftast upp först som dubbletter på kund och produkt.

Börja med en ägarsedel på en sida per datadomän. Den listar attributen, systemet som får ändra, rollen som godkänner och regeln som gäller. Då har varje beslut om ett värde en namngiven person bakom sig. Vi har skrivit om hur kunddata hålls samman mellan affärssystem och CRM när ni vill se hur kedjan brukar se ut i praktiken.

Kvaliteten byggs in från källan och följer datans hela livscykel

En produkt har tre olika mått i företagets system: 10 × 20 cm i affärssystemet, 12 × 22 cm i webbutiken och det gamla måttet kvar i ett tredje system. Felet uppstod när en ändring gjordes på ett ställe men inte fördes vidare. Ingen behövde göra något med flit för att uppgifterna skulle glida isär.

Följden kan bli returer, felaktiga offerter och supportärenden som hade kunnat undvikas. Datakvalitet kräver därför mer än en gemensam databas. För varje attribut behöver det vara tydligt var värdet skapas, vem som får ändra det och hur ändringen följs genom systemen.

SCB beskriver datakvalitet som en förutsättning för säkrad datatillgång. I SCB:s verksamhetsplan för 2024 till 2026 framgår att myndigheten arbetar med dataägare, gemensamma standarder och rutiner för att säkra kvalitet vid källan.

Kontrollerna behöver följa datan från registrering till publicering och uppföljning.

Vid registrering styr obligatoriska fält och formatregler hur måttet anges, exempelvis alltid i millimeter. Vid ändring godkänner attributets ägare det nya värdet. I integrationen kontrolleras fältmappning och enheter innan uppgiften förs vidare. Före publicering kontrolleras att tillräckligt många obligatoriska fält är ifyllda. Vid uppföljning mäts hur stor andel poster som har en namngiven ägare.

Gränsen för publicering är något ni kommer överens om. Anpassa den efter verksamhetens behov och se till att det går att spåra vem som har beslutat om den. Rensning i efterhand kan hitta fel, men förebygger inte att de återkommer om ägarskap och kontroller saknas vid källan.

Börja med tre mått: andelen poster med namngiven ägare, andelen obligatoriska fält som är ifyllda och antalet kända dubbletter. De går att följa utan en ny plattform och visar om reglerna ger bättre datakvalitet över tid.

När MDM är för tungt och vad det kräver av er

Ett MDM-arbete kräver tid från verksamheten, en ägare per datadomän, beslut om definitioner och en plats där ändringar godkänns. Kravet är organisatoriskt, och det är där de flesta införanden tappar fart.

Ett mindre bolag med ett affärssystem, en webbplats och några hundra artiklar klarar sig oftast utan en separat MDM-plattform. Där räcker tydliga regler, ett PIM-flöde för produktdata och en lista över vilka system som är källa för vad.

MDM blir motiverat när flera affärssystem eller bolag delar samma kund- och produktdata, när flera kanaler läser samma uppgifter, när produktdata återanvänds mellan varumärken eller när revisionen kräver spårbara ändringar. Då blir spårbarheten billigare än att reda ut felen i efterhand.

Var ärliga mot er själva om kostnaden. Ägarskap och processer tar längre tid än tekniken, och ett införande som bara byter verktyg löser sällan problemet. Styrningen behöver en budget över tid, och förvaltningen är en egen kostnadsrad långt efter go-live. Sådana kostnader syns sällan i projektkalkylen. 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.

Passar ett lättare angreppssätt? Om ledningen ännu inte kan peka ut en ägare per domän är svaret ja. Börja då med en produktgrupp och en ägare, och bygg ut när besluten bär.

AI gör bristfälliga produktdata till ett affärskrav

Under 2025 använde 35 procent av företagen i SCB:s undersökning AI, en ökning med 10 procentenheter från 2024. Samma undersökning visar att 44,3 procent uppgav bristande tillgång till eller kvalitet på nödvändiga data som ett hinder, jämfört med 37,7 procent 2024, enligt SCB:s statistik om artificiell intelligens i Sverige.

För ett företag som vill använda AI i kundservice eller försäljning börjar arbetet med att välja ett konkret flöde och de attribut det behöver. Det kan handla om produkt-ID, enheter, kompatibilitet, språk, kundsegment, prisvillkor och vilket system som är källa till varje uppgift.

Börja med ett flöde, till exempel reservdelssökning i kundportalen. En självserviceassistent behöver rätt kompatibilitet och enheter för maskinen kunden har. Fel koppling mellan reservdel och modell kan ge kunden ett felaktigt svar och leda till en retur.

Skriv ett datakontrakt för attributen i flödet: definiera varje uppgift, ange enhet och bestäm vad som måste finnas innan informationen publiceras. Peka ut vilken källa som levererar varje attribut och vem som ansvarar för att det är korrekt. Följ avvikelser före publicering, så att brister upptäcks innan de når kunden.

När datan fungerar i ett avgränsat flöde kan ni pröva fler användningsområden, exempelvis agentbaserade flöden inom handeln. Utöka först när de uppgifter flödet kräver går att följa tillbaka till en tydlig källa.

Frågor som visar hur leverantören hanterar ägarskap och ändringar

Be leverantören peka ut vilka attribut i er masterdata som ägs av vilket system, och vem som godkänner en ändring som slår mot flera system samtidigt. Ett svar som bara hänvisar till ett verktyg visar att styrningen inte är byggd än.

Fråga sedan hur en ändring spåras från källsystem till kanal, och om en felaktig post kan återställas utan att hela importen körs om. Svaret avslöjar om leverantören tänker i livscykel eller bara i synkronisering.

Den tredje frågan gäller förvaltningen: vad ingår när affärssystemet eller en kanal uppdateras till en ny version, och vilka kontroller körs före publicering. Här märker ni om produktansvaret sträcker sig förbi go-live.

Frågorna fungerar lika bra mot er egen IT-avdelning som mot en extern part. Be om svaren med en riktig exempelpost, där ni följer ett artikelnummer från affärssystemet till produktsidan. En leverantör som kan visa ägare, logg och återställning i ett och samma exempel har byggt styrningen. En som beskriver det i mötesformuleringar har troligen inte gjort det.

Börja med en produktgrupp och ett ägarskap

Om flera system delar produktdata, börja med en produktgrupp där en förbättring får tydlig betydelse för verksamheten. Bestäm vem som ansvarar för varje attribut och dokumentera vilka regler som gäller för ändringar. Då går det att pröva arbetssättet i liten skala innan fler produktområden ansluts.

En produktwebb kan införas för en produktfamilj eller marknad i taget. Först definieras attributmodellen för filtrering och varianter. Därefter kopplas datakällorna in och katalogen byggs ut stegvis. PIM och affärssystemet hanterar olika delar av produktflödet, enligt ansvarsfördelningen ovan.

Funktionsbiblioteket har tre nivåer. Standard har fast omfattning och fast pris. Anpassad utgår från samma grund med avtalade ändringar, och Kundunik isoleras så att resten kan uppgraderas utan att påverkas.

Ett tydligt ägarskap per attribut gör det lättare att hitta orsaken när information skiljer sig mellan kanaler. Börja med att beskriva en konkret produktpost: vilka uppgifter som ingår, vem som godkänner ändringar och var informationen ska användas. Det ger en praktisk grund för att bedöma om ni behöver PIM och vilka funktioner som kan vänta.

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.