De fleste virksomheder har rigeligt med kandidater til AI og automation. Det svære er at vælge den første. Denne artikel giver en konkret metode: fire kriterier, et eksempel, de typiske fejlvalg og en tjekliste, der kan bruges i morgen.
I denne artikel
Det korte svar
Vælg en case, der er lille nok til at kunne afgrænses, hyppig nok til at værdien kan måles, og ufarlig nok til at fejl kan håndteres med kladder eller godkendelser. Den første case skal bevise arbejdsformen, ikke transformere virksomheden.
Det lyder banalt, men det modsatte valg, den store, synlige og komplekse case, er den hyppigste enkeltårsag til skuffede AI-projekter.
Hvorfor den første case afgør resten
Den første AI-case sætter standarden for alt det næste: hvordan data håndteres, hvordan godkendelser fungerer, hvordan værdi måles, og hvor meget organisationen tør bagefter. En vellykket lille case skaber appetit, erfaring og et mønster, der kan genbruges. En fejlslagen stor case skaber det modsatte, ofte i årevis.
Derfor er det vigtigste valg ikke leverandør eller model, men selve casen. Og valget kan kvalificeres med fire simple kriterier.
Fire kriterier for en god første case
- Værdi: tid, kvalitet, gennemløb eller risiko, som kan gøres op i en baseline. "Det føles hurtigere" er ikke en baseline.
- Kompleksitet: hvor stor en del af opgaven kræver fortolkning frem for faste regler? Regel-tunge opgaver kan ofte løses med klassisk automation, billigere og mere forudsigeligt.
- Datagrundlag: findes de nødvendige data, er kvaliteten kendt, og må de bruges til formålet?
- Risiko: hvad sker der, når løsningen tager fejl? Ikke hvis, men når. Kan konsekvensen håndteres med kladder, godkendelser og log?
Score kandidaterne groft på de fire akser, for eksempel lav, mellem og høj. Den bedste første case er sjældent den med størst potentiale, men den med bedst balance: målbar værdi, kendt datagrundlag og håndterbar risiko.
Tre kandidater, ét valg: et gennemregnet eksempel
Forestil jer tre typiske kandidater i samme virksomhed:
- A. Automatisk tilbudsskrivning til kunder. Høj værdi, men høj kompleksitet, følsomme kundeløfter og direkte ekstern konsekvens ved fejl.
- B. Triage af fælles postkasse. Mellem værdi, afgrænset fortolkning, data findes i postkassen og sagssystemet, og fejl fanges af et godkendelsestrin.
- C. Chatbot på hjemmesiden "til alt". Uklar værdi, åben afgrænsning, intet naturligt godkendelsespunkt og svær måling.
B vinder ikke, fordi den er mest imponerende, men fordi den kan afgrænses, måles og fejle uden konsekvens for kunder. A kan blive case nummer to eller tre, når arbejdsformen er bevist, typisk i en kladdebaseret udgave uden kommerciel godkendelseskompetence. C er i praksis et projekt uden succeskriterium.
Typiske fejlvalg
- At vælge den største smerte først. Den er som regel også den mest komplekse og politisk følsomme.
- At starte med en åben chatbot "til alle". Uden afgrænset opgave og målgruppe kan hverken kvalitet eller værdi måles.
- At automatisere en proces, ingen kan beskrive. Uklarheden forsvinder ikke; den bliver eksekveret hurtigere og mere konsekvent.
- At springe datagrundlaget over. Er kilderne spredte, udefinerede eller ulovlige at bruge, er det dér, arbejdet reelt starter.
- At bygge handling ind fra dag ét. Skrivehandlinger uden godkendelsesdesign flytter risikoen direkte ind i driften.
Alle fem fejlvalg har samme rod: casen blev valgt efter synlighed frem for målbarhed.
Hvem skal med i beslutningen?
Tre roller er nødvendige, uanset virksomhedens størrelse: procesejeren, der kender arbejdsgangen i praksis og kan afsløre undtagelserne; en beslutningstager, der kan prioritere og eje business casen; og ved systemtunge workflows en person med indsigt i IT, adgange og datakvalitet.
Medarbejderne, der udfører opgaven i dag, hører også med tidligt. Ikke af høflighed, men fordi accepttesten i sidste ende er deres: bruger de forslagene, eller arbejder de udenom?
Sådan måler I, om casen virker
Fastlæg baseline, før der bygges: hvor lang tid tager opgaven i dag, hvor ofte fejler den, hvad koster fejlene, og hvem bruger tiden. Definér få, konkrete acceptkriterier for piloten, for eksempel andelen af udkast, der kan bruges uden væsentlig omskrivning, eller tiden fra henvendelse til korrekt fordeling.
Mål på de samme punkter efter en aftalt periode, og beslut på forhånd, hvad der skal ske ved succes, ved blandet resultat og ved fiasko: skalér, justér eller stop. Det gør evalueringen ærlig og beslutningen enkel. En pilot, der ikke kan fejle, er ikke en pilot.
Fra valg til pilot
En god pilot er read-only eller kladdebaseret: løsningen læser godkendte kilder og afleverer forslag, mens mennesker beslutter. Det fjerner det meste af risikoen, mens værdi og kvalitet måles på rigtige opgaver i rigtig drift.
Først når piloten har bevist sig mod baseline, udvides handlekraften trin for trin: flere kilder, flere brugere eller kontrollerede skrivehandlinger med godkendelse. Hvert trin er en beslutning med dokumentation, ikke en glidebane.
Datagrundlaget afgør mere end modellen
Før casen låses fast, er tre dataspørgsmål vigtigere end noget teknologivalg. Findes dataene: ligger henvendelserne, dokumenterne eller målingerne et sted, en løsning kan læse dem? Er kvaliteten kendt: er felterne udfyldt ens, og betyder det samme tal det samme i alle systemer? Og må de bruges: er der personoplysninger, kundedata eller fortrolighed, som kræver afklaring af adgang, opbevaring og sletning?
Et ærligt nej på et af de tre er ikke et stop, men en omprioritering: så er den første leverance et afgrænset stykke datagrundlagsarbejde, ikke en agent. Det er billigere at opdage før byggeriet end efter.
Efter piloten: skalér, justér eller stop
En pilot slutter med en beslutning, ikke med en demo. Ved succes mod baseline skaleres kontrolleret: flere brugere, flere kilder eller næste workflow, mens godkendelser og logning følger med. Ved blandet resultat justeres én ting ad gangen, typisk datakvalitet, instrukser eller afgrænsning, og der måles igen. Ved fiasko stoppes casen, og læringen dokumenteres: hvad manglede, og hvilken kandidat er så den næste?
Det vigtigste output af den første case er sjældent selve løsningen, men mønsteret: en afprøvet vej fra idé over baseline og pilot til beslutning, som kan genbruges på case to og tre med langt mindre friktion.
Kort tjekliste
- Kan casen beskrives på én side: opgave, brugere, input, output?
- Findes der en baseline, eller kan den etableres hurtigt?
- Er datakilderne udpeget, og må de bruges til formålet?
- Er konsekvensen ved fejl håndterbar med kladde eller godkendelse?
- Er det aftalt, hvem der ejer beslutningen efter piloten?
Kan I svare ja til de fem, er casen sandsynligvis god nok til at starte. Kan I ikke, er en struktureret kortlægning af workflowet det rigtige første skridt, før der investeres i udvikling.
Læs også
Har I flere kandidater end afklaring?
En Automation Audit kortlægger workflow, data og risiko og leverer en prioriteret caseliste, så den første investering rammer rigtigt.
Vurdér et workflow →