Frykt er et utrullingsproblem, ikke et menneskeproblem
Det meste av motstanden mot AI på jobben er rasjonell. Slik gjennomfører du en utrulling teamet ditt stoler på, fra det første bruksområdet til nittidagersgjennomgangen.
De fleste AI-utrullinger stopper opp på samme sted. Verktøyet fungerer, pilotprosjektet så bra ut, og seks uker senere er det tre personer som bruker det. Ledelsen tolker dette som motstand mot endring. Vanligvis er det ikke det. Det er en rasjonell reaksjon på en uklar avtale.
Når du gir noen et system som gjør deler av jobben deres, og ikke sier noe mer, vil de fylle stillheten selv. De vil anta det verste, vente, og fortsette å gjøre arbeidet på den gamle måten i tilfelle den nye måten gir dem dårlige målinger. Den atferden er billig for dem og dyr for deg.
Svar på jobbspørsmålet før noen stiller det
Det første teamet ditt vil vite, er om dette erstatter dem. Sier du det ikke, bestemmer de svaret uten deg.
Så si det, konkret, på en måte du kan holdes ansvarlig for. «Ingen mister jobben på grunn av dette systemet de neste tolv månedene» er en setning en direktør kan forplikte seg til. «AI supplerer i stedet for å erstatte» er det ikke — folk har hørt det, og de vet at det ikke betyr noe.
Hvis bemanningen skal endres, si det også, og si hva som skjer med dem det gjelder. Et vanskelig svar gitt tidlig koster deg mindre enn et vagt svar som lekker over seks måneder. Og hvis du ikke kan forplikte deg til noe, er du ikke klar for å rulle ut; du er klar for en annen samtale med styret.
Start med arbeid folk allerede misliker
Instinktet er å velge prosessen med høyest verdi. Velg den mest irriterende i stedet.
Å avstemme to regneark som aldri stemmer overens. Å skrive om den samme standardteksten i tilbud. Å lese førti supporthenvendelser for å finne de tre som betyr noe. Ingen forsvarer det arbeidet, ingens yrkesidentitet avhenger av det, og alle merker det når det forsvinner. Du får de første forkjemperne gratis.
Prosessen med høy verdi står der fortsatt i måned fire, og da har du et team som har sett at dette fungerer og som har meninger om hvor det skal gå videre.
Skriv ned reglene, på én side
Det er tvetydigheten som gjør folk forsiktige. Det meste av den forsvinner med et kort dokument som svarer, i klarspråk:
- Hva du kan legge inn i systemet, og hva du ikke kan — kundenavn, kontrakter, lønnsdata, kildekode
- Hvilke resultater som må gjennomgås av et menneske før noen utenfor selskapet ser dem
- Hvem du skal si fra til når det gjør noe feil, og hva som skjer videre
- Om det å bruke det, eller å la være, påvirker hvordan arbeidet ditt vurderes
Den siste linjen betyr mer enn de tre andre. Hvis folk mistenker at AI-bruk spores og vurderes, kommer de til å bruke det defensivt og dårlig. Si tydelig hvordan det inngår i evalueringen, selv om svaret er «det gjør det ikke».
Rekrutter skeptikeren, ikke entusiasten
Entusiastene dine tar i bruk hva som helst og overbeviser ingen. Personen du vil ha med i piloten, er den erfarne og respekterte som tror dette sannsynligvis er overvurdert.
De finner de reelle feilmåtene på en uke, fordi de vet hvordan et korrekt resultat ser ut. Og hvis de ender opp med å si «dette sparer meg for en ettermiddag», veier det tyngre enn noe ledelsen kan kjøpe. Gi dem en reell kanal for å melde fra om problemer, og løs så problemene raskt nok til at det føles verdt å melde fra.
Gjør det enkelt å si at systemet tok feil
Ethvert AI-system produserer selvsikre feil. En utrulling lykkes eller mislykkes med det som skjer etterpå.
Hvis det å melde fra om et dårlig resultat krever en e-post til IT, melder ingen fra om noe, feilene hoper seg opp i stillhet, og tilliten renner ut. Legg rapporteringsknappen inn i verktøyet. Ha en navngitt person som leser rapportene. Publiser hva dere endret. Team tilgir systemer som tar feil iblant; de tilgir ikke å bli oversett når de sier fra.
Vurder utrullingen, ikke teknologien
Etter nitti dager handler de nyttige spørsmålene om atferd. Hvor mange brukte det de siste to ukene, ikke siden lansering. Hvilke team sluttet med det, og hva sa de da du spurte hvorfor. Hvor lang tid tar det å få svar på en meldt feil. Hvor har noen stille gått tilbake til den gamle prosessen, og hadde de rett i det.
De tallene forteller deg om endringen traff. Modellbenchmarker gjør det ikke.
Å bære den vekten — retningslinjene, utformingen av piloten, den ubehagelige første samtalen — er mesteparten av arbeidet, og det er den delen som blir hoppet over. Det er også den delen vi bruker mest tid på med kundene våre.
Håndtert riktig slutter innføringen å se ut som et pålegg og begynner å se ut som et verktøy folk selv ba om.