Frygt er et udrulningsproblem, ikke et menneskeproblem
Det meste modstand mod AI på arbejdspladsen er rationel. Sådan gennemfører du en udrulning, dit team har tillid til — fra den første use case til evalueringen efter halvfems dage.
De fleste AI-udrulninger går i stå samme sted. Værktøjet virker, pilotprojektet så godt ud, og seks uger senere bruger tre personer det. Ledelsen læser det som modstand mod forandring. Det er det som regel ikke. Det er en rationel reaktion på en uklar aftale.
Når du giver nogen et system, der udfører en del af deres arbejde, og ikke siger andet, udfylder de selv tavsheden. De vil antage den værste udgave, vente og fortsætte med at løse opgaven på den gamle måde, i tilfælde af at den nye måde får dem målt dårligt. Den adfærd er billig for dem og dyr for dig.
Besvar spørgsmålet om jobbet, før nogen stiller det
Det første, dit team vil vide, er, om det her erstatter dem. Siger du det ikke, afgør de svaret uden dig.
Så sig det, konkret, på en måde du kan holdes op på. "Ingen mister sit job på grund af dette system de næste tolv måneder" er en sætning, en direktør kan forpligte sig på. "AI understøtter frem for at erstatte" er ikke — folk har hørt den, og de ved, at den ikke betyder noget.
Hvis antallet af medarbejdere ændrer sig, så sig også det, og sig, hvad der sker med dem, det berører. Et hårdt svar givet tidligt koster dig mindre end et vagt svar, der siver ud over seks måneder. Og kan du ikke forpligte dig på noget, er du ikke klar til at rulle ud; du er klar til at tage en anden samtale med din bestyrelse.
Start med arbejde, folk allerede ærgrer sig over
Instinktet er at vælge den proces med størst værdi. Vælg i stedet den mest irriterende.
Afstemning af to regneark, der aldrig stemmer. Omskrivning af de samme standardafsnit i tilbud. Læsning af fyrre supportsager for at finde de tre, der betyder noget. Ingen forsvarer det arbejde, ingens faglige identitet afhænger af det, og alle bemærker, når det forsvinder. Du får dine første fortalere gratis.
Processen med den store værdi ligger der stadig i måned fire, og til den tid har du et team, der har set tingen virke, og som har holdninger til, hvor den skal hen næste gang.
Skriv reglerne ned, på én side
Tvetydighed er det, der gør folk forsigtige. Det meste af den forsvinder med et kort dokument, der i almindeligt sprog besvarer:
- Hvad du må lægge ind i systemet, og hvad du ikke må — kundenavne, kontrakter, lønoplysninger, kildekode
- Hvilke output der skal gennemgås af et menneske, før nogen uden for virksomheden ser dem
- Hvem man siger det til, når systemet tager fejl, og hvad der så sker
- Om det at bruge det, eller ikke bruge det, påvirker, hvordan ens arbejde bliver bedømt
Den sidste linje betyder mere end de tre andre. Hvis folk har mistanke om, at AI-brug bliver målt og bedømt, bruger de det defensivt og dårligt. Sig lige ud, hvordan det indgår i evalueringen, også selvom svaret er "det gør det ikke".
Rekrutter skeptikeren, ikke entusiasten
Dine entusiaster tager alt til sig og overbeviser ingen. Den, du vil have med i pilotprojektet, er den erfarne, velansete person, der mener, det her nok er overhypet.
De finder de reelle fejlmønstre på en uge, fordi de ved, hvordan et korrekt resultat ser ud. Og ender de med at sige "det her sparer mig en eftermiddag", vejer det tungere end noget, ledelsen kan købe sig til. Giv dem en reel kanal til at melde problemer, og løs så problemerne hurtigt nok til, at det føles umagen værd at melde dem.
Gør det let at sige, at systemet tog fejl
Ethvert AI-system producerer selvsikre fejl. En udrulning lykkes eller mislykkes på, hvad der sker derefter.
Hvis det kræver en mail til IT at markere et dårligt output, markerer ingen noget, fejlene hober sig stille op, og tilliden siver væk. Læg knappen til at melde fejl ind i værktøjet. Hav en navngiven person, der læser meldingerne. Offentliggør, hvad I har ændret. Teams tilgiver systemer, der tager fejl en gang imellem; de tilgiver ikke at blive ignoreret, når de siger til.
Bedøm udrulningen, ikke teknologien
Efter halvfems dage handler de brugbare spørgsmål om adfærd. Hvor mange brugte det i de sidste to uger — ikke siden lanceringen. Hvilke teams droppede det, og hvad sagde de, da du spurgte hvorfor. Hvor lang tid går der, før en markeret fejl får et svar. Hvor er nogen stille og roligt gået tilbage til den gamle proces, og havde de ret i det.
De tal fortæller dig, om forandringen landede. Modelbenchmarks gør ikke.
At bære den vægt — politikken, designet af pilotprojektet, den akavede første samtale — er størstedelen af arbejdet, og det er den del, der bliver sprunget over. Det er også den del, vi bruger mest tid på sammen med kunderne.
Gøres det ordentligt, holder udbredelsen op med at ligne et påbud og begynder at ligne et værktøj, folk selv har bedt om.