Anomaly detection: 3 afvigelsestyper rapporten selv finder

En ledelsesrapport på fjorten sider rummer omkring 200 tal, hvoraf fem betyder noget. Hele arbejdet består i at finde dem. Anomaly detection vender pilen om: systemet sammenligner hvert nøgletal med en sæsonkorrigeret forventning og siger til, når forskellen er større, end tilfældig variation kan forklare. Her er de tre afvigelsestyper, statistikken bag og alert-økonomien regnet igennem.

Resumé og konklusion

Pilen vendes om: rapporten forudsætter, at nogen leder i den. Her finder systemet afvigelsen og sender den til en navngiven ejer.
Tre afvigelsestyper: punktafvigelse, niveauskift og trendbrud kræver hver sin regel. De fleste opsætninger fanger kun den første.
Statistikken er enkel: en sæsonkorrigeret baseline, en standardafvigelse beregnet på afvigelsen og en tærskel, ledelsen selv vælger.
Regneeksempel: med 750 kr. pr. alert og 12.000 kr. i gennemsnitligt fund tåler økonomien 15 falske alarmer pr. reelt fund. Opmærksomheden gør ikke.
Start småt: 4-6 alerts, én ejer og én aftalt handling pr. alert. Alerts, ingen handler på, slukkes igen.

Vend rapporteringslogikken om

De 195 af rapportens tal er som de plejer. Værdien ligger i de fem, der har flyttet sig, og hele arbejdet består i at finde dem. Det er en dårlig arbejdsdeling: mennesket leder, og maskinen venter på at blive spurgt.

Anomaly detection bytter om på rollerne. Ingen åbner en rapport for at opdage problemet — rapporten bruges bagefter, til at forstå det.

Det er springet fra trin 2 til trin 3 på AI-modenhedstrappen, og det kræver ikke nye systemer, men definerede nøgletal, en baseline og en ejer pr. alert. Især erkendelseslatensen forsvinder — tiden fra tallet findes, til nogen ser det.

Tre former for afvigelse

Punktafvigelse. Ét tal springer i én periode og falder tilbage igen. En uges ordreindgang halveres. En kundes betalingstid går fra 32 til 74 dage. Punktafvigelser er lette at fange og oftest de mindst alvorlige — tit en fejlpostering, en enkeltordre eller en helligdag.

Niveauskift. Tallet lægger sig på et nyt, permanent leje. Dækningsgraden på en varegruppe går fra 34 % til 31 % og bliver dér. Ingen enkelt uge ser dramatisk ud, så en periodetærskel fanger det ikke. Niveauskift kræver en anden regel: flere perioder i træk på samme side af baseline. Syv perioder i træk over eller under forventningen sker ved ren tilfældighed under to gange ud af hundrede.

Niveauskiftet er den dyreste afvigelsestype, fordi det bliver ved, indtil nogen opdager det.

Trendbrud. Retningen skifter. Ordreindgangen har vokset stabilt i femten måneder og flader ud. Niveauet er stadig højt, så ingen alarm ringer, men hældningen er vendt. Det ses kun ved at sammenligne de seneste seks perioder med de foregående tolv. Trendbrud er det tidligste signal — og det, der først ses i regnskabet et halvt år senere.

Læg mærke til, at hverken niveauskiftet eller trendbruddet bryder en enkelt periodes tærskel — de fanges kun af regler, der ser på flere perioder ad gangen.

Hvilke nøgletal egner sig til anomaly detection

Et nøgletal egner sig til overvågning, hvis det opdateres mindst ugentligt, har mindst to års historik, har en ejer og har en handling knyttet til sig. Mangler ét af de fire, er det en nyhed frem for en alert. I en typisk SMV holder syv tal:

DSO pr. kundegruppe. Ikke samlet — samlet DSO skjuler den ene kunde, der er skredet.
Dækningsgrad pr. varegruppe og pr. kunde. Den mest lønsomme af alle overvågninger.
Ordreindgang pr. uge, målt på ordredato og sæsonkorrigeret.
Lagerbinding og liggetid pr. varekategori.
Leveringsgrad: bekræftet leveringsdato mod faktisk.
Kreditnotaandel af omsætning pr. kunde og varegruppe.
Timeforbrug mod budget pr. sag, for projekt- og servicevirksomheder.

Listen overlapper med de tidlige advarselssignaler, der advarer før regnskabet — forskellen er, at tallene her ikke aflæses manuelt, men overvåges maskinelt.

Statistikken bag anomaly detection, jordnært

Baseline er ikke et gennemsnit, men en forventning: hvad plejer tallet at være i netop denne uge, hos netop denne kundegruppe? Typisk et glidende gennemsnit over 12-13 perioder ganget med et sæsonindeks.

Sæsonkorrektion er nødvendig i næsten alle danske SMV’er. Juli, uge 7 og december er ikke afvigelser, men mønstre, og et sæsonindeks på tre års historik fjerner det meste af den støj. Standardafvigelsen beregnes på forskellen mellem faktisk og forventet, ikke på tallet selv — ellers straffes sæsonen igen.

Tærsklen er en ledelsesbeslutning, ikke en teknisk. Overvåges 10 nøgletal ugentligt, er det 520 kontroller om året. Ved to standardafvigelser flages omkring 5 % ved ren tilfældighed — 26 falske alarmer om året. Ved tre er det under to om året, men til gengæld overses de langsomme skred.

Derfor bør punktafvigelser have høj tærskel, mens niveauskift fanges af reglen om flere perioder i træk. Den kombination gør anomaly detection brugbar frem for larmende.

Regneeksempel: hvad må en alert koste

En alert koster tid: nogen undersøger, nogen beslutter. Sæt det til halvanden time à 500 kr., altså 750 kr. pr. alert.

Hvad er et reelt fund værd? En varegruppe med 6 mio. kr. i årsomsætning taber to procentpoint i dækningsgrad: 120.000 kr. om året, 10.000 kr. om måneden. Opdages det tre måneder tidligere, er fundet 30.000 kr. værd. Andre fund er mindre. Sæt gennemsnittet forsigtigt til 12.000 kr.

Med seks alerts, der hver udløses halvanden gang om måneden, er det 108 alerts om året til 81.000 kr. i behandlingstid. Rammer hver tredje, er det 36 reelle fund til 432.000 kr. Nettoen er 351.000 kr.

Break-even ligger, hvor 750 kr. møder 12.000 kr.: en træfsikkerhed på 6 %, altså ét reelt fund pr. 16 alerts. Økonomisk kan man tåle 15 falske alarmer pr. fund. Det kan opmærksomheden bare ikke. Ligger træfsikkerheden under cirka én ud af tre, holder folk op med at åbne mailen efter to måneder — og så er også de rigtige alarmer værdiløse. Derfor designes en alert-opsætning efter præcision, ikke efter at fange alt.

Alert-træthed er den reelle risiko

Den typiske fejl er at slå tyve alerts til den første uge. Efter en måned er de fleste filtreret til en undermappe. Fire regler holder opsætningen i live:

Start med 4-6 alerts og tilføj kun en ny, når en gammel er slukket. Hver alert har én ejer — et navn, ikke en afdeling eller en fællespostkasse. Hver alert har en aftalt handling, skrevet ned før den tændes; kan man ikke formulere handlingen, er tallet ikke en alert. Alerts, der ikke handles på, fjernes.

Gennemgå loggen kvartalsvis: hvor ofte udløste hver alert, og hvor ofte førte det til en handling? Er svaret nul, er alerten enten forkert sat op eller uden betydning — begge dele løses ved at slukke den.

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

Tallene ligger i faste tabeller. DSO beregnes på debitorposterne som faktisk betalingsdato mod forfaldsdato, dækningsgrad på værdiposterne med salgs- og kostbeløb pr. varelinje, og ordreindgang på salgsordrerne efter ordredato, ikke bogføringsdato. Lagerbinding og liggetid kommer fra vareposter og lagerværdiansættelsen, leveringsgrad fra bekræftet leveringsdato mod den bogførte følgeseddel, kreditnotaandel fra bogførte salgskreditnotaer og timeforbrug mod budget fra sagsposterne. Opdelingen sker på dimensioner og kategorier, så alerten peger på en gruppe frem for totalen.

Business Central har selv regelbaserede notifikationer under Mine notifikationer, blandt andet overskredet kreditmaksimum og forfalden saldo — nyttige, men faste tærskler, ikke statistik. Selve overvågningen bygges i Power BI, hvor Find anomalier på et linjediagram med tidsakse giver et forventningsbånd og forslag til forklaring. Datadrevne advarsler på kort-, måler- og KPI-felter sender mail eller push, og et Power Automate-flow kan lægge opgaven i Teams eller oprette en opfølgning i Business Central. Det er rutingen, der gør alerten til en handling.

Sådan understøtter oneBC365 det

Alle syv nøgletal kan beregnes på data, der allerede står i Business Central — men i syv tabeller med hver sin logik. oneBC365 samler dem i én semantisk model med ensartede definitioner, sæsonkorrigeret baseline og opdeling på dimensioner.

Så handler mødet om afvigelsen, ikke om hvis tal der er rigtigt. Kunden ejer selv koden.

Sådan kommer du i gang med anomaly detection i 4 trin

Vælg fire nøgletal, I allerede diskuterer på ledelsesmødet. Overvåg intet nyt i første omgang.
Beregn baseline og sæsonindeks bagud på to år, og se, hvor ofte en alert ville være udløst. Det er jeres støjniveau.
Skriv ejer og handling ned for hver alert, før den tændes. Én sætning pr. alert.
Kør i tre måneder, og gennemgå loggen. Slet dem, ingen handlede på, og tilføj én ny.

Relaterede artikler

Vil du se de syv nøgletal med en sæsonkorrigeret baseline på jeres egne tal fra Business Central? Book en demo, så gennemgår vi de fire alerts, der giver mest mening hos jer.