Un team avvia un pilot. Una cinquina di collaboratori, un processo circoscritto, uno strumento rapido da attivare. Dopo qualche settimana i risultati all'interno di quel piccolo gruppo sono buoni. Si risparmia tempo, il lavoro procede più velocemente, le prime reazioni sono positive. Il pilot viene condiviso internamente come prova che l'AI funziona per l'organizzazione.
Dopo di che accade qualcosa di curioso: niente. Il pilot resta con quel team, in quel processo, con quelle cinque persone. Gli altri reparti osservano, dicono che è interessante, e continuano il proprio lavoro come hanno sempre fatto. Un anno dopo il pilot esiste ancora, ma l'organizzazione non è cambiata.
Il ragionamento dietro un pilot chiuso in un angolo non è irragionevole. Si vuole limitare il rischio, si vuole imparare prima di implementare su larga scala, non si vuole sconvolgere subito tutta l'organizzazione per qualcosa di non provato. Iniziare in piccolo è un punto di partenza sensato.
Il problema non sta nell'iniziare in piccolo. Sta in ciò che dopo non succede. Un pilot che funziona bene in un ambiente protetto dice soprattutto qualcosa su quell'ambiente: persone motivate, un processo chiaro, poche dipendenze da altri reparti. Non dice nulla sul fatto che il resto dell'organizzazione possa fare lo stesso. I dati sono organizzati diversamente altrove, i processi funzionano in modo diverso, le persone hanno altre priorità. Il pilot dimostra che può funzionare in condizioni ideali, non che l'organizzazione sia pronta a farlo funzionare ovunque.
Altrettanto riconoscibile è la situazione in cui due entusiasti e nessun altro portano avanti il pilot. Finché quelle due persone investono energia nel progetto, questo continua. Nel momento in cui una di loro assume un altro ruolo o ha troppo da fare, il pilot si ferma. Nessuno se ne accorge subito, perché l'organizzazione non ne è mai stata davvero dipendente.
Ci sono alcuni segnali riconoscibili. Il pilot viene citato nelle presentazioni interne come storia di successo, ma nessuno sa dire quale sia il passo successivo per estenderlo. Non c'è un accordo concreto su quando l'esperimento diventerà qualcosa di strutturale, e quindi non c'è accordo su cosa dovrebbe effettivamente emergere dalla prova. Ha successo se il risparmio di tempo è dimostrabile? Se la qualità resta invariata? Se altri team chiedono spontaneamente di avere accesso? Senza questo criterio, un pilot continua a girare senza mai arrivare da nessuna parte.
Un altro segnale è che la tecnologia funziona, ma il modo di lavorare attorno a essa non è stato adattato. Le persone usano lo strumento in aggiunta al processo esistente invece che al suo posto. È un segno che la tecnologia è più avanti della struttura in cui deve funzionare: l'organizzazione non ha cambiato nulla per creare spazio al nuovo modo di lavorare, quindi è il nuovo lavoro ad adattarsi al vecchio, non il contrario.
Un terzo segnale è che nessuno fuori dal pilot si sente proprietario del progetto. C'è un team che lo sta sperimentando, ma nessun manager, dirigente o responsabile di processo che si assuma la responsabilità di scalarlo. Se un pilot resta una demo invece di diventare una proprietà, è esattamente il pattern per cui una demo senza proprietario perde il suo effetto non appena passa la novità iniziale.
E infine: se si immagina cosa accadrebbe se il pilot dovesse domani essere estenso a altri tre reparti, e la risposta è poco chiara o mette a disagio, probabilmente ci si trova già in questa trappola. Non perché il pilot sia fallito, ma perché non era mai stato pensato per andare da qualche parte.
La ragione per cui i pilot restano bloccati nel loro angolo raramente riguarda la tecnologia in sé. Riguarda ciò che sta sotto il pilot: quanto sono maturi l'organizzazione, l'infrastruttura IT e la gestione dei dati rispetto a quanto richiede l'implementazione su larga scala. Un pilot può funzionare perfettamente su un dataset isolato con un team selezionato, e rivelarsi comunque impossibile non appena tocca il resto dell'organizzazione, semplicemente perché gli strati fondamentali non sono predisposti per questo. È anche esattamente per questo che scalare senza che le fondamenta siano solide si blocca così spesso: il pilot non è mai stato il problema, il terreno sottostante sì.
La misurazione della maturità di hybridresourcing rende visibile quel terreno: cinque livelli, da baseline a intelligence, su sette dimensioni che insieme determinano se un'organizzazione può sostenere un pilot fuori dal suo angolo. In un giro di plot, più persone attribuiscono punteggi separatamente, e la dispersione tra le loro risposte spesso mostra già dove l'organizzazione è in disaccordo su se stessa, ancora prima che si sia parlato di tecnologia. Chi vuole sapere a cosa dovrebbe prestare attenzione un CEO riguardo alla maturità AI prima che parta il prossimo pilot, trova lì un primo spunto.
Questa misurazione riguarda la domanda se l'organizzazione può sostenere un pilot: la struttura è pronta, i dati sono in ordine, l'infrastruttura è adeguata. È una domanda diversa da quale parte del lavoro stesso sia adatta a essere affidata all'AI. A questa domanda risponde la scansione del lavoro di FTE TO AI: calcola, per ogni compito, quale parte del lavoro può essere ripresa, indipendentemente dal fatto che l'organizzazione nel suo insieme sia già pronta o no. Chi considera di estendere un pilot fa bene a porsi entrambe le domande separatamente prima di confonderle tra loro.
La misurazione della maturità è in fase di sviluppo. Chi vuole completare il giro di plot non appena sarà disponibile può iscriversi alla lista d'attesa.
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.