Un projet d'intelligence artificielle sans responsable métier — quelqu'un dont les objectifs annuels dépendent de l'amélioration du processus — n'aboutira jamais. Il peut disposer d'un excellent modèle, d'une équipe compétente et d'un budget suffisant, et pourtant stagner, car au moment de décider des exceptions, de défendre la phase suivante ou d'accepter un changement dans les méthodes de travail d'une équipe, personne n'aura l'autorité et la motivation nécessaires pour le faire.
C'est la cause de défaillance la moins technique et la plus fréquente.
Dans la plupart des projets, il existe un parrain exécutif : une personne qui a approuvé le budget et qui siège au comité de suivi. Ce n’est pas la même chose.
Rôle | Que fais-tu | Ce qu'il ne fait pas |
|---|---|---|
Parrainer | Approuve le budget et assure une protection politique | Décider sur des cas particuliers |
propriétaire d'entreprise | Responsable du résultat du processus | Écrire du code |
Responsable technique | Concevoir et exploiter le système | Déterminer ce qui est acceptable pour l'entreprise |
Utilisateur clé | Elle permet de bien comprendre le processus | Établir les priorités entre les départements |
Les quatre rôles sont nécessaires. Celui qui fait presque toujours défaut est le deuxième, et son absence se fait sentir à trois moments précis du projet.
Lorsque des exceptions apparaissent. Il faut bien que quelqu'un décide ce qui doit être automatisé et ce qui doit être géré par un humain. C'est une décision d'entreprise qui comporte des risques, et non un choix technique.
Quand une équipe a besoin de changer son mode de fonctionnement. La refonte des processus génère des retours sur investissement, mais elle suscite également des résistances. Sans l'autorité de la direction, ces résistances l'emportent.
Quand viendra le moment de défendre la phase suivante. Le passage du projet pilote à la production nécessite des financements supplémentaires et implique une décision risquée. Un responsable technique peut en défendre la pertinence ; seul un responsable commercial peut l’approuver.
Ce n'est la faute de personne ; c'est une évolution naturelle. L'initiative émane généralement des services d'innovation ou des systèmes, car ce sont eux qui maîtrisent la technologie. Le secteur d'activité collabore, mais ne se sent pas concerné, car son objectif annuel est différent.
Il en résulte un projet techniquement fonctionnel mais qui reste lettre morte. Lors de la revue budgétaire, il se trouve désavantagé par rapport aux initiatives soutenues par un directeur.
Le signal d'alarme est facile à détecter : Si, lorsqu'on demande « à qui appartient ce projet ? », la réponse est un département et non une personne, Le projet est menacé quelle que soit sa qualité technique.
C’est le propriétaire qui subit le problème, et non celui qui connaît la solution. Si le projet permet de réduire le temps de gestion des fichiers, le responsable est le directeur des opérations, et non le directeur des systèmes.
Leur objectif doit changer. Si le processus améliore un 30% et que son objectif annuel reste inchangé, il n'y a pas de véritable incitation. L'appropriation se manifeste dans la feuille de route, et non dans les procès-verbaux du comité.
Vous devez avoir autorité sur l'ensemble du processus. Si le processus passe par trois services et que le propriétaire n'en contrôle qu'un seul, les décisions seront bloquées aux frontières.
Vous devez pouvoir arrêter le projet. C'est la preuve irréfutable de propriété. Quiconque ne peut l'annuler ne peut pas non plus la défendre.
Il n'est pas nécessaire de tout réorganiser. Trois étapes :
Identifiez le poste budgétaire sur lequel figurerait l'avantage. Si le projet réduit les coûts de gestion d'un département, ce département en est le bénéficiaire naturel.
Proposez-lui le bien en incluant les unités métriques. Non pas « Accepterez-vous de prendre en charge ce projet ? », mais « Si cela fonctionne, votre coût par fichier diminuera de X ; êtes-vous prêt à vous engager sur ce chiffre ? ».
Transférer la décision de poursuivre. À partir de ce moment-là, la décision de poursuivre ou non le projet n'est plus prise par la technologie.
Si personne n'accepte le bien dans ces conditions, c'est un signe précieux : Ce projet ne résout probablement aucun problème qui préoccupe suffisamment qui que ce soit.. Le découvrir au cours de la troisième semaine coûte beaucoup moins cher que de le découvrir au cours du quatorzième mois.
Pour un département ayant plusieurs initiatives en IA en cours, il existe un examen qui nécessite une réunion et réorganise l'ensemble du portefeuille : Pour chaque projet, indiquez le nom de la personne dont la prime sera affectée en cas de succès..
Les projets portant ce nom sont ceux qui entreront en production. Ceux qui n'en portent pas sont candidats à devenir des projets pilotes permanents ; il est donc conseillé de décider dès maintenant s'il convient de leur attribuer un responsable ou de les abandonner.
Les deux décisions sont préférables à l'abandon du statu quo.
Il s'agit de la personne dont l'objectif repose sur l'amélioration du fonctionnement du processus concerné et qui est responsable du résultat, et non de la mise en œuvre de l'outil. Elle se distingue du commanditaire exécutif, qui approuve le budget et assure le financement, et du responsable technique, qui conçoit et exploite le système.
Car dans trois moments critiques, personne n'est là pour décider : lorsque des exceptions surviennent et qu'il faut déterminer ce qu'il faut automatiser, lorsqu'il faut changer le mode de fonctionnement d'une équipe, et lorsqu'il faut défendre le budget de mise en production face à d'autres initiatives.
La personne qui rencontre le problème, et non celle qui connaît la solution, est responsable. Si le projet permet de réduire le temps de gestion des fichiers, le responsable opérationnel en est le maître d'œuvre. De plus, il doit avoir autorité sur l'ensemble du processus et la possibilité d'interrompre le projet.
Il s'agit de vérifier que l'objectif annuel de la personne évolue en fonction des résultats du projet. L'appropriation de l'objectif est démontrée dans la fiche d'objectifs, et non dans le procès-verbal du comité de suivi.
Quatrièmement : quel niveau de succès est acceptable compte tenu du coût de l'erreur, quels cas sont automatisés et lesquels sont transmis à une personne, quels changements interviennent dans la façon dont l'équipe travaille et quel est le seuil en dessous duquel le projet s'arrête ?.
Identifiez le poste budgétaire où le bénéfice serait visible, confiez la responsabilité du projet à la partie concernée en précisant l'indicateur convenu, et transférez-lui la décision de poursuivre. Si personne n'accepte ces conditions, cela indique que le projet ne résout pas un problème suffisamment critique.
Vos projets d'IA ont-ils un responsable ou seulement un budget ? Nous vous aidons à définir le contexte commercial, les indicateurs de performance et les responsabilités avant tout développement. Deux heures d'analyse, sans engagement. Parlons-en →