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