Kennisbank

Choisir un outil sans regret commence par l'ordre des choses

La question posée trop tôt

Qui veut choisir un outil pose généralement d'abord la mauvaise question. Pas « quel outil nous convient », mais « que doit réellement pouvoir faire cet outil, compte tenu de la façon dont nos données circulent actuellement ». Cette seconde réponse n'existe souvent pas encore au moment où la première question est posée. Il y a alors une liste de fournisseurs, quelques démonstrations, peut-être un rapport de conseil sur les leaders du marché. Il n'y a pas de réponse à la question de savoir quel point de donnée provient de quel système, qui en est responsable, et quelles règles de qualité devraient s'y appliquer.

L'ordre qui évite le regret est simple à formuler et difficile à suivre, car la pression d'acheter quelque chose est généralement plus forte que la sérénité nécessaire pour d'abord faire l'inventaire. D'abord le registre des points de données, la traçabilité de la source jusqu'au reporting, la propriété de chaque point de donnée. Ensuite seulement l'outil, et alors comme réponse à des exigences qui découlent de ce registre. Quelles exigences fonctionnelles découlent de votre propre processus n'est donc pas une question à laquelle un fournisseur répond pour vous, mais une question à laquelle vous devez déjà avoir répondu avant de parler à un fournisseur.

Ce que coûte l'ordre inversé

Un outil acheté avant que le processus ne soit établi est configuré sur des hypothèses. L'équipe d'implémentation du fournisseur s'informe sur des flux de données que personne ne peut reconstituer précisément, et la réponse est alors complétée sur la base de ce qui est probablement correct. Ces hypothèses ne disparaissent pas, elles deviennent partie intégrante du paramétrage. Le résultat est un outil qui fonctionne, en ce sens qu'il produit des rapports, mais ces rapports reposent sur les mêmes zones d'incertitude qu'auparavant — désormais simplement cachées derrière une interface qui inspire confiance.

Le coût de cet ordre inversé ne se limite pas à la licence. C'est le temps qu'il faut pour découvrir, un an plus tard, qu'un chiffre clé a été mal construit, et pour élucider cela dans un système qui n'a pas été conçu pour faciliter ce travail de recherche. Ce que coûte un outil au-dessus d'un processus non organisé dépend du nombre de points de données, du nombre de systèmes impliqués et de la durée pendant laquelle cela reste inaperçu — mais le poste de coût est réel, même s'il ne devient visible que tardivement.

Pourquoi ce n'est pas une question de préférence

Il est tentant de considérer l'ordre comme une question d'approche, où une organisation préfère d'abord tester un outil et une autre préfère d'abord faire des recherches. Ce n'est pas le cas. Un outil ne peut satisfaire correctement des exigences fonctionnelles que si ces exigences existent avant que l'outil ne soit choisi. Sans registre des points de données, il n'y a pas d'exigences, seulement des souhaits — plus rapide, plus clair, moins d'Excel. Les souhaits ne sont pas des critères de sélection, ce sont des images d'ambiance. Un fournisseur qui répond à des images d'ambiance répond à autre chose que ce dont l'organisation aura besoin six mois plus tard.

Acheter d'abord un outil ou d'abord organiser le processus n'est donc pas une question à deux réponses équivalentes. C'est une question dont l'ordre est déterminé par la nature du problème : des données qui n'ont pas été cartographiées ne peuvent pas être formulées comme exigence pour un progiciel. Cela vaut pour toute organisation, indépendamment du secteur ou de la taille, même si l'ampleur du travail de recherche varie. Dans une organisation où les données de durabilité dans la construction sont dispersées entre des administrations de projets, des sous-traitants et des feuilles de calcul isolées, ce travail de recherche est plus important que dans une organisation disposant de quelques systèmes centraux. Mais l'ordre ne change pas : d'abord voir où se trouvent les données et qui en est responsable, ensuite seulement un outil qui s'y raccorde.

Le regret est généralement un report, pas un mauvais choix

Le regret après l'achat d'un outil est souvent décrit comme un mauvais choix entre fournisseurs. C'est généralement autre chose : c'est le regret d'une organisation qui a déplacé un problème au lieu de le résoudre. L'outil fonctionne exactement comme acheté, et c'est bien le problème — il fonctionne sur la base d'un paramétrage qui n'a jamais été confronté aux flux de données réels. Comment choisir un outil sans regret ne dépend alors pas d'une liste restreinte plus longue ou d'un processus de démonstration plus étendu, mais de la réponse à une question qui précède l'achat : existe-t-il un registre des points de données, de la traçabilité et de la propriété par rapport auquel l'outil peut être évalué. Sans ce registre, chaque choix est un pari habillé d'apparences soignées.

Le pont vers le travail lui-même

Choisir un outil sur la base d'un processus bien organisé est une étape. L'autre étape consiste à savoir quelle partie du travail doit continuer à être effectuée par des personnes et quelle partie peut être reprise par l'automatisation, sans que la fiabilité des chiffres n'en souffre. Cette question dépasse le cadre d'un registre des points de données, mais en découle logiquement : ce n'est qu'une fois clairement établies les tâches existantes — collecter les données, les valider, les retracer jusqu'à la source, les rapporter — que l'on peut déterminer, tâche par tâche, quelle partie peut être confiée à l'IA. Le scan de travail de FTE TO AI calcule cela tâche par tâche, comme étape suivante une fois les données et le processus en ordre.