Un outil est souvent acheté comme première étape : il y a une pression, il y a une échéance, il y a un fournisseur avec une démonstration convaincante. La question qui est rarement posée : y a-t-il déjà quelque chose au-dessus de quoi cet outil peut se placer ? Un outil n'organise rien par lui-même. Il montre, calcule et structure ce que vous y introduisez. Si les données sous-jacentes n'ont pas été consignées — pas de registre des points de données, pas de provenance établie, pas de propriétaire désigné par chiffre — alors vous obtenez un outil qui affiche proprement ce qui reste en réalité des feuilles de calcul isolées et des hypothèses isolées.
L'outil lui-même fonctionne généralement très bien. Le problème se situe dans ce qui y est introduit. Un tableau de bord qui affiche la consommation d'énergie par site vaut ce que valent les données qu'il reçoit. Si personne n'a établi quel service fournit ces chiffres, avec quels fichiers source, selon quelle règle de calcul, alors l'outil comble un vide avec une estimation, un mauvais lien, ou un chiffre qu'un collègue a saisi une seule fois il y a trois ans et qui n'a plus jamais été mis à jour. L'outil ne le signale pas lui-même. Il continue simplement de calculer.
Le coût de cet ordre ne se résume pas en un seul chiffre, et c'est précisément là l'enjeu : il est diffus et disséminé. Du temps à nouveau consacré à retrouver l'origine d'un chiffre, après qu'il figurait déjà dans l'outil. Des discussions entre la finance et le développement durable sur qui a fourni quel chiffre. Un contrôleur qui doit admettre, lors du premier contrôle externe, que la provenance d'un indicateur clé ne peut être reconstituée. Une mise en œuvre qui doit être refaite, en partie ou entièrement, parce que la structure des données n'avait pas été conçue pour cela. Sur cette page, la question centrale elle-même est développée plus en détail : quel ordre est logique et pourquoi précisément celui-là.
Un outil se choisit sur la base de sa fonctionnalité : peut-il traiter les bons points de données, correspond-il à la bonne norme de reporting, la structure de reporting est-elle suffisamment flexible pour ce qui va encore changer. Ces exigences ne peuvent pas se formuler dans l'abstrait. Elles découlent de ce qui existe déjà comme données, de qui gère ces données, et des lacunes qui existent. Sans cette vue d'ensemble, l'outil est choisi sur ce que le fournisseur montre lors d'une démonstration, et non sur ce dont votre organisation a besoin. Les exigences fonctionnelles qui découlent effectivement de votre propre situation sont expliquées sur cette page sur les exigences fonctionnelles issues du processus propre.
L'ordre inversé — l'outil d'abord, le processus ensuite — conduit à un second achat, une migration, ou un outil qui est en permanence complété par les feuilles de calcul qu'il aurait dû remplacer. Quiconque se retrouve une fois dans cette spirale constate que l'outil ne résout pas le problème qu'il devrait résoudre : des données peu fiables, introuvables ou non gérées. Il déplace le problème vers une interface plus élégante.
Organiser au préalable n'est pas un exercice bureaucratique. C'est un registre : quels points de données sont nécessaires pour le reporting, d'où viennent-ils, par quels systèmes ou feuilles de calcul se déplacent-ils vers le chiffre final, qui est responsable de leur exactitude, et quelle règle de qualité s'applique pour signaler une erreur à temps. Ce registre existe indépendamment de l'outil qui sera placé au-dessus par la suite. C'est la base sur laquelle un outil fonctionne, quel que soit le fournisseur choisi.
Pour éviter que la seconde erreur ne soit identique à la première, il est utile de savoir comment choisir un outil sans regret : les étapes qui s'y rattachent sont présentées sur cette page sur la sélection d'un outil sans regret. Pour les organisations de secteurs spécifiques, il est en outre utile de voir d'où proviennent concrètement les données de durabilité : dans le secteur de la construction, elles se trouvent souvent réparties entre les administrations de projet et les sous-traitants, comme décrit sur cette page sur les données de durabilité dans la construction, et dans le secteur de l'installation, elles sont réparties différemment, comme expliqué sur cette page sur les données de durabilité dans le secteur de l'installation.
Le Data Readiness Scan établit ce registre avant même qu'il soit question d'un outil : pour chaque point de données, la provenance, le propriétaire et la règle de qualité. Pas un rapport, pas un questionnaire complété, mais la structure sur laquelle un rapport ou un questionnaire pourra s'appuyer plus tard. L'outil est en cours de développement ; toute personne intéressée peut s'inscrire sur la liste d'attente.
Dès qu'il est clair quels points de données existent, d'où ils proviennent et qui les gère, une image plus précise se dessine également du travail qui l'entoure : qui collecte, qui contrôle, qui consigne. Ce travail ne se prête pas partout de la même manière à l'automatisation. Le scan de travail de FTE TO AI calcule, par tâche, quelle part peut effectivement être reprise par l'IA, sur la base de ce que cette tâche implique précisément et non sur la base d'une estimation générale relative au secteur.
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.