In quasi ogni organizzazione che sperimenta con l'AI, a un certo punto emerge lo stesso gruppo: due, forse tre persone che capiscono la questione, che hanno iniziato a provare da sole, che raccontano con entusiasmo cosa è possibile. Costruiscono un prototipo, testano uno strumento, condividono risultati in una chat interna. Il resto dell'organizzazione osserva, annuisce, e continua a lavorare come sempre.
Dopo qualche mese c'è un elenco di esperimenti interessanti e nessun cambiamento nel modo in cui il lavoro viene effettivamente svolto. I due entusiasti sono ancora entusiasti. Tutti gli altri intorno a loro non si sono mossi.
Il ragionamento dietro questo approccio suona sensato: iniziare in piccolo, con persone motivate, e lasciare che il successo si diffonda da solo. Per alcuni cambiamenti funziona davvero così. Un nuovo modo di lavorare che fa risparmiare tempo in modo visibile a volte si diffonde in modo organico perché i colleghi lo adottano.
Con l'AI questo meccanismo di solito non funziona, e la ragione non sta nelle persone ma nell'organizzazione che le circonda. Gli entusiasti hanno spesso accesso a sistemi, tempo e mandato che altri non hanno. Ciò che per loro è una questione di provare per un pomeriggio, per un collega senza quell'accesso richiede una richiesta, un'approvazione, un ticket IT. L'entusiasmo non è il problema. L'assenza di un percorso lungo il quale altri possano seguire è il problema.
L'ordine in cui si costruisce la maturità nell'AI non inizia dalle persone che vogliono. Inizia dalla struttura che lo rende possibile: come è organizzata l'organizzazione, quale infrastruttura IT è presente, come vengono gestiti i dati. Due entusiasti possono lavorare intorno a quella struttura, con accesso proprio, trucchi propri, scorciatoie proprie. Il resto dell'organizzazione non può farlo, e non dovrebbe nemmeno volerlo — le scorciatoie non sono una base per qualcosa che deve continuare a funzionare.
Ciò spiega perché lo schema si ripete spesso insieme ad altre trappole note. Chi legge cosa deve emergere prima che un pilota porti a qualcosa, vede un meccanismo simile: attività senza un accordo su cosa significhi successo resta attività. Con due entusiasti l'accordo manca altrettanto — non su cosa deve emergere, e non su chi li segua.
Ci sono alcuni segnali riconoscibili. Il primo è che gli stessi due o tre nomi ricompaiono sempre quando si parla di AI, in ogni riunione, in ogni aggiornamento. Il secondo è che le domande di altri reparti iniziano con "come hanno fatto loro" invece che con un proprio percorso. Il terzo, e il più sottovalutato, è che nessuno può spiegare cosa dovrebbe succedere se una di quelle due persone se ne andasse domani.
Un quarto segnale è più sottile: l'esperimento continua a funzionare nel proprio angolo, staccato dal resto del processo. Questo si collega a ciò che accade quando un pilota che opera fuori dal proprio team non trova collegamento — l'entusiasmo senza collegamento con il resto dell'organizzazione resta un'isola, per quanto bene funzioni l'isola stessa.
Un quinto segnale, infine, è che si propone di scalare come passo successivo, mentre nessuno ha verificato se la base sottostante sia già presente. Questo rischio è descritto in ciò che accade quando si tenta di scalare prima che la base sia presente: due entusiasti che vogliono moltiplicare il proprio successo su dieci team si arenano esattamente sulla struttura che loro stessi avevano evitato.
È tentante concludere che servono più entusiasti, o una formazione migliore, o un programma culturale. Questo non colpisce il punto. La domanda non è se ci siano persone sufficientemente motivate — spesso ce ne sono già due, e questo è esattamente il problema, perché due non è una struttura. La domanda è se l'organizzazione nel suo insieme — nel modo in cui è organizzata, in come i sistemi comunicano tra loro, in come i dati sono disponibili e attendibili — possa sostenere una situazione in cui non due ma molte più persone possano lavorare con l'AI. Questa è una domanda diversa da chi sia entusiasta, ed è la domanda a cui bisogna rispondere prima.
Per chi in un ruolo dirigenziale si scontra con questo schema, è utile sapere a cosa presterebbe attenzione qualcuno in una posizione simile: a cosa presterebbe attenzione un CEO nel valutare la maturità nell'AI descrive alcuni di questi punti di attenzione, così come lo sguardo di a cosa presterebbe attenzione un COO nella maturità nell'AI da una prospettiva diversa sulla stessa organizzazione.
Se due entusiasti dimostrano che qualcosa è possibile, resta senza risposta la domanda di quanta parte del lavoro sia effettivamente da trasferire, e a chi. Questa domanda non riguarda la prontezza ma il lavoro stesso: quali compiti si prestano a essere trasferiti all'AI e quale parte ciò comporti. È esattamente a questo che serve la scansione del lavoro di FTE TO AI — calcola per ogni compito quale parte del lavoro sia da trasferire, indipendentemente da chi già ci sperimenta con entusiasmo.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.