Master data management, ofte forkortet MDM, er styringen af de stamdata, som flere systemer eller selskaber deler: kunder, leverandører, varer og konti. Oprydning i ét system er en overskuelig opgave, og teksten om stamdata på ekstern-it-chef.dk dækker den. Her er spørgsmålet et andet. Når to eller flere selskaber har hver sin version af samme kunde, skal ledelsen afgøre, hvad der skal være fælles, hvem der ejer det, og hvor meget den fælles styring må koste. Svaret er oftest en mindre fælles kerne, end IT-folk drømmer om, med en klar ejer for hvert område. Værktøjet kommer til sidst.
Hvornår det er et ledelsesspørgsmål
Stamdata bliver sjældent et emne for direktionen, før noget går galt. Tegnene er kendte: koncernen kan ikke svare på, hvor meget den samlet sælger til sin største kunde. Samme vare har tre numre, så indkøb ikke kan samles. Leverandøren er oprettet flere gange, og betalinger bliver svære at følge. Et ERP-program får sat sin tidsplan over styr, fordi data ikke kan flyttes, som de står.
Fælles for dem er, at det koster forretningen noget, og at ingen enkelt afdeling kan løse det. Derfor hører sagen hjemme hos ledelsen. Og derfor bør den begrundes med en forretningsmæssig gevinst, som en leder vil stå ved.
Fire domæner, fire ejere
Stamdata falder normalt i nogle få områder, ofte kaldet domæner. Hvert af dem skal have sin egen ejer, og ejeren skal komme fra forretningen.
- Kunder. Typisk salgsdirektøren eller økonomidirektøren.
- Varer. Produktansvarlige eller supply chain.
- Leverandører. Indkøb sammen med økonomi.
- Kontoplan og dimensioner. Økonomidirektøren.
Det er samme rolle som dataejeren i data governance, og MDM er den del af området, der handler om de delte stamdata. I hverdagen er det dataejeren, der afgør, hvad der er en kunde, hvilke felter der skal være udfyldt, og hvornår to poster er den samme.
Koncerner skal desuden afgøre, om ejeren er én person for det hele, eller et fælles forum med en repræsentant fra hvert selskab. Svaret afhænger af, hvor tæt selskaberne arbejder sammen, se det fælles og det lokale.
Hvor meget der skal være fælles
Det vigtigste valg er, hvor stor den fælles kerne skal være. Det fristende svar er, at alt skal være fælles. Det gør opgaven meget stor og lader mange forskellige selskaber kæmpe om felter, de ikke bruger.
Tre niveauer hjælper til en bedre samtale:
- Fælles nøgle. Selskaberne beholder deres egne stamdata, men en kunde eller vare får en fælles identifikation, så tallene kan lægges sammen. Det kan ofte løse koncernens rapporteringsbehov.
- Fælles kerne. Nogle felter ejes centralt, fx navn, CVR og koncernforhold. Resten er lokalt.
- Fælles stamdata. Alle oprettelser og ændringer sker ét sted. Det passer til selskaber, der arbejder ens og deler ERP.
Valget skal følge forretningsmodellen. Et holdingselskab med forskellige forretninger har sjældent brug for mere end en fælles nøgle til kunderne, mens selskaber med samme varer og kunder har en stærkere grund til at dele. Se også holdingselskabet med forskellige forretninger og koncernrapportering fra flere ERP-systemer.
Processen er vigtigere end værktøjet
MDM forbindes ofte med en softwarepakke. Processen giver som regel mere end softwaren og skal på plads først. Spørgsmålene er enkle: hvem må oprette en ny kunde, hvem godkender, hvad sker der med dubletter, og hvordan når ændringen ud til de andre systemer?
Vurder først et værktøj, når processen er tydelig, og når omfanget kræver det. I nogle tilfælde kan ERP-systemet bære det meste, hvis alle selskaber er på samme system. I andre tilfælde er der så mange systemer, at et separat værktøj kan være berettiget, og det hænger så sammen med jeres integrationsplatform. Hvilket produkt der passer, og hvordan det sættes op, må jeres arkitekter og en specialist se på. Behandl det som enhver anden investering med en business case.
Sammenhængen med programmer
Den bedste anledning til at tage fat er sjældent et selvstændigt stamdataprojekt, som kan være svært at sælge. Den bedste anledning er et ERP-program, et opkøb eller et krav om bedre koncerntal. Så er der en konkret grund, en frist og en gevinst.
Et tænkt eksempel: en koncern skal samle tre selskaber på én ERP-skabelon. Inden flytningen aftaler indkøbschefen og produktansvarlige en fælles varestruktur for de to selskaber, der deler sortiment. Det tredje selskab beholder sin struktur og får en fælles nøgle til rapporteringen. Programmet får færre spørgsmål at afgøre, og næste selskab kan tilføjes efter samme aftale.
Det samme gælder efter opkøb. En virksomhed, der kommer til, har egne stamdata, og det skal besluttes, hvornår og hvordan de følger med. Læs mere under to ERP-systemer efter opkøbet.
Efter oprydningen
Stamdata holder sig ikke selv rene. Når ejerne er udpeget, skal de følge kvaliteten med få målinger: dubletter, manglende felter og tid til oprettelse. Tallene hører til hos dataejerne og i det forum, de mødes i. Hvis kvaliteten falder, er det et signal om, at processen bliver omgået, ofte fordi den er for langsom. Så skal processen ændres.
Hvad gør I nu?
Stil ét spørgsmål, som kræver en samlet opgørelse, fx hvor meget koncernen sælger til sine ti største kunder. Tager det uger at svare, kender I problemet. Find ejeren af det domæne, og beslut, hvilket niveau af fælles styring der er nok til at løse netop dét.
Det skal I lade være med
- At begynde med et værktøj · ejerskab og proces kommer først.
- At kræve alt fælles · en fælles nøgle kan være nok for selskaber, der arbejder forskelligt.
- At lade IT afgøre, hvad en kunde er · det er et forretningsspørgsmål.
Det skal I kræve af dem, der leder IT
- ☐ Et overblik over, hvor stamdata oprettes og lever i dag.
- ☐ Et udkast til fælles nøgle, kerne eller stamdata med begrundelse.
- ☐ Enkle målinger af kvaliteten pr. domæne.
- ☐ En vurdering af, om ERP kan bære opgaven, før der tales om nye produkter.
- ☐ Stamdata som fast punkt i planerne for ERP-programmer og opkøb.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Fælles ERP-skabelon · Koncernrapportering fra flere ERP-systemer
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
