Byg en MVP der kan vise værdi i rigtig brug
En AI-MVP skal være den mindste sammenhængende løsning, som udvalgte brugere kan anvende forsvarligt i en rigtig arbejdsgang. Den skal vise forventet værdi og afdække krav til videre udvikling. Begrænset omfang kan reducere investeringen; nødvendige kontroller følger stadig anvendelsens konsekvenser.
En prototype viser, at en idé kan fungere under udvalgte forhold. En MVP skal også fungere for andre end udvikleren og indgå i det arbejde, hvor gevinsten forventes. EnableAIs andet stadie lægger derfor vægt på faktisk anvendelse og målbar forventet værdi. [1]
Beslut først, hvilken arbejdsgang der skal være komplet. En intern assistent kan være en MVP uden integration til alle systemer, hvis medarbejderen kan bruge svaret til at afslutte den valgte opgave. Hvis løsningen kræver, at projektteamet reparerer hver sag manuelt i baggrunden, er dens reelle omkostning og modenhed endnu ikke synlig.
Afgræns brugen frem for at svække kvaliteten
Vælg én proces, et begrænset antal brugere og klare typer af sager. Beskriv også, hvad løsningen ikke skal håndtere endnu. Det kan være bestemte sprog, kundetyper, undtagelser eller handlinger. Afgrænsningen skal kunne forstås af brugerne og håndhæves i arbejdsgangen.
MoSCoW skelner mellem nødvendigt, vigtigt, muligt og det, der udskydes i denne levering. [2] Brug metoden til at beskytte MVP’ens kerne. Hvis en kildehenvisning er nødvendig for, at medarbejderen kan kontrollere et svar, er den ikke blot en kosmetisk funktion. En flot startside kan til gengæld ofte vente.
Undgå at kalde alle ønsker nødvendige. Spørg for hvert krav, om den valgte anvendelse kan gennemføres forsvarligt og måles uden det. Hvis svaret er ja, kan kravet ofte udskydes. Vælg hvilke AI initiativer der skal komme først (Q04) og Prioritering af AI initiativer (AI-04-001) beskriver metoderne til afgrænsning og rækkefølge.
Gør den fulde anvendelse synlig
| Område | MVP’en skal kunne vise | Typisk tegn på et hul |
|---|---|---|
| Brugerforløb | En opgave fra start til brugbart resultat | Brugeren er afhængig af projektets ekspert |
| Kvalitet | Korrekthed og håndtering af manglende grundlag | Fejl opdages kun tilfældigt |
| Adgang | Tilladte data og handlinger for hver rolle | Alle bruger en fælles konto |
| Drift | Hjælp, fejlmelding og manuel overtagelse | Ingen ved hvem der reagerer |
| Værdi | Baseline og måling af faktisk effekt | Antal logins bruges som eneste succesmål |
Microsofts AI-arkitektur beskriver samspillet mellem applikation, data, modeller og understøttende systemer. [3] Vores anbefaling er at teste dette samspil i det omfang, den afgrænsede MVP kræver. I behøver ikke en stor platform, men I skal kunne se, hvor løsningen afhænger af andre systemer og mennesker.
Aftal forventet værdi og ansvar før opstart
Værdiejeren beskriver, hvilken forbedring der skal være synlig, og hvordan den skal anvendes. Procesejeren sikrer tid til brugerne og ændrer de nødvendige arbejdsgange. En teknisk ansvarlig håndterer løsningen og dens fejl. Roller kan samles i en SMV, men ansvaret må ikke forsvinde mellem dem. Fordel ansvar og beslutninger for AI (Q19) uddyber fordelingen.
Mål den eksisterende praksis, før MVP’en indføres, og brug en sammenligning, der passer til opgaven. Hvis sæson, kundemix eller bemanding ændres, skal det fremgå af vurderingen. Følg tid inklusive kontrol, kvalitet og gennemførte opgaver. Mål om AI skaber reel værdi (Q09) forklarer forskellen mellem brug, operationel effekt og forretningsværdi.
Planlæg oplæring på rigtige, godkendte eksempler. Medarbejderne skal vide, hvornår de skal kontrollere, afvise eller overtage. Registrér ekstra støtte fra projektteamet som en del af indsatsen. Ellers kan en tilsyneladende effektiv MVP skjule en dyr servicefunktion.
Et eksempel med en kundeserviceassistent
Virksomheden i dette eksempel afprøver en assistent til returspørgsmål for ét produktområde. Den finder godkendte regler og skriver et svarudkast. En medarbejder kontrollerer, at vilkårene passer til den konkrete ordre. MVP’en kan ikke selv tilbagebetale penge.
Teamet måler svartid, rettelser, kildekorrekthed og antallet af sager, der kræver en specialist. Det registrerer også, om medarbejderne bruger løsningen efter den første introduktion. En god gennemsnitlig tidsbesparelse er utilstrækkelig, hvis bestemte undtagelser giver alvorlige fejl.
Ved problemer kan teamet begrænse brugen til standardsager, forbedre kilderne eller forlænge målingen. Det må samtidig kontrollere, om den smallere løsning stadig har tilstrækkelig værdi. Den må ikke erklæres vellykket alene ved at fjerne alle vanskelige sager fra opgørelsen.
Beslut hvad der skal være bevist før skalering
En MVP skal ikke levere sikker viden om hele fremtiden. Den skal give et stærkere grundlag end eksperimentet. Beskriv den målte effekt, fejlprofilen, brugernes adfærd og den resterende indsats. Vurder, om resultatet kan holde med andre brugergrupper og større variation.
Direkte værdi kan være kortere behandlingstid. Indirekte værdi kan være bedre kilder eller genbrugelige integrationer. Estimatet for næste trin skal rumme både kendt arbejde og usikkerhed om eksempelvis rettigheder, datavækst og support. Beslut hvornår en AI løsning skal skaleres (Q26) behandler selve skaleringsbeslutningen.
Agile Definition of Done kan give inspiration til klare kvalitetskrav. Gør kvalitet og sikkerhed til en del af leverancen (A08) viser, hvordan disse krav skal udvides til AI-adfærd, databrug og menneskelig kontrol. Fastlæg menneskelig kontrol med AI agenter (Q25) behandler grænserne for autonomi.
Næste ledelsesbeslutning: Godkend én komplet, afgrænset arbejdsgang, en værdiejer og få målbare kriterier for fortsættelse. Sørg for, at både brugere og drift kan deltage, før MVP’en sættes i reel anvendelse.
Kundeeksempel med mål og opfølgning
Serviceeksemplets MVP måles fra kundehenvendelse til et brugbart, kontrolleret svar. Målet er 12 til 9 minutter pr. sag ved 4.000 sager om måneden. Brug en samtidig sammenligning, når det er praktisk muligt.
Falder testgruppen til 10 minutter og kontrolgruppen til 11,5, understøtter eksemplet 1,5 minuts tilskrevet forbedring eller 100 timer ved det angivne omfang. Afprøv derefter, hvor meget der faktisk kan omsættes til mindre købt assistance, før løsningen skaleres.
Brug den samlede VP/SE-model, VP-vejledningen og SE-vejledningen. Begge estimater revurderes før Hypotese, MVP og Skalering. VP/SE er et lokalt præferenceindeks, ikke økonomisk ROI eller WSJF. Lær anvendelsen på halvdag 1 om VP og halvdag 2 om SE og prioritering, hver fire timer inklusive pause.
Kilder og videre læsning
Eksempler og handlingsforslag er EnableAIs faglige vurdering. Virksomhedseksempler og regnetal er illustrative. Artiklen er opdateret med konkrete regneeksempler og henvisninger den 15. september 2026.
[1] EnableAI · Tre trin fra AI hypotese til skaleret værdi