Når alle kan bygge med AI, hvem tager så ansvaret?

AI har gjort det markant hurtigere og billigere at omsætte en idé til fungerende kode. Derfor kan medarbejderne i økonomifunktionen nu selv bygge værktøjer, som tidligere krævede både udviklere, budget og ventetid. Det skaber nye muligheder, men også en ny ledelsesopgave for CFO’en: Hvornår er noget et personligt hjælpemiddel, og hvornår er det blevet en løsning, som virksomheden skal tage ansvar for?

I mange år var prisen på udvikling med til at træffe beslutningen. Hvis økonomifunktionen havde brug for en ny afstemning, en særlig rapport eller en mindre automatisering, krævede det ofte en specialist, et budget og en plads i IT-afdelingens kø. Mange idéer blev derfor sorteret fra, længe før nogen behøvede at tage stilling til, om de var gode.

Den mekanisme er ved at forsvinde.

Med generativ AI kan en controller eller analytiker få hjælp til at skrive et mindre program, forbinde datasæt eller afprøve en beregningsmodel på få timer. Det betyder ikke, at udvikling er blevet gratis, eller at alle nu er softwareudviklere. Men selve arbejdet med at skrive den første version af koden fylder langt mindre i den samlede opgave end tidligere.

Dermed flytter den knappe ressource sig. Det afgørende er ikke længere kun, om I har råd til at bygge, men om I ved, hvad der bør bygges, hvordan løsningen må bruges, og hvornår nogen skal tage ansvar for den.

Det er en ledelsesopgave, som lander hos CFO’en, uanset om økonomifunktionens egne løsninger står på den officielle digitaliseringsplan eller ej.

Forestil dig en controller, der hver måned bruger flere dage på at sammenholde to datasæt, fordi virksomhedens systemer ikke kan matche oplysningerne automatisk. Med hjælp fra AI kan hun måske skrive et mindre program, der løser en stor del af opgaven på en eftermiddag.

Eller tænk på analytikeren, der vil undersøge, om en ny model med forretningsdrivere kan forbedre virksomhedens prognoser. Tidligere kunne det kræve en business case og et egentligt udviklingsforløb, før idéen kunne afprøves. Nu kan en foreløbig model være klar samme dag.

Det er i udgangspunktet positivt. Medarbejderne kommer tættere på løsningen, eksperimenter bliver billigere, og økonomifunktionen kan afprøve flere idéer, før den beslutter, hvad der er værd at investere i.

Udfordringen opstår, når et personligt hjælpemiddel gradvist bliver en del af virksomhedens drift. Det sker sjældent gennem en formel beslutning. Det sker, fordi værktøjet virker.

En kollega beder om adgang. Værktøjet bliver kørt igen måneden efter. Resultatet finder vej til ledelsesrapporteringen, og efter et halvt år er organisationen afhængig af en løsning, som kun ophavspersonen forstår. Ingen har nødvendigvis handlet uforsvarligt, men løsningens betydning har ændret sig, uden at styringen er fulgt med.

En beregning, der skal bruges én gang som støtte for en analyse, har et forholdsvis enkelt formål. Den skal behandle de rigtige data og give et resultat, som medarbejderen kan kontrollere, før det anvendes.

En løsning, der hver måned leverer tal til ledelsesrapporteringen eller koncernregnskabet, skal kunne langt mere. Den skal kunne vedligeholdes, dens beregninger skal kunne forklares, og fejl skal opdages, før de påvirker beslutninger eller rapportering. Derudover skal nogen kunne overtage ansvaret, hvis den medarbejder, der byggede løsningen, får en ny rolle eller forlader virksomheden.

Det er ikke blot to forskellige kvalitetsniveauer. Det er to forskellige produkter med forskellige krav.

AI har især reduceret omkostningen ved det første: at skabe en foreløbig løsning, afprøve en idé eller automatisere en afgrænset opgave. Omkostningen ved at drive en stabil, sikker og dokumenteret løsning er ikke faldet tilsvarende, for den består kun delvist af arbejdet med at skrive kode. Resten handler blandt andet om test, datakvalitet, adgangsstyring, overvågning, dokumentation, vedligeholdelse og forankring.

Derfor bør CFO’en ikke spørge, om AI-genereret kode er god eller dårlig. Det relevante spørgsmål er, hvilken rolle løsningen skal spille i virksomheden.

En praktisk vurdering kan begynde med ét spørgsmål:

Hvem kan blive ramt, hvis løsningen tager fejl eller holder op med at virke?

Hvis konsekvensen er begrænset til den medarbejder, der har bygget værktøjet, og medarbejderen selv kan kontrollere resultatet, bør der være god plads til at eksperimentere. Det kan eksempelvis være en foreløbig analyse, en enkeltstående afstemning eller en prototype, der skal vise, om en idé er værd at arbejde videre med.

Hvis kolleger, ledelse, kunder, myndigheder eller den finansielle rapportering kan blive påvirket, er situationen en anden. Så er løsningen ikke længere kun et personligt hjælpemiddel, og virksomheden må tage stilling til ejerskab, kontrol og drift.

Antallet af brugere er et nyttigt faresignal, fordi bruger nummer to ofte markerer begyndelsen på en bredere anvendelse. Men det kan ikke stå alene. En løsning med én bruger kan være forretningskritisk, hvis den eksempelvis leverer tal til årsregnskabet, mens et simpelt værktøj godt kan deles af flere uden at blive kritisk.

Vurderingen bør derfor bygge på både konsekvensen af en fejl, løsningens anvendelse og den afhængighed, der opstår omkring den.

Når en løsning først virker, er det fristende at blive ved med at udvide den. Medarbejderen beder AI’en om endnu en funktion, derefter om en fejlrettelse og senere om en tilpasning til en ny datakilde.

Det kan fungere længe. Men hvis ingen længere forstår løsningens samlede opbygning, bliver hver ændring vanskeligere at vurdere, og virksomheden opbygger en afhængighed, som først bliver synlig, når noget går galt.

Det er teknisk gæld i en ny og mere tilgængelig form. Gælden opstår ikke, fordi AI har skrevet koden, men fordi en midlertidig løsning har fået lov til at blive permanent uden et bevidst valg.

Omvendt behøver kortlivede løsninger ikke at blive behandlet, som om de skal drives i fem år. Et mindre program, der løser en enkeltstående opgave og derefter slettes, kræver ikke samme dokumentation og forankring som en automatisering, der indgår i den månedlige rapportering.

Problemet er derfor ikke, at medarbejderne bygger hurtigt. Problemet opstår, når ingen beslutter, om det byggede skal kasseres, videreudvikles eller overtages som en fælles løsning.

Et generelt forbud mod selvbyggede løsninger er næppe svaret. Det vil først og fremmest flytte aktiviteterne ud af ledelsens synsfelt, samtidig med at virksomheden går glip af den innovation, der opstår, når fagligt stærke medarbejdere hurtigt kan afprøve deres idéer.

CFO’en bør i stedet sikre to ting.

For det første skal medarbejderne have et godkendt sted at eksperimentere. Her skal de kunne afprøve idéer uden at få uhindret adgang til produktionssystemer, følsomme oplysninger eller muligheden for at sende data til ikke-godkendte tjenester. Miljøet behøver ikke at være stort eller kompliceret, men det skal være tilgængeligt, og medarbejderne skal vide, hvordan de må bruge det.

For det andet skal virksomheden have en tydelig tærskel for, hvornår et personligt værktøj skal vurderes som en fælles løsning. Det kan eksempelvis være, når værktøjet:

• indgår i en tilbagevendende proces

• leverer grundlag for andres beslutninger

• behandler væsentlige eller fortrolige data

• får flere brugere eller bliver delt på tværs af teams

• kræver løbende vedligeholdelse

• bliver kritisk for rapportering, kontrol eller compliance.

Tærsklen skal ikke nødvendigvis udløse et langt godkendelsesforløb. Den skal udløse en samtale om, hvem der ejer løsningen, hvilke kontroller der er nødvendige, og om den fortsat hører hjemme som et lokalt værktøj.

AI ændrer ikke kun, hvordan kode bliver skrevet. Den ændrer også, hvem der kan omsætte en faglig idé til en fungerende løsning.

Det er en betydelig mulighed for økonomifunktionen, fordi de bedste idéer ofte findes hos de medarbejdere, der forstår data, processer og forretningsbehov i detaljer. Når de hurtigere kan afprøve deres idéer, kan finans løse flere problemer uden at vente på et stort systemprojekt.

Men teknologien fjerner ikke behovet for faglig og ledelsesmæssig dømmekraft. Tværtimod bliver den vigtigere, når flere kan bygge, og når afstanden fra idé til løsning bliver kortere.

CFO’ens opgave er derfor ikke at standse udviklingen eller at gøre alle controllere til programmører. Opgaven er at skabe rammer, hvor økonomifunktionen kan eksperimentere hurtigt, samtidig med at virksomheden opdager det øjeblik, hvor et nyttigt værktøj bliver til en løsning, som nogen skal eje.

Kode er blevet billigt. Ansvar og viden er ikke.