Une obligation de reporting se présente, et la première réaction est de chercher un outil. Un tableau de bord, une plateforme, un module ajouté au logiciel existant. Cela donne une impression de progrès : quelque chose de nouveau apparaît, de l'argent y est consacré, il y a un fournisseur avec qui vous pouvez échanger.
La question qui est escamotée, c'est celle de savoir d'où l'outil tire ses chiffres. Un outil calcule, visualise et rapporte, mais n'invente rien. Les données qui y entrent proviennent des mêmes feuilles de calcul, des mêmes e-mails au responsable des installations, des mêmes estimations qui existaient déjà. Sauf que ces données se trouvent désormais derrière une interface qui a l'air organisée.
Choisir un outil avant de savoir quelles données vous avez, qui en est responsable et à quel point elles sont fiables, signifie choisir un outil sur la base d'une supposition. Le fournisseur demande quelles fonctionnalités vous avez besoin, et vous répondez en fonction de ce que vous pensez avoir — pas en fonction de ce qui existe réellement en termes de points de données, de sources et de propriétaires. Quelles exigences fonctionnelles découlent de votre propre processus est une question à laquelle on ne peut répondre que si le processus est déjà en place ; sans cette base, l'outil est choisi sur une liste d'exigences établie par quelqu'un d'autre, ou qui s'avère ensuite manquer précisément ce qui était nécessaire.
L'ordre inverse — d'abord régler le registre des points de données, la lignée et la propriété, puis seulement sélectionner un outil — prend plus de temps au départ. Il n'y a pas de tableau de bord à montrer, pas de progrès à présenter en réunion. Mais les questions qui sont ensuite posées à un outil sont des questions fondées sur ce qui se passe réellement dans l'entreprise, pas sur une liste reprise d'une démonstration.
Les coûts de l'approche outil-d'abord ne se résument pas à un seul poste, mais ils sont bel et bien reconnaissables.
Il y a l'outil lui-même, qui s'avère après un an manquer ce qui était nécessaire — une connexion à un système source qui n'existe pas, une structure de reporting qui ne correspond pas au fonctionnement de l'organisation, un module qui fait quelque chose dont personne n'avait besoin. Il y a le temps des personnes qui devaient alimenter l'outil : si le registre des points de données n'existait pas, l'outil est alimenté avec les mêmes exports Excel isolés qu'auparavant, sauf que maintenant c'est au sein d'un système qui suggère que tout est maîtrisé.
Il y a la fausse sécurité, qui est la plus coûteuse. Un outil avec un tableau de bord convaincant donne l'impression que les données sont en ordre. Cette impression tient jusqu'à une mission d'assurance, un auditeur ou une question du conseil de surveillance sur l'origine d'un chiffre. On découvre alors que personne ne peut désigner qui a fourni la source, quelle hypothèse y est intégrée, si le chiffre de cette année a été calculé de la même manière que celui de l'année dernière. L'outil ne le savait pas, parce que l'outil n'a jamais posé cette question — il a simplement accepté ce qui était saisi.
Et il y a le remplacement. Un outil choisi sans vue sur le processus sous-jacent est, avec le temps, échangé contre un autre outil, dans l'espoir que celui-ci fasse mieux l'affaire. Le problème se déplace, mais ne disparaît pas : faut-il d'abord acheter un outil ou d'abord organiser le processus est précisément le choix qui se représente à chaque remplacement, et qui, sans réponse du côté du processus, tourne de nouveau mal de la même manière.
Le poids du mauvais ordre dépend de l'endroit où naissent les données. Dans une entreprise de construction, une grande partie des données de durabilité se trouve chez les sous-traitants, sur le chantier et dans des administrations de projet qui n'ont pas été conçues pour le reporting — d'où proviennent les données de durabilité dans la construction déterminera quelles connexions un outil doit réellement avoir. Dans le secteur de l'installation, les données sont dispersées entre bons de service, registres de matériaux et contrats d'entretien, et où se trouvent les données de durabilité dans le secteur de l'installation montre qu'un outil générique construit pour une organisation de bureau se révèle rapidement insuffisant ici. Un outil qui ne connaît pas ces différences ne peut pas non plus les résoudre — quelle que soit la qualité de l'interface. Ceux qui souhaitent malgré tout choisir d'abord un outil feraient bien de lire comment choisir un outil sans regret par la suite, même si l'essentiel reste le même : un outil ne résout pas un processus qui n'existe pas.
L'ordre qui subsiste n'est pas compliqué, mais il est moins attrayant à proposer : d'abord établir quels points de données existent, d'où ils viennent, qui en est responsable et quelles règles de qualité s'y appliquent. C'est le travail pour lequel le Data Readiness Scan de CSRDready.net a été conçu — un registre des points de données, une lignée source-to-report par point de données, la propriété et les règles de qualité, sans qu'un outil ou une forme de rapport n'y soit encore associé. L'outil est en cours de développement ; ceux qui souhaitent s'y mettre dès maintenant peuvent s'inscrire sur la liste d'attente.
Une fois le registre des points de données établi, il reste encore une question qu'il n'est pas nécessaire de poser à un fournisseur de logiciel : quelle part de ce travail — collecter, contrôler et répéter les mêmes points de données — doit rester un travail humain, et quelle part peut être reprise. C'est à cela que sert le scan de travail de FTE TO AI : il calcule, par tâche, quelle part du travail peut être reprise par l'IA, sur la base des tâches telles qu'elles sont réellement exécutées dans votre organisation.
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.