Un fournisseur demande tôt ou tard : que doit pouvoir faire le système ? La réponse ne se trouve pas chez le fournisseur, ni dans une liste de fonctionnalités que d'autres entreprises ont également cochées. La réponse se trouve dans votre propre processus : quels points de données vous collectez, qui les fournit, d'où ils proviennent, et ce qui se passe quand personne ne vérifie.
La voie habituelle consiste à sélectionner un outil, à le configurer, puis à découvrir seulement après quelles données doivent venir d'où. Cet ordre produit l'effet inverse, car un outil n'a pas d'avis sur votre processus. Il demande des entrées, et ces entrées doivent provenir de quelque chose. Si ce quelque chose — le registre des points de données, les responsabilités, les sources — n'existe pas encore, la configuration de l'outil devient une recherche que personne n'avait prévue.
L'autre ordre commence par le processus. D'abord cartographier quels points de données sont nécessaires, qui les fournit, de quel système ou de quelle feuille de calcul ils proviennent, et quelles règles de qualité s'y appliquent. Ce n'est qu'ensuite qu'il devient clair quelles exigences un outil doit réellement remplir. Pas des exigences abstraites comme « convivial » ou « évolutif », mais des exigences concrètes telles que : devoir se connecter à ce système source spécifique, devoir distinguer trois responsables au sein d'un même point de données, devoir signaler un écart lorsqu'un chiffre sort d'une marge déterminée à l'avance.
L'ordre n'est pas une préférence de méthode ; il découle de ce qui précède fonctionnement logiquement l'outil. Un outil ne peut recevoir des exigences que s'il existe quelque chose auquel les rattacher. Ce quelque chose, c'est le processus : le flux de données de la source au rapport, avec toutes les étapes manuelles, les transmissions et les hypothèses qui l'accompagnent. Sans cette vue d'ensemble, une organisation formule ses exigences en fonction de ce qu'un outil peut faire, et non de ce dont le processus a besoin. Cela peut sembler une différence subtile, mais elle détermine si l'outil correspondra ensuite à la réalité ou s'en écartera.
Ceci rejoint la question de savoir comment choisir un outil sans le regretter après coup : le regret naît souvent non pas d'un mauvais outil, mais d'un outil qui a dû deviner des exigences parce que personne ne les avait consignées.
Lorsque l'outil vient d'abord et le processus ensuite, deux types de coûts apparaissent. Le premier est une reconfiguration directe : des fonctionnalités qui ne correspondent pas, des connexions qui doivent encore être construites, des champs qui restent vides parce que personne ne sait qui doit les remplir. Le second coût est moins visible mais plus lourd : l'outil se met à produire des rapports plus soignés en apparence, alors que les chiffres qui les sous-tendent restent introuvables jusqu'à une source ou un responsable. Ce risque est décrit plus en détail sur la page consacrée à ce que coûte le fait de placer un outil au-dessus d'un processus non organisé : l'outil masque le problème au lieu de le résoudre.
La question de savoir quel ordre revient moins cher dépend du nombre de points de données, de systèmes et de responsables déjà présents, et de la part de ceux-ci qui n'est pas encore consignée. Pour un processus de petite taille avec peu de sources, les dégâts de l'ordre inversé restent limités. Pour un processus réparti sur plusieurs services, systèmes et feuilles de calcul, ces dégâts s'accroissent à chaque point de données qui n'a pas été clarifié avant que l'outil ne le demande. Cet arbitrage est développé sur la page acheter d'abord un outil ou d'abord organiser le processus : ce que cette différence coûte.
Avant qu'un outil puisse recevoir des exigences, il faut disposer d'un aperçu des points de données nécessaires à la rapportage, de la provenance de chaque point de données, du responsable de son exactitude, et de la règle qui permet de déterminer si une valeur est plausible. Cet aperçu n'est pas un document technique ni un outil en soi ; c'est un registre qui constitue la base de chaque étape suivante, que cette étape soit un outil, un processus manuel, ou une combinaison des deux.
La question de savoir quelles exigences fonctionnelles en découlent est donc en réalité la question suivante : que contient ce registre, et qu'est-ce qui manque encore ? Tant que cette question reste sans réponse, chaque exigence posée à un outil reste un pari. Ce lien entre les exigences et le processus sous-jacent est développé plus en détail sur la page consacrée à quelles exigences fonctionnelles découlent de votre propre processus et ce que coûte un mauvais ordre dans ce domaine.
Une fois le registre des points de données et les responsabilités mis en ordre, la question se déplace : il ne s'agit plus de savoir ce qu'un outil doit pouvoir faire, mais de savoir ce qui arrive aux personnes qui effectuent aujourd'hui ce travail : la collecte, le contrôle et la retranscription de chiffres issus de feuilles de calcul et de systèmes. Une partie de ces tâches est répétitive et suit des règles fixes, et c'est précisément le genre de travail dont une partie peut être reprise par l'IA. Le [scan de travail de FTE TO AI](https://ftetoai.nl) calcule, par tâche, quelle part peut être automatisée, ce qui permet de voir clairement où les personnes restent nécessaires et où le travail peut être transféré à un système qui contrôle et fournit les données selon des règles fixes.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.