Tirer une valeur commerciale de l'IA : comprendre le problème de l'entreprise


Après avoir planté le décor dans le dernier article, nous entamons maintenant notre série d'articles qui examinent les étapes à suivre pour s'assurer que nos projets d'IA atteignent mieux la valeur commerciale, le premier étant axé sur la compréhension du problème commercial. Une fois cette étape franchie, nous aborderons les thèmes suivants : s'adresser aux parties prenantes, adapter la solution à la logique de l'entreprise et gérer les projets d'IA.
C'est souvent en reliant une solution d'IA à un besoin de l'entreprise que l'IA échoue et ne parvient pas à atteindre son objectif d'ajouter de la valeur à l'entreprise. Si l'on prend l'exemple de l'apprentissage automatique, il peut être possible, dans l'abstrait, de construire de très bons modèles capables de prédire la probabilité que les clients se désabonnent (quittent un service ou un abonnement). Cependant, le problème peut être que l'entreprise n'a pas de moyen d'utiliser ces prédictions, ou que la valeur qu'elles apportent peut être disponible plus facilement, à moindre coût ou de manière plus efficace auprès d'une source différente. Il est peu probable que les modèles de ML (la même chose s'appliquant à d'autres formes d'IA, y compris l'IA générique) ajoutent de la valeur par eux-mêmes, simplement parce qu'ils existent. Ils doivent plutôt être en mesure de résoudre un problème commercial réel.
Pour y parvenir, les premières étapes d'un projet doivent être abordées comme un travail de détective : il existe une piste de preuves provenant de la documentation et des données, ainsi que des entretiens avec diverses personnes, qui, ensemble, indiquent ce que pourrait être le problème. Il se peut qu'il y ait différents points de vue sur le problème perçu, et que des points de vue tout aussi divers se reflètent dans les idées sur la solution à apporter. C'est là que nous, en tant qu'experts, devons aider le projet à naviguer dans cette situation pour trouver une solution appropriée.
Mais avant d'y parvenir, nous devons mettre notre chapeau de détective et préparer nos loupes pour comprendre le problème de l'entreprise. À quoi ressemble ce processus ? Il n'est jamais exactement le même, mais la figure 1 illustre ce à quoi il pourrait ressembler.

Comprendre le problème de l'entreprise
Dans le schéma ci-dessus, les deux premières étapes sont consacrées à l'exploration de l'espace du problème, à savoir "Comprendre le problème de l'entreprise" et "Comprendre le contexte".
En ce qui concerne la "compréhension du problème commercial", l'objectif est d'essayer de comprendre le problème autant que possible et de continuer jusqu'à ce que l'on ait l'impression de le comprendre de fond en comble.
Il est probable que l'on commence à un niveau assez élevé avec les principaux acteurs de l'entreprise (c'est-à-dire très probablement ceux qui contrôlent le budget et proposent le projet). Il faut ensuite s'attendre à une compréhension plus fine du problème en discutant avec les utilisateurs finaux de ce que vous comptez construire, ainsi qu'avec tous les praticiens qualifiés concernés. Ce processus devrait vous aider à connaître les points douloureux des différents acteurs de l'entreprise.
Ce point de vue est ensuite validé auprès d'un plus grand nombre de parties prenantes et les idées d'un état "à venir" imaginaire sont rassemblées. Une question intéressante à poser aux parties prenantes est "ce qu'elles aimeraient que la solution soit si elles pouvaient l'utiliser d'un coup de baguette magique".
Un aspect essentiel ici est de toujours valider ce que l'on vous dit ; un excellent moyen de validation est de s'inspirer des chercheurs ethnographiques et d'observer ce qui se passe réellement dans ces contextes d'entreprise. Après avoir pris en compte les différents points de vue, cela permet de dépasser les éventuels préjugés.
Comprendre le problème de l'entreprise à partir d'un éventail de perspectives n'est qu'un aspect. Les données pratiques et les contraintes techniques doivent également être comprises, ce qui peut être fait en parallèle. Au niveau le plus simple, il s'agit d'établir quelles sont les données disponibles et de comprendre le(s) système(s) existant(s) dans le(s)quel(s) la solution envisagée devrait s'intégrer.
Tout en collectant et en assimilant ces informations, il est également judicieux de commencer à les mettre en correspondance avec un prototype de solution. Voici quelques-unes des questions qu'il peut être utile de se poser à ce stade :
- Comment les éléments peuvent-ils être construits à l'aide de modèles ou d'approches d'IA existants ou communément compris (génératifs) ?
- Quel traitement ou quelle logique faudrait-il appliquer à ces résultats d'algorithme pour les rendre utilisables ?
- Comment combiner différentes sources de données ou sorties de modèles pour améliorer la solution ?
À ce stade, avec une meilleure compréhension du contexte, il peut également être utile de poser des questions pratiques à certaines des parties prenantes de l'entreprise sur la manière dont elles effectuent leurs tâches, ce qui contribuerait à la solution, comme par exemple : "Quelles hypothèses les praticiens compétents font-ils dans leur travail ?
- Quelles hypothèses les praticiens qualifiés font-ils dans leur rôle en accomplissant ces tâches ?
- Existe-t-il des règles empiriques que les praticiens compétents utilisent pour faire leur travail ?
Le développement de la solution sera sans aucun doute un processus itératif, avec des mises à jour ajoutées au fur et à mesure que de nouvelles informations sont disponibles. Toutefois, il est bon de présenter quelque chose aux principales parties prenantes le plus tôt possible afin d'identifier les éventuels malentendus et de s'assurer que les réactions - constructives ou non - sont recueillies. C'est au moment où l'on dispose d'une sorte de projet concret à partager avec les parties prenantes que l'on peut obtenir un retour d'information réel et pratique (ainsi que des "problèmes" évidents).
Au fil des itérations, et une fois qu'une version plus aboutie de la solution a été créée, une étape de contrôle formelle est prévue pour obtenir un retour d'information sur la solution proposée ("Valider la valeur de la solution"), l'élément clé étant la validation de la valeur offerte par cette solution.
Mesurer la valeur
La façon dont la valeur est mesurée dépend du cas d'utilisation, mais il s'agit essentiellement de savoir si l'action a permis de résoudre le problème de l'entreprise en question :
- la solution apportée au problème de l'entreprise en question est-elle satisfaisante ?
- les performances sont-elles acceptables ?
- Quel est le coût par rapport à l'approche existante ?
- Peut-on le faire plus facilement, à moindre coût ou plus efficacement en utilisant d'autres méthodes ?
Sur la base de cette évaluation, nous pouvons prendre une décision quant à l'intérêt pour l'entreprise de poursuivre l'itération de la solution proposée ("Idéation et développement de la solution") ou quant à la nécessité de poursuivre l'itération pour comprendre les systèmes et les données ou le problème de l'entreprise ("Comprendre le problème de l'entreprise" et "Comprendre le contexte"). Les étapes mentionnées dans cette section impliquent implicitement la nécessité de travailler en étroite collaboration avec les parties prenantes, car sans elles, il aurait été pratiquement impossible d'aller aussi loin. C'est un point que nous aborderons plus en détail dans le prochain article.
En résumé
Pour commencer à tirer profit de l'IA, nous devons d'abord comprendre quel est exactement le problème que nous essayons de résoudre et, à l'aide de ces informations et de celles relatives au contexte de l'entreprise, nous pouvons ensuite concevoir des solutions possibles. Dans cet article, nous avons identifié des exemples d'étapes nécessaires ainsi que des questions utiles à poser, qui nous aideront à progresser dans cette voie.
Dans cet article, nous avons identifié des exemples d'étapes nécessaires ainsi que des questions utiles à poser, qui nous aideront à progresser dans cette voie.
