Data governance uden teatertorden: det mindste setup der faktisk virker

“Vi har tre officielle omsætningstal for sidste måned. Hvilket et vil du have?”

Den sætning hørte jeg første gang fra en frustreret salgschef i en scaleup med 70 medarbejdere. Der var ikke noget ondt i det. De havde bare vokset sig hurtigere end deres datamodel, og hver afdeling havde lavet deres eget Excel-ark, eget dashboard og egen sandhed.

Hvis du kan genkende det billede, er du ikke alene. De fleste mindre og mellemstore virksomheder har i dag BI-værktøjer, masser af data og måske også en AI-pilot eller to. Men uden et minimum af data governance ender beslutningerne med at blive langsommere og mindre sikre, ikke hurtigere og bedre.

I denne artikel folder jeg et minimum viable data governance-setup ud. Altså det mindste, man kan slippe af sted med, hvis man vil have stabile dashboards, færre KPI-krige og en AI, der ikke konstant skal undskyldes med: “Ja, den er ikke helt trænet endnu”.

1. Hvad data governance egentlig skal løse (og hvordan problemerne ser ud i hverdagen)

Hvad er det egentlig, der går galt, når en virksomhed får mere data, flere dashboards og flere AI-projekter, men ikke mere klarhed?

Hvis vi skærer alle frameworks ned til noget, man kan forklare på et whiteboard, handler data governance om tre ting:

• At ledelsen kan stole på tal og rapporter
• At man kan svare hurtigt og nogenlunde ens på vigtige spørgsmål
• At man ikke løber unødvendig risiko ift. lovgivning og sikkerhed

Problemerne viser sig sjældent som “mangler data governance”. De viser sig som helt konkrete irritationsmomenter:

• Tre møder i træk hvor man ikke når beslutningen, fordi folk diskuterer tal fremfor valg
• Dashboards, der tages ned igen, fordi “de viser noget andet end vores Excel”
• En AI-model, der virker lovende i en POC, men ikke kan komme i drift, fordi ingen helt ved, hvilke data der må bruges hvor
• Medarbejdere, der laver deres egne udtræk, fordi de ikke stoler på “det officielle”

Det er her, et letvægts-setup kan gøre en forskel. Ikke et tungt enterprise-program, men en simpel arbejdsdeling, nogle få kvalitetstal og en møderytme, der holder fast i forbedringer over tid. Tænk mere i pragmatisk organisering og governance end i store transformationer.

2. Minimumsrollerne: hvem har ansvaret for hvad?

De fleste data governance-frameworks introducerer en mindre hær af roller. Det kan give mening i meget store virksomheder. I en SMV eller scaleup er det opskriften på, at ingen tager det seriøst.

Jeg vil foreslå, at man starter med tre roller, og at de formelt udpeges. Altså ikke bare “alle ved jo, at…”.

2.1 Data owner: forretningsansvaret

Data owner er forretningslederen for et dataområde. Det er typisk salgschefen, marketingchefen, økonomichefen eller lederen af et driftsteam.

De ejer ikke databasen. De ejer beslutningerne omkring:

• Hvilke nøgletal er “officielle”
• Hvilke kvalitetsniveauer der er acceptable
• Hvilke ændringer i processer og systemer der skal til for at hæve kvaliteten

Hvis I for eksempel vælger “Kunde og salg” som domæne, er det ofte salgschefen eller den kommercielle direktør, der bør være data owner.

2.2 Data steward: den der kender detaljerne

Data steward er den person, der faktisk ved, hvordan data opstår, og hvor de kan gå galt. Det er typisk en power user, controller eller analytiker.

Deres opgaver i et minimum setup:

• Definere felter og KPI’er sammen med data owner
• Overvåge simple kvalitets-KPI’er
• Registrere dataproblemer og foreslå løsninger

Det er ofte denne rolle, der i forvejen sidder alene om aftenen og forsøger at få tallene til at passe. Forskellen er, at de nu får mandat, sprog og struktur til at gøre noget ved årsagerne, ikke kun brandslukke.

2.3 Data custodian: den tekniske forvalter

Data custodian er den tekniske ejer af de systemer og databaser, hvor data faktisk ligger. Det kan være IT-chefen, en BI-udvikler, en ekstern partner eller en superbruger på et ERP-system.

I et minimum setup har de tre opgaver:

• Sikre at tekniske ændringer dokumenteres og kommunikeres til stewards
• Implementere datakvalitetsregler, hvor det giver mening (validering, obligatoriske felter osv.)
• Bidrage til vurdering af indsats ift. forbedringsforslag

Pointen er enkel: en data owner beslutter, hvad der er vigtigt. En data steward opdager og beskriver problemerne. En data custodian implementerer de tekniske ændringer, der skal til.

3. Start småt: vælg 3-5 datadomæner

En klassisk fejl er at ville have governance på “alle data”. Det er en pæn tanke, men urealistisk. I praksis bør du vælge 3 til 5 datadomæner, som I starter med.

Et datadomæne er i denne sammenhæng et forretningsområde, hvor data hænger nogenlunde naturligt sammen. Typiske eksempler:

• Kunder og salg
• Produkter og prislister
• Økonomi og regnskab
• Drift og leverancer
• Marketing og kampagner

Hvordan vælger man så de første domæner?

Jeg plejer at stille tre spørgsmål til ledelsen:

• Hvor skaber dataproblemer i dag mest støj i møderne?
• Hvor er konsekvensen af forkerte tal størst (kroner, kunder, compliance)?
• Hvor har vi allerede nogen, der er naturlige data owners og stewards?

Hvis “Omsætning og pipeline” er det mest konfliktfyldte emne på ledermøderne, er det et godt sted at starte. Ikke fordi det er nemmest, men fordi effekten af forbedringer mærkes hurtigt. Og det er afgørende, hvis dette ikke bare skal blive endnu et projekt på listen.

4. Definitioner og data contracts: sådan undgår I KPI-krige

Jeg har set flere virksomheder bruge hundrede tusindvis af kroner på BI, hvor den mest værdifulde leverance viste sig at være et simpelt definitionsdokument på 8 sider.

Data governance handler ikke om at lave 200 sider datamodel. Det handler om at få de 10 vigtigste definitioner på skrift og få dem accepteret.

4.1 Vælg de 10 vigtigste begreber pr. domæne

For hvert af dine 3-5 domæner: bed data owner og data steward om at lave en liste over de vigtigste forretningsbegreber og KPI’er. Ikke alt. Bare det, der hele tiden skaber diskussioner.

For “Kunder og salg” kunne det være:

• Aktiv kunde
• Tabt kunde
• Lead
• Kvalificeret lead
• Pipeline
• Omsætning
• MRR/ARR hvis I kører abonnement

For hver af dem skal I besvare tre spørgsmål:

• Hvordan er definitionen i ord?
• Hvordan er definitionen i system-logik (felter, datoer, værdier)?
• Hvem er ansvarlig for, at feltet opdateres korrekt (rolle, ikke navn)?

4.2 Data contracts: små, men forpligtende aftaler

Data contracts lyder tungt, men i en SMV kan du tænke på dem som små aftaler mellem forretning og teknik om, hvordan data skal se ud og bruges.

Et eksempel på en enkel contract for “Pipeline”:

• Scope: alle åbne salgsmuligheder i CRM-systemet
• Regel: kun deals med estimeret lukket dato inden for de næste 6 måneder medregnes
• Regel: deals uden ansvarlig sælger medregnes ikke
• Regel: deals i status “Opsøgende” medregnes ikke
• Owner: salgschef
• Steward: CRM-superbruger

Det tager en time at skrive, men kan spare jer for mange timers pseudo-diskussioner på tværs af salg og økonomi. Og det bliver pludselig muligt at lave meningsfulde BI-rapporter og mere stabile AI-modeller, fordi inputtet er klart.

5. Fem datakvalitets-KPI’er der holder styr på virkeligheden

Her kommer den del, hvor regnearksfolk som mig bliver lidt ekstra glade. Hvis data governance skal være mere end principper, skal det kunne måles.

Et minimum setup kan nøjes med fem datakvalitets-KPI’er på tværs af jeres vigtigste tabeller. De klassiske fem er:

• Komplethed
• Validitet
• Aktualitet
• Konsistens
• Unikhed

Lad os tage dem én for én med eksempler.

5.1 Komplethed: hvor meget mangler?

Komplethed handler om, hvor stor en andel af de nødvendige felter der faktisk er udfyldt.

Eksempel: I jeres kundetabel er “Branche” og “Land” vigtige felter til segmentering og prissætning. En simpel KPI kunne være: “Andel af aktive kunder med både Branche og Land udfyldt”.

Threshold for et modent setup: 98-99 %. Threshold for et minimum setup: sæt mål om at komme over 90 % og hæve den løbende.

5.2 Validitet: er værdierne inden for de regler, I selv har sat?

Validitet måler, om feltet har en værdi, der giver mening ift. de regler, I har defineret. Det kan være:

• Leveringsdatoer, der ikke ligger før ordredato
• Procenter mellem 0 og 100
• Postnumre, der findes i det land, kunden tilhører

KPI’en er typisk: “Andel af rækker, der overholder alle valideringsregler”.

5.3 Aktualitet: hvor gamle er data, når I bruger dem?

Aktualitet handler om, hvor langt der er mellem virkelighedens hændelser og tidspunktet, hvor de findes i jeres rapporter.

Eksempel: I ønsker daglige salgsrapporter. En KPI kan være: “Andel af ordrer der er registreret i ERP senest dagen efter ordredato”.

Her er det vigtigt, at data owner er med til at sætte det rigtige niveau. I nogle processer er 24 timer fint. I andre skaber selv 2 timers forsinkelse problemer.

5.4 Konsistens: siger tabellerne det samme?

Konsistens måler, om den samme oplysning er ens på tværs af systemer eller tabeller.

Det klassiske eksempel er antal aktive kunder. Hvis CRM, ERP og et abonnementssystem viser tre forskellige tal, har I et konsistensproblem.

En simpel KPI kan være: “Afvigelse i antal aktive kunder mellem CRM og ERP”. Det kan faktisk stå som et tal: f.eks. “Afvigelse: 37 kunder”. Det viser direkte, at der er oprydningsarbejde.

5.5 Unikhed: hvor mange dubletter har I?

Unikhed handler om, hvor ofte den samme enhed (kunde, produkt, medarbejder) findes flere gange i jeres systemer, selvom den burde være én gang.

KPI’en kunne være: “Andel af kunder med potentiel dublet” baseret på match på navn, CVR-nummer eller email.

Her er et realistisk threshold måske, at andelen af dubletter skal under 2-3 % i første omgang, og at der løbende ryddes op. Perfektion er dyrt. Markant forbedring er opnåelig.

6. Governance-ritualer: ét møde om måneden og en simpel backlog

Hvis du kun skulle indføre én ting, ville jeg faktisk vælge dette: et månedligt data review-møde med fast struktur.

Deltagere:

• Data owners for de valgte domæner
• Data stewards for samme domæner
• En repræsentant for IT/BI (custodian) hvis relevant

Varighed: 60-90 minutter. Ikke mere.

6.1 Fast agenda

En simpel, men fast agenda kunne være:

1. Gennemgang af datakvalitets-KPI’er for hvert domæne
2. Nye dataproblemer i backloggen (kort omtale)
3. Beslutning om 2-3 forbedringstiltag til næste måned
4. Eventuelle ændringer i definitioner og data contracts

Backloggen behøver ikke være mere avanceret end et delt regneark eller et simpelt ticket-system. Det vigtige er, at problemerne beskrives kort, tilknyttes et domæne og en steward, og får en simpel prioritet: Lav, Mellem, Høj.

6.2 Beslutningsregler

For at mødet ikke ender i “det tager vi lige videre”, skal der være nogle klare beslutningsregler:

• Kun data owners kan godkende ændringer til definitioner
• Data stewards beskriver problemet og et forslag til løsning skriftligt
• Data custodians vurderer teknisk indsats (lav, mellem, høj)

Beslutningen i mødet er enten “Gennemføres til næste møde” eller “Parkeres / kræver projekt”. Intet tredje. Det gør underværker for momentum.

Hvis du er vant til at arbejde med implementerings-tjeklister, vil du opleve, at det samme mindset fungerer fint her: små, konkrete leverancer, synlig fremdrift, få ting i gang ad gangen.

7. Tooling light: det her kan I gøre uden nye platforme

Mange tror, at data governance kræver en ny platform, et metadata-katalog og endnu et dyrt abonnement. Det kan komme senere. Men et minimum viable-setup kan bygges med ting, I sandsynligvis allerede har.

7.1 Dokumentation

Til definitioner og data contracts er et simpelt dokument i SharePoint, Confluence eller Google Docs fint. Det vigtigste er:

• At det er delt og let at finde
• At der står dato og ansvarlig på ændringer
• At det faktisk bruges som reference i møderne

7.2 Datakvalitets-KPI’er

Til selve målingen kan jeres eksisterende BI-løsning næsten altid bruges. Power BI, Tableau, Looker eller hvad I har.

Typisk gør man sådan:

• Bygger et lille datakvalitets-dashboard pr. domæne
• Laver simple DAX- eller SQL-regler, der beregner de fem KPI’er
• Publicerer det til de relevante data owners og stewards

Microsoft har f.eks. en brugbar introduktion til, hvordan man arbejder med dashboards i Power BI i deres egen dokumentation. Den kan være et fint startpunkt, også selvom jeres løsning ikke er identisk.

7.3 Backlog og møder

Til backlog og møder kan I bruge det samme værktøj, som I bruger til øvrige opgaver: Jira, Trello, Planner eller bare et delt ark. Målet er ikke at gøre det smukt. Målet er at gøre det stabilt.

Hvis I i forvejen arbejder med projekter indenfor digitalisering og teknologi, så prøv at få data governance ind som et fast tema på jeres eksisterende styringsmøder, i stedet for at opfinde et helt separat univers.

8. En 6-ugers plan til at komme fra kaos til et minimums-setup

For ikke at ende i endnu et diffust “vi skal blive bedre til data”-projekt, kan du tænke i en stram 6-ugers plan. Ikke for at være perfektionist, men for at komme til et punkt, hvor effekten kan mærkes i hverdagen.

Uge 1: Vælg domæner og roller

• Ledelsen vælger 3-5 datadomæner, hvor datakvalitet og fælles definitioner vil gøre størst forskel
• For hvert domæne udpeges en data owner og en data steward
• IT/BI identificerer, hvem der er primær data custodian pr. domæne

Det kan klares på ét ledermøde og et par korte opfølgninger.

Uge 2: Kort liste over begreber og KPI’er

• Hver data owner og steward laver en liste over 10 centrale begreber/KPI’er i deres domæne
• De beskriver nuværende udfordringer: hvor skaber de her tal forvirring eller konflikter?
• Listen samles centralt og deles med resten af ledergruppen

Målet er ikke fuld enighed endnu. Målet er synlighed.

Uge 3: Definitioner og første data contracts

• For hvert domæne vælges 3-5 begreber, der skal have en egentlig definition
• Data owner og steward beskriver dem i både ord og system-logik
• Enklere data contracts formuleres, hvor det giver mening (f.eks. for pipeline, aktiv kunde, ordre)

Her kan det være en fordel at tage én fælles workshop med whiteboard og derefter lade stewards rydde op i formuleringerne.

Uge 4: Datakvalitets-KPI’er implementeres teknisk

• BI/IT sætter de fem datakvalitets-KPI’er op for de vigtigste tabeller i hvert domæne
• Første version af et simpelt datakvalitets-dashboard laves
• Stewards tjekker, om tallene virker plausible og forstår logikken

Det behøver ikke være perfekt. Det skal være godt nok til at se relative forbedringer over tid.

Uge 5: Første data review-møde

• Første månedlige data review afholdes
• Datakvalitets-KPI’er præsenteres per domæne
• De 3 vigtigste problemer pr. domæne identificeres og beskrives i backloggen
• 2-3 konkrete tiltag aftales til næste måned

Vigtig pointe: sig højt, at dette er første iteration. Formålet er at skabe fælles sprog, ikke at “fange” nogen i fejl.

Uge 6: Justering og tydeliggørelse

• Definitioner og data contracts justeres, hvor der opstod misforståelser i uge 5
• Roller og ansvar justeres, hvis nogen er fejlplacerede
• Planen for de næste tre måneder aftales: hvad vil I forbedre først?

Efter 6 uger bør I stå med:

• Udpegede data owners, stewards og custodians for 3-5 domæner
• Et kort, men brugbart definitionsdokument
• De fem datakvalitets-KPI’er oppe at køre i et dashboard
• En tilbagevendende møderytme og en simpel backlog

Det lyder beskedent, men for mange virksomheder er det springet fra datakaos til et styret forbedringsforløb. Og det er først her, at avancerede AI-projekter for alvor giver mening, fordi man har en nogenlunde stabil “single source of truth” i praksis, ikke kun i præsentationer.

Hvis du sidder med ansvar for data, BI eller digitalisering og i forvejen arbejder med fx NIS2 eller andre regulative krav, kan du med fordel tænke data governance ind som søsterdisciplin. Strukturen fra arbejdet med NIS2 uden panik ligner faktisk påfaldende meget det, der skal til her: roller, processer, dokumentation og en fast rytme.

Forskellen er, at gevinsten ved bedre data governance ikke kun er, at man undgår risici. Man får også roligere ledermøder, hurtigere beslutninger og AI, der opfører sig mindre tilfældigt. Det er ikke nogen dårlig byttehandel for et par ekstra regneark og et møde om måneden.