Quand une prévision ne tient pas, l'instinct est d'ajuster le modèle. C'est rapide, cela ressemble à de la résolution de problème, et cela fonctionne généralement un temps.
C'est aussi ainsi qu'un système de planification cesse discrètement d'être fiable. Ajuster les modèles Adaptive Planning pour compenser des problèmes dans les données source ne règle pas ces problèmes. Il les encode, et il efface la preuve qu'ils ont jamais existé.
C'est un risque gérable depuis des années. Il cesse de l'être dès l'instant où vous ajoutez l'IA par-dessus, et pour une raison que la plupart des équipes ne voient pas venir.
Pourquoi les équipes le font
Personne ne se lance dans la construction d'un modèle de planification sur des données peu fiables. La décision se prend généralement sous pression, tard dans un déploiement, et pour des raisons tout à fait compréhensibles sur le moment.
Corriger les données dans le système source implique investigation, analyse des causes profondes, et souvent un travail de ressaisie. À quelques semaines de la mise en production, cela ressemble à un redémarrage de projet. Ajuster le modèle prend un après-midi.
Il y a aussi un problème de responsabilité. Si le problème se situe dans le système source, il appartient à quelqu'un d'autre. Contournez-le dans Adaptive et la responsabilité devient floue, ce qui est plus confortable pour tout le monde à court terme.
Et les ajustements de modèle sont invisibles d'une manière que les corrections de données ne le sont pas. Personne côté métier ne voit le contournement. Ils voient des prévisions qui se réconcilient.
Alors le contournement est mis en place. Il fonctionne. Le projet passe en production. Ce qui se passe ensuite est la partie qu'il vaut la peine de comprendre.
Ce qui casse réellement
Les prévisions s'éloignent de la réalité. Quand un modèle compense un problème de données, la prévision s'améliore par rapport aux propres hypothèses du modèle et diverge du métier. Les dépenses réelles continuent de suivre les données réelles. La prévision continue de suivre l'ajustement. L'écart se creuse, et comme l'ajustement n'est pas visible, il devient plus difficile à expliquer à chaque cycle.
L'analyse des écarts cesse d'être utile. La planification est itérative : prévoir, comparer aux réels, trouver l'écart, ajuster. Si la prévision repose sur un contournement plutôt que sur des données fiables, vous ne pouvez pas savoir si vous avez raté le plan parce qu'une hypothèse était fausse ou parce que le modèle compensait quelque chose dans les données. Chaque cycle commence par une incertitude que personne n'a quantifiée.
Le raisonnement part avec la personne. C'est celui-là qui prend les équipes au dépourvu.
À la suite d'un déploiement de Workday Financials et d'une demande de mise à jour d'Adaptive, nous avons trouvé un problème dans le mapping des centres de coûts. La structure dans Financials était initialement erronée, alors pendant l'intégration une correction a été appliquée en SQL. Financials a ensuite été corrigé correctement et restructuré. Le SQL a continué de suivre l'ancienne logique.
Rien n'a échoué. Aucune erreur n'a été levée. Le mapping n'avait jamais été documenté, et la divergence n'a été détectée que six mois plus tard, lors d'une revue du système et d'une réconciliation approfondie des données Workday vers Adaptive.
Six mois de prévisions en avaient été issues. Elles semblaient correctes.
Cette voie de correction particulière était propre à la façon dont l'intégration avait été construite. Le schéma, lui, ne l'est pas. Un contournement est appliqué parce que c'est le chemin le plus rapide, il n'est pas documenté parce qu'il est censé être temporaire, et la personne qui le comprenait part.
À quoi cela ressemble à l'intérieur d'Adaptive
La raison pour laquelle ces problèmes survivent des mois plutôt que des jours mérite d'être comprise, car elle est propre à la façon dont Adaptive traite les données qu'il ne reconnaît pas.
Adaptive ne rejette pas les valeurs qu'il ne peut placer. Selon la hiérarchie, les valeurs inconnues atterrissent dans un compartiment non catégorisé. C'est le détail qui compte : une hiérarchie incomplète ne produit pas une erreur évidente, elle produit un chiffre plausible. Les totaux se raccordent toujours en haut. Le reporting et l'analyse sont affectés selon vos paramètres système, mais rien ne se signale.
Les contournements se comportent de la même manière. Mapper des centres de coûts non identifiés vers d'autres niveaux résoudra un problème de réconciliation à court terme entre les réels de Financials et Adaptive. Laissé en place, il fausse les écarts plus bas tandis que le récapitulatif continue de paraître correct. Les valeurs et dimensions codées en dur au sein de formules, là où elles devraient être rattachées à des hypothèses clairement définies, ne sont pas différentes. Elles fonctionnent, puis elles cessent d'être visibles.
La réconciliation est le contrôle, et en pratique elle est plus faible que ne le supposent la plupart des équipes. Dans un déploiement idéal, vous n'en auriez pas besoin. Parce que des contournements sur les structures de centres de coûts existent, la position réaliste est que la sortie d'Adaptive est réconciliée avec un rapport Workday Financials chaque mois. Cela prend du temps, et le niveau auquel vous le faites détermine si cela vaut la peine d'être fait. Réconciliez trop haut et cela se raccordera, ce qui ne vous apprend rien. Les dimensions mal mappées n'apparaissent pas dans un total. Elles apparaissent en dessous.
Pourquoi l'IA transforme cela en exposition
Voici ce qui change.
Une personne qui lit un rapport d'écarts travaille du haut vers le bas. Les totaux d'abord, puis les lignes qui ont bougé. Un récapitulatif qui se raccorde ressemble à un système qui fonctionne.
L'IA ne le lit pas ainsi. Demandez-lui de prévoir ou de mener une analyse des écarts et elle travaille au niveau le plus granulaire disponible. Si une dimension est non catégorisée, ou si un centre de coûts est mappé au mauvais emplacement, la prévision qu'elle produit n'inclura pas toutes les données. Elle ne lit pas le récapitulatif qui se réconcilie. Elle lit le détail qui ne se réconcilie pas.
Le problème s'inverse donc. Avec un modèle traditionnel, les problèmes de données finissent par apparaître dans l'analyse des écarts, parce qu'une personne les cherche. Avec un modèle d'IA, les mêmes problèmes se situent en amont d'un processus qui n'a aucune raison de les signaler, et la sortie paraît plus sophistiquée plutôt que moins.
Cela compte à cause de qui finit par la défendre. Le modèle produit une prévision. La finance la présente. Un trimestre plus tard elle est fausse, le conseil demande pourquoi, et la réponse honnête est que personne n'est certain de ce que le modèle a appris. L'IA n'a pas échoué. Les données, si. La finance porte le problème de crédibilité dans tous les cas.
La différence entre une prévision d'IA qu'un directeur financier peut présenter et une qu'il ne peut pas, ce n'est pas le modèle. C'est de savoir si la réponse à « d'où cela vient-il ? » est une phrase ou un haussement d'épaules.
« Il a appris de trois ans de données de transactions auditées, analysées par centre de coûts et catégorie de dépenses, et il suit les réels dans la tolérance que nous avons convenue. » C'est défendable.
« Il a appris de données dont nous savions qu'elles présentaient des lacunes, dont certaines corrigées dans la couche de planification, et nous ne sommes pas certains de ce qu'il a retenu. » Même modèle. Il ne peut pas être défendu.
L'intégrité des données d'abord
Adaptive Planning dépend de trois couches, dans cet ordre : des données source fiables, une gouvernance des données claire, et des modèles construits sur ces données plutôt que de les compenser. Sautez les deux premières et la troisième finira par échouer.
En pratique, cela signifie quelques choses.
Auditez le système source avant de configurer quoi que ce soit. Les hiérarchies sont-elles complètes ? Les affectations de centres de coûts sont-elles cohérentes ? Les soldes se réconcilient-ils à chaque niveau, et pas seulement en haut ? Documentez la base de référence, afin de pouvoir dire plus tard si la qualité s'améliore ou dérive.
Définissez la responsabilité tant que c'est encore peu coûteux. Qui maintient le plan comptable. Quand les centres de coûts sont créés. Ce qui valide une nouvelle dimension. Ces questions sont triviales avant la mise en production et coûteuses ensuite.
Décidez de ce qu'est réellement un écart acceptable. Il n'y a pas de chiffre sectoriel ici, et quiconque vous en propose un devine. Ce qui compte comme un écart raisonnable entre les réels et la prévision relève du jugement du propriétaire du système, et cela dépend de l'entreprise. Faites-le explicitement, notez-le, et réconciliez par rapport à cela.
Réconciliez à un niveau assez bas pour trouver quelque chose. Mensuellement, la sortie du modèle par rapport aux données source, et lorsqu'il y a un écart, enquêtez plutôt que de l'absorber. Corrigez d'abord les problèmes de données dans le système source, puis ajustez le modèle s'il a encore besoin d'être ajusté.
Si vous ajoutez de l'IA, menez cet audit avant de commencer, pas après que la première prévision déçoit. L'IA amplifie la dérive des données, la validation doit donc être continue plutôt qu'un exercice ponctuel au début. Et si vous trouvez des problèmes de qualité en cours d'initiative IA, arrêtez et corrigez les données. Aucune configuration ne permet à un modèle de les contourner.
Deux questions à poser à votre équipe
Pouvez-vous expliquer chaque hypothèse de votre modèle Adaptive Planning en pointant vers des données fiables dans le système source ? Si la réponse est « pas entièrement », c'est un problème de données plutôt qu'un problème de planification, et aucun ajustement de modèle ne le résoudra.
Et si vous construisiez une prévision d'IA sur vos données actuelles aujourd'hui, pourriez-vous la défendre devant le conseil en la retraçant jusqu'à la source ? Si la réponse est « nous voudrions d'abord nettoyer les données », c'est la bonne réponse. C'est aussi une conversation bien moins coûteuse à avoir maintenant qu'après l'investissement.
Michael Trussell est Architecte Workday Adaptive Planning chez VirtualResource, où nous travaillons avec les équipes finance et HR sur les déploiements Workday, l'optimisation continue d'Adaptive Planning, et la facilitation de l'IA. Si vous pesez l'une ou l'autre, la conversation commence généralement par un examen de l'endroit où se trouvent réellement les données.