Il n'y a pas de pénurie de logiciels pour le reporting de durabilité. Il y a en revanche une pénurie d'organisations qui savent à l'avance ce qu'elles doivent demander à un outil. C'est ce dernier point qui constitue le véritable problème, et cela explique pourquoi tant d'implémentations sont abandonnées après un an ou restent silencieusement en suspens.
Un outil est un instrument qui exécute ce qu'on lui soumet. Il demande des points de données, relie des sources, calcule et rapporte. Ce qu'il ne fait pas, c'est déterminer quels points de données votre organisation a réellement besoin, qui en est responsable, et d'où viennent actuellement les chiffres. Ce travail se situe avant l'outil, pas dans l'outil.
L'ordre n'est donc pas arbitraire : d'abord savoir ce que vous avez et où cela se trouve, puis choisir ce qui correspond. L'inverse ne fonctionne pas, car un outil n'apporte pas de structure à quelque chose qui n'en a pas encore. Il ne fait, au mieux, que poser une interface sur le chaos. Cette page et la page correspondante pour le secteur de l'installation expliquent pourquoi ce chaos est en pratique aussi dispersé : à travers l'ERP, les factures, les feuilles de calcul du responsable des installations et les échanges de courriels avec les fournisseurs.
Quiconque sélectionne d'abord un outil et ne découvre qu'ensuite quelles données existent en interne se heurte à un schéma récurrent. L'implémentation prend plus de temps que prévu, car il s'avère qu'à mi-parcours il faut encore déterminer qui fournit quel chiffre. L'outil est rempli de ce qui est disponible par hasard, et non de ce qui est complet ou vérifiable. Et dès que le comptable ou un auditeur demande d'où vient un chiffre, il n'y a d'autre réponse que « c'était dans le système ».
Ce coût ne peut pas être exprimé en pourcentage — cela dépend de l'organisation, du nombre de départements concernés et du nombre de points de données qui étaient déjà identifiés. Le schéma est en revanche reconnaissable : un second projet pour cartographier après coup les sources et la responsabilité, alors que l'outil est déjà en fonctionnement. Ce second projet aurait été nécessaire même sans outil, et aurait pu être mené plus tôt. Une analyse plus détaillée de ce poste de coût figure sur la page consacrée à ce que coûte réellement un outil au-dessus d'un processus non organisé.
L'inversion n'est pas compliquée, seulement inhabituelle. Vous commencez par cartographier quels points de données votre reporting exige, d'où ils proviennent actuellement, qui en est responsable et quelles règles de qualité s'y appliquent ou non. Cet aperçu — un registre des points de données avec une traçabilité de la source jusqu'au rapport — est indépendant de l'outil que vous choisirez finalement. Mieux encore, cet aperçu est ce qui permet réellement de déterminer les exigences que vous pouvez poser à un outil. Sans cet aperçu, vous achetez un système sur la base d'une démonstration et d'un entretien commercial ; avec cet aperçu, vous achetez un système sur la base de ce dont votre organisation a réellement besoin. La manière dont ces exigences découlent de votre propre processus est détaillée sur la page consacrée aux exigences fonctionnelles qui découlent de votre propre processus.
Ce raisonnement n'est pas nouveau pour ceux qui se sont déjà penchés sur le sujet — la question centrale est traitée plus largement sur la page de synthèse consacrée au choix d'un outil sans regret, et l'arbitrage entre acheter d'abord et organiser d'abord est développé séparément sur la page qui met les deux ordres face à face.
Le Data Readiness Scan de csrdready.net est conçu précisément pour réaliser cette première partie : établir le registre des points de données, documenter la traçabilité de la source jusqu'au rapport pour chaque point de données, attribuer la responsabilité et définir les règles de qualité. Pas de rapport, pas de questionnaire rempli — les données sous-jacentes, mises en ordre, avant qu'un outil n'entre en jeu.
L'outil est en cours de développement. Toute personne intéressée peut s'inscrire sur la liste d'attente ; rien n'est proposé qui n'existe pas encore, et rien n'est promis quant à ce qu'il produira avant qu'il n'existe.
Une fois le registre des points de données établi et clairement identifiées les étapes répétées entre la source et le rapport — récupérer le même chiffre auprès du même fournisseur, effectuer le même contrôle sur la même feuille de calcul, envoyer le même courriel au même département — une deuxième question se pose : quelle part de ce travail nécessite encore une intervention humaine, et quelle part peut être automatisée. Cette question dépasse le cadre de ce que fait csrdready.net, mais elle s'inscrit logiquement dans l'étape suivante. FTE TO AI calcule, tâche par tâche, quelle part du travail peut être reprise par l'IA, sur la base des tâches telles qu'elles sont effectivement exécutées — et non sur la base d'une estimation préalable.
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.