Perché i tuoi piloti AI continuano a bloccarsi prima della spedizione?
I piloti AI che non raggiungono mai la produzione svuotano più del loro budget. Ecco il vero costo e come fermare il ciclo.
Le aziende che sperimentano con l'AI hanno spesso un cimitero
È una cartella piena di presentazioni, alcuni canali Slack inattivi e tre o quattro progetti pilota che hanno funzionato abbastanza bene durante una demo per poi spegnersi silenziosamente. Nessuno li ha uccisi. Semplicemente non sono mai passati alla fase di utilizzo quotidiano.
La storia comoda è che si trattava di esperimenti economici, quindi la perdita è minima. Questa storia è sbagliata. Un progetto pilota che non raggiunge mai la produzione costa molto di più della fattura per la sua costruzione, e i costi più grandi non appaiono nemmeno sulla fattura.
Cosa spende effettivamente un progetto pilota
Iniziamo con ciò che possiamo contare. Un progetto pilota consuma ore di ingegneria, tariffe dei fornitori e l'attenzione delle persone che hanno accettato di testarlo. Ma le persone che testano un pilota sono raramente risorse libere. Di solito sono i tuoi operatori più forti, perché sono quelli che comprendono bene il processo al punto da giudicare se l'AI ha aiutato. Ogni ora che trascorrono valutando uno strumento che non produce nulla è un'ora sottratta al lavoro che solo loro possono fare.
Poi c'è il lavoro sui dati. La maggior parte dei progetti pilota seri richiede qualcuno che pulisca i registri, etichetti gli esempi o colleghi una connessione a un sistema vivo. Questo sforzo è reale e duraturo - ma solo se il progetto pilota viene completato. Quando si ferma, i dati puliti diventano obsoleti e l'integrazione viene disattivata. Hai pagato per costruire un asset e poi lo hai fatto scadere.
I costi che non appaiono nel bilancio
La parte costosa è ciò che un progetto pilota fermo fa a chiunque ne sia stato testimone.
La prima vittima è la credibilità. Quando uno strumento promettente viene mostrato al team e poi scompare, le persone imparano che i progetti sull'AI sono teatro. La prossima volta che proporrai un altro progetto, gli operatori più forti - gli stessi di cui hai bisogno - opteranno per l'astensione, perché hanno visto come finisce. Non inizi da zero il prossimo pilota; parti da sottozero, contro lo scetticismo accumulato che tu stesso hai creato.
La seconda vittima è il tempismo. Mentre il tuo progetto pilota era in stallo, i modelli di base continuavano a migliorare e i tuoi concorrenti spedivano le loro soluzioni. Il vantaggio che speravi di catturare non era nella demo. Era nei mesi di apprendimento cumulativo che iniziano solo quando gli utenti reali dipendono dal sistema. Un progetto pilota che non viene mai distribuito non ti garantisce nessuno di questi vantaggi.
Perché i progetti pilota si fermano?
I progetti pilota raramente falliscono perché la tecnologia non funziona. Si fermano per motivi presenti prima che una singola riga di codice venisse scritta:
- Mancanza di un proprietario con autorità per distribuirlo. Un progetto sponsorizzato dall'"innovazione" ma non dal team che lo gestirebbe non ha una via d'accesso alla produzione.
- Non è mai stata definita una successo. Se nessuno ha concordato in anticipo il risultato che giustificherebbe il rilascio, ogni risultato sembra interessante e meritevole di ulteriori esplorazioni.
- L'ultimo miglio era fuori ambito. Permessi, monitoraggio, gestione degli errori e supporto sono trattati come pensieri successivi, quindi un prototipo funzionante è ancora a mesi dall'essere sicuro da affidare.
- Il progetto pilota ha risolto una demo, non un lavoro reale. Gestiva in modo impressionante il caso pulito e ignorava il 30% disordinato che costituisce la maggior parte del lavoro effettivo.
Notate che nessuno di questi è un problema legato al modello. Sono decisioni relative alla proprietà, all'ambito e all'impegno - prese all'inizio.
Esegui i progetti pilota come se dovessero essere distribuiti
La soluzione consiste nel smettere di trattare un progetto pilota come una questione relativa alla tecnologia e iniziare a considerarlo la prima fase della produzione. Prima di iniziare, nomina la persona che sarà responsabile dello strumento in produzione e dale il potere di veto. Scrivi il numero singolo che giustificherà il rilascio e quello che attiverà uno spegnimento pulito. Includi il lavoro dell'ultimo miglio - accesso, monitoraggio, fallback quando il modello sbaglia - all'interno del progetto pilota, non dopo di esso. Scegli un flusso di lavoro reale con volumi reali, non una vetrina.
Questo è più lento da avviare, ed è proprio questo il punto. Un numero minore di progetti pilota costruiti per essere distribuiti supererà una pipeline affollata di esperimenti che rimangono nel laboratorio, sia in termini di risultati che di fiducia mantenuta con il tuo team.
In Hercules A, questa è la prima cosa che controlliamo quando uno sforzo AI di un cliente si è fermato - non un modello migliore, ma un proprietario mancante e una linea di arrivo indefinita. La tecnologia è raramente l'ostacolo.
Un progetto pilota non è un successo perché ha funzionato. È un successo perché le persone vi sono venute a dipendere e noterebbero la sua assenza. Qualsiasi cosa al di sotto di questo è un costo che hai già pagato e non hai ancora conteggiato.