AWS påstår, at deres finance‑teams har taget “hundreder af timer” tilbage ved at lade Amazon Quick rydde op i dataarbejdet og køre analyser direkte på Redshift. Casen er interessant, fordi den rammer to velkendte FP&A‑flaskehalse: scenariemodellering på strategiske kunder og de ugentlige revenue‑reviews. Begge beskrives med konkrete tidsmål og en før‑/efter‑proces, der virker genkendelig i praksis.
Det vigtigste først: AWS skriver, at en enkelt kundeanalyse før tog op til 6 timer. Efter Quick kører regression, Monte Carlo og scenarieopsætning, lander den samme analyse omkring 10 minutter. Det flytter kapaciteten fra dybde på cirka en tredjedel af kunderne til dækning af hele porteføljen. Den anden case handler om de ugentlige gennemgange — væk fra mandagsmaraton til agenter og Flows, der forbereder materiale automatisk. Nøgternt, men brugbart.
Hvad Amazon Quick er i praksis
Amazon Quick beskrives som en generativ AI‑assistent til virksomhedsdata og apps. Pointen er, at brugere stiller spørgsmål i almindeligt sprog og får beregninger, søgninger og handlinger udført uden at skrive SQL eller kode. Ifølge AWS kan agenten håndtere forespørgsler på millioner af rækker, køre avancerede analyser og gentage workflows på fast kadence. Det kræver dog et datagrundlag, som ikke alle økonomifunktioner har helt på plads endnu.
Case 1 Scenariemodellering og risiko
Før: Analytikerne nåede typisk kun i dybden med cirka en tredjedel af de strategiske kunder mellem bottoms‑up inputs og deadlines for targets. Hver kundeanalyse tog op til 6 timer fra udtræk og afstemning til modelkørsler og dokumentation. Klassiske datasiloer og manuelle hop mellem Excel og BI trak tiden ud.
Efter: En Quick‑agent kobles på datakilderne og svarer i samtaleform. Den kører statistiske forecasts, regression, Monte Carlo og opsætter scenarier på tværs af flere faktorer. Ifølge AWS tager det cirka 10 minutter pr. kunde. Agenten fremhæver bull/bear‑områder som fornyelsestidspunkt, pipeline‑styrke og risikosignaler. Dækningen glider fra 33 procent til 100 procent af porteføljen — med større dybde, hvis tallene holder.
Case 2 De ugentlige business reviews
Før: Mandage forsvandt i at hente, afstemme og forklare ugens revenue‑tal. Slides, noter, kommentarbokse — ofte med mindst fire systemer bag tallene, hvor ét af dem altid er nede på det forkerte tidspunkt.
Efter: AWS beskriver, at Quick‑agenter blev sat op pr. region og bundet sammen med Flows, så de kører på fast kadence uden manuel indgriben. Overblikket genereres, KPI’er afstemmes, og ledelsesmaterialet bliver til i samme omgang. Blogindlægget kalder casen “Weekly business reviews from 6 hours to 10 minutes”. Detaljerne er sparsomme, men retningen er tydelig: færre klik, mere kontekst, mindre mandagsstøj.
Teknikken bag integrationen
Det her er ikke en chat på toppen af et regneark. For at Quick kan stille smarte spørgsmål til millioner af rækker, skal fundamentet være i orden: Redshift eller et andet datawarehouse med konsistente skemaer, stabile ETL/CDC‑strømme, korrekt opsatte credentials og en datakatalog med ejerforhold og lineage. Ellers ender man i fejl, tidsudløb — og til sidst i manuelle ekstrakter igen.
Autorisation er næste lag: granulære rettigheder pr. tabel, kolonne og i nogle tilfælde pr. række — og en agent, der respekterer det i alle flows. Dertil kommer logning af prompts, svar og underliggende queries, så revision kan se, hvem der så hvad, hvornår og hvorfor. AWS giver ikke hele opskriften her, men i en enterprise‑stack er det ufravigelige byggesten.
Ydelse og skala i praksis
AWS skriver, at agenten “instant” kan spørge på millioner af rækker. Hastighed afhænger i praksis af query‑kompleksitet, datastørrelse, samtidighed og hvor meget, der pushes ned i Redshift. Uden præaggregeringer, materialiserede views eller solide indeksmønstre vil responstider svinge — og sving er det sidste, en finansafdeling ønsker fem minutter før et ledelsesmøde.
Der mangler også benchmarks for samtidighed. Hvad sker der, når 40 analytikere stiller scenarie‑spørgsmål kl. 09.05? Caches delresultater? Kører batch‑lignende flows uden om chatten? Blogindlægget siger ikke meget her, så antag, at optimering kræver arkitekturarbejde og monitorering — ikke blot en feature‑toggle.
Resultater og tidsgevinster
Værdien ligger ikke kun i minutter sparet, men i skiftet fra datagraveri til beslutningsstøtte. Hurtigere scenariemodeller køres oftere, og flere antagelser bliver testet — det løfter kvaliteten i dialogen med forretningen. Omvendt: Hvis datagrundlaget er svagt, går man bare hurtigere galt i byen. Hastighed forstørrer også fejl.
Governance, sikkerhed og omkostninger
Enterprise‑agenter kan hurtigt blive en omkostningsmaskine, hvis de ikke styres. VentureBeat peger netop på, at når brugen skalerer, skalerer AI‑udgifterne, og styringen flytter op i ledelseslaget. Der følger også sikkerhedsblindspots i mere autonome flows og organisatorisk friktion, når ny praksis møder eksisterende politikker. Mange oplever: pilot går fint, produktion er sværere.
Derudover: Hvem står på mål for en scenariekonklusion? Kan man forklare, hvilke tabeller og hvilken version af en forecastmodel, der lå bag? Uden auditspor, versionsstyring af prompts og PII‑kontroller ender svaret ofte som nej — og det er dyrt i finans.
Praktiske skridt for FP&A og data
Start ikke med mission control. Vælg 1–2 højværdi‑workflows, hvor datastrømmen kan ejes end‑to‑end, fx scenariemodellering for topkonti. Kortlæg felter, skemaer, ejerskab og refresh‑frekvens. Byg automatiserede tests, så fejl i kildedata fanges, før agenten laver slides ud af dem. Ellers forsvinder gevinsten i brandøvelser.
Teknisk kræver det en hård kerne: stabil CDC/ETL til Redshift, en datakatalog med lineage, secrets‑hygiejne, as‑code‑konfiguration af agent‑flows og central logning. Læg guardrails på query‑omkostninger og opsæt alarmer for spikes. Ellers ædes besparelsen af compute.
Hvad historien ikke siger
Blogindlægget mangler uafhængig verifikation af “hundreder af timer” og en metodik for tidsmåling. Der er ingen tal for månedlige AI‑omkostninger i drift for de to flows. Ingen arkitekturdiagrammer, ingen forklaring på caching eller pushdown, ingen benchmarks for samtidighed. Det er også uklart, hvor ofte eksterne signaler (hvis brugt) opdateres.
Og så er der generaliserbarheden. AWS Finance har en moden dataplatform. Hvor meget af gevinsten afhænger af netop den modenhed? Bloggen svarer ikke. Læs det som en virksomheds case — ikke som branchekonklusion.
Hvorfor det betyder noget for danske økonomifunktioner
Kort sagt: den samme tid spildes ofte her. Hvis 30–50 procent af et FP&A‑teams mandag går med at samle, rydde og forklare data, er potentialet reelt. Realismen: gevinsten kræver, at datahuset står. Ikke perfekt, men solidt nok til, at en agent kan spørge, uden at alt vælter. “Sæt en agent på toppen af et regneark” er en fristende overskrift — men en svag plan.
Casen lover ikke ny indsigt fra nye modeller, men hurtigere adgang til kendt indsigt, som før var dyr at hente frem. Det er jordnært — og derfor anvendeligt, når man sidder med det i hænderne.
