Un control est une règle ou une vérification qui doit garantir qu'un point de données est correct : un rapprochement entre deux sources, une approbation avant qu'un chiffre ne poursuive son chemin, une vérification d'une fourchette acceptable. Sur papier, le control est décrit dans un document de processus ou un rapport d'audit. Mais un control que personne n'exécute n'est pas un control. C'est une phrase dans un document.
Dans un groupe à entité unique, ce problème est généralement limité. Il y a un seul service financier, un seul contrôleur, une seule personne qui sait qui regarde quoi. Dans un groupe à entités multiples, cette évidence disparaît. Chaque entité a potentiellement son propre système comptable, son propre contrôleur local, sa propre façon d'enregistrer la consommation d'énergie ou les données de personnel. Le control conçu au niveau du groupe doit être exécuté séparément sur chaque entité — ou nulle part.
La propriété d'un control se divise en deux parties qui ne reposent pas toujours sur la même personne. Il y a celui qui a conçu ou approuvé le control — souvent au niveau du groupe, du côté de la durabilité ou de la finance. Et il y a celui qui exécute réellement le control par entité — souvent un contrôleur local, un responsable opérationnel, quelqu'un qui tient la feuille de calcul à jour.
Si ces deux rôles ne sont pas explicitement attribués, quelque chose de prévisible se produit : le groupe pense que le control existe parce qu'il a été conçu, tandis qu'au niveau de l'entité, personne ne se sent responsable de son exécution. C'est exactement ce que décrit ce que vous faites si personne n'est propriétaire dans un groupe à entités multiples : la question n'est pas seulement de savoir qui devrait détenir le control, mais ce qui dysfonctionne structurellement lorsque cette question reste sans réponse.
Une manière utile d'attribuer la propriété ne commence pas par l'entité mais par le point de données. Pour chaque point de données qui revient dans le reporting — émissions de CO2 par site, nombre d'ETP, consommation d'eau — il existe une chaîne : une définition, un processus dans lequel il est enregistré, et un control qui doit démontrer qu'il est correct. Qui détient la définition d'un point de données déterminele ce qui est précisément mesuré et selon quelle norme. Qui détient le processus sous-jacent détermine qui enregistre et fournit le point de données. Et au-dessus se trouve la question qui détient le control : qui vérifie si le résultat de ce processus est plausible et correct, et qui en signe la responsabilité.
Dans un groupe à entités multiples, cela signifie que chacun de ces trois rôles peut varier selon l'entité, tandis que la définition et le control lui-même sont idéalement identiques à l'échelle du groupe. Un control qui est un rapprochement manuel chez une entité et une vérification automatisée chez une autre produit des données non comparables — même si les deux entités appellent cela « control sur la consommation d'énergie ».
Un control n'a de valeur que s'il sait ce qui constitue un résultat acceptable et ce qui ne l'est pas. Cela requiert deux éléments qui restent souvent implicites. Premièrement, une réponse à qu'est-ce qu'une valeur valide : une fourchette, une unité, un format dans lequel un chiffre saisi est acceptable. Sans cette norme, un control ne peut vérifier que si quelque chose a été rempli, pas si c'est correct. Deuxièmement, une manière de repérer les écarts avant qu'ils n'atterrissent dans le rapport final — comment configurez-vous un écart de signalement traite des seuils qui indiquent quand un chiffre mérite le regard d'un humain, au lieu que chaque control sur chaque point de données reçoive la même attention.
Avec plusieurs entités, il est utile de fixer ces deux éléments — valeur valide et écart de signalement — au niveau du groupe et de les faire exécuter localement. Cela évite que chaque entité applique sa propre interprétation du « normal ».
La tentation, dans un groupe à entités multiples, est d'acquérir un logiciel qui effectue automatiquement les rapprochements et signale les écarts. Ce logiciel fait ce qu'il doit faire une fois que la question sous-jacente est résolue : qui est responsable de quoi, par point de données, par entité. Sans cette réponse, un outil n'organise rien — il exécute une logique de control sur des données dont personne ne sait exactement qui en assure la surveillance.
La propriété du control n'est donc pas une question à laquelle on répond après coup, lors de la mise en œuvre. C'est la première question, et celle qui déterminele si tout ce qui suit repose sur une base solide.
Dès que la propriété du control par entité et par point de données est consignée, on obtient également une vue sur ce qui, dans ce travail, est répétable : le rapprochement des chiffres, la vérification des fourchettes, le signalement des écarts. Une partie de ces étapes est suffisamment fixe pour être confiée à un ordinateur, une autre partie exige une évaluation qui doit rester du ressort d'un humain. Le scan de travail de FTE TO AI calcule, par tâche, quelle part de ce travail peut être reprise par l'IA, afin de révéler clairement où l'automatisation renforce le contrôle et où elle risque au contraire d'éroder la propriété.
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.