Kennisbank

Quand personne n'est propriétaire dans un groupe à entités multiples

Un groupe à entités multiples a souvent plusieurs versions du même point de données. Une filiale mesure les émissions scope 2 via le fournisseur d'énergie, une autre via une entreprise de facility management, une troisième livre une estimation issue d'un tableau Excel que plus personne ne peut retracer jusqu'à la source. Au niveau du groupe, cela se rassemble en un seul chiffre, mais la question de savoir qui est propriétaire de ce chiffre reste souvent sans réponse. Pas parce que personne ne veut s'en charger, mais parce que la structure du groupe fragmente la propriété entre des entités qui ont chacune leurs propres systèmes, définitions et responsables.

Pourquoi c'est typique des groupes à entités multiples

Au sein d'une seule entreprise, la propriété est généralement une question d'associer un nom à une tâche. Dans un groupe à entités multiples, la question est d'abord : à quel niveau se situe la propriété ? La responsabilité d'un point de données incombe-t-elle à l'entité qui effectue la mesure sous-jacente, ou à la fonction groupe qui consolide le chiffre ? Les deux réponses sont défendables, et c'est précisément le problème. Sans choix explicite, une zone grise apparaît dans laquelle l'entité pense que le groupe est responsable de l'exactitude, et le groupe pense que l'entité répond de l'exactitude de la mesure source. Ce que vous entendez par définition et périmètre à ce niveau dépend de qui possède la définition d'un point de données au niveau du groupe par rapport au niveau local — une question distincte de, mais qui précède, celle de savoir qui gère le processus sous-jacent.

Ce qui se passe mal sans propriétaire

Si personne n'est propriétaire, rien ne se produit immédiatement de visible. Le chiffre arrive simplement, venant de quelque part, et est intégré dans la consolidation. Le problème ne se révèle que lorsque quelque chose doit changer : une définition est précisée, un contrôle demande une justification, ou le chiffre de cette année diffère fortement de celui de l'année précédente. C'est alors qu'il s'avère que personne ne peut expliquer d'où vient le chiffre, quelles hypothèses il contient, ou qui peut approuver l'ajustement. Pour une seule entité, c'est déjà gênant. Pour un groupe à entités multiples, cela devient une quête à travers les services, chacun pensant qu'un autre peut répondre à la question.

Cela touche directement à qui possède le processus sous un point de données : pas seulement qui fournit le chiffre, mais qui est responsable des étapes qui y conduisent — la mesure, la conversion, la saisie dans le système. Dans un groupe à entités multiples, ces étapes peuvent relever de parties différentes, et sans propriétaire défini pour chaque étape, il est impossible de retracer où un écart est apparu.

Attribuer la propriété sans la forcer

La solution n'est pas de nommer pour chaque point de données un propriétaire qui se trouve être disponible. Cela ne fait que déplacer le problème. Un propriétaire doit être quelqu'un qui a réellement une influence sur la source du chiffre : celui qui effectue la mesure, gère le système, ou contrôle la livraison. Dans les groupes à entités multiples, cela implique souvent une attribution à plusieurs niveaux — un propriétaire local pour la mesure source, et un propriétaire groupe pour la logique de consolidation qui rassemble les mesures individuelles en un seul chiffre.

Ces deux rôles ne sont pas interchangeables. Le propriétaire local peut confirmer que la mesure au niveau de l'entité est correcte, mais pas que l'addition au niveau du groupe a été correctement appliquée, avec les bons facteurs de conversion et sans double comptage. Le propriétaire groupe peut gérer la consolidation, mais ne peut garantir que chaque mesure sous-jacente est valide. Remplir ces deux rôles est nécessaire pour savoir d'où vient un écart lorsque le contrôle le demande au niveau du groupe — une question qui aboutit finalement à qui possède le contrôle d'un point de données : qui signe pour l'exactitude, et sur la base de quelles confirmations sous-jacentes.

Consigner ce qui n'existe souvent qu'à l'oral

Dans de nombreux groupes à entités multiples, la propriété existe bel et bien, mais seulement dans la tête de personnes en poste depuis des années. Tout le monde sait à peu près qui fait quoi, jusqu'à ce que cette personne soit en congé, change de fonction, ou que la question soit juste un peu plus spécifique que ce que couvre l'image informelle. Un registre des points de données qui consigne pour chaque point de données qui gère la source, qui effectue la consolidation et qui signe pour l'exactitude, rend cela indépendant de qui est joignable cette semaine-là par hasard. Ce registre n'a pas besoin d'être plus grand que le groupe lui-même ; il doit simplement exister avant que la question devienne urgente.

Le pont vers le travail lui-même

Établir la propriété est une étape ; c'est aussi un bon moment pour examiner quelle part du travail qui atterrit chez ce propriétaire demande réellement une évaluation, et quelle part se résume à recopier des chiffres d'un système vers un autre. Le scan de travail de FTE TO AI calcule, par tâche, quelle part de ce travail peut être reprise par l'IA, afin qu'un propriétaire dans un groupe à entités multiples consacre son temps aux questions qui exigent réellement une évaluation, plutôt qu'à assembler manuellement des tableaux Excel provenant de différentes filiales.