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.