Et værktøj er ikke en problemformulering
Når jeg tager fat på en ny idé, vil jeg begynde med selve opgaven: Hvem udfører den? Hvad sætter den i gang? Hvilke oplysninger bruger personen? Og hvad skal der komme ud af arbejdet?
Dette er min foreslåede arbejdsramme, ikke en påstand om dokumenterede resultater eller en gennemgang af en bestemt forskningsmodel.
Beskriv ét forløb
Et tænkt eksempel er en medarbejder, der læser en henvendelse og placerer den i en kategori. Før jeg foreslår en løsning, vil jeg beskrive kategorierne, finde eksempler på tvivlstilfælde og afklare, hvem der har det sidste ord.
Det første spørgsmål er derfor ikke, hvilken model der skal bruges. Det er, om opgaven overhovedet er beskrevet tydeligt nok til at kunne afprøves.
Sammenlign mindst to tilgange
Jeg vil gerne sammenligne en enkel regelbaseret tilgang med en AI-baseret prototype, når det giver mening. Måske kan et filter klare en stor del af opgaven. Måske kræver nogle beskeder en vurdering, der ikke bør automatiseres.
At vælge en mindre kompliceret løsning er også et relevant resultat.
Aftal, hvad der tæller som en forbedring
Inden testen vil jeg beskrive, hvad der skal observeres: tid til at løse opgaven, fejl, behov for efterkontrol og konsekvensen af at tage fejl. En tilsyneladende hurtig løsning er ikke nødvendigvis nyttig, hvis den kræver meget efterarbejde.
Begynd uden følsomme data
Min første prototype skal bruge syntetiske eller ufølsomme eksempeldata. Det giver et afgrænset sted at undersøge idéen, før spørgsmålet om en virkelig driftssituation overhovedet opstår.
Det er denne type forsøg, jeg vil dokumentere i ORAIs portfolio: små nok til at gennemføre, konkrete nok til at kritisere og tydelige nok til at lære af.