Stop datakaosset: brug data contracts som en simpel aftale mellem teams

“Jeg aner ikke, hvad ‘kunde_status’ betyder mere. Marketing bruger den én vej, økonomi en anden, og IT har lige ændret noget i baggrunden. Vores dashboard lyver mindst tre gange om ugen.”

Det sagde en kommerciel direktør til mig over en kaffe for nylig. Hun var ikke sur, bare træt. Træt af at diskutere tal i stedet for at diskutere beslutninger.

Hvis du kan genkende den situation, er pointen her: Det er sjældent datawarehouse, BI-værktøj eller data lake der er problemet. Det er manglen på helt konkrete aftaler mellem dem, der laver data, og dem, der bruger dem. Og det er præcis det, data contracts kan hjælpe med.

Forstå data contracts som en praktisk aftale, ikke som et IT-projekt

Der findes mange teoretiske definitioner, men i praksis er et data contract bare en meget konkret aftale mellem et “producerende” team (dem der ejer systemet eller integrationen) og et “forbrugende” team (dem der bygger rapporter, modeller eller produkter ovenpå).

Aftalen beskriver blandt andet:

Hvilke felter der findes. Hvad de betyder. Hvor ofte de opdateres. Hvilken kvalitet man kan regne med. Og hvad der sker, hvis noget skal ændres.

Hvis du har arbejdet med klassiske kontrakter eller it kontraktpraksis, vil du genkende logikken. Forskellen er bare, at vi her laver den i light-version inde i virksomheden, uden advokater og 60 siders bilag.

Hvordan ser et data contract ud i virkeligheden?

Forestil dig, at dit CRM-team er “producer” af kundedata, mens BI-teamet er “consumer”. En simpel data contract mellem dem kan være et 2-3 siders dokument med felter som:

Navn på datasæt, fx “Kunde_master”. Formål: “Grundlag for omsætningsrapporter, churn-analyser og kampagnestyring”. Ejerskab: Hvem godkender ændringer, og hvem har ansvaret for datakvalitet. Skema: Liste over felter, deres type, tilladte værdier og definitioner. Kvalitetskrav: Hvor mange manglende værdier eller fejl accepteres. Opdateringsfrekvens: Fx “hver nat senest kl. 03”. Ændringsproces: Hvad er varslingstid, og hvordan testes ændringer.

Det kan leve i et simpelt dokument, Confluence, Notion, SharePoint eller som markdown i et Git-repo. Formatet er mindre vigtigt end, at folk faktisk kan finde det og føler, at det er deres aftale.

Se efter disse symptomer: Så har du brug for data contracts

Man behøver ikke være data engineer for at opdage, at der er behov for mere styr på aftalerne. Typisk dukker det op i helt hverdagssituationer.

Symptom 1: Møder om tal ender i semantik, ikke beslutninger

Hvis du ofte sidder i ledelsesmøder, hvor første halvdel går med at diskutere, hvordan man overhovedet har defineret “kunde” eller “aktiv”, har du et kontraktproblem, ikke et dashboardproblem. Definitioner er blevet til mavefornemmelser og historik, i stedet for noget der står ét sted, alle har accepteret.

Symptom 2: Breaking changes uden varsel

“Breaking change” er det øjeblik, hvor et felt forsvinder, skifter betydning eller datatype, og halve rapporter bryder sammen natten over. Klassikeren er, at et felt bliver genbrugt i et kildesystem til noget “mere smart”, og ingen får det at vide, før supportmailen gløder.

Hvis du jævnligt oplever, at dashboards fejler efter releases, så mangler I aftaler om, hvad man må ændre uden varsel, og hvornår data-teamet skal med på råd.

Symptom 3: BI-teamet bruger mere tid på fejlfinding end på analyse

Jeg har set BI-teams, der bruger 60-70 % af tiden på at finde ud af, hvorfor tallene pludselig ikke stemmer med sidste uge. Ikke fordi systemerne er dårlige, men fordi der ingen tydelige aftaler er om datakvalitet og ændringer. Det slider både teamet og tilliden til data.

Byg kontrakten om datastruktur, kvalitet og ansvar

Hvis vi piller et data contract fra hinanden, består det af nogle få byggesten. De er forholdsvis simple hver for sig, men sammen gør de hele forskellen.

Felter og schema: Hvad findes, og hvad betyder det

Første del er et schema. En struktureret liste over felter i datasættet og deres betydning. Det lyder banalt, men forbløffende mange virksomheder har ikke et opdateret schema ét sted.

Eksempel for “Kunde_master”:

kunde_id: Unik nøgle genereret i CRM. Må ikke genbruges. kunde_type: Værdier: “B2B”, “B2C”. Kunde klassificeres ved oprettelse og ændres kun i særlige tilfælde. kunde_status: “Aktiv”, “Inaktiv”, “Prospect”. Definition skal være entydig, fx: Aktiv = mindst ét køb indenfor de sidste 24 måneder.

Pointen er ikke at gøre det perfekt fra start, men at få de vigtigste felter beskrevet, så alle kan se, hvad de bygger ovenpå.

Kvalitetsregler: Hvad lover vi hinanden om datakvalitet

Næste del er kvalitetsregler. Her taler vi ikke avanceret statistik, men konkrete, målbare krav.

Eksempler:

kunde_id må aldrig være tom. kunde_type skal være udfyldt for mindst 99 % af rækkerne. email skal have gyldigt format for mindst 95 % af aktive kunder. Ingen dubletter på kunde_id.

Du kan starte med 3-5 regler på de felter, der rent faktisk driver beslutninger. Det er sjovere at have 4 regler, man kan holde, end 40, ingen kender.

Ejerskab: Hvem bestemmer, og hvem kan brokke sig

Ejerskab er det punkt, der oftest er implicit. Alle antager, at “nogen” har styr på det. Det har de sjældent. I et data contract skriver du helt konkret:

Data owner: Forretningsansvarlig, fx chefen for CRM eller økonomidirektøren. Godkender ændringer i definitioner og felter. Data steward: Operationel ansvarlig, typisk i et data- eller systemteam. Sikrer, at regler for kvalitet, opdatering osv. bliver overholdt. Primary consumers: Hvem er de vigtigste brugere af datasættet, typisk BI, controlling, marketing eller produkt.

Det behøver ikke være et avanceret governance setup. Bare navne og mails, så det er tydeligt, hvem man skal have fat i ved ændringer.

Håndter breaking changes med en simpel ændringsproces

Den mest smertefulde del af dataverdener er breaking changes. Der, hvor noget ændres i et kildesystem, og ingen har forberedt dem, der bygger rapporter og modeller.

Du behøver ikke en tung proces for at få styr på det. En letvægtsversion kan være:

Fem trin til ændringer, der ikke vælter produktionen

1. Kategoriser ændringen: Er det en ren tilføjelse (nyt felt), en ændring uden brud (fx udvidet værdisæt) eller en reel breaking change (fjernet eller ændret betydning af felt). 2. Meld breaking changes tidligt: Når du planlægger en breaking change, varsles de primære consumers, fx via en fælles kanal eller mail, med forventet dato og konsekvens. 3. Versioner schemaet: Hvis muligt, opret en ny version af datasættet (fx kunde_master_v2) og kør gammelt og nyt parallelt i en periode. Det giver tid til at flytte rapporter. 4. Test mod centrale rapporter: Identificer 5-10 nøglereports, der altid skal fungere. Test dem før go-live. 5. Frys i spidsbelastning: Aftal perioder, hvor man kun laver ikke-breaking changes, fx ved kvartalsafslutninger eller større kampagner.

Det lyder måske som ekstra arbejde, men det erstatter typisk langt mere kaotisk brandslukning. Især hvis du kombinerer det med en enkel implementerings tjekliste for større ændringer.

Mål datakvalitet med få, men skarpe nøgletal

Du kan ikke forbedre det, du ikke måler. Men du kan også hurtigt drukne i datakvalitets-KPI’er, der aldrig bliver brugt. Erfaringen fra både store og små virksomheder er, at 4-5 nøgletal rækker langt, hvis de er valgt rigtigt.

Fem typer målinger, der faktisk gør en forskel

1. Fuldførelsesgrad: Andel af rækker, hvor et givent felt er udfyldt. Fx hvor mange aktive kunder der mangler kunde_type. 2. Valideringsfejl: Andel af rækker, der bryder en regel, fx ugyldige e-mails eller negative beløb, hvor det ikke giver mening. 3. Aktualitet: Hvor gammel data maksimalt må være, fx at ordredata senest er 2 timer gamle i driftsdashboardet. 4. Konsistens på tværs: Hvor ofte adskiller det samme felt sig mellem to kernesystemer, fx CRM og ERP. 5. Fejlrate over tid: Hvordan udvikler datakvaliteten sig. Færre fejl måned for måned er vigtigere end at være “perfekt” én gang.

Det vigtige er, at ejeren af datasættet får de tal serveret løbende og kan reagere. Ikke at BI-teamet sidder alene med dem og laver endnu en rapport, ingen kigger på.

Kom i gang på 30 dage: Tre contracts der giver mest værdi

Hvis du gerne vil i gang uden at gøre det til et flerårigt program, kan du tænke i en 30-dages sprint. Ikke på hele organisationen, men på de datasæt, der gør mest ondt, når de fejler.

Dag 1-5: Vælg slagmarken med omtanke

Start med at vælge de 2-3 vigtigste datasæt. Typisk er det “kunde”, “ordre” og måske “produkt”. Kig på, hvor konflikterne om tal opstår i dag. Hvilke dashboards skaber flest diskussioner. Hvad bruger ledelsen faktisk.

Her er det en fordel, hvis du i forvejen arbejder med digitalisering og teknologi som et strategisk område. Mange af de samme prioriteringsøvelser går igen.

Dag 6-15: Lav første version af kontrakterne

Brug en simpel skabelon, fx:

1. Basinfo: Navn på datasæt, formål, ejere, primære forbrugere. 2. Schema: Liste over felter, datatype, tilladte værdier og definitioner. Start med top 10-15 felter. 3. Kvalitet: 3-5 regler, du faktisk vil holde. 4. Opdatering: Hvor ofte, hvor hurtigt ved fejl, hvordan meldes forsinkelser. 5. Ændringer: Varslingstid, hvem inddrages, hvordan testes.

Sæt en time i kalenderen med både datafolk og forretning på én gang. Ikke mail frem og tilbage i 3 uger. Beskriv det, I ved, og marker de åbne spørgsmål. De kan løses løbende.

Dag 16-25: Test kontrakterne mod et par kritiske scenarier

Når første version er skrevet, så brug 1-2 møder på at “spille” den igennem. Hvad sker der, hvis marketing vil have en ny segmenteringslogik. Hvad sker der, hvis ERP-teamet vil genbruge et felt til noget andet. Hvem siger ja eller nej, og hvor står det.

Det lyder næsten banalt, men den test er ofte dét, der gør kontrakten levende i stedet for at være endnu et dokument på intranettet.

Dag 26-30: Gør det til hverdag i stedet for projekt

Til sidst skal du beslutte, hvordan data contracts skal holdes opdateret. Det kræver ikke et stort program, men nogle få vaner:

Tilføj kontrakt-review som et fast punkt ved større systemændringer. Gør det til standard, at nye datasæt først kommer i produktion, når en simpel kontrakt er udfyldt. Knyt datakvalitets-KPI’er til de eksisterende mødefora, fx månedlige performance reviews.

Hvis du arbejder i en organisation, hvor forandringer allerede fylder meget, kan det give mening at koble det til jeres eksisterende arbejde med forandringsledelse. Data contracts er i virkeligheden bare en mere konkret måde at håndtere forandringer i data på.

Data contracts gør dine dashboards kedelige på den gode måde

Min erfaring er, at gode data contracts ikke gør din hverdag mere spændende. De gør den en lille smule kedeligere. Færre brande. Færre natlige schema-fejl. Færre møder, hvor folk bruger de første 20 minutter på at diskutere definitioner.

Det frigiver tid til det, de fleste egentlig gerne vil bruge data til: at tage bedre beslutninger, teste nye idéer, bygge nye produkter. Ikke at gætte på, hvorfor “kunde_status” pludselig er faldet 12 procentpoint fra sidste uge.

Og hvis du har det ligesom mig, er det faktisk dér, dataverdenen begynder at blive interessant.