Det skjer i nesten alle implementeringsprosjekter. Et sted mellom kick-off og go-live dukker spørsmålet opp, gjerne formulert av noen som ønsker å forenkle arkitekturen: «Har vi ikke all kundeinformasjonen i CRM-en allerede? Kan vi ikke bare bruke den som masterkilde?»

Svaret er nei — med noen nyanser. I små organisasjoner med få datakonsumenter kan CRM pragmatisk tjene som det nærmeste man kommer et masterregister. Men jo flere systemer som leser fra registeret, og jo mer kritiske beslutninger det skal bære, desto svakere blir CRM som master. Og grunnen til det er ikke teknisk svakhet i plattformen — det er en fundamental motsetning i hva de to systemene er designet for å gjøre.

CRM-ens egentlige oppdrag: åpenhet på bekostning av renhet

Et godt CRM-system — enten det er Microsoft Dynamics 365, Salesforce eller et annet — er bygget rundt én kjernetanke: senk terskelen for dataregistrering til null.

Selgeren som har møtt en potensiell kunde på et arrangement skal kunne opprette kontakten på mobilen mellom to sesjoner, med bare et fornavn og et LinkedIn-profilbilde. Kundeservicemedarbeideren skal kunne logge en henvendelse selv om kunden oppgir et navn som allerede finnes tre ganger i systemet. Markedsavdelingen skal kunne importere en liste fra en messe uten at halvparten avvises av valideringsregler.

Dette er ikke slurv — det er arkitektonisk intensjon. Alternativet er at dataene aldri registreres. I stedet havner de i en Excel-fil på skrivebordet, i en Outlook-mappe, eller — det verste tenkelige scenarioet — bare i hodet på den ansatte som håndterte saken. Data som ikke er i systemet, eksisterer ikke for organisasjonen.

Et CRM må derfor tåle duplikater (samme kunde registrert litt ulikt av ulike brukere), ufullstendige poster (kontakter uten e-post, selskaper uten organisasjonsnummer), feilaktige data (feilstavet adresse, utdatert telefonnummer) og motstridende data (to brukere som har lagt ulike titler på samme person). Dette er ikke systemsvikt. Dette er systemet som fungerer etter hensikten.

MDM-ens oppdrag: renhet på bekostning av fleksibilitet

Et Master Data Management-system opererer etter et diametralt motsatt prinsipp: beskytt integriteten til dataene, selv om det betyr å holde noe ute.

MDM-plattformens primæroppgave er å produsere det som kalles en golden record — én autoritativ, verifisert og deduplisert representasjon av en kunde, et produkt eller en enhet. Denne posten er resultatet av en prosess som samler data fra multiple kilder (CRM, ERP, netthandelsplattform, kundeservice-system), matcher poster på tvers av kilder, slår sammen og løser konflikter etter definerte prioriteringsregler, validerer mot definerte datakvalitetsstandarder, og publiserer den distillerte, godkjente posten tilbake til konsumerende systemer.

Det kritiske punktet er det siste steget: masterregisteret er output, ikke input. Det er systemet andre systemer leser fra, ikke skriver til. En golden record i et MDM-system er beskyttet. Direkte skrivetilgang — fra integrasjoner, fra brukere, fra AI-agenter — er ikke tillatt uten å gå gjennom den definerte datakvalitetsprosessen. Dette er ikke byråkrati; det er dataarkitekturens versjon av «four eyes»-prinsippet.

MDM trenger forøvrig ikke være én monolittisk plattform. Moderne implementasjoner bygges ofte som data products, event-baserte identitetsresolusjons-tjenester eller composable arkitekturer på toppen av et data lakehouse. Prinsippet er det samme uansett valg av teknologi: data distilleres før de distribueres.

Hva skjer når vi prøver å kombinere de to

La oss si at vi bestemmer oss for å implementere masterregisterfunksjonalitet direkte i Dynamics 365. Vi skal altså bruke samme plattform til å la selgere opprette kontakter fritt og raskt (CRM-oppdraget) og samtidig vedlikeholde et autoritativt, rent og duplikatfritt register (MDM-oppdraget). For å få dette til må vi bygge en kompleks datamodell — separate entiteter for «operasjonelle kontakter» og «master-kontakter», sammenslåingslogikk og statusfelt — bygget på toppen av en plattform der Dataverse er optimalisert for operasjonelle workloads, ikke tung matching og governance. Merge-funksjonaliteten i Dynamics er relativt enkel, relasjonshåndtering på tvers av juridiske enheter er begrenset, og native duplikatdeteksjon er heuristisk sammenlignet med dedikerte MDM-motorer.

Legg til komplekse forretningsprosesser — duplikatdeteksjon, gjennomgangskøer, godkjenningsworkflows og audit trails, i en plattform der brukerne primært er selgere og kundeservicemedarbeidere. Og komplekse brukergrensesnitt — sluttbrukeren må forholde seg til at «kontakten vi ser her» ikke nødvendigvis er «kontakten som gjelder», med UI-logikk som kommuniserer datastatus og låste felt kontrollert av masterregisteret.

Resultatet er et system som er for komplekst for CRM-brukerne og for svakt for et reelt MDM-behov. Vi har kompromittert begge oppdragene.

Scenario: En mellomstor organisasjon prøvde å gjøre CRM til masterregister ved å legge inn strenge valideringsregler: påkrevde felt på hver kontakt, dedupliseringssjekk ved lagring, ingen lagring uten organisasjonsnummer. Innen seks måneder lagde selgerne falske placeholder-kontakter for å komme forbi reglene. CRM-en holdt seg «ren». Selve kundeinformasjonen flyttet til regneark og notater. Reglene fikset ikke dataproblemet. De flyttet det.

«Men vi kan da sette opp noen datakvalitetsregler i CRM-en?»

Ja. Og det bør vi. Det er sunn fornuft å implementere et minimumssett av valideringsregler i Dynamics 365: obligatorisk e-postformat, organisasjonsnummer mot et validerende API, adressenormalisering, og en enkel duplikatdeteksjon på navn og e-post. Dette reduserer støyen i inngangsdataene og gjør MDM-jobben lettere nedstrøms.

Men dette er hygiene, ikke governance. En duplikatdeteksjonsregel i CRM-en fanger den åpenbare dubletten. Den fanger ikke «Kari Olsen hos Acme AS avd. Bergen» og «K. Olsen, Acme Bergen» som er registrert av to ulike selgere på to ulike tidspunkt. Den fanger ikke at «Olsen Consulting» og «Olsen Consulting AS» er samme juridiske enhet.

Og viktigst: en valideringsregel i CRM-en beskytter ikke masterregisteret. Den reduserer bare antall feil som aldri burde ha oppstått.

"Vi har sett det samme mønsteret over tid: organisasjonene som lykkes med CRM, presser ikke på for at det skal bli sannhetskilden. De aksepterer at CRM er der virkeligheten samles, og bygger et eget lite lag som distillerer det videre. Det er sjelden et stort prosjekt — men det er nesten alltid en bevisst beslutning."

— Cartagena, fra praksis

Den praktiske konklusjonen

Dynamics 365 er systemet der data oppstår — lavterskel, inkluderende og tolerant. Det rommer virkeligheten slik den er: kaotisk, ufullstendig og menneskelig. Optimalisert for samhandling i sanntid.">Arkitekturen er enklere enn den ofte presenteres. Dynamics 365 er systemet der data oppstår — lavterskel, inkluderende og tolerant. Det rommer virkeligheten slik den er: kaotisk, ufullstendig og menneskelig. Optimalisert for samhandling i sanntid.

ERP-systemer, rapporteringsplattformer, regulatoriske rapporter og AI-modeller kan stole på. Optimalisert for kvalitet og pålitelighet.">MDM-plattformen er systemet der data distilleres. Den leser fra CRM-en (og andre kilder), kjører sin prosess, og produserer et register som ERP-systemer, rapporteringsplattformer, regulatoriske rapporter og AI-modeller kan stole på. Optimalisert for kvalitet og pålitelighet.

Det finnes i dag MDM-løsninger som er langt enklere og rimeligere å implementere enn de store «enterprise MDM»-plattformene fra tidlig 2000-tall. Et riktig dimensjonert og fokusert MDM-verktøy, integrert med Dynamics 365 via standard API-er, er ikke et stort prosjekt. For kunder med mer eksotiske behov kan også en tilpasset serverless-løsning, for eksempel Azure Functions eller andre skreddersydde API-tjenester, være et fornuftig alternativ til kommersielle MDM-verktøy.

De fleste organisasjoner ender opp med å bygge et MDM-lag. Det eneste reelle spørsmålet er om de gjør det bevisst eller tilfeldig.

Et CRM som prøver å være masterregisteret er som et lager som også prøver å være butikkvinduet. Det kan teknisk sett gjøres. Men det tjener ingen av de to formålene særlig godt.

Ofte stilte spørsmål om CRM, MDM og masterdata

Hva er forskjellen mellom CRM og MDM?

CRM-systemet er der kundedata oppstår — det er optimalisert for åpenhet, samhandling og fleksibilitet. MDM (Master Data Management) er et eget lag som distillerer kundedataene — det er optimalisert for renhet, konsistens og pålitelighet. De løser forskjellige problemer og bør ikke kombineres i samme system.

Kan vi ikke bare bruke CRM-en som masterregister og slippe MDM?

I små organisasjoner kan det fungere en stund. Når dere passerer 5–10 brukere, blir datakvaliteten i CRM uforutsigbar — fordi den må være det for å være brukbar. På det punktet betaler MDM-laget seg fort tilbake gjennom rapportering, ERP-integrasjon og AI-modeller som faktisk kan stole på dataene.

Hva er typiske MDM-løsninger som passer for en SMB?

Det finnes flere lett-vekt MDM-verktøy som integreres mot Dynamics 365 via standard APIer — Profisee, Semarchy, Stibo Step og enkelte Azure-native alternativer. For organisasjoner med mer eksotiske behov kan en serverless-løsning (Azure Functions + Cosmos DB) gi MDM-funksjonalitet uten å låse seg til en bestemt leverandør.

Hvordan vet vi om vi trenger MDM?

Tre signaler: ledelsen stoler ikke på kundetallene i rapporter, samme kunde har ulik stavemåte og ulike organisasjonsnummer i ulike systemer, og IT bruker betydelig tid på å synkronisere kundedata manuelt mellom CRM og ERP. Når to av tre er sanne, er en MDM-arkitekturdiskusjon overmoden.

Kan AI-agenter fungere uten et masterregister?

AI-agenter som skal lese kundedata for å ta beslutninger trenger en stabil sannhetskilde. Hvis dataene de leser fra er rotete, vil agentens beslutninger speile det — men med større volum. En MDM-lag er forutsetning for autonom AI, ikke et tillegg.

De fleste organisasjoner ender opp med et MDM-lag til slutt. Det eneste spørsmålet er om dere bygger det med vilje.

Vi hjelper med å kartlegge hvor CRM slutter og masterregisteret begynner — og finne det letteste MDM-mønsteret som faktisk passer organisasjonen, ikke det største.

Diskuter dataarkitekturen deres