BI til mellemstore danske virksomheder

De spørgsmål, der skal besvares én gang

Omsætning lyder som et entydigt ord, og det er det aldrig. Tæller den fra ordredatoen, leveringsdatoen eller fakturadatoen? Forskellen er små uger, og over et kvartalsskifte kan den flytte et tal nok til at ændre en beslutning.

Så kommer de næste: hører fragt, gebyrer og rabatter med i dækningsgraden? Er en ordre, der er krediteret, væk fra historikken, eller står den med et minus? Hvad er en aktiv kunde, og hvor længe skal der være stille, før de ikke er det?

Ingen af dem har et teknisk svar. Det er jer, der beslutter, og det tager typisk nogle timer i starten. Til gengæld er det de timer, der afgør, om ledelsen stoler på nøgletallet om et år.

Den samme kunde under fire navne

I regnskabssystemet står de med det fulde juridiske navn. I CRM står de med et forkortet navn. I webshoppen er de oprettet to gange, fordi indkøberen skiftede mailadresse. For et menneske er det åbenlyst den samme kunde. For en maskine er det fire.

Findes der et CVR-nummer, bruger jeg det som nøgle, og så løser det sig selv. Gør der ikke, skal koblingen besluttes, og der er ikke noget smart alternativ til at se på listen sammen. Det er typisk en halv dag, og den halve dag er billig.

Springer man den over, ser man det først på et møde. To rapporter viser hver sit tal for den samme kunde, og så går resten af mødet med at finde ud af hvilken der er rigtig.

Tid er sin egen disciplin

Kører jeres regnskabsår fra juli til juni, skal alt kunne vises både i regnskabsår og i kalenderår. Arbejdsdage pr. måned varierer, påsken flytter sig mellem marts og april, og uge 53 findes kun nogle år.

Det er derfor, en sammenligning mod sidste år så ofte ser forkert ud. Marts var ikke dårlig, den havde bare to arbejdsdage mindre. En datamodel skal kunne svare på begge dele: hvad tallet var, og hvad det var sammenligneligt.

Rullende 12 måneder er ofte det nøgletal, der giver ledelsen mest ro. Den fjerner sæsonen uden at skjule udviklingen, og den kan ikke reddes af en god december.

En definition, der ikke kan testes, holder ikke

Hver gang data opdateres, kører der automatiske tests, før det går videre. Summen af omsætningen skal stemme med saldobalancen. Ingen rækker må forsvinde fra en måned, der er lukket. Et nøgletal må ikke ændre sig bagud, uden at der er en forklaring på det.

Fanger testen fejlen, får jeg besked, og I ser aldrig det forkerte tal. Fanger den den ikke, opdager en direktør det på et møde. Så har det kostet tillid, som tager længere tid at bygge op end fejlen tog at rette.

Skal en definition alligevel ændres, og det skal den før eller siden, bliver historikken regnet om efter den nye. Så er serien sammenlignelig bagud, og ændringen bliver sagt højt i stedet for at ligge og flytte tallene i det stille.

Vej 1: byg selv i det setup, I har

Har I Azure, Power BI eller et data warehouse, og har I folk der kan bruge det, er dette den billigste vej i licenser. I ejer alt, og ingen skal spørges om lov, når noget skal laves om.

Det kræver én ting, og den er sværere end den lyder. Der skal være en person, for hvem datamodellen er en del af jobbet, også i den uge hvor der er kvartalsafslutning og to sygemeldinger. Er det en opgave, der ligger oven i et fuldtidsjob, bliver den ikke passet på.

Det er også her, jeg oftest bliver hentet ind som konsulent. Setuppet står der, men der mangler en, der lægger strategien, henter data ud af systemerne, modellerer det og bygger dashboards, indtil det kører af sig selv.

Vej 2: en dataplatform som Snowflake eller Databricks

I får et stærkt fundament, der kan gemme og beregne næsten ubegrænsede mængder data. Det er teknisk gode produkter, og de er ikke dyre at komme i gang med. Det, der overrasker, er hvad der følger med i regningen.

Platformen kommer tom. Integrationer, datamodel og dashboards skal bygges ovenpå, typisk med et datateam eller et konsulenthus, og det er den største post. Oveni kommer forbruget, der følger antallet af opdateringer og brugere og derfor er svært at forudsige, før løsningen kører.

Har I meget store datamængder, egne udviklere og et datateam, er det her det rigtige valg, og det siger jeg i den første snak. Er I en mellemstor virksomhed uden eget datateam, køber I i praksis et byggeprojekt oveni.

Vej 3: få det leveret færdigt

Jeg forbinder jeres systemer til min BI-platform og leverer datamodel, dashboards og AI-svar på jeres egne data. I får en løsning og én at gå til, ikke et værktøj I selv skal bygge på. Tre virksomheder kører på den i produktion i dag.

Det kræver en snak om, hvad I gerne vil kunne se, og adgang til systemerne. Resten er mit arbejde, også integrationer, tests og drift. Det første dashboard står klar inden for 14 dage fra jeg har adgang.

Til gengæld får I ikke et frit fundament at bygge videre på selv, og det er meningen. Vokser I jer ud af det, ligger jeres data i jeres egen database i et almindeligt format, og datamodellen er dokumenteret. Så er nøgletallene defineret, den dag I flytter.

De fem spørgsmål, der afgør valget

Har I en person, for hvem datamodellen er en del af jobbet? Hvor mange systemer skal forbindes, og hvor mange af dem er hjemmebyggede? Hvor hurtigt skal ledelsen kunne se noget, før tålmodigheden slipper op?

Skal regningen kunne forudsiges, eller kan I leve med, at den følger forbruget? Og hvad sker der, hvis den, der har bygget det, ikke er der næste år? Det sidste spørgsmål skal I stille til alle tre veje, også til mig.

Svarene peger næsten altid tydeligt på én af de tre. Er I i tvivl, så tag det i den første snak. Jeg har ikke noget imod at sige, at en af de to andre veje er den rigtige for jer.

Fælde 1: at starte med værktøjet

Valget af rapportværktøj er det mindst vigtige valg i hele processen, og det er næsten altid det første, der bliver diskuteret. Det er også det nemmeste at diskutere, fordi alle har en mening om en skærm.

Vælg værktøjet til sidst. Ligger datamodellen rigtigt, kan I skifte mening om værktøjet på en uge. Ligger datamodellen inde i værktøjet, har I bundet jer til det uden at have besluttet det.

Fælde 2: at bygge alt på én gang

Et projekt, der skal dække hele forretningen, før noget vises frem, bliver aflyst efter seks måneder. Ikke fordi det var forkert bygget, men fordi ingen kunne se, hvad de fik, og tålmodigheden slap op før leveringen.

Start med det nøgletal, ledelsen mangler mest, og få det til at stå rigtigt og opdatere sig selv. Så har I noget konkret at rette til efter, og det næste bliver nemmere at blive enige om.

Fælde 3: at ingen hos jer ejer definitionerne

Jeg kan bygge fundamentet, men jeg kan ikke beslutte, hvad omsætning betyder hos jer. Er der ingen, der tager den beslutning, bliver den taget alligevel, bare af den der byggede rapporten, og så står den ingen steder.

Det behøver ikke være en stor rolle. Det skal bare være tydeligt, hvem der siger ja til en definition, og hvem der bliver spurgt, når den skal ændres. Ét navn pr. nøgletal er nok.

Fælde 4: at glemme driften

En løsning, der ikke bliver passet på, holder cirka et halvt år. Systemerne skifter felter, en integration falder ud en nat, og en kunde bliver oprettet på en ny måde. Det er ikke fejl i løsningen, det er almindeligt slid.

Derfor skal det være aftalt fra starten, hvem der får beskeden, når en test fejler, og hvem der retter det. Er svaret "det finder vi ud af", så er svaret i praksis ingen.

Fælde 5: at måle på antallet af dashboards

Tolv dashboards er ikke bedre end tre. Det er tit et tegn på det modsatte. Ingen har turdet lukke noget ned, og folk har bygget hver sin version, fordi de ikke stolede på den, der var.

Mål på noget andet. Bliver beslutningerne truffet på data? Kommer svaret samme dag som spørgsmålet? Er der nogen, der stadig samler den rapport i hånden? Det er de nøgletal, der betyder noget her.