Pourquoi vos pilotes d'IA continuent de stagner avant leur mise en service

La plupart des entreprises qui expérimentent l'IA ont un cimetière. C'est un dossier de présentations, quelques canaux Slack inactifs et trois ou quatre projets pilotes qui ont bien fonctionné lors d'une démonstration, puis se sont tranquillement arrêtés. Personne ne les a tués. Ils sont simplement jamais passés dans la phase d'utilisation quotidienne.

L'histoire confortable est que ces expériences étaient peu coûteuses, donc les pertes sont minimes. Cette histoire est erronée. Un projet pilote qui ne atteint jamais la production coûte bien plus que la facture pour sa construction, et les plus grandes dépenses ne figurent même pas sur la facture.

Ce que dépense réellement un projet pilote

Commencez par ce que vous pouvez compter. Un projet pilote consomme des heures de travail d'ingénieurs, des frais de prestataires et l'attention des personnes qui ont accepté de le tester. Mais les personnes qui testent un projet pilote sont rarement des ressources libres. Elles sont généralement vos opérateurs les plus forts, car ce sont celles qui comprennent bien le processus pour juger si l'IA a été utile. Chaque heure qu'elles passent à évaluer un outil qui ne produit rien est une heure retirée du travail qu'elles seules peuvent faire.

Il y a ensuite le travail sur les données. La plupart des projets pilotes sérieux nécessitent quelqu'un pour nettoyer les dossiers, étiqueter les exemples ou mettre en place une connexion avec un système en direct. Cet effort est réel et durable - mais seulement si le projet pilote est lancé. Lorsqu'il stagne, les données nettoyées deviennent obsolètes et l'intégration est désactivée. Vous avez payé pour construire un actif et puis l'avez laissé expirer.

Les coûts qui ne figurent pas dans la comptabilité

La partie coûteuse est ce qu'un projet pilote arrêté fait à toutes les personnes qui l'ont observé.

La première victime est la crédibilité. Lorsqu'un outil prometteur est présenté à une équipe puis disparaît, les gens apprennent que les projets d'IA sont un spectacle. La prochaine fois que vous proposerez un projet, les opérateurs les plus forts - ceux dont vous avez besoin - opteront pour l'éviter, car ils ont vu comment cela se termine. Vous ne commencez pas le prochain pilote à zéro. Vous commencez depuis en dessous de zéro, contre un scepticisme accumulé que vous avez créé vous-même.

La deuxième victime est le timing. Pendant que votre projet pilote était dans une impasse d'évaluation, les modèles sous-jacents s'amélioraient et vos concurrents livraient leurs produits. L'avantage que vous espériez saisir n'était pas dans la démonstration. Il était dans les mois de l'apprentissage cumulatif qui ne commencent qu'une fois que le système dépend réellement des utilisateurs. Un projet pilote qui ne est jamais lancé ne vous procure aucun de ces avantages.

Pourquoi les projets pilotes stagnent-ils ?

Les projets pilotes échouent rarement parce que la technologie ne fonctionne pas. Ils stagnent pour des raisons présentes avant qu'une seule ligne de code ne soit écrite :

• Aucun propriétaire avec l'autorité de le lancer. Un projet pilote sponsorisé par "l'innovation" mais pas par l'équipe qui le gérerait n'a aucune voie vers la production.
• Le succès n'a jamais été défini. Si personne n'a convenu à l'avance du résultat justifiant le déploiement, tout résultat semble "intéressant, continuons à explorer."
• La dernière étape était hors champ. Les permissions, la surveillance, la gestion des erreurs et le support sont traités comme des pensées ultérieures, donc un prototype fonctionnel est encore loin d'être sûr de dépendre.
• Le projet pilote a résolu un cas propre, pas un travail réel. Il a géré impressionnamment le cas propre et ignoré les 30% sales qui constituent la majeure partie du travail réel.

Remarquez que aucune de ces situations ne sont des problèmes liés au modèle. Ce sont des décisions concernant la propriété, l'étendue et l'engagement - prises dès le début.

Lancez vos projets pilotes comme s'ils devaient être déployés

La solution consiste à cesser de traiter un projet pilote comme une question sur la technologie et commencer par le considérer comme la première phase de la production. Avant de commencer, désignez la personne qui sera responsable de l'outil en production et donnez-lui un droit de veto. Écrivez le nombre unique qui déclenchera le déploiement et celui qui déclenchera une fermeture propre. Intégrez les travaux de dernière étape - accès, surveillance, recours lorsque le modèle est erroné - dans le cadre du projet pilote, pas après. Choisissez un flux de travail réel avec un volume réel, pas une vitrine.

Cela prend plus de temps pour démarrer, et c'est l'objectif. Un plus petit nombre de projets pilotes construits pour être déployés surpassera un pipeline occupé d'expériences qui ne quittent jamais le laboratoire, tant en termes de résultats qu'en termes de confiance que vous gardez avec votre équipe.

Chez Hercules A, c'est la première chose que nous recherchons lorsque les efforts d'IA d'un client ont stagné - non pas un modèle amélioré, mais un propriétaire manquant et une ligne d'arrivée indéfinie. La technologie est rarement le goulot d'étranglement.

Un projet pilote n'est pas une réussite parce qu'il a fonctionné. Il est une réussite parce que les gens sont venus dépendre de lui et remarqueraient son absence s'il disparaissait. Tout autre chose est un coût que vous avez déjà payé et que vous n'avez pas encore comptabilisé.