← Tilbake til bloggen

Hvordan måle om et AI-prosjekt faktisk fungerte

Et praktisk rammeverk for å vurdere AI-prosjekter etter forretningsresultater — utgangspunkt, reelle måltall, fulle kostnader og hva du bør følge med på etter lansering.

De fleste AI-prosjekter ender med en demo og en applaus. Få ender med et tall. Seks måneder senere kan ingen si om systemet sparte penger, vant kunder eller bare ble enda et verktøy å vedlikeholde. Problemet er sjelden teknologien. Det er at ingen definerte hvordan suksess skulle se ut før arbeidet begynte, så suksess ble det prosjektet tilfeldigvis produserte.

Å måle et AI-prosjekt er ikke komplisert. Det krever at man på forhånd bestemmer hvordan virksomheten skal se ut hvis prosjektet fungerer — og deretter sjekker.

Definer «fungerte» før noen skriver kode

Et AI-prosjekt fungerer når det endrer et forretningstall du allerede bryr deg om. Ikke nøyaktighet, ikke svarkvalitet, ikke «bruk» i abstrakt forstand. Et tall: timer med manuelt arbeid fjernet, dager kuttet fra en prosess, feilrater i fakturaer, kostnad per håndtert henvendelse, omsetning per selger.

Skriv ned det tallet før prosjektet starter, sammen med målet. «Systemet skal kutte tiden det tar å utarbeide tilbud fra tre dager til én» er en påstand du kan etterprøve. «Systemet vil forbedre effektiviteten» er en påstand du bare kan si deg enig i. Hvis teamet ikke kan navngi tallet prosjektet skal flytte, er prosjektet ikke klart til å finansieres.

Mål utgangspunktet først

Du kan ikke vise forbedring mot et utgangspunkt ingen har registrert. Før systemet settes i drift, bruk en uke eller to på å kartlegge hvordan prosessen presterer i dag: hvor lang tid oppgaver tar, hvor ofte de går galt, hva de koster, hvem som er involvert. Dette er lite glamorøst arbeid, og det er det steget som oftest hoppes over i AI-adopsjon.

Utgangspunktet trenger ikke være perfekt. Ti tidsmålte eksempler på dagens prosess slår null. Uten dem blir enhver senere samtale om verdi til påstand mot påstand.

Vurder resultater, ikke modellytelse

Tekniske team vil rapportere tekniske måltall — nøyaktighet, responstid, benchmark-skårer. Disse betyr noe for dem og bør ikke bety mye for deg. En modell kan være 95 % nøyaktig og likevel mislykkes som prosjekt fordi de 5 % den tar feil på rammer dine viktigste kunder, eller fordi de ansatte stille sluttet å bruke den i mars.

Måltallene som er verdt å gjennomgå på ledelsesnivå, faller i fire grupper:

  • Resultat: er arbeidet målbart raskere, billigere eller bedre enn utgangspunktet
  • Bruk: hvor stor andel av det aktuelle arbeidet som faktisk går gjennom systemet, og om andelen vokser eller krymper
  • Unntak: hvor ofte et menneske må gripe inn, korrigere eller overstyre — og om disse tilfellene blir sjeldnere
  • Tillit: om de som bruker systemet ville protestert mot å miste det

Brukstallet fortjener spesiell oppmerksomhet. Et system som brukes i 8 % av de aktuelle tilfellene har ikke fungert, uansett nøyaktighet. Fallende bruk er det tidligste ærlige signalet om at noe er galt, og det viser seg lenge før noen sender inn en klage.

Regn med hele kostnaden

Byggekostnaden er den synlige delen. Den reelle totalen inkluderer de løpende delene: abonnements- og regnekostnader, tiden ansatte bruker på å gjennomgå resultater, vedlikeholdet når en leverandør endrer et API eller prosessen systemet ble bygget rundt forandrer seg. Et prosjekt som sparer tjue timer i uken, men bruker ti på gjennomgang og vedlikehold, har en reell gevinst — halvparten av den annonserte.

Sett en gjennomgang i kalenderen tre og seks måneder etter lansering, og sammenlign den fulle driftskostnaden med den målte gevinsten. Mange prosjekter som så marginale ut ved lansering, er klart positive ved måned seks; noen som demonstrerte glimrende, er klart negative. Du vil vite hvilket av dem du har mens det fortsatt er tid til å fikse eller stoppe det.

Se opp for forvitring

Et AI-system er ikke en bro; det forblir ikke bygget. Dataene endrer seg, virksomheten endrer seg, modellen bak et API endrer seg uten varsel. Et system som fungerte i januar, kan drive stille av kurs innen juli, og fordi resultatene fortsatt ser plausible ut, merker ingen det før en kunde gjør det.

Løsningen er enkel: hold en liten samling kjente tilfeller med kjente riktige svar, og kjør dem gjennom systemet månedlig. Hvis resultatene endrer seg, oppdager du det gjennom egne kontroller i stedet for gjennom markedet. Gi ansvaret til en navngitt person. Forvitring som ingen har som jobb å fange opp, blir ikke fanget opp.

Énsidestesten

Hvis et AI-prosjekt fungerte, bør du kunne oppsummere det på én side: utgangspunktet, målet, det målte resultatet, den fulle kostnaden og utviklingen siden lansering. Hvis den siden ikke kan skrives, er den ærlige konklusjonen ikke at prosjektet mislyktes — det er at ingen kan vite det, noe som for virksomheten er det samme.

Denne måledisiplinen er tyngre enn de fleste team forventer, og det er nettopp en vekt verdt å bære — det er den som skiller AI som demonstrerer godt fra AI som lønner seg. Det er også den delen av adopsjonen Hercules A bygger inn fra starten, slik at spørsmålet «fungerte det» alltid har et tall som svar.

Artikler · Hercules A

Innsikt om å tilpasse bedriften til AI.

Contact