Faut-il s'éloigner de la comptabilité pour piloter les performances ?

La comptabilité est une source essentielle du pilotage des performances. Elle fournit des indicateurs incontestables pour juger de la performance des entités, mais elle applique ses normes propres qui peuvent s’éloigner des besoins opérationnels. Depuis toujours, le jeu consiste à en tirer profit tout en lui appliquant des transformations qui rendent les données plus explicites pour le pilotage.

Or, on ne peut tenter de s’éloigner des données comptables sans prendre le risque d’obtenir des chiffres non partagés. Maintenir cette fidélité comptable tout en s’éloignant si nécessaire des règles comptables, c’est le challenge auquel on peut essayer de répondre avec un outil comme Workday Adaptive Planning.

Le modèle de gestion

Le modèle hérité de la comptabilité repose souvent sur un nombre d’axe classiques, tels que le compte comptable, le centre de coût ou de profit et les axes analytiques. D’autres dimensions peuvent être renseignés selon les cas (clients, fournisseurs, etc). Pour le pilotage des performances, il convient souvent de classer les données différemment. Par exemple, une ligne du compte de résultat peut être déduite d’une combinaison d’axes, ou bien les fournisseurs doivent être regroupés en fournisseurs globaux. L’objectif ici est de fournir instantanément un compte de résultat de gestion ou une analyse qui repose sur les objets de gestion les plus pertinents, même s’ils ne sont pas issus de la comptabilité.

Pour autant, le besoin de réconciliation oblige de conserver aussi les axes purement comptables, pour passer d’une vue à l’autre sur les mêmes données. Ainsi, on peut toujours revenir aux données d’origine, voire aux écritures d’origine.

L’ajustement des données comptables

La vocation de la comptabilité n’est pas seulement de produire des indicateurs de performance. Etant une source fiable de données, on lui confère souvent ce rôle mais on peut en attendre plus. Par exemple, ne faudrait-il pas prendre en compte les engagements ou les salaires versés en-dehors de toute provision ?

Pour corriger certains aspects comptables, il est possible dans Workday Adaptive Planning de charger automatiquement les données comptables puis d’intégrer des données financières ou de gestion supplémentaires ou des formules de calcul, pour ajuster le résultat présenté au management. Les jeux de données sont toujours distincts, la traçabilité est assurée, mais le résultat final est plus conforme aux besoins de pilotage.

L’association à d’autres données de gestion plus détaillées

Dans d’autres cas, le niveau de détail des données comptables est insuffisant. Par exemple, les ventes en comptabilité peuvent être enregistrées par compte comptable mensuel alors que le besoin d’analyse est par produit et par jour.

Les unités d’œuvre des systèmes de production permettent d’associer des données financières avec des données de production.

La constitution d’un P&L « produit » doit dans ce cas aller chercher dans un autre système le détail des ventes pour venir remplir la ligne "Chiffre d’Affaires". Du fait des décalages, des revalorisations et des écritures complémentaires, il est fréquent que les deux sources ne soient pas égales sur le total. Dans ce cas, on fera en sorte de conserver les deux sources de données simultanément accessibles, et si besoin de faire apparaitre dans le P&L l’écart entre les ventes provenant du logiciel de ventes et ceux de la compta pour garantir l’égalité avec cette dernière.

Le budget

Le cas de la construction budgétaire est plus subtil. Une logique ancienne voulait que le budget validé puisse redescendre dans le système comptable pour permettre des comparaisons. C’est toujours le cas, par exemple, si l’on procède dans un ERP à des contrôle d’engagement. Cependant, dans les autres situations, on constate que le budget n’a aucune raison d’être construit dans un modèle de données comptable s’il est utilisé pour l’analyse dans un modèle de gestion. Créer un budget compte par compte est fastidieux et ne présente pas d’intérêt s’il finit agrégé et transformé pour correspondre au modèle de gestion. Autant le bâtir dans le modèle de données où il sera utilisé.

Bien souvent, le budget est même construit à un niveau plus fin. Par exemple, la masse salariale peut être construite dans Workday Adaptive Planning par employé pour obtenir un résultat très précis, alors que le réalisé sera plus agrégé.

Dans un modèle complet, la comptabilité n’est qu’une des sources de données pour garantir le reporting, mais c’est souvent la première. Un outil de type EPM ou FP&A conduit à réfléchir en plaçant sur un premier plan ce que le modèle de contrôle de gestion doit être, puis à intégrer les différentes données et indicateurs, financiers ou non. En appliquant les transformations, en chargeant des données complémentaires, en conservant la traçabilité des données sources, en partageant des rapports explicites avec le plus grand nombre, on tire au mieux profit des données comptables sans s’y contraindre.

Pour en savoir plus, demandez une présentation personnalisée                   


Quelle intégration entre les systèmes (Workday Adaptive Planning)

Solution d'élaboration budgétaire : quel niveau d'intégration avec les outils opérationnels ?

Le paysage système d’une entreprise est composé d’une multitude d’outils. Entre la bureautique, les ERP, les outils spécialisés (CRM, SIRH, etc), les messageries...Il semble évident que plus ces outils sont intégrés (c’est-à-dire que l’échange de données est automatisée, simple et rapide) et plus leur utilisation est facilitée.

Qu’en est-il des solutions d’élaboration budgétaire et de reporting (FP&A), qui sont devenues incontournables pour les directions financières et de contrôle de gestion ?

S’il s’agit de restituer des données du réalisé créées dans d’autres systèmes (comptabilité, commercial, effectifs, etc), on ne peut le contester dans le principe, mais il existe certaines limites. S’il est question d’élaboration budgétaire, la nuance est encore plus forte.

L’intégration du réalisé

Evoquons en premier lieu la plateforme FP&A comme un outil de collecte et de reporting sur des données produites dans d’autres systèmes. Dans ce cas, le chargement de ces données peut passer par plusieurs méthodes, que ce soit le simple chargement manuel de fichiers, la connexion directe aux bases de données ou encore par les API. Ce chargement, effectué régulièrement, permet d’analyser les données dans un format compréhensible par les utilisateurs, avec des outils d’analyse puissants et de les comparer avec des prévisions qui auraient été construites dans la même solution FP&A, afin d'en expliquer les écarts.

Quels sont les bémols à cette intégration ? En premier lieu, il n’est pas certain qu’il faille toujours une connexion forte entre les outils, si ce chargement s'effectue peu souvent et au prix de nombreuses transformations de données. La question ici est le rapport entre l’effort et le résultat obtenu. On choisira peut-être de favoriser le chargement de simples fichiers Excel au lieu de mettre en place un flux technique de données.

Par ailleurs, les données sont souvent séparées en deux catégories : le référentiel (dimensions, comme la liste des clients ou des employés) et les transactions (les montants enregistrés) qui reposent sur les premiers. Or, le modèle d’analyse de gestion peut parfois différer (ou s’ajouter) du modèle transactionnel. Par exemple, un « centre de coût » d’un ERP peut s’éloigner du référentiel des sections analytiques du FP&A, car le premier comporte dans sa définition un regroupement de concepts (géographique, entités, etc) qui ont été séparés dans le second.

En clair, le système FP&A, du fait de sa grande flexibilité, se doit de disposer d’un modèle de données adapté au reporting alors que le système transactionnel, plus rigide, répond à d'autres contraintes. Si l’ERP et le FP&A sont « trop » intégrés, alors le second hérite des contraintes du premier au détriment des possibilités d’analyse.

Par ailleurs, certaines dimensions du FP&A peuvent comporter des propriétés spécifiques qui ne proviennent pas de l’ERP et qui doivent être ajoutées manuellement ou qui rendent simplement l'intégration impossible.

Lors de la mise en oeuvre de la solution, il conviendra donc de réfléchir au modèle optimal pour le reporting et la façon dont les systèmes opérationnels peuvent venir nourir, ou non, celui-ci.

La construction budgétaire

La désolidarisation des systèmes est encore plus flagrante concernant l’élaboration budgétaire, quand il s’agit du référentiel. Non seulement le modèle de données peut être différent, mais le référentiel (la liste des clients, fournisseurs, projets, etc) le sera aussi, même pour des dimensions existantes théoriquement dans celui-là. Pourquoi ? Car le système FP&A permet l'élaboration de la prévision, et donc potentiellement avec des produits, entités ou salariés qui ne sont pas présents dans l'ERP.

Prenons le cas d’une affaire importante qui se profile, et qui produira peut-être une vente chez un nouveau client. Ce client n’existe pas dans l’ERP mais il doit être imputé dans le FP&A. Il n’est pas recommandé de créer ce nouveau client dans l’ERP (car il ne s’agit que de suppositions et que le processus de prévision serait gravement freiné s’il fallait en passer par là). Le référentiel du FP&A pourrait donc évoluer de manière autonome pour intégrer la prévision. Charge, ensuite, à l’administrateur, de réconcilier le référentiel prévisionnel et le réalisé pour faciliter la comparaison.

Dans le cas où certaines données prévisionnelles existent dans d’autres systèmes et doivent être chargées dans le FP&A, on se posera la même question que dans la première partie : si c’est une intégration rare ou si cela exige de lourdes transformations, cela mérite-t-il qu’on mette en place un flux technique automatique ? Ainsi, une base RH chargée trois fois par an pour constituer le socle initial de la prévision de la masse salariale est le plus souvent chargée par un fichier Excel plutôt que connecté au SIRH.

Enfin, qu’en est-il de l'envoi dans le système opérationnel du résultat de la prévision effectué dans le FP&A ? Il est souvent utile de procéder à cette opération, par exemple, pour effectuer des comparaisons en temps réel dans un ERP, de contrôler les engagements ou de générer des demandes de recrutement pour les nouveaux postes validés au budget. Dans ce dernier cas, l’intégration permet de « boucler la boucle » et de traduire automatiquement les décisions budgétaires en tâches opérationnels. C’est ainsi que Workday, depuis l’acquisition d’Adaptive Planning, renforce régulièrement l’intégration dans les deux sens.

Dans la plupart des cas, l'intégration des données a peu d'intérêt pour la prévision en dehors des référentiels réels et de l'envoi des données prévisionnelles dans l'opérationnel.

Les autorisations

Nous pouvons distinguer l'accès des utilisateurs et le périmètre qui leur est autorisé.

La gestion centralisée des utilisateurs facilite leur administration et rend plus simple pour les utilisateurs l'accès aux outils. Par exemple, une intégration complète avec LDAP ou avec les identifiants créés dans un système opérationnel.

Cependant, le second cas peut présenter quelques défauts, notamment pour les utilisateurs qui n’ont pas d’accès à ce système opérationnel, et pour lesquels il faut créer un « login » dans un système pour en bénéficier dans l'autre. Le premier devient donc "maître" sans toujours disposer des fonctionnalités pour ce faire.

Concernant le périmètre autorisé pour chaque utilisateur, nous retrouvons ici les limitations vues plus haut. Une "trop forte" intégration avec les systèmes opérationnels rend difficile la gestion des autorisations sur des dimensions absentes de ceux-ci ou sur des référentiels différents. Cela peut être utile d’en reprendre l’essentiel mais il est rarissime de s’y limiter.

Une solution comme Workday Adaptive Planning permet par exemple de gérer les périmètres autorisés par la saisie directe ou le chargement automatique des valeurs de dimension autorisées (entité, groupe de produits, etc) venant de tout système, y compris Workday HCM ou Finance.

L’intégration entre les systèmes est évidemment un atout dans la plupart des cas. Il est nécessaire de charger le référentiel et le réalisé des systèmes opérationnels à des fins d’analyse et pour bénéficier des données de base communes. Dans cet article nous avons évoqué les nuances à prendre en compte avant de se lancer pour choisir la meilleure option, en particulier les référentiels complémentaires et prévisionnels et le rapport entre le coût d’intégration des systèmes et les bénéfices.

Pour en savoir plus, demandez une présentation personnalisée