Datafundament: sådan bygger I et grundlag, rapporteringen kan hvile på

De fleste virksomheder oplever det samme forløb. Man investerer i rapportering, får noget pænt at se på — og et halvt år senere bruger ledelsen stadig de første tyve minutter af hvert møde på at blive enige om, hvilket tal der er det rigtige.

Reaktionen er som regel at bygge et nyt dashboard. Det hjælper sjældent, for problemet sidder ikke i visningen. Det sidder i laget under: hvor data kommer fra, hvordan de er sat sammen, og hvad begreberne betyder. Det lag kalder vi datafundamentet, og det er usynligt, når det virker.

Hvad er et datafundament?

Et datafundament er alt det, der sker mellem jeres kildesystemer og den rapport, nogen ser på. Det samler data ét sted, ensretter dem, gemmer historik og oversætter dem til de begreber, forretningen faktisk taler i.

Pointen er ikke opbevaring. Pointen er enighed. Når økonomi og salg begge henter deres omsætningstal fra samme sted, med samme definition, forsvinder diskussionen om, hvem der har ret — og møderne kan handle om, hvorfor tallet bevæger sig.

Hvorfor rapportering uden fundament altid skrider

Rapportering bygget direkte oven på kildesystemerne virker fint i starten. Den falder fra hinanden på tre forudsigelige måder:

• Kilden ændrer sig. Et felt får et nyt navn, en kategori bliver splittet i to, en integration skifter format. Rapporten fejler ikke — den bliver bare stille forkert.
• To kilder skal kobles sammen. Så skal nogen beslutte, hvordan en kunde i det ene system svarer til en kunde i det andet. Den beslutning bliver som regel truffet ad hoc, i en formel, som ingen finder igen.
• Nogen spørger til historikken. Kildesystemer viser tilstanden nu. De husker sjældent, hvordan verden så ud i marts sidste år, og de husker aldrig, hvad der siden er blevet rettet.

Hver af dem koster tillid. Og tillid er asymmetrisk: den tager måneder at bygge op og ét forkert tal på et ledelsesmøde at miste.

De fire lag i et datafundament

Et fundament er ikke ét system. Det er fire lag, der hver løser et afgrænset problem. De bygges nedefra, og hvert lag antager, at laget under det er på plads.

1. Indsamling: at få data ud af kilderne, pålideligt

Første lag henter data fra kildesystemerne og lægger dem et sted, hvor de kan arbejdes med. Det lyder trivielt og er det ikke: indsamlingen skal køre efter en fast rytme, den skal kunne genstartes uden at lave dubletter, og den skal sige tydeligt fra, når en kilde ikke svarer.

Det vigtigste princip er, at rådata gemmes som de kom ind, før noget ændres. Så kan enhver senere fejl spores tilbage — og en transformation, der viser sig at være forkert, kan køres om uden at hente alt igen.

2. Ensretning og historik: at gøre data sammenlignelige over tid

Andet lag rydder op. Datoformater bliver ens, beløb får samme valuta og fortegnsregel, koder oversættes til noget læsbart, og dubletter fjernes efter en regel, der er skrevet ned.

Her lægges også historikken. Hvis en kunde skifter segment, eller et produkt flytter kategori, skal I kunne vælge: skal sidste års tal følge den gamle eller den nye inddeling? Begge svar kan være rigtige — men kun hvis I har gemt nok til at kunne vælge.

3. Forretningsmodellen: at oversætte data til begreber, I taler i

Tredje lag er der, hvor teknik bliver til forretning. Ordrelinjer, konteringer og tidsregistreringer bliver til omsætning, dækningsbidrag og kapacitetsudnyttelse — med en definition per begreb, som nogen har taget stilling til.

Det er også her, de svære spørgsmål skal besvares: Tæller en ordre ved bestilling eller ved levering? Er en kreditnota negativ omsætning eller en omkostning? Hører en rabat til på ordren eller på kunden? Spørgsmålene forsvinder ikke af, at man lader være med at stille dem — de dukker bare op senere som to rapporter, der ikke stemmer.

4. Præsentationslaget: at gøre modellen brugbar

Fjerde lag former data til det, brugerne møder: KPI'er, dashboards, udtræk. Det er det eneste lag, folk normalt kan se — og derfor det, de tror problemet sidder i.

Et godt præsentationslag tilføjer ingen ny logik. Hvis et dashboard skal regne noget, som modellen ikke allerede kan svare på, er der noget, der mangler et lag længere nede.

Rækkefølgen, der virker

Fristelsen er at starte med det synlige. Det er også den dyreste vej. En rækkefølge, der holder:

1. Beslut, hvad I skal kunne svare på. Ikke hvilke tal I vil se — hvilke beslutninger de skal understøtte. Tre til fem konkrete spørgsmål er nok til at starte.
2. Følg spørgsmålene tilbage til kilderne. Så bliver det tydeligt, hvilke kilder der faktisk er nødvendige, og hvilke der bare er tilgængelige.
3. Byg indsamling og ensretning for netop de kilder. Ikke for alt. Et smalt, færdigt fundament slår et bredt, halvt.
4. Definér begreberne, mens I har fat i dem. Uenigheder om definitioner er nemmest at afklare, mens nogen stadig kan huske, hvorfor feltet ser ud som det gør.
5. Byg først derefter KPI'er og dashboards. Nu er der noget at bygge dem på. Se metoden fra forretningsmål til KPI'er for det næste skridt.

Fem beslutninger, der er dyre at ændre bagefter

Noget kan altid laves om. Det følgende kan også, men det gør ondt — så det er værd at bruge en time på hver af dem tidligt.

• Granularitet. Gemmer I på ordrelinjeniveau eller på dagsniveau? Man kan altid aggregere op fra det detaljerede, aldrig regne sig ned fra det aggregerede.
• Historikstrategi. Skal ændringer i stamdata overskrive fortiden eller gemmes som versioner? Vælger I overskrivning, er historikken væk, når I opdager, at I havde brug for den.
• Nøgler på tværs af systemer. Hvad identificerer entydigt en kunde, når to systemer har hver sit id? Vælg nøglen bevidst, og skriv reglen ned.
• Tidsdimensionen. Regnskabsår, kalenderår eller begge? Uge efter ISO eller efter noget andet? Det er trivielt at aftale og pinefuldt at ændre, når tal er blevet kommunikeret.
• Ejerskab af definitioner. Hvem beslutter, hvad «aktiv kunde» betyder? Uden en navngiven ejer bliver definitionen forhandlet igen hvert kvartal.

Hvornår er fundamentet godt nok?

Et fundament bliver aldrig færdigt, men det bliver hurtigt godt nok. Brug de her fire spørgsmål som prøve:

• Kan to personer nå frem til det samme tal uden at tale sammen?
• Kan I se, hvordan tallet så ud for tolv måneder siden?
• Får nogen automatisk besked, hvis en kilde holder op med at levere?
• Kan en ny medarbejder finde ud af, hvad et begreb betyder, uden at spørge?

Fire ja er et solidt fundament. To ja er nok til at komme i gang — men så ved I også, hvor de næste to skridt ligger.

Hvor I går videre herfra

Fundamentet er første halvdel. Den anden er at bruge det: at oversætte forretningsmål til få, veldefinerede måltal og give dem en form, folk faktisk handler på. De to artikler herunder tager fat, hvor denne slipper — og gennemgangen af de typiske datakvalitetsfejl er værd at læse, inden I bygger, snarere end efter.

Vil I hellere have os til at gøre det, kan I se hvordan vi bygger datafundamenter eller hvordan et forløb forløber.