Dette er et dybdedyk i økonomi-afsnittet fra min tidligere artikel om at arbejde i dybden med AI.
De fleste virksomheder på vores størrelse har to typer hjælp på økonomi: en bogholder der står for bogføringen, og en rådgiver eller CFO der hjælper med at forstå det. Jeg har vores eksterne bogholder Thomas, der står for bogføringen og leverer saldobalancen hver måned.
Spørgsmålet jeg stillede mig selv for nylig var enkelt: kan man bygge en økonomi support og CFO-funktion med AI? Som selve funktionen, ikke som supplement til et team. Analysen, fortolkningen, sparringen, rapporterne til ejerkredsen.
Svaret er ja. Og jeg fandt ud af at når jeg havde bygget motoren kunne jeg også bruge det til mange andre ting. Men det kræver et setup der er tænkt igennem, inden man åbner den første prompt. Setuppet er bygget i tre lag: en driftsmodel der definerer hvad systemet må og ikke må, en dataarkitektur der holder kilderne adskilt, og en rutinestruktur der sikrer at arbejdet kan gentages.
Inden man går i gang med at bygge
Da jeg første gang bad Claude Cowork om at analysere min saldobalance, opdagede jeg hurtigt at der var for mange blinde vinkler. Svaret var teknisk korrekt, men ufuldstændigt. Jeg kunne se hvad der stod i saldobalancen, men ikke hvad der lå bag. Havde en konsulent haft ferie den måned? Sygdom der forklarede et lavere faktureringsgrundlag? Det kunne bogføringen ikke svare på. Løsningen var at tilføje data fra vores tidsregistreringssystem som en separat kilde, så systemet også fik adgang til det operationelle lag bogføringen ikke fanger.
Inden jeg byggede det, definerede jeg hvad Claude Cowork skulle hjælpe med: strategisk sparring på Consid Danmarks økonomi. Hvad betyder tallene? Hvad er bekymrende, hvad er forventeligt, og hvad er bare en faktura der landede i den forkerte måned som potentielt kan være med til at skævvride mit månedsresultat.
Og lige så vigtigt: hvad den ikke må. Den skal forstå konteksten og ikke konkludere optimistisk på svage tal. Den må ikke fortolke mekanisk. Den skal altid adskille fire ting fra hinanden: om en bevægelse er strukturel, om den skyldes timing, om den er et regnskabsmæssigt fænomen, eller om det er et reelt operationelt skifte i min drift.
Den skelnen lyder teknisk. I praksis er den det modsatte. Uden den har jeg ingen chance for at forstå hvad der bygger min omsætning og resultat. Med den kan man stille det rigtige spørgsmål.
Begrænsningerne er mindst lige så vigtige for at forstå hvad systemet leverer.
Fire kilder. Fire roller.
Den største forskel oplevede jeg da jeg fik systemet til at forstå forskellen på vores tre konsulenttyper: egne konsulenter ansat i Consid Danmark, gruppekonsulenter fra Consid Sverige, Tyskland eller Norge, og freelancere vi trækker på via vores datterselskab Upgraded. I saldobalancen er de blandet sammen. Men de har fundamentalt forskellige marginprofiler. Uden den skelnen er tallene svære at bruge til noget.
Saldobalancen er sandheden for én måned isoleret. Den siger hvad der skete, men ikke hvorfor. Måned-til-måned-sammenligningen er sammenligningslaget: den viser bevægelser og giver konteksten til at vurdere om noget er et mønster eller en undtagelse. Eksporten fra tidsregistreringssystemet er det operationelle lag som bogføringen ikke kan se. Bench, utilisation, faktureringsgrad, hvem der er på hvilke projekter. Den forklarer ofte det, saldobalancen blot konstaterer. Og så er der fakturaerne, ind- og udgående, som bryder den sorte boks på gruppe- og freelancekonsulenter: hvad koster de præcist, hvad fakturerer vi videre, og hvad er marginen reelt på de enkelte konsulenter.
Claude Cowork ved hvilken kilde den skal åbne afhængigt af spørgsmålet. Det er en designbeslutning. Hvis alt lå i én mappe, ville analysen behandle alle data ens. Den vil den ikke. En timing-effekt i saldobalancen kræver en anden kilde end et spørgsmål om utilisation.
Det er forskellen på at have data og at have en agentstruktur.
Det er forskellen på at have data og at have en agentstruktur.
Når januar og maj kan sammenlignes
Den tredje del af setuppet er det der sikrer konsistens over tid.
De opgaver der gentager sig månedligt er sat op som faste rutiner i Claude Cowork. Månedsrapporten til ejerkredsen, faktura- og utilisationsoverblikket til HQ, prissætningen på konsulenterne. Hver rutine følger den samme logik og det samme format hver gang. Det betyder at rapporten fra januar og rapporten fra maj kan sammenlignes direkte. Ikke fordi jeg husker at gøre det ens, men fordi strukturen sikrer det.
Det samme data, en helt anden kontekst
Den samme dataarkitektur driver også noget der ikke handler om økonomi.
Vores sælgere har brug for at vide hvem der er ledig, hvornår de er ledige, og til hvilken minimumspris. Den information eksisterer allerede i min agentstruktur: belægningsdata fra Consid Group, prissætning beregnet månedligt på baggrund af lønninger og targets. Det krævede et nyt lag oven på det der allerede var der, ikke et nyt dataprojekt.
Resultatet er en intern app bygget i Lovable, synkroniseret via Dropbox, opdateret hver gang belægningsfilen og prisfilen opdateres. Sælgerne logger ind og ser en tidslinje over alle konsulenter: hvem er booket, hvem er på vej til at blive ledig, hvad er den faktiske rate versus minimumsrate versus target. Hvem fakturerer til for lav pris og skal genforhandles? Hvem bør flyttes til andre opgaver?
Sælgerne, salgsledelsen og jeg som direktør arbejder nu fra det samme billede af virkeligheden. Vi taler ikke forbi hinanden i møderummet, fordi vi alle ser det samme.
Det er det der sker, når dataarkitekturen er rigtig. De samme data kan bruges i en samtale der ser helt anderledes ud, til en modtager der aldrig ville åbne en saldobalance.
Rammen er det første arbejde
Så kan man bygge en fuld økonomi-funktion med AI?
Ja — men forudsætningen er at man har gjort arbejdet inden: defineret hvad systemet skal være, struktureret hvad der går ind, bygget det så det kan gentages.
Man sætter ikke tre måneder af til det — man bruger tid på det én gang og forbedrer det løbende. Og når det er på plads, begynder hvert månedsluk på et bedre udgangspunkt end det forrige.