È prevista una demo. Un fornitore o un team interno mostra cosa può fare un'applicazione AI: un chatbot che risponde alle domande dei clienti, uno strumento che riassume report, un assistente che scrive codice. La sala è entusiasta. Si annuisce, si fanno domande, qualcuno dice che questo è "davvero qualcosa per noi". Una settimana dopo l'energia è svanita e non succede più nulla.
La trappola non è la demo in sé. La trappola è che una demo viene tenuta senza che sia stato stabilito in anticipo chi, dopo, è responsabile di ciò che accade con il risultato. C'è una presentazione, non un proprietario di processo. C'è una reazione, non una decisione. C'è attenzione, non un'agenda.
Organizzare una demo sembra intraprendere un'azione. Si mostra qualcosa, si reagisce, si vede del movimento. In un'organizzazione sotto pressione per fare qualcosa con l'AI, quel movimento ha già valore: dimostra che non si sta con le mani in mano. Una demo costa poco, è veloce da pianificare e produce subito una storia condivisibile con una direzione o un consiglio di amministrazione.
Inoltre, organizzare una demo è più facile che assegnare un eigenaarschap (proprietà). Una demo richiede uno slot di tempo in un'agenda. L'eigenaarschap richiede qualcuno a cui vengono assegnati budget, tempo e mandato per rispondere di un risultato, anche quando quel risultato delude. Quest'ultima è una questione politica, non operativa. Pianificare una demo è più facile che porre quella domanda, quindi si pianifica la demo e si salta la domanda.
Il risultato è che una demo diventa un sostituto di una decisione invece che uno spunto per una decisione. Finché nessuno chiede chi sarà il responsabile in seguito, la demo resta una presentazione senza seguito.
Ci sono alcuni segnali riconoscibili. Dopo la demo si applaude, ma non viene fatto alcun nome di chi porta avanti l'iniziativa. Si parla di "andiamo avanti a guardare" senza che sia stabilito chi fa quel guardare e quando quella persona torna con un risultato. La demo viene ripetuta entro poche settimane per un altro reparto, con la stessa reazione e la stessa mancanza di seguito.
Un altro segnale è che la discussione dopo la demo verte sulla tecnologia — quanto è abile lo strumento, cosa sa fare — invece che sull'organizzazione che dovrebbe utilizzarlo. Questo è un segno che si salta la domanda se la struttura esistente possa sostenere l'applicazione. Cosa significhi questo lo si legge in perché la tecnologia sopra una struttura immutata non produce alcun risultato.
Anche riconoscibile: la demo è sostenuta da due persone che sono esse stesse entusiaste dell'AI, mentre il resto dell'organizzazione resta spettatore. Non appena queste due persone si trovano impegnate con altro lavoro, l'iniziativa si ferma, perché nessun altro si sente responsabile. Questa dinamica è descritta in perché due entusiasti e nessun altro non produce alcun risultato.
Un ultimo segnale: dopo la demo si decide per un pilot, ma nessuno ha concordato in anticipo su cosa quel pilot verrà valutato. Senza quell'accordo, un pilot è una demo prolungata — mostra qualcosa, ma non dimostra nulla. Questo schema è approfondito in perché un pilot senza un accordo su cosa deve emergere non produce alcun risultato.
Una demo senza responsabile non è un errore nella demo, ma un errore nella sua preparazione. Prima di pianificare una demo, si può stabilire chi, in seguito, prende in carico il risultato, chi decide se ci sarà un seguito ed entro quale termine quella decisione viene presa. Questa non è una condizione tecnica ma organizzativa, e quella condizione precede la domanda su quale strumento dimostri meglio.
Quest'ordine — prima l'organizzazione, poi la tecnologia — è esattamente dove si arenano la maggior parte delle iniziative AI. Chi vuole sapere se la propria organizzazione ha già queste fondamenta trova una panoramica dettagliata per ruolo in a cosa presta attenzione un CEO riguardo alla maturità AI e a cosa presta attenzione un COO riguardo alla maturità AI.
Una demo mostra cosa può fare una tecnologia, ma non dice nulla su cosa significhi ciò per il lavoro nella propria organizzazione. Non appena è chiaro chi è responsabile di un'iniziativa AI e le basi sono pronte, sorge la domanda su quale parte del lavoro effettivo sia davvero possibile automatizzare. A questa domanda non risponde una demo, ma un calcolo strutturato per singola attività. La werkscan di FTE TO AI fa esattamente questo: calcola per ogni attività quale parte del lavoro può essere svolta dall'AI, così che un responsabile possa decidere con dati concreti, invece che con impressioni, cosa vale la pena portare avanti.
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.