Hvorfor sondringen er afgørende
Du står over for beslutningen om, hvorvidt AI virkelig fungerer i din virksomhed. Teknologien er til stede, løfterne store – men hvordan finder du ud af, om investeringen kan betale sig?
Her skilles fårene fra bukkene. Mens mange virksomheder starter med tekniske Proof of Concepts (PoC), overser de ofte det afgørende punkt: Fungerer ≠ kan betale sig.
Et Proof of Concept viser, at noget er teknisk muligt. Et Proof of Value beviser, hvorfor det er forretningsmæssigt fornuftigt. Denne opdeling afgør, om dit AI-projekt ender i succes eller skuffelse.
Thomas fra vores maskinbygningseksempel kender til udfordringen: “Vi har testet tre forskellige chatbots. De virker alle på hver deres måde – men hvilken sparer os reelt tid, når vi skal lave kravspecifikationer?”
Svaret ligger i metoden. Hvor PoCs afprøver tekniske grænser, måler PoVs de forretningsmæssige resultater. Begge tilgange har deres berettigelse – men kun på det rette tidspunkt.
Hvorfor er det særligt vigtigt netop nu? Virksomheder fejler sjældent med AI-tiltag på grund af teknologien – men på grund af manglende forretningsvalidering. Løsningen ligger i en systematisk tilgang.
Proof of Concept – Teknisk gennemførlighed i fokus
Hvad er et Proof of Concept?
Et Proof of Concept er en eksperimentel tilgang, der demonstrerer, om en idé grundlæggende kan lade sig gøre. I AI-sammenhæng betyder det: Kan et Large Language Model som GPT-4, Claude eller Gemini i princippet løse den ønskede opgave?
Kernespørgsmålet er: “Kan det overhovedet lade sig gøre?”
Lad os tage et konkret eksempel fra Annas HR-afdeling. Et PoC for automatiserede jobopslag ville teste, om en AI-model kan generere en komplet stillingsannonce ud fra nøgleord som “Seniorudvikler, Remote, JavaScript”.
Typiske PoC-kendetegn i praksis
Et klassisk AI-Proof of Concept kendetegnes ved følgende egenskaber:
- Begrænset datamængde: Ofte kun 50-100 eksempler i stedet for store produktionsdatasæt
- Ideelle forhold: Rene, forberedte data uden legacy-problemer
- Teknisk fokus: Præcision, svartider og token-forbrug er i centrum
- Kort varighed: Ofte 2-4 uger for de første resultater
Det er ikke forkert – men heller ikke nok til at træffe en investeringsbeslutning.
Begrænsninger ved PoC-tilgangen
Her bliver det kritisk. PoC’er fordrejer ofte billedet af virkelig drift. Hvorfor?
For det første: Datakvalitet. I teorien fungerer AI-modellen med perfekt strukturerede eksempler. I praksis slås du med inkonsistente Excel-ark, manglende oplysninger og forældede formater.
For det andet: Skalering. Et PoC håndterer 100 forespørgsler. I drift skal der håndteres 10.000 forespørgsler dagligt – ofte med helt andre krav til performance.
For det tredje: Integration. PoC’et kører isoleret. I produktion skal løsningen spille sammen med SAP, Salesforce og eksisterende e-mailsystemer.
Markus fra IT-afdelingen siger det rammende: “Vores ChatGPT-PoC var imponerende. Men så skulle den forstå vores 15 år gamle projektdokumenter. Det var en helt anden udfordring.”
Proof of Value – Forretningsværdi som målestok
Definition og filosofi
Et Proof of Value stiller det grundlæggende spørgsmål: Hvilken målbar forretningsværdi leverer denne AI-løsning under reelle betingelser?
Forskellen er både filosofisk og praktisk. Hvor PoC’er spørger “Virker det?”, spørger PoV’er “Kan det betale sig?”
Det skifter hele perspektivet. Pludselig handler det ikke længere mest om teknologien – men om nytten for mennesker og arbejdsgange.
Målbare KPI-kategorier
Et professionelt Proof of Value arbejder med konkrete nøgletal fra fire kategorier:
| Kategori | Eksempler på KPI’er | Målemetode |
|---|---|---|
| Tidsbesparelse | Reduktion af tilbudsudarbejdelse fra 8t til 3t | Før-efter-måling over 4 uger |
| Kvalitetsforbedring | Fejlrate i dokumenter falder med 40% | Stikprøvekontrol af fageksperter |
| Omkostningsbesparelse | Færre udgifter til eksterne oversættelser | Direkte omkostningssammenligning |
| Omsætningsvækst | Flere kvalificerede leads med bedre tekster | A/B-test med eksisterende processer |
Men pas på falsk præcision. Et seriøst PoV angiver også spændvidder: “Tidsbesparelsen ligger mellem 35% og 65% afhængig af dokumenternes kompleksitet.”
Virkelighedstesten
Et ægte Proof of Value tester under produktionslignende forhold. Det betyder:
Rigtige brugere: Ikke IT-teamet, men for eksempel Anna fra HR arbejder reelt med systemet. Hendes feedback tæller.
Rigtige data: Ikke polerede eksempler, men de kaotiske Excel-lister og PDF’er fra hverdagen.
Rigtige arbejdsgange: Systemet skal håndtere afbrydelser, multitasking og det sædvanlige kontorkaos.
Denne realisme gør PoV’er mere krævende – men også langt mere værdifulde for investeringsbeslutninger.
Metodiske forskelle i praksis
Planlægningsfase: Teknologi vs. forretning
Allerede i planlægningsfasen viser der sig grundlæggende forskelle mellem de to tilgange.
Et PoC starter med spørgsmålet: “Hvilke AI-modeller kan teoretisk løse denne opgave?” Teamet undersøger GPT-4, Claude, Gemini og lokale alternativer som Llama.
Et PoV starter anderledes: “Hvilket forretningsproblem skal vi løse, og hvordan måler vi succes?” Først derefter vælges teknologien.
Eksempel tilbudsudarbejdelse: PoC’et tester, om AI kan generere tilbud ud fra produktdata. PoV’et spørger: “Hvor mange timer kan vi forkorte processen, og øger det afslutningsraten?”
Datahåndtering: Ideelt vs. reelt
Her bliver forskellen især tydelig.
PoC-data er ofte kuraterede og ryddelige. Et eksempel-datasæt med produktbeskrivelser er komplet, ensartet formateret uden manglende værdier.
PoV-data afspejler virksomhedens virkelighed. Produktdata fra tre forskellige systemer, delvist på dansk og engelsk, med forskellige kategoriseringer og mangler i tekniske specifikationer.
Denne forskel forklarer, hvorfor mange PoC’er ser succesfulde ud – men fejler i produktion.
Succesmåling: Teknisk vs. forretningsmæssig
Et PoC måler tekniske metrikker: Præcision på 87%, svartid under 2 sekunder, hallucinationsrate 3%.
Et PoV måler forretningsresultater: Tilbudsudarbejdelse 60% hurtigere, kundetilfredshed stiger fra 4,2 til 4,6, ROI nået efter 8 måneder.
Begge typer metrikker er vigtige – men til forskellige beslutninger. Tekniske metrikker hjælper med systemoptimering. Forretningsmæssige metrikker retfærdiggør investeringer.
Tidsramme og ressourcer
Et typisk PoC forløber over 2-4 uger med et lille udviklerteam. Omkostninger: 5.000-15.000 euro.
Et grundigt PoV tager 6-12 uger med tværfaglige teams fra IT, forretning og ledelse. Omkostninger: 20.000-50.000 euro.
Forskellen retfærdiggøres af resultatets slagskraft. Et PoC viser gennemførlighed, et PoV forudsiger forretningsmæssig effekt.
Beslutningshjælp: Hvornår hvilken tilgang?
PoC er det rigtige valg, når…
Du bør starte med et Proof of Concept, hvis der er grundlæggende teknisk usikkerhed.
Nye teknologiområder: Din virksomhed har aldrig arbejdet med Large Language Models og du vil forstå, hvad der overhovedet er muligt.
Komplekse faglige krav: Du udvikler højt specialiserede løsninger, hvor det er uklart, om AI kan rumme den nødvendige dybde. Eksempel: Automatisk kontrol af konstruktionstegninger efter DIN-standarder.
Regulatoriske usikkerheder: I stærkt regulerede brancher som medicoteknik eller finans skal du først sikre, at AI-genereret indhold overhovedet er tilladt.
Begrænsede budgetter: Hvis du hurtigt skal have en grundretning på et lille budget, kan et PoC åbne døren for større investeringer.
PoV er uundværlig, når…
Et Proof of Value er nødvendigt, når konkrete forretningsbeslutninger skal tages.
Investeringstilladelse: Du har brug for midler til fuldtidsudviklere, softwarelicenser eller hardware. Fra et projektvolumen på 50.000 euro er en PoV uomgængelig.
Skaleringsbeslutninger: AI-systemet skal udvides fra 10 til 100 brugere eller fra ét til ti use cases.
Organisatoriske forandringer: Skal der etableres nye roller, processer eller træningsinitiativer, må du kunne kvantificere udbyttet.
Konkurrencepres: I kritiske processer, der direkte påvirker din virksomheds succes, er “kan måske fungere” ikke nok.
Den sekventielle tilgang
I praksis kombinerer succesfulde virksomheder begge metoder strategisk.
Fase 1 – PoC (4 uger): Test grundlæggende gennemførlighed, udvikl de første prototyper, identificer tekniske barrierer.
Fase 2 – PoV (8 uger): Validér business case, involvér reelle brugergrupper, udarbejd ROI-prognoser.
Fase 3 – Pilotprojekt (6 måneder): Begrænset produktionsdrift, løbende optimering, forberedelse af skalering.
Denne tretrinsmodel minimerer risikoen og øger læringen. Hver fase bygger oven på den forrige, men kan også føre til et stop, hvis resultaterne ikke er overbevisende.
Praktisk implementering for SMV’er
Teamstruktur og roller
Succes afhænger i høj grad af den rigtige sammensætning af projektteamet.
For PoCs: En udvikler med AI-erfaring samt en fagekspert fra det relevante område er ofte nok. Tidsforbrug: ca. 20% hver over 4 uger.
For PoVs: Du har brug for et tværfagligt team med klare ansvarsområder:
- Business Owner: Definerer succeskriterier og prioriterer funktioner
- Power User: Arbejder dagligt med systemet og giver detaljeret feedback
- Technical Lead: Ansvarlig for integration og datakvalitet
- Project Manager: Sikrer koordinering og overholdelse af tidsplaner
Uden disse roller går selv velmente PoV-projekter i stå i hverdagens travlhed.
Budgetplanlægning og omkostningsstruktur
Gennemsigtighed om omkostninger skaber tillid og realistiske forventninger.
PoC-budget (typisk 10.000-25.000 euro):
- Udvikling: 60% af omkostningerne
- API-omkostninger (OpenAI, Anthropic): 15%
- Dataforberedelse: 15%
- Dokumentation: 10%
PoV-budget (typisk 30.000-70.000 euro):
- Udvikling og integration: 45%
- Forretningsanalyse og testing: 25%
- Change Management: 15%
- Infrastruktur og værktøjer: 15%
Disse tal er baseret på aktuelle projekterfaringer med kunder i SMV-segmentet og kan bruges som pejlemærker.
Undgå de klassiske faldgruber
Fra vores rådgivningspraksis kender vi de typiske fejlkilder – og hvordan du undgår dem.
Faldgrube 1 – Urealistiske tidsplaner: “ChatGPT-demoen tog 30 minutter, så alt bør køre om to uger.” Realitet: Integration tager som regel længere end selve udviklingen.
Faldgrube 2 – Manglende datagovernance: “Vi har vist dataene et sted.” Uden tydeligt dataansvar fejler 80% af AI-projekter allerede i forberedelsen.
Faldgrube 3 – Manglende brugeraccept: “Teknologien virker, men ingen bruger den.” PoV’er skal inddrage brugere fra starten.
Faldgrube 4 – Scope creep: “Kunne vi ikke også lige…” PoVs kræver klare rammer og succeskriterier.
Den gode nyhed: Alle disse problemer kan undgås med en struktureret tilgang og erfaren projektledelse.
Konklusion: Vejen til bæredygtig AI-succes
Valget mellem Proof of Concept og Proof of Value er ikke et enten-eller. Det er en strategisk rækkefølge, der afgør, om din AI-indsats lykkes.
PoCs giver overblik over den tekniske gennemførlighed. De er det rigtige første skridt i nye teknologiområder og hjælper med at finde vej i AI-junglen.
PoVs skaber klarhed om den forretningsmæssige værdi. De er uundværlige for investeringsbeslutninger og grundlaget for succesfuld skalering.
For Thomas, Anna og Markus i vores eksempler betyder det konkret:
Thomas bør starte med et PoC for tilbudsgenerering for at forstå de grundlæggende muligheder. Den efterfølgende PoV viser ham, om investeringen tjener sig hjem på seks måneder.
Anna kan gå direkte til en PoV for HR-processer, da teknologien bag sproglige modeller allerede er modnet. Hendes fokus er på målbare effektivitetsgevinster.
Markus har behov for et grundigt PoC på grund af legacy-integration, efterfulgt af en struktureret PoV for de vigtigste use cases.
Nøglen ligger i ærlig vurdering af din udgangssituation og konsekvent fokus på målbare forretningsresultater.
For til syvende og sidst handler det ikke om, hvorvidt din AI kan levere flotte demoer. Det afgørende er, om den varigt styrker din forretning.
Ofte stillede spørgsmål om PoC vs. PoV
Hvor lang tid tager et typisk Proof of Value sammenlignet med et PoC?
Et PoC varer typisk 2-4 uger, mens et grundigt PoV tager 6-12 uger. Den længere tidshorisont for PoV skyldes involvering af rigtige brugere, måling af forretnings-KPI’er og integration i eksisterende arbejdsgange. Den ekstra tid er en investering i troværdigheden af resultaterne.
Hvilke omkostninger opstår ved et PoV sammenlignet med et PoC?
PoC’er koster typisk 10.000-25.000 euro, mens PoV’er ligger på 30.000-70.000 euro. Prisforskellen skyldes længere tidsforbrug, tværfaglige teams og mere omfattende test under realistiske forhold. Den højere investering giver til gengæld langt mere værdifulde resultater for forretningsbeslutninger.
Kan man konvertere et PoC direkte til et PoV?
Ja, men ikke automatisk. Et vellykket PoC udgør det tekniske fundament for et PoV, men der skal tilpasses metode. Hvor PoC’et beviser gennemførlighed, skal der i PoV-defineres nye succeskriterier, inddrages rigtige brugere og måles på forretnings-KPI’er. Det anbefales at planlægge begge faser sekventielt.
Hvilke roller kræves for et succesfuldt PoV?
Et PoV-team bør mindst bestå af fire roller: en Business Owner for succeskriterier, en Power User til daglig feedback, en Technical Lead for integration, samt en Project Manager til koordinering. Denne tværfaglige sammensætning sikrer, at både tekniske og forretningsmæssige aspekter håndteres passende.
Hvordan måler jeg ROI på et AI-projekt korrekt?
ROI måles ud fra fire kategorier: Tidsbesparelse (f.eks. kortere tilbudsudarbejdelse), kvalitetsforbedring (færre fejl), omkostningsbesparelse (færre eksterne tjenesteydelser) og omsætningsvækst (flere kvalificerede leads). Det er vigtigt at foretage før-efter-målinger over mindst 4-8 uger med klare baseline-værdier og kontrollerede testforløb.
Hvornår bør jeg springe et PoV over og implementere direkte?
Ved meget standardiserede løsninger med en klar business case kan du springe PoV over. Eksempler er veletablerede værktøjer som Grammarly til korrektur eller DeepL til oversættelser. For skræddersyede løsninger eller komplekse integrationer anbefales PoV dog næsten altid for at minimere risici og styre forventningerne.
Hvilken datakvalitet skal jeg bruge for et meningsfuldt PoV?
For et PoV bør du bruge virksomhedens reelle produktionsdata – med alle fejl og mangler. Især de “kaotiske” hverdagsdata viser, om AI-løsningen er robust i praksis. Ideelt set bruges 3-6 måneders historiske data som trænings- og testgrundlag. For rene og polerede data giver forvredne resultater og urealistiske forventninger.
