Ajouter un Logiciel de Données sur un Processus Cassé ne Produit que des Rapports Plus Jolis, Pendant que les Chiffres Sous-Jacents Restent Peu Fiables

Construisez d'abord un registre des points de données, puis concevez un processus source-vers-rapport par point de données avec des définitions cohérentes entre unités, plutôt que de laisser chaque unité développer sa propre approche de collecte indépendamment. Les définitions incohérentes entre unités sont souvent invisibles jusqu'à ce que quelqu'un essaie d'additionner les chiffres au niveau du groupe, moment où le total résultant combine silencieusement des chiffres qui n'ont jamais vraiment mesuré la même chose.

Réparez d'abord le processus, propriété, définitions, contrôles, avant d'introduire un quelconque outil ; un outil sur un processus cassé ne produit que des rapports peu fiables plus propres qui semblent plus crédibles qu'ils ne le sont. Les tableurs ne sont pas vraiment le problème ; l'absence de propriété claire, de définitions cohérentes, et de tout contrôle sur ce qui compte comme chiffre valide est le problème, et aucun achat de logiciel ne résout cela seul.

Concevez chaque processus de collecte avec contrôles, agrégation, normalisation, calcul et standardisation, afin que chaque chiffre soit traçable jusqu'à une source plutôt que d'arriver dans le rapport final comme un nombre inexpliqué que personne ne peut défendre si on le demande. Un processus vérifiable ressemble beaucoup à la façon dont la finance gère déjà les données financières, cette même discipline n'a simplement pas été traditionnellement appliquée aux chiffres de durabilité, exactement l'écart que cette approche comble.

Documenter, par point de données, d'où il vient, quel traitement il subit, et où il termine dans le rapport final, afin que tout le chemin de la source brute au chiffre publié soit explicite et vérifiable plutôt qu'une chose que seule une personne dans l'organisation comprend vraiment. Sans cette cartographie, un chiffre dans le rapport final est en pratique une boîte noire que personne ne peut vérifier de façon indépendante ni reconstruire si on le demande.

Attribuez un RACI par point de données et processus, propriété de la définition côté durabilité, propriété du processus et du contrôle côté finance, plutôt que de laisser la propriété implicite et de supposer que quelqu'un s'en chargera naturellement. Les données de durabilité ont une tendance spécifique à finir sans propriétaire, car elles tombent entre des services qui supposent chacun que l'autre est responsable, exactement ce qu'un RACI explicite est censé éviter.

Déterminez quels points de données vos sujets matériels et le standard de reporting exigent vraiment, et enregistrez ce qui existe déjà par rapport à ce qui doit être construit, plutôt que d'essayer de collecter chaque point de données imaginable que le standard permet théoriquement. Un registre limité à ce qui est vraiment nécessaire, fondé sur vos sujets matériels spécifiques, représente une fraction de la taille de celui construit en essayant de couvrir chaque divulgation possible sans considérer sa pertinence.

Standardisez la définition à l'étape du registre des points de données, avant de concevoir un quelconque processus de collecte, car essayer de réconcilier des définitions incohérentes après que chaque unité a déjà construit son propre processus est considérablement plus perturbateur. S'accorder tôt sur une définition partagée, même si cela prend plus de temps au départ, évite le coût bien plus élevé de démanteler des processus incompatibles plus tard.

Définissez à quoi ressemble une valeur valide par point de données et quel écart déclenche une alerte, la même discipline que les données financières ont déjà, étendue à des chiffres de durabilité historiquement collectés avec bien moins de rigueur. Un cadre de contrôle n'a pas besoin d'être élaboré pour être efficace ; il doit spécifier, pour chaque point de données, à quoi ressemble une plage plausible et ce qui se passe quand un chiffre en sort.

Assurez-vous que chaque chiffre a une source traçable et un propriétaire nommé dès le premier jour, reconstruire cela après coup est bien plus coûteux, surtout une fois que la personne qui avait initialement compilé un chiffre a changé de poste ou quitté l'organisation. Les fournisseurs d'assurance recherchent spécifiquement ce type de traçabilité, et son absence est l'une des raisons les plus courantes pour lesquelles un rapport de durabilité n'obtient pas une opinion d'assurance propre.

Réparez d'abord le processus. Les exigences fonctionnelles d'un outil devraient découler du processus conçu, pas l'inverse, car choisir le logiciel avant que le processus n'existe signifie deviner les exigences au lieu de les définir à partir d'un vrai flux de travail testé. Les outils choisis ainsi manquent souvent de capacités dont le processus a vraiment besoin, ou incluent une longue liste de fonctionnalités que le processus n'utilise jamais.

Définissez les exigences fonctionnelles selon votre processus de collecte conçu, puis faites la sélection, jamais avant que le processus n'existe, car une démo de fournisseur est bien plus persuasive qu'une évaluation claire de ce dont votre collecte de données spécifique a vraiment besoin. Les exigences définies à partir d'un vrai processus sont généralement plus spécifiques et utiles lors de l'évaluation des fournisseurs qu'une checklist générique de fonctionnalités copiée d'un rapport sectoriel.

La propriété de la définition revient à la durabilité ; la propriété du processus et du contrôle revient à la finance, qui a déjà les systèmes et la discipline pour cela, car la finance a passé des décennies à construire la rigueur que le reporting de durabilité doit maintenant atteindre. Cette division évite l'erreur courante où la durabilité possède à la fois les définitions et le processus, sans les systèmes que la finance a déjà pour exécuter ce processus de façon fiable à grande échelle.

Utilisez le même registre de points de données et la même conception de processus comme modèle, adapté par unité mais jamais redéfini par unité, afin que l'agrégation au niveau du groupe continue d'avoir du sens plutôt que de devenir une mosaïque d'approches réinventées localement. L'adaptation au contexte local est acceptable et souvent nécessaire ; redéfinir le point de données sous-jacent ou sa définition localement est ce qui casse la comparabilité au niveau du groupe.

Des semaines pour un seul sujet ; un déploiement complet au niveau du groupe avec gouvernance se mesure en trimestres, piloté principalement par le nombre d'unités et de parties impliquées plus que par la complexité technique des données elles-mêmes. Le calendrier monte en échelle bien plus avec la coordination organisationnelle qu'avec la difficulté de la mesure sous-jacente, donc un pilote sur un seul sujet peut avancer bien plus vite qu'un déploiement complet.

Maintenez la cartographie source-vers-rapport et le cadre de contrôle comme la documentation elle-même, construite prête pour l'audit dès la conception, plutôt que de traiter la documentation comme une tâche séparée à compléter une fois le processus déjà en cours. Ajouter de la documentation après coup à un processus déjà existant est généralement à la fois plus lent et moins précis que de construire la documentation comme sous-produit naturel d'une bonne conception de processus dès le début.