L'ordre habituel est le suivant : sélectionner un outil, configurer l'outil, puis espérer que le processus s'y adaptera. Cela ne fonctionne pas dans la pratique, car un outil n'apporte pas de processus avec lui. Un outil apporte des champs, des connexions, des tableaux de bord — mais pas la réponse à la question de savoir qui, dans votre organisation, est responsable de la consommation d'énergie du bâtiment trois, ou si le responsable des installations qui fournit ce chiffre sait qu'il aboutira dans le rapport scope 2.
Le bon ordre est inversé : décrire d'abord le processus, puis seulement choisir un outil sur la base de ce dont ce processus a besoin. Cela ressemble à un détour, mais c'est le chemin le plus court, car chaque exigence fonctionnelle que vous imposez à un outil doit provenir de quelque part dans votre propre organisation de données. Sans ce point de départ, vous sélectionnez sur la base de fonctionnalités qu'un fournisseur juge importantes, pas de fonctionnalités qui résolvent votre point de blocage.
Les coûts du mauvais ordre ne sont pas immédiatement visibles, car un outil qui ne correspond pas fonctionne d'abord parfaitement bien — pour la partie du processus qui coïncide par hasard avec ce que l'outil attend. Le reste est construit manuellement autour : une annexe Excel ici, un échange d'e-mails là, un collaborateur qui sait exactement quelle étape échappe au système. Cela fonctionne, jusqu'à ce que ce collaborateur parte ou que le volume de données augmente.
Ce que cela coûte dépend du nombre de points de données qui circulent en dehors de l'outil et de la fréquence à laquelle ceux-ci doivent être recollectés manuellement à chaque cycle de rapportage. Pour un petit nombre de points, c'est un détour acceptable. Pour un nombre croissant — davantage de sites, davantage de catégories scope 3, davantage de réglementations qui s'ajoutent — le détour devient l'itinéraire principal, et vous payez structurellement pour l'inadéquation entre l'outil et le processus. C'est une autre façon de dire ce qui figure également sur cette page : un outil superposé à un processus non organisé produit des rapports plus soignés sur les mêmes chiffres peu fiables.
Une exigence fonctionnelle n'est une exigence que si elle découle de quelque chose. « L'outil doit pouvoir afficher la traçabilité (lineage) » n'est pas une exigence tant que vous ne savez pas que votre contrôleur doit rechercher manuellement trois fois par an d'où provient un chiffre. « L'outil doit pouvoir enregistrer la responsabilité (ownership) » n'est pas une exigence tant que vous n'avez pas constaté qu'un point de données sans propriétaire ne figure sur la liste d'actions de personne.
C'est précisément pourquoi le registre des points de données, la traçabilité source-to-report par point de données, et l'attribution de la responsabilité doivent d'abord exister, indépendamment de l'outil que vous choisirez finalement. Une fois que ces trois éléments sont couchés sur papier — quel point de données, d'où il provient, qui en est responsable — vous disposez d'une liste d'exigences qui ne provient pas d'un fournisseur mais de votre propre organisation. Vous utilisez cette liste pour comparer des outils, pas pour en choisir un aveuglément. La manière d'aborder cette comparaison sans regret est décrite sur cette page consacrée à la sélection d'outils.
L'endroit où se trouvent les données varie fortement selon le secteur, ce qui déterminet aussi quelles exigences fonctionnelles sont pertinentes. Dans une entreprise de construction, une grande partie des données de durabilité se trouve chez les sous-traitants et sur le chantier lui-même, comme décrit sur cette page consacrée aux sources de données dans la construction ; une exigence relative à de multiples sources externes par projet y est probablement plus importante que dans d'autres secteurs. Dans le secteur de l'installation technique, les données sont plus souvent dispersées entre bons de service et registres de matériaux au niveau du projet, comme on peut le lire sur cette page consacrée au secteur de l'installation technique ; ce qui compte surtout là, c'est de savoir si un outil peut regrouper des points de saisie distincts sans que quelqu'un doive le faire manuellement.
La question générale — organiser d'abord le processus ou acheter d'abord un outil — est développée plus en détail sur cette page, et la question centrale de cette page, à savoir quelles exigences découlent précisément de votre propre processus, est résumée sur cette page. Ces deux pages partent du même point : c'est l'ordre qui détermine si une exigence est une exigence, ou un pari.
Le Data Readiness Scan établit le registre des points de données, la traçabilité et la responsabilité avant même qu'il ne soit question d'un outil. Ce n'est ni un outil de rapportage ni une solution de questionnaire — c'est l'étape qui déterminet ce qu'un outil doit réellement pouvoir faire pour votre organisation. Sans cette étape, vous achetez des fonctionnalités ; avec cette étape, vous achetez une solution à un problème que vous pouvez identifier précisément.
Le scan est en cours de développement. Toute personne souhaitant faire cartographier son processus de cette manière avant qu'un choix d'outil ne soit fait peut s'inscrire sur la liste d'attente et sera informée dès que le scan sera disponible.
Dès que le registre des points de données est établi et qu'il est clair de quelle source provient chaque point de données et qui en est responsable, une deuxième question, naturelle, se pose : quelle partie du travail qui l'entoure — la collecte, le contrôle et le transfert des chiffres — relève encore du travail humain, et quelle partie un système peut-il reprendre sans que la fiabilité en pâtisse. C'est à cette question que répond le scan de travail de FTE TO AI, qui calcule, tâche par tâche, quelle part du travail peut être reprise par l'IA. C'est un scan différent du Data Readiness Scan, et une suite logique à celui-ci : d'abord savoir ce que sont les données et d'où elles viennent, puis seulement examiner quelle partie du travail manuel qui les entoure peut devenir superflue.
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.