Forretningsanalytikeren i AI‑agenternes æra

AI kan generere et use‑case‑overslag på under et minut, omdanne en simpel idé til en grundlæggende prototype inden for en time og producere kravdokumentation på en brøkdel af den tid, det engang tog. Dette skift er allerede synligt i den daglige forretningsanalyse, hvor praktikere bruger AI til at forberede indhentningssessioner, udarbejde krav og identificere huller før validering. Kig kun på disse leverancer, så virker konklusionen indlysende: forretningsanalytikeren forsvinder.

Jeg deler ikke den konklusion. Jeg har i årevis arbejdet med forretnings‑ og IT‑analyse, løsningsdesign og digital transformation og har fulgt den konstante forandring og forskellige tilpasningsstadier. Det, der forsvinder, er ikke rollen. Det, der forsvinder, er dens periferi. Og det er noget helt andet.

Hvad en analytiker gør

Når du spørger en kunde, hvad de har brug for, fortæller de dig, hvad de ønsker. Det er ikke altid det samme. Ikke fordi de ikke forstår deres eget arbejde – de kan simpelthen ikke altid formulere deres behov tydeligt nok. Rutineopgaver nævnes ofte ikke, fordi kunderne udfører dem automatisk hver dag. Kanttilfælde overses let, fordi folk kun husker dem, når de indtræffer.

Forbindelser mellem afdelinger forstås ud fra et personligt perspektiv, ikke nødvendigvis ud fra helhedens synspunkt. Og når en kunde beslutter at ændre flere systemer på én gang, ser de ofte ikke, at en ændring af ét system næsten altid også ændrer en proces.

Analytikerens opgave er ikke at skrive ned, hvad kunden har sagt. Opgaven er at finde ud af, hvad kunden ikke har sagt, og fortsætte med at stille spørgsmål, indtil alt kommer frem. Analytikeren sporer forbindelser, afhængigheder og konsekvenser på tværs af systemer, data og forretningsprocesser.

Det er en diagnostisk evne, ikke en administrativ aktivitet.

Tre retninger for forretningsanalytikere

Grænserne for forretningsanalyse har aldrig været faste. Analytikere har længe bevæget sig ind i produktansvar, projektledelse og mere tekniske roller. AI accelererer blot denne bevægelse ved at reducere den tid, der kræves til rutineleverancer.

En nylig Gartner‑undersøgelse viste, at mere end halvdelen af organisationerne havde redesignet eller omdefineret roller på grund af AI, mens 78 % af HR‑lederne var enige om, at arbejdsprocesser og roller skulle realisere værdien af deres AI‑investeringer.

Ud fra mine observationer og direkte erfaringer tager tre hovedtrajektorier form.

1. Mod produkt og forretning

Analytikere, der nyder at forme produkter, kan bevæge sig ind i bredere roller, der spænder over produktansvar, forretningsanalyse og leveringskoordinering. Sådanne kombinationer findes allerede, især i mindre teams. Efterhånden som AI reducerer den tid, der bruges på at producere rutineartefakter, vil grænserne mellem disse ansvarsområder sandsynligvis blive mere flydende.

Det bør ikke betyde, at fire job overlægges til én person blot fordi AI kan skrive dokumenterne. Muligheden ligger i at samle ansvarsområder, der allerede afhænger af den samme forståelse af kundebehov, produktprioriteter og forretningsresultater.

Retningen kræver også en stærkere forståelse af data. Analytisk arbejde har ofte fokuseret på processer, funktionalitet og krav, mens datalaget er blevet holdt i baggrunden. AI‑systemer gør denne adskillelse stadig vanskeligere.

En analytiker, der forstår både forretningskonteksten og dataene, kan genkende, når en model besvarer det forkerte spørgsmål korrekt. Det kan ske, fordi de tilgængelige data ikke repræsenterer situationen nøjagtigt, den forretningsmæssige definition bag en måling er ændret, eller det oprindelige spørgsmål var dårligt formuleret.

AI kan hjælpe næsten alle med at skabe et dashboard eller en rapport. At fortolke, hvad resultatet betyder for en specifik virksomhed på et bestemt tidspunkt, kræver stadig kontekst og dømmekraft. Forrester beskriver en lignende forandring på tværs af software‑roller, hvor AI flytter tid væk fra gentagen artefaktproduktion og mod aktiviteter som validering, orkestrering og kontrol.

2. Mod teknisk prototyping

Analytikere med en stærk forkærlighed for udvikling kan muligvis tale med en kunde og derefter bygge en fungerende prototype – ikke blot en mock‑up, men noget kunden kan teste og validere.

Dette ændrer kravvalidering: kunder kan interagere med en idé i stedet for at forsøge at fortolke den ud fra et dokument. Misforståelser kan fremkomme tidligere, mens ændringer stadig er relativt billige at foretage.

Men en prototype er ikke et produktionssystem.

Sikkerhed, integration, skalering og ydeevne under belastning løses ikke af “AI hjælper mig med at kode”. At bygge enterprise‑software til produktion kræver et andet niveau af ingeniørekspertise. Nogle analytikere kan gradvist udvikle disse færdigheder og komme tættere på produktionsniveau‑udvikling. Det er en betydeligt mere krævende vej end hurtig prototyping antyder, men den er realistisk.

3. Mod projekt‑ og leveringsledelse

Analytikere koordinerer allerede kundediskussioner, bidrager til estimater og håndterer spørgsmål omkring omfang, krav og ændringer. Det skaber en naturlig overlapning med projektledelse.

På mindre projekter kan én person muligvis kombinere analytiske og koordinerende ansvarsområder, fordi begge afhænger af forståelse af omfang, interessenter og afhængigheder. Det kan forkorte kommunikationsveje og gøre det lettere at forbinde dag‑til‑dag leveringsbeslutninger med det oprindelige forretningsbehov.

Dette gør ikke projektlederen overflødig. På større projekter, hvor koordinering af personer, risici og afhængigheder er virkelig kompleks, forbliver projektledelse en specialiseret disciplin. Den kombinerede tilgang giver kun mening, hvor omfanget tillader det.

Forskellen er vigtig. AI kan reducere den indsats, der kræves for at udarbejde planer, mødeopsummeringer eller statusrapporter, men produktionen af disse artefakter har aldrig udgjort den fulde værdi af projektledelse.

Hvad der adskiller dem, der navigerer dette godt

Alle tre retninger kræver, at analytikere bevæger sig ud over de velkendte rollegrænser. Nysgerrighed giver dem viljen til at afprøve nye værktøjer og tilgange. Kontinuerlig læring forhindrer, hvad jeg kalder vidensgæld: den gradvise ophobning af forældede antagelser og færdigheder, ligesom teknisk gæld i et legacy‑system.

Måske vigtigst er evnen til at verificere. Analytikere er vant til at spørge “Er dette faktisk korrekt?” før de spørger “Er dette færdigt?” I et miljø fyldt med flydende, professionelt præsenterede AI‑output bliver denne vane endnu mere værdifuld.

AI kan levere forkerte svar i en selvsikker og overbevisende form – et mønster fremhævet af MIT Sloan‑forskere som en af de vigtigste årsager til, at menneskelig kontrol forbliver afgørende. Dens output kan være struktureret, flydende og poleret.

Fejl opstår ikke i selve brugen af AI. Det begynder, når et plausibelt output accepteres uden verifikation.

Spørgsmålet er ikke, om BAs vil forsvinde

Mange artikler om analytikerrollens fremtid er skrevet som forudsigelser. Dette er ikke en forudsigelse. Det er en observation: rollen ændrer sig, som den altid har gjort. Det, der er anderledes denne gang, er hastigheden – og det faktum, at dens periferi bliver tilgængelig for næsten alle.

En udvikler kan bruge AI til at udføre kravanalyse. En leder kan bruge den til at generere brugerhistorier. De gør måske ikke hverken den ene eller den anden særlig godt, men en analytiker, hvis værdi udelukkende hviler på at producere leverancer, vil have svært.

Hvad der forbliver i centrum af rollen, er evnen til at afdække usagte behov, forbinde forretnings‑ og teknisk kontekst, verificere output og se forbindelser, som kunden ikke kan. Ifølge IIBAs 2025 Global State of Business Analysis‑rapport siger 74 % af praktikere, at AI påvirker deres karriere positivt, mens menneskelige færdigheder som kommunikation, strategisk tænkning og tilpasningsevne bliver vigtigere.

Spørgsmålet er ikke, om forretningsanalyse vil forsvinde. Det er, hvad der forbliver, når dens periferi bliver tilgængelig for alle.

Svaret er den dømmekraft, der kræver år med praksis, varierede projekter og erfaring med fejl for at udvikle. Det er evnen til at genkende, at et dokumenteret krav er ufuldstændigt, at en fungerende prototype løser det forkerte problem, eller at et poleret svar hviler på en falsk antagelse.

Det er den del af forretningsanalyse, der ikke kan erhverves hurtigt.