Viene avviato un pilota. Un team, uno strumento, un periodo di alcune settimane o mesi. Alla fine segue un riscontro: si è sentito bene, le persone erano entusiaste, alcune cose sono andate più velocemente. E allora viene presa una decisione basata su quella sensazione, mentre nessuno ha stabilito in anticipo a quale domanda il pilota dovesse effettivamente rispondere.
Questa è la trappola. Non il pilota in sé, ma l'assenza di una domanda a cui il pilota doveva rispondere. Senza quella domanda, ogni risultato è un buon risultato, e questo è esattamente il problema. Un pilota senza un accordo su cosa deve emergere non può fallire, e per questo non può nemmeno dimostrare nulla.
Un pilota sembra un modo sicuro per cominciare. Iniziare in piccolo, vedere cosa succede, poi scalare se funziona. Sembra ragionevole, e in una situazione stabile lo è davvero. Ma l'AI non riguarda solo il team che gestisce il pilota. Riguarda il modo in cui i dati vengono registrati, chi decide su cosa, e quali sistemi devono comunicare tra loro. Un pilota che non misura nulla su questo, quindi, non misura nemmeno la domanda se il resto dell'organizzazione otterrebbe lo stesso risultato.
La logica del "provare prima in piccolo" presuppone che il successo in piccola scala si traduca in successo su larga scala. Questo è esattamente il motivo per cui scalare senza che le basi siano solide non produce nulla: ciò che funzionava in un pilota spesso funzionava grazie a circostanze che altrove non sono presenti. Un team motivato, un set di dati puliti, un dirigente che per caso ha partecipato attivamente. Senza un accordo su cosa doveva essere verificato, resta poco chiaro se il risultato sia dovuto alla tecnologia o alle circostanze eccezionali in cui è stata testata.
Ci sono alcuni segnali riconoscibili.
Il primo segnale è che il pilota si conclude con un racconto invece che con una risposta. Si racconta cosa è successo, ma nessuno può dire se la domanda posta in anticipo — che in realtà non è mai esistita — ha ottenuto una risposta.
Il secondo segnale è che il pilota era isolato dal resto dell'organizzazione. Un team, un caso d'uso, nessun collegamento con i sistemi o i reparti che dovrebbero sostenere il risultato se funziona. È la stessa trappola descritta quando un pilota funziona solo nel suo angolino: un successo isolato dice poco su cosa accade quando il resto dell'organizzazione deve collegarsi.
Il terzo segnale è che nessuno possiede il pilota. C'è un project manager, forse un fornitore, ma nessun proprietario responsabile di ciò che deve accadere dopo il pilota. Ci si accorge di questo solo quando il pilota è terminato e la domanda "e adesso?" resta senza risposta, esattamente lo schema che si vede quando una demo senza proprietario non produce nulla.
Il quarto segnale è che è stata testata la tecnologia, ma non la struttura in cui questa deve funzionare. Ruoli, responsabilità, linee decisionali: sono rimasti invariati durante il pilota, ed è esattamente per questo che la tecnologia sovrapposta a una struttura immutata non produce nulla. Un pilota che non tocca la struttura verifica solo se la tecnologia funziona in un ambiente che non deve cambiare. È una domanda diversa dal chiedersi se l'organizzazione sia pronta a lavorarci.
L'ordine in cui si costruisce la maturità nell'AI non è arbitrario. L'organizzazione, l'infrastruttura IT e la gestione dei dati costituiscono la base su cui possono poggiare le dimensioni dipendenti — come il modo in cui le persone collaborano con l'AI o come vengono prese le decisioni. Un pilota che ignora questo ordine misura in realtà qualcosa di diverso da quello che afferma di misurare. Misura la creatività di un team in un determinato momento, non la maturità dell'organizzazione nel suo insieme.
È anche qui che un CEO e un COO guardano tipicamente in modo diverso. Ciò che un CEO osserva riguardo alla maturità dell'AI differisce da ciò che un COO valuta a riguardo, e un pilota senza un punto di misurazione stabilito in anticipo lascia entrambi senza appigli. La domanda non è se il pilota sia stato piacevole, ma se dice qualcosa sulle dimensioni che devono sostenere il resto.
La misurazione della maturità di hybridresourcing.com è pensata per rendere possibile quell'accordo preliminare. Cinque livelli, dal baseline all'intelligence, su sette dimensioni, con un giro di valutazione in cui più persone attribuiscono punteggi indipendentemente l'una dall'altra, così che emerga la dispersione invece di un'unica impressione data per verità assoluta. In questo modo si rende visibile dove l'organizzazione si trova realmente, prima di avviare un altro pilota che dovrà dimostrare a posteriori ciò che non è mai stato stabilito in anticipo.
Questa misurazione riguarda la domanda se l'organizzazione può sostenere l'AI: se le basi ci sono per far funzionare qualcosa in modo strutturale. Una volta risposto a questa domanda, si crea spazio per un'altra domanda, cioè quale parte del lavoro effettivo l'AI può assumere. A questa domanda risponde lo scan del lavoro di FTE TO AI, che calcola per ogni compito quale parte di esso può essere trasferita all'AI. Lo strumento per questa misurazione della maturità è in fase di sviluppo; chi desidera utilizzare la misurazione 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.