Datafundamentet for AI: 4 krav før modellen kan bruges

De fleste AI-projekter i danske SMV’er strander ikke på modellen. De strander på, at den samme kunde står tre gange i debitorkartoteket, at varekategorikoden er valgfri, og at historikken knækker der, hvor virksomheden skiftede system. Datafundamentet for AI hviler på fire konkrete krav — og nedenfor står regnestykket på, hvad 8 % dubletter koster i en churn-model.

Resumé og konklusion

Fire krav: AI i vækstsammenhæng er mønstersøgning i egne data. Datadisciplin, historik, granularitet og ejerskab skal være på plads, før modellen kan bruges.
Datadisciplin: Konsistente dimensioner — kunde, vare, afdeling, sælger, projekt — en kontoplan der afspejler forretningen, og vedligeholdt stamdata. Valgfrie dimensioner er i praksis ingen dimensioner.
Historik: Der skal være 24-36 måneders historik på transaktionsniveau. Aggregerede månedstotaler giver 24-36 datapunkter, og det rækker ikke.
Granularitet: Varelinje, ikke ordrehoved. Skift i produktmix er typisk den tidligste forløber for, at en kunde er på vej ud.
Ejerskab: Uden én navngiven ejer pr. nøgletal bliver datakvalitet et fælles ansvar — og dermed ingens.

Datafundamentet for AI hviler på fire krav

En model finder kun mønstre i det, den får, og den kan ikke skelne et rigtigt tal fra et forkert. Datafundamentet for AI er derfor ikke en forberedelse til AI-arbejdet. Det er selve arbejdet.

De fire krav er datadisciplin, historik, granularitet og ejerskab. De tre første kan du måle på en eftermiddag; det fjerde er en beslutning, ledelsen skal træffe. Står din virksomhed lavt på AI-modenhedstrappen, er det her, arbejdet begynder — ikke ved valget af model.

Datadisciplin: dimensioner, kontoplan og stamdata

Datadisciplin er det første krav: at de dimensioner, du styrer efter — afdeling, sælger, projekt, varekategori, kundesegment — er udfyldt hver gang. Det, der går galt, er sjældent dramatisk.

En sælger fratræder, koden genbruges til efterfølgeren, og to års salgshistorik ser ud til at tilhøre samme person. En varegruppe oprettes som ”Diverse”, og 400 varenumre lander der, fordi det var hurtigst. En dimension er valgfri og udfyldes på 80 % af posteringerne — og de manglende 20 % er ikke tilfældige. De ligger i de travle måneder.

Kontoplanen hører med. Bogføres fragt over vareforbrug i den ene afdeling og som omkostning i den anden, er ”dækningsgrad pr. kunde” ikke ét tal, men to. En model trænet på det lærer geografien i din kontoplan i stedet for adfærden hos dine kunder. Det er også derfor, stamdata der bærer analysen er en ledelsesopgave og ikke en oprydning, man tager, når der bliver tid.

Konsekvensen af et manglende lag står til højre: 8 % dubletter i bunden gør knap 44 % af churn-modellens træningsdata forkerte.

Historik og granularitet: 24-36 måneder på varelinjeniveau

Historik er det andet krav. Sæson kan først adskilles fra tilfældig variation, når den samme sæson er set mindst to gange, og en churn-model skal se både kunder, der blev, og kunder, der gik. Derfor 24 måneder som minimum og 36 som det komfortable.

Men det skal være historik på transaktionsniveau. Tolv månedstotaler pr. år er 24 tal på to år. En virksomhed med 900 kunder og ti ordrer pr. kunde om året har derimod 18.000 ordrer i samme periode — hver med dato, kunde, sælger, beløb og linjer. Det er forskellen på at beregne et gennemsnit og at genkende et mønster.

To ting ødelægger historikken. Den ene er systemskiftet: ved migreringen blev der overført åbne poster og saldi, ikke transaktioner, og kundenumrene blev nye. Modellen ser det, som om alle kunder blev oprettet samme dag. Den anden er datoforvirring. Ordredato, dokumentdato, bogføringsdato og leveringsdato er fire forskellige begreber. Blandes de sammen, forskydes hele mønsteret med det, der reelt er din interne sagsbehandlingstid.

Granularitet er det tredje krav. Ordrehovedet fortæller, hvor meget kunden købte. Varelinjen fortæller hvad. En kunde med flad omsætning, hvis mix har flyttet sig fra dine A-varer til lavmargin-standardvarer, er ofte i gang med at flytte kernesortimentet til en konkurrent. Det ses kun på linjeniveau — og typisk to til fire måneder før omsætningen falder.

Ejerskab: én navngiven person pr. nøgletal

Det fjerde krav er organisatorisk. Hvert nøgletal, du vil forudsige, skal have én navngiven ejer — ikke en afdeling, ikke en styregruppe. Ejeren af DSO ejer definitionen, ejer datakvaliteten bag den og reagerer, når tallet ser forkert ud.

Uden det falder kvaliteten tilbage til udgangspunktet inden for et år, uanset hvor grundig oprydningen var. Det er det lag i datafundamentet for AI, der hverken kan købes eller automatiseres.

Garbage in, confident garbage out

Et regneark viser sin egen usikkerhed. Tomme celler er tomme, og #DIV/0 kan ses. En model gør det modsatte: den returnerer en sandsynlighed på 0,83, uanset om kunden bag findes tre gange i kartoteket. Selvtillid i outputtet siger intet om kvaliteten i inputtet.

Det er den egentlige risiko. Et forkert tal i en rapport fanges ofte, fordi nogen kender forretningen. Et forkert tal med en sandsynlighed og en pæn visualisering bliver handlet på. Datakvalitet er derfor et ledelsesemne, ikke et it-emne.

Regneeksempel: hvad 8 % dubletter gør ved en churn-model

En grossist med 48 mio. kr. i omsætning har 1.000 debitorkonti. 8 % er dubletter — 80 konti, hvilket er lavt for et kartotek bygget op over ti år. Der er altså 920 reelle kunder. Af de 80 dubletkonti er 50 gamle kort, der gik i dvale, da kunden blev oprettet på ny; de ser ud som churn. De sidste 30 er parallelle kort på aktive kunder, hvis ordrer nu deler sig i to.

Den faktiske churn er 7 % om året, altså 64 kunder. Træningsdata indeholder derfor 64 + 50 = 114 churn-hændelser, hvoraf de 50 ikke er churn. Knap 44 % af det, modellen skal lære ”tabt kunde” af, er en flytning i kartoteket. Oveni ser 30 aktive kunder ud til at have halveret ordrefrekvensen — præcis den variabel, modellen vægter højest.

Modellen flager 40 kunder pr. kvartal, og 18 af dem er falske. Ved 2,5 timers opfølgning er det 180 timer om året, og ved 600 kr. i timen 108.000 kr. i spildt salgstid. Hertil kommer de reelle churn-kunder, modellen ikke fanger: ti kunder à 52.000 kr. med 30 % dækningsgrad er 156.000 kr. i tabt dækningsbidrag. I alt cirka 264.000 kr. om året — for 80 forkerte linjer i et kartotek.

Faldgruber: ryd op efter nøgletal, ikke efter kartotek

Den største faldgrube er at rydde op i alt. Et fuldt datakvalitetsprojekt på tværs af debitorer, varer, dimensioner og kontoplan tager typisk fire til seks måneder i en virksomhed med 50 mio. kr. i omsætning — og mister opbakning, før det er færdigt.

Prioritér efter det nøgletal, du vil forudsige først. Hvilke vækstområder AI betaler sig bedst på, ser vi på i næste artikel. Skal det være churn, skal debitorkartoteket og varelinjerne være rene, og kontoplanen kan vente. Skal det være likviditet, skal betalingsbetingelser og betalingsdatoer være rigtige, mens varekategorierne er irrelevante.

Realistisk tidsforbrug: dubletsøgning i 1.000 debitorer er to til tre arbejdsdage. Varekategorisering af 3.000 varenumre er tre til seks uger, fordi hierarkiet kræver en forretningsmæssig beslutning. Dimensioner kan gøres obligatoriske på en formiddag — men historikken udfyldes ikke bagud. Den starter den dag, du strammer op.

Sådan sætter du det op i Business Central

Start på debitorkortet. Udfyld Registreringsnr. (CVR) konsekvent, og brug Sammenlæg dubletter til at flette debitorer, kreditorer og kontakter, så posthistorikken følger med i stedet for at blive efterladt på det gamle kort. Sæt Sælgerkode på debitorkortet, ikke kun på ordren. På varekortet gøres Varekategorikode obligatorisk, og varekategorierne bygges med hierarki. Konfigurationspakker (RapidStart) bruges til masseopdateringen.

Afgør derefter, hvilke to dimensioner der skal være globale, og hvilke der ligger som genvejsdimensioner. Sæt Værdiudbredelse til Kodeobligatorisk på dem, du styrer efter, og læg Standarddimensioner på debitor, vare og finanskonto. Det er her, ”valgfri” bliver til ”altid”.

I kontoplanen udfyldes Kontokategori og Underkategori, så finansrapporter bygger på struktur frem for hårdkodede kontointervaller. Undlad datokomprimering af finans- og vareposter: den sletter præcis den granularitet, modellen skal bruge. Brug ordredato på bogførte salgsfakturaer til efterspørgselsmønstre og forfaldsdato plus lukkedato på debitorposter til betalingsmønstre.

Sådan understøtter oneBC365 det

Data ligger i forvejen i Business Central, men spredt over vareposter, værdiposter, debitorposter, salgsfakturalinjer og dimensionsværdier, der hver kræver sin egen fortolkning. oneBC365 samler dem i én semantisk model med ensartede definitioner af kunde, vare, periode og dimension.

Det gør datakvaliteten synlig, før den bliver til en modelfejl: dubletter og manglende varekategorikoder falder ud som synlige huller frem for stille skævheder i et resultat. Dermed bliver arbejdet med datafundamentet for AI noget, du kan følge måned for måned i stedet for at gætte på.

Sådan kommer du i gang med datafundamentet for AI i 4 trin

Vælg det ene nøgletal, du vil forudsige først: churn, DSO eller ordreindgang. Ikke tre.
Træk debitorkartoteket ud, match på CVR-nummer og navn, tæl dubletterne og læg tallet frem på næste ledermøde.
Tjek udfyldningsgraden på de dimensioner, nøgletallet afhænger af, måned for måned to år tilbage. Se efter, om hullerne ligger i de travle måneder.
Udpeg én ejer ved navn, og sæt de nødvendige dimensioner til kodeobligatoriske, så historikken fra i dag er brugbar.

Relaterede artikler

Vil du se, hvordan dine egne debitorer, varelinjer og dimensioner ser ud, når de samles i én model? Book en demo, så gennemgår vi datafundamentet på dine tal — før der bruges en time på en model.