Facilitering af AI hackathons: Den komplette guide for ledere

Et AI hackathon er kun så godt som dets facilitering. I vores 5+ år med at afholde hackathons for nordiske virksomheder har vi set alle fejlene, og lært hvad der skaber de prototyper der faktisk ender i produktion.

Hvad er en facilitators egentlige rolle?

Mange virksomheder tror, at en facilitator er en slags teknisk underviser der viser medarbejderne, hvordan man bruger ChatGPT. Det er en misforståelse der konsekvent skaber skuffende resultater.

En hackathon-facilitator er ikke ekspert på løsningerne. Facilitatoren er ekspert på processen: hvornår man skubber, hvornår man holder igen, hvornår man udfordrer og hvornår man giver plads. Rollen kræver erfaring med gruppers dynamik under tidspres, forståelse for hvornår et team er på vej mod noget godt og hvornår det er ved at gå forkert vej.

Forberedelse: Problemformulering er altafgørende

Den vigtigste forberedelse til et AI hackathon er problemformuleringen. Det vil sige den præcise formulering af de konkrete forretningsudfordringer som teams skal løse.

Svag problemformulering: "Brug AI til at forbedre vores kundeoplevelse"

Stærk problemformulering: "Reducer tid fra indkommende kundeservicehenvendelse til første svar fra 4 timer til under 30 minutter for de 60% af henvendelser der handler om ordrestatus, uden at øge headcount"

Forskellen er specificiteten: gode problemformuleringer har et målbart udgangspunkt, et kvantificerbart succeskriterium og et klart datagrundlag. Teams der arbejder med vage problemformuleringer bruger halvdelen af hackathon-tiden på at definere problemet i stedet for at løse det.

Vi bruger 3-5 timer på problemformulerings-workshops med ledelsen inden et hackathon. Det er den forberedelse der giver mest afkast, og det er den der oftest springes over.

Tjekliste til god problemformulering

• Er problemet målbart? (antal, tid, omkostning, fejlrate)
• Er der adgang til relevante data under hackathon?
• Er problemet specifikt nok til at løses på 48 timer?
• Er forretningsejeren til stede og klar til at svare på spørgsmål?
• Er der defineret et succeskriterium der kan verificeres live i demoen?

Spørgsmål 5 er afgørende. Hvis succesen ikke kan verificeres i en 5-minutters demo, er problemformuleringen for abstrakt.

Uge 2: Praktisk forberedelse

To uger inden hackathon håndterer vi:

Deltagerliste og holdsætning: Bland afdelinger bevidst. Et hold bestående af en udvikler, en forretningsperson og en repræsentant fra den berørte afdeling præsterer konsekvent bedre end funktionelt ensartede hold. Diversitet i perspektiv er vigtigere end ensartet teknisk niveau.

Teknisk opsætning: Sørg for at alle deltagere har relevante konti oprettet (AI-modeller, n8n, GitHub) inden de møder op. Teknisk opsætning på selve dagen er tidsspild og sænker energiniveauet.

Briefing til deltagere: Send en præcis beskrivelse af problemformuleringerne, hvilke data der er tilgængelige og hvilke værktøjer I anbefaler. Ikke for at bestemme løsningerne, men for at deltagerne kan tænke over problemet inden de møder op.

Ledelsesforankring: Sørg for at en ledelsesrepræsentant er til stede ved præsentationen og har mandat til at tage en beslutning om opfølgning. Hackathons uden ledelsespublikum producerer sjældent implementerede løsninger.

Dag 1: Energi, struktur og psykologisk tryghed

De første 2 timer sætter tonen for hele hackathon.

Opstart (45 min): Hvorfor er I her? Hvad er tilladt? Fejl er velkomne, det er et forsøg. Hvad vinder det vindende hold? Brug tid på at etablere psykologisk tryghed. Teams der er bange for at fejle, producerer konservative og uambitiøse løsninger.

Problemformulering præsentation (30 min): Forretningsejerne præsenterer udfordringerne. Hold stiller spørgsmål. Undgå at lade ledelsen antyde foretrukne løsninger på dette tidspunkt. Lad teams nå frem til idéerne selv.

Holdsammensætning (15 min): Brug ikke frivillig gruppering. Facilitatoren blandede hold aktivt for at sikre tværfaglig sammensætning. Meddelelsen om holdsammensætning bør komme fra facilitatoren, ikke fra ledelsen.

Teknisk introduktion (30 min): En kort praktisk gennemgang af de tilgængelige AI-værktøjer. Ikke en kursusdag, men en demonstration af hvad der er muligt og hvad der er realistisk at bygge på 48 timer.

Undervejs: Faciliteringens tre kritiske øjeblikke

Øjeblik 1: De første 4-8 timer (det første vadested)

Mange teams har på dette tidspunkt en god idé men ingen klar plan for prototypen. Facilitatoren tjekker ind hos hvert hold med dette spørgsmål: "Hvad er det præcise input, og hvad er det præcise output i jeres demo?" Hvis teamet ikke kan svare klart, er der et problem der skal adresseres nu.

Øjeblik 2: Efter 20-24 timer (midtvejscheck)

Her afslører sig typisk et af to mønstre: holds der er langt fremme og ved at over-bygge, og hold der er bagud og ved at give op. Facilitatoren håndterer begge:

• Overambition: "I har allerede det I behøver til en stærk demo. Stop med at bygge og begynd at øve præsentationen."
• Underpræstation: "Lad os forenkle. Hvad er den simpleste version der stadig demonstrerer kernekonceptet?"

Øjeblik 3: De sidste 8-12 timer (præsentationsforberedelse)

Alle hold øver præsentation mindst to gange. Facilitatoren giver feedback på: klarhed i problemformulering (de fleste glemmer at forklare problemet, inden de viser løsningen), demonstrationens flow og brugen af faktiske data i stedet for beskrivelse af hvad systemet "ville kunne gøre".

Præsentationsformat der virker

Vi bruger konsekvent dette format til hackathon-præsentationer:

2 minutter: Problemet. Hvad er udfordringen, hvem rammes, hvad koster det nu?

1 minut: Løsningskonceptet. Hvad gør prototypen, og hvordan fungerer AI-komponenten?

2 minutter: Live demonstration. Kør prototypen med rigtige (eller realistiske) data. Undgå slides her.

30 sekunder: Næste trin. Hvad kræves for at gå fra prototype til drift?

Spørgsmål fra publikum: 2-3 minutter.

Det er i alt 8 minutter per hold. Med 6 hold er det 48 minutter, plus tid til vinderannoncering og afslutning.

Dommerpanel og evalueringskriterier

Undgå at lade én person (fx den øverste leder) alene vurdere vinderne. Brug et panel på 3-5 personer med forskellig baggrund. Kriterier vi bruger:

Kriterium	Vægtning	Vurdering
Forretningsværdi	35%	Løser det et reelt problem med målbar effekt?
Demonstrabilitet	25%	Kørte det live? Var outputtet overbevisende?
Realiserbarhed	20%	Kan det implementeres inden for 90 dage?
Nyhedsværdi	20%	Er tilgangen ny eller anderledes end det eksisterende?

Gør kriterierne kendte for deltagerne fra starten. Det styrer ambitionen i rigtig retning.

Opfølgning: Implementeringsplanen der mangler

80% af virksomheder afholder hackathon og går hjem. 3 måneder senere er intet implementeret, og ledelsen konkluderer at hackathons "ikke virker."

Problemet er ikke hackathon. Problemet er manglen på en struktureret opfølgning.

Den rigtige struktur efter hackathon:

Dag 1-7: Prototype-forfining med det originale hold. Løs de åbenlyse svagheder identificeret under præsentationen. Intet nyt bygges endnu.

Uge 2-4: Minimumsbehovsplan med IT og produktorganisation. Hvad kræves for en pilottest med 10-50 rigtige brugere?

Måned 2-3: Pilottest med rigtige brugere. Indsaml data. Mål mod de baseline-KPI'er der blev defineret inden hackathon.

Måned 3: Beslutning om fuld implementering. Beslutningstagere har nu data at træffe valget på, ikke kun en præsentation fra en entusiastisk hackathon-weekend.

Med denne struktur ser vi 3 ud af 5 prototyper i drift inden for 90 dage. Uden strukturen: under 1 ud af 10.

De mest udbredte faciliteringsfejl

Fejl 1: For brede problemformuleringer. "Forbedre kundeoplevelsen med AI" er ikke en problemformulering, det er et ønske. Brug tid på at formulere specifikt inden hackathon starter.

Fejl 2: Ledelsen prioriterer ikke præsentationen. Hvis de beslutningstagere der kan give opfølgning grønt lys ikke er til stede ved præsentationen, er sandsynligheden for implementering minimal.

Fejl 3: Monofunktionelle hold. Fem udviklere bygger imponerende teknisk set, men løser sjældent det rigtige forretningsproblem. Fem forretningsfolk har gode idéer men ingen prototype. Bland bevidst.

Fejl 4: Manglende generalprøve. Hold der ikke har afviklet demoen mindst to gange inden præsentationen, oplever tekniske problemer under pres. Facilitatoren sikrer at alle hold øver.

Fejl 5: Ingen opfølgningsplan. Planlæg implementeringsstrukturen inden hackathon, ikke efter. Annoncér den ved starten, så alle ved at dette er starten på noget, ikke et afsluttet projekt.

Konklusion

Et vellykket AI hackathon er resultatet af 2-3 ugers forberedelse, præcise problemformuleringer, tværfaglige hold og en facilitator der er til stede som energistyrer, teknisk brobygger og præsentationscoach i ét. Men vigtigst af alt: et hackathon er kun værdifuldt hvis opfølgningsstrukturen er på plads. Den investering sikrer, at den energi og de idéer der genereres over 48 timer, ender som kørende software og ikke som en glemt præsentation.