Laurent Allais
Il s’agit d’évaluer la capacité de la solution à évoluer et non uniquement à couvrir les besoins initiaux.
Ces critères sont généralement appliqués car ils permettent de couvrir le besoin immédiat. Pourtant, d’autres points essentiels sont rarement évoqués : ce qui est lié au cycle de vie du logiciel.
Pourquoi s’intéresser au cycle de vie de votre solution EPM ?
Contrairement aux ERP, dont l’efficacité repose sur une standardisation et une stabilité des traitements et des processus, les solutions EPM ont pour vocation de s’adapter, au fil du temps. Le contrôle de gestion est un domaine qui a besoin d’une grande flexibilité concernant les tâches, les données, le format de restitution, les accès, etc. Non seulement parce qu’il répond souvent à des circonstances nouvelles et imprévisibles, mais aussi parce qu’il se penche sur l’avenir et les perspectives alternatives.
La forte présence d’Excel dans les directions financières témoigne de cette recherche de flexibilité et de la méfiance envers les progiciels dont on peut craindre qu’ils réduisent cette flexibilité au profit d’une rigueur nécessaire mais pesante.
Un logiciel EPM qui ne peut s’adapter facilement au nouveau contexte apporte certes des bénéfices immédiats mais il risque de devenir une contrainte et produire un effet contraire. S’adapter facilement, cela signifie sans l’intervention d’experts techniques ni la présence à demeure d’une équipe chargée de la faire évoluer.
Cette adaptation est particulièrement nécessaire après la mise en œuvre et l’utilisation réelle. Si la solution est « gravée dans le marbre » alors il n’est d’autre solution que d’appeler en renfort de nouvelles feuilles Excel pour pallier les manques sans renier l’outil EPM désormais installé.
Un logiciel EPM qui ne peut s’adapter aux nouveaux contextes devient une contrainte.
La mise en place d’une solution EPM doit commencer par la distinction des tâches qu’on souhaite optimiser, et celles dont le besoin de flexibilité n’est pas compatible avec un logiciel et qui resteront gérées dans Excel. Comment savoir si une solution EPM sera efficace dans la durée et apportera la flexibilité nécessaire ? Voici quelques points à étudier lors du choix de votre solution :
La gestion des versions
La documentation du budget
La gestion du référentiel
L’évolution du modèle de données
La gestion des accès
L’intégration avec les autres outils
L’architecture technique
1. Gestion des versions
Toutes les solutions EPM permettent de gérer des versions différentes, qui représentent des jeux de données tels que le budget, la re-prévision, le réalisé, etc.
Il faut bien entendu avoir la possibilité de créer plusieurs versions, leur donner un intitulé explicite, délimiter leur période et choisir qui y accèdera. Dans la durée, il faut pouvoir manipuler ces versions librement.
La version est en effet l’objet central de tout processus budgétaire. Pendant ce processus, vous devez pouvoir bloquer les accès à tout moment, renommer la version et changer les périodes où la saisie est possible. Vous devez pouvoir choisir facilement qui y a accès et peut modifier les données (soit personne par personne, soit selon l’entité organisationnelle pour laquelle il saisit).
Les fonctions de traitement des données ne doivent pas dépendre d’experts ou de lourds paramétrages.
Une version est aussi un jeu de données. Il ne faut pas seulement raisonner version par version mais dynamiquement sur l’ensemble des versions, lors de la préparation ou de la diffusion par exemple. Voici quelques cas de traitements des données :
– Pensez-vous avoir besoin de reprendre certaines données d’une autre version ? Une fonction de copie doit être disponible.
– Pensez-vous avoir besoin d’effacer toute une partie d’un budget ou d’une prévision (par exemple les ventes pour un article qu’on décide de sortir du catalogue en cours d’année) ? Il faut une fonction de suppression sélective.
– Pensez-vous avoir besoin d’une version pour la re-prévision basée sur le budget mais sans le détail des ventes saisies initialement par article ? Vous avez besoin d’une fonction d’agrégation.
Ces fonctions doivent être natives, ce qui signifie qu’on ne doit pas avoir besoin de les prévoir ni de les paramétrer pour les utiliser le moment venu. Grâce à une bonne gestion des versions dans le processus et une souplesse dans la manipulation des données, vous produisez facilement les jeux de données complets à chaque nouvelle phase.
Quel est le risque ?
Sans une gestion souple de la version, vous serez à terme limité dans les visions alternatives, ou vous devrez compenser les manques par des chargements de fichier, un travail complémentaire sur Excel ou le traitement des erreurs de saisie (mauvaise période, mauvaise version…).
2. Documentation du budget
Les fonctions de documentation sont-elles survolées lors de l’évaluation des solutions EPM ? Pourtant, si l’on construit un budget, c’est pour décider d’une part des moyens à affecter et d’autre part pour donner une certaine vision de l’avenir conformément à la stratégie. S’il est imparfait par nature, le budget remplit en général ces deux missions. Mais que vaut-il s’il n’est qu’une somme de chiffres sans explications ?
Il peut être validé et partagé puis rester muet le reste de l’année sans une documentation des hypothèses. Le budget est utilisé comme référence de comparaison, puis il sert de point de départ aux re-prévisions qui doivent permettre de prendre des décisions en cas d’écarts significatifs avec le réalisé. Ces écarts ne sont pas en eux-mêmes un problème, car ils peuvent traduire un changement de l’environnement ou de la stratégie, mais ils le deviennent si on ne peut les expliquer.
Un budget sans documentation ne permettra pas d’identifier la cause des écarts.
Or c’est un des rôles de la direction financière que d’expliquer les causes des écarts. Mais comment faire si on a perdu entre-temps les explications, parce que la personne qui avait saisi un budget est partie depuis lors, parce que les fichiers ont disparu au fond d’un serveur, ou parce que rien n’avait été noté à l’origine ?
Pour être efficace dans la durée, la solution EPM doit permettre de documenter les données pour faciliter plus tard l’analyse des écarts. Saisir des commentaires, charger des fichiers, et surtout les retrouver par la suite. Si l’on copie les données d’une version vers une autre, les commentaires et fichiers associés doivent être copiés également (même s’ils sont supprimés ensuite car devenus obsolètes). L’utilisateur responsable d’une saisie doit être identifiable pour fournir les éclaircissements, même si ses responsabilités et ou ses accès dans l’outil ont changé depuis.
Quel est le risque ?
Sans possibilité de documenter facilement le budget dans l’outil, les justificatifs éventuels seront gérés ailleurs et seront difficiles à retrouver. L’analyse des écarts deviendra alors un exercice de mémoire collective…ou d’inventivité.
3. Gestion du référentiel
Par référentiel, nous entendons tous les niveaux de détail (appelés aussi « données de base ») sur lesquels sont imputés les montants : liste des articles pour le chiffre d’affaires, liste des employés pour les salaires, liste des fournisseurs pour les achats, etc.
Le premier point à vérifier est la facilité de mise à jour pour ajouter des «données de base» au fil du temps. Comment intégrer rapidement de nouveaux clients dans la liste et permettre aux utilisateurs de saisir leur budget pour ces nouveaux clients ? Ceci inclut les «données de base» prévisionnelles, qui n’existent pas encore dans le référentiel de l’ERP ou le CRM mais dont on a besoin lors du budget, sans les créer pour le moment dans ces systèmes.
Le second point est plus complexe : il s’agit de la suppression de ces données de base.
En effet, si vous avez créé un article prévisionnel pour saisir un budget, vous ne souhaitez pas forcément le retrouver dans votre liste d’articles dans les prochaines versions. Un exemple courant : vous voulez supprimer un centre de coût pour lequel il existe un budget antérieur. Vous ne souhaitez plus voir ce centre de coût dans la liste mais vous ne souhaitez pas non plus supprimer les données sur ce centre dans les versions antérieures. De plus, la contrainte informatique d’ « intégrité référentielle » ne permet pas de supprimer purement et simplement le centre de coût de la base de données sans supprimer les données qui lui font référence.
La gestion du référentiel prévisionnel doit permettre d’isoler les valeurs obsolètes ou le rapprocher du réalisé.
Pour couvrir ce point, il faut trouver dans la solution EPM des fonctionnalités natives d’archivage, de renommage de données de base, de réorganisation, ou autre chose qui permette à la fois de ne plus être gêné par cette donnée de base obsolète…tout en la retrouvant quand le besoin se présente.
Dans le cas inverse où une donnée de base « prévisionnelle » devient « réelle », il faut permettre une comparaison entre le budget saisi en fin d’année précédente et le réalisé qui sera chargé en cours d’année. Il faut éviter de faire coexister une donnée de base prévisionnelle sur laquelle porte le budget et une donnée de base réelle différente sur laquelle porte le réalisé. Par exemple, le cas d’un article « Futur produit 25» et de l’article équivalent « Stylo Rouge » créé dans l’ERP. Une solution passe par les tables de correspondance et l’existence d’une clé technique commune modifiable.
Quel est le risque ?
Un référentiel incohérent, difficile à faire évoluer et composé de données actuelles, passées et prévisionnelles, est source de multiples erreurs. Ceci risque d’être compensé par des traitements manuels sur feuilles Excel, soit pour conserver « quelque part » les budgets sur données de base obsolètes, soit par un traitement Excel pour comparer réel et prévision sur la même ligne d’un rapport.
4. Evolution du modèle de données
Le modèle de données représente la relation entre les natures budgétaires à saisir et le niveau de détail associé. On appelle parfois cela un « cube » dans les systèmes décisionnels, composé de « dimensions » (articles, clients, employés, fournisseurs…).
La question ici est de savoir si le modèle créé lors de la mise en œuvre de l’outil pourra facilement évoluer, c’est à dire en peu de temps et d’effort.
Faire évoluer le modèle de données consiste soit à ajouter une dimension, soit à en supprimer, soit à transformer son comportement. C’est un besoin qui est fréquent pour un contrôleur de gestion : on demande aux commerciaux de saisir au budget un chiffre d’affaires par client et par article, mais pour la re-prévision on ne possède pas ce niveau de détail. De même, on peut se rendre compte de la difficulté de saisir un budget par article, et décider dans la version suivante de saisir par famille d’articles. Le changement de niveau de détail doit pouvoir s’appliquer à tout moment, y compris au sein d’un même budget selon l’étape du processus.
Le niveau de détail doit pouvoir évoluer facilement d’une version à l’autre.
Hélas, les solutions EPM reposent souvent sur une structure de données relativement figée, définie lors de la mise en œuvre initiale, sur laquelle sont créées les feuilles de saisie, les calculs, l’intégration de données, etc. L’ajout de dimensions est parfois possible, mais la suppression demeure techniquement plus complexe si le modèle est identique pour toutes les versions. Par ailleurs, les rapports créés sur la base de ce modèle ne fonctionneront plus si la dimension devient inaccessible.
Quelle est la démarche traditionnellement employée pour répondre à ce problème ? Créer un autre modèle connecté au premier, fixer la dimension inutilisée sur une constante « vide » puis agréger toutes les données sur celle-ci, recréer le modèle avec rechargement de l’historique… Compte tenu de la complexité de la démarche on finira par renoncer à le faire évoluer trop souvent.
Certains outils EPM ont prévu cette fonctionnalité et permettent de choisir, pour chaque version de budget, quelles dimensions doivent effectivement être renseignées ou non, pour chaque nature budgétaire, et même s’il est possible de saisir ces dimensions à la fois au total et en détail.
L’évolution du modèle de données comprend aussi la possibilité pour la direction financière de modifier facilement l’ensemble des calculs et règles de gestion.
Quel est le risque ?
L’absence de flexibilité dans la gestion des modèles multidimensionnels amène tout simplement la direction financière à utiliser le modèle mis en œuvre initialement et renoncer à le faire évoluer. Elle fera en sorte de renseigner toutes les dimensions (au pire sur une valeur nulle) et ne viendra en ajouter de nouvelles qu’au prix d’un projet plus ou moins lourd selon les outils.
5. Gestion des accès
Avec l’usage d’un outil EPM, l’accès aux rapports ou aux feuilles de saisie devient un libre-service.
Le premier point à vérifier est la facilité avec laquelle vous pouvez ajouter un nouvel utilisateur, soit manuellement soit grâce aux annuaires d’entreprise, et lui donner les accès qui conviennent. Ceci implique si nécessaire le choix de chaque « donnée de base» (chaque valeur dans la liste) autorisé dans chaque dimension. A un instant T, vous devez par ailleurs être capable de savoir qui a accès à quoi.
Les autorisations sont combinées à la gestion du processus pour connaitre l’accès réel et actuel aux données.
Là encore, la problématique consiste à faire évoluer ces accès dans le temps. Supprimer les accès, changer les autorisations, retrouver qui a fait quoi à un moment donné, etc.
Comme pour le référentiel, il n’est pas possible de supprimer la fiche d’un utilisateur, il faut donc pouvoir le « désactiver » sans perdre l’historique de ses interventions.
Compte tenu de la confidentialité de certaines informations, il faut obtenir facilement un rapport sur les accès et pouvoir les corriger dans la minute, en particulier quand ceux-ci reposent sur un grand nombre de dimensions, écrans de saisie et versions différents.
Par ailleurs, quand on aborde la gestion des accès, on aborde de manière plus large la gestion du processus budgétaire. Il ne s’agit pas seulement de savoir qui possède un accès technique à l’outil et sur quel périmètre, mais qui peut réellement voir et changer quoi compte tenu de la phase du processus.
Par exemple, il arrive qu’on travaille en même temps sur une re-prévision de fin d’année (à partir de septembre) et un budget pour l’année suivante. Pour ce faire, un utilisateur a besoin de connaître le réalisé de l’année antérieure et jusqu’au mois d’août. Il aura donc accès à trois années. Il voit toutes les périodes, mais il ne peut modifier que pour les mois à partir de septembre. Quand le budget est validé pour l’ensemble de son entité organisationnelle, les données ne sont plus modifiables. Ensuite, la direction financière supprime la totalité des accès à la version au profit d’une nouvelle, etc.
Quel est le risque ?
En l’absence d’un contrôle dynamique des accès, avec la clarté suffisante, les risques sont nombreux : absence de confidentialité, modification des données déjà validées, absence d’accès aux périmètres souhaités, gestion en « tout ou rien » des accès, frustration des utilisateurs perdus au milieu de données non pertinentes. Ceci se traduit par une incohérence des données, un processus plus long et un lourd travail de vérification et de rectification par le contrôle de gestion.
6. Intégration avec les autres outils
L’intégration avec les autres outils concerne l’import (référentiel, réalisé, budgets préparés dans un autre outil, fichier Excel…) et l’export (ERP, DataWarehouse, Excel…).
Par défaut, il est évidemment indispensable de pouvoir intégrer l’outil EPM dans votre paysage applicatif, organiser les transferts, procéder aux transformations requises, etc.
Quels sont les points à contrôler pour une utilisation durable ? Là aussi il s’agit de la suppression, de l’ajout et de la transformation des flux de données. Si la suppression ne pose pas de problème puisqu’il n’y a qu’à « couper » le flux, l’ajout et la modification peuvent être plus contraignantes.
Il faut pouvoir identifier rapidement les erreurs de chargement quotidien et anticiper les futures intégrations.
La connexion avec un outil tiers est une partie relativement technique d’un projet de mise en œuvre d’un outil EPM. Pour répondre rapidement au besoin de chargement d’une source, il faut en premier lieu permettre à la direction financière de charger elle-même un fichier de type CSV, parce que le projet d’intégration n’a pas encore abouti ou parce qu’il s’agit d’une opération manuelle ou ponctuelle.
Par ailleurs, même si ce n’est pas l’idéal de l’automatisation auquel on aspire, la question est aussi la suivante : compte tenu de la charge de mise en œuvre, de maintenance, du coût de licence, etc, le chargement automatique présente-t-il un bénéfice par rapport au chargement manuel ? Dit autrement, faut-il mener un projet technique d’intégration pour remplacer une tâche manuelle peu consommatrice de temps ?
Si la réponse est oui, et pour anticiper les besoins, il faut vérifier que les futurs outils pourront s’intégrer avec votre solution EPM grâce à l’existence de méthodes nombreuses (par fichier, connexion directe, Web services), une ouverture large des bases de logiciels propriétaires et la possibilité de faire évoluer les règles de transformation (tables de correspondance, SQL, etc.). Dit autrement, si une nouvelle source vient remplacer une ancienne, il faut vérifier qu’il sera possible de réutiliser ce qui peut l’être dans le flux complet ; des règles de transformation jusqu’au modèle de données.
Enfin il faut pouvoir maintenir l’intégration avec les outils existants. En particulier, la gestion des tables de correspondance (« mapping »), qui permettent de transformer le référentiel d’un système « source » vers celui de votre solution EPM, doit être accessible et rapide. Par exemple, si un nouveau compte comptable a été créé dans votre ERP, il faut pouvoir identifier rapidement si celui-ci n’a pas été « mappé » avec une nature budgétaire de l’EPM, créer ce mapping et relancer le chargement. Ceci est vrai aussi en cas d’export de données.
Quel est le risque ?
Le risque d’un manque de flexibilité sur la question de l’intégration, dans la durée, est la succession de projets d’intégration technique relativement lourds, ou une gestion manuelle des chargements à partir de fichiers. Si les tables de correspondance sont difficiles à gérer, les conséquences peuvent être de longs délais dans la mise à jour des données dus aux corrections successives ou de mauvaises imputations au chargement qui obligent à supprimer les données, corriger et recharger les données. Mais encore faut-il se rendre compte de l’erreur d’imputation…
7. L’architecture technique
Évoquons les deux cas de figure principaux rencontrés actuellement : « on-premise », qui consiste pour l’entreprise à administrer ou faire administrer les serveurs et la base de données, et « cloud », qui consiste à laisser l’éditeur s’en charger à partir de plateformes mutualisées. Il existe aussi des cas où l’éditeur se charge d’administrer un serveur pour le compte du client, ceux où la base de données est « on-premise » mais l’applicatif en « cloud », etc. Nous n’aborderons pas ici les avantages et inconvénients de chacun mais les points à contrôler.
En premier lieu on étudiera la fréquence et la charge des mises à jour du logiciel : celle incombant aux équipes techniques et aux utilisateurs clés. La solution est-elle indisponible à chaque mise à jour et combien de temps ? Faut-il refaire une recette complète ou non (« tests de non-régression ») ? Ceci implique-t-il de former les utilisateurs ?
Quelles sont les perspectives de déploiement interne et la « roadmap » de l’éditeur ?
Par ailleurs, il est utile de traiter les aspects de volumétrie et de performance. Que se passera-t-il si le volume de données devient important ou si le nombre d’utilisateurs vient à augmenter au fil du temps. Quels temps de réponse et quels prix de licences ? Quelles sont les solutions pour réduire la volumétrie des données inutilisées ou accélérer les performances (in-memory, agrégats, etc) ?
Parmi les questions techniques à poser : Si l’outil utilise MS Office, quelles sont les versions pertinentes et comment peut-on anticiper la montée de version de MS Office ou de l’OS rendue nécessaire par l’outil EPM ? Dans le cas où apparaîtraient des besoins que l’outil ne sait pas couvrir, est-il possible de l’étendre avec des développements spécifiques ? Est-il possible d’appliquer des modifications dans les objets du logiciel EPM pour les tester mais sans impacter immédiatement la solution opérationnelle ?
Enfin, on vérifiera avec l’éditeur quelle est sa stratégie autour du produit. L’histoire des solutions EPM est pleine de rebondissements : des rachats, des disparitions, des changements de technologie, etc. Évoquons pour mémoire : le rachat de Cognos par IBM, le rachat et la suppression de Clarity Systems par IBM, la disparition de Microsoft Performance Point, le remplacement supposé de SAP BW-IP par Outlooksoft (initialement sur SQL Server, renommé BPC et recréé sur NetWeaver) avant de voir son retour, mixé avec le front-end de BPC et la base de données HANA, l’apparition des nouvelles solutions cloud telles SAP BusinessObjects Cloud, Anaplan, AssignUp et Adaptive Insights, etc.
On vérifiera auprès de l’éditeur et d’experts indépendants si le choix de la solution est pertinent compte tenu des évolutions technologiques du secteur et de la stratégie de l’éditeur.
Quel est le risque ?
Une mauvaise anticipation sur les aspects techniques peut avoir des conséquences sur les performances, des limites en termes d’utilisation (réduction du nombre d’utilisateurs, de dimensions) et des surcoûts inattendus (mise à jour des postes, projets techniques d’optimisation, serveurs ou licences supplémentaires, etc.).
En conclusion, les outils EPM doivent répondre à une double contrainte : la flexibilité et la rigueur. Pour ce faire, ils proposent en général une « boite à outil » où chaque client peut créer son propre modèle personnalisé, ses écrans de saisie, ses dimensions, ses rapports, etc. Ces solutions sont de plus en plus séduisantes au premier contact, pour convaincre les clients de la facilité de mise en œuvre lors des phases commerciales, mais elles doivent aussi être efficaces dans la durée, sans effort technique et sans surcoût, compte tenu des évolutions possibles des besoins et de l’environnement. En combinant ces qualités, elles permettent aux directions financières des gains de productivité importants et le développement de leur rôle central dans l’organisation.
Ces critères sont généralement appliqués car ils permettent de couvrir le besoin immédiat. Pourtant, d’autres points essentiels sont rarement évoqués : ce qui est lié au cycle de vie du logiciel.
Pourquoi s’intéresser au cycle de vie de votre solution EPM ?
Contrairement aux ERP, dont l’efficacité repose sur une standardisation et une stabilité des traitements et des processus, les solutions EPM ont pour vocation de s’adapter, au fil du temps. Le contrôle de gestion est un domaine qui a besoin d’une grande flexibilité concernant les tâches, les données, le format de restitution, les accès, etc. Non seulement parce qu’il répond souvent à des circonstances nouvelles et imprévisibles, mais aussi parce qu’il se penche sur l’avenir et les perspectives alternatives.
La forte présence d’Excel dans les directions financières témoigne de cette recherche de flexibilité et de la méfiance envers les progiciels dont on peut craindre qu’ils réduisent cette flexibilité au profit d’une rigueur nécessaire mais pesante.
Un logiciel EPM qui ne peut s’adapter facilement au nouveau contexte apporte certes des bénéfices immédiats mais il risque de devenir une contrainte et produire un effet contraire. S’adapter facilement, cela signifie sans l’intervention d’experts techniques ni la présence à demeure d’une équipe chargée de la faire évoluer.
Cette adaptation est particulièrement nécessaire après la mise en œuvre et l’utilisation réelle. Si la solution est « gravée dans le marbre » alors il n’est d’autre solution que d’appeler en renfort de nouvelles feuilles Excel pour pallier les manques sans renier l’outil EPM désormais installé.
Un logiciel EPM qui ne peut s’adapter aux nouveaux contextes devient une contrainte.
La mise en place d’une solution EPM doit commencer par la distinction des tâches qu’on souhaite optimiser, et celles dont le besoin de flexibilité n’est pas compatible avec un logiciel et qui resteront gérées dans Excel. Comment savoir si une solution EPM sera efficace dans la durée et apportera la flexibilité nécessaire ? Voici quelques points à étudier lors du choix de votre solution :
La gestion des versions
La documentation du budget
La gestion du référentiel
L’évolution du modèle de données
La gestion des accès
L’intégration avec les autres outils
L’architecture technique
1. Gestion des versions
Toutes les solutions EPM permettent de gérer des versions différentes, qui représentent des jeux de données tels que le budget, la re-prévision, le réalisé, etc.
Il faut bien entendu avoir la possibilité de créer plusieurs versions, leur donner un intitulé explicite, délimiter leur période et choisir qui y accèdera. Dans la durée, il faut pouvoir manipuler ces versions librement.
La version est en effet l’objet central de tout processus budgétaire. Pendant ce processus, vous devez pouvoir bloquer les accès à tout moment, renommer la version et changer les périodes où la saisie est possible. Vous devez pouvoir choisir facilement qui y a accès et peut modifier les données (soit personne par personne, soit selon l’entité organisationnelle pour laquelle il saisit).
Les fonctions de traitement des données ne doivent pas dépendre d’experts ou de lourds paramétrages.
Une version est aussi un jeu de données. Il ne faut pas seulement raisonner version par version mais dynamiquement sur l’ensemble des versions, lors de la préparation ou de la diffusion par exemple. Voici quelques cas de traitements des données :
– Pensez-vous avoir besoin de reprendre certaines données d’une autre version ? Une fonction de copie doit être disponible.
– Pensez-vous avoir besoin d’effacer toute une partie d’un budget ou d’une prévision (par exemple les ventes pour un article qu’on décide de sortir du catalogue en cours d’année) ? Il faut une fonction de suppression sélective.
– Pensez-vous avoir besoin d’une version pour la re-prévision basée sur le budget mais sans le détail des ventes saisies initialement par article ? Vous avez besoin d’une fonction d’agrégation.
Ces fonctions doivent être natives, ce qui signifie qu’on ne doit pas avoir besoin de les prévoir ni de les paramétrer pour les utiliser le moment venu. Grâce à une bonne gestion des versions dans le processus et une souplesse dans la manipulation des données, vous produisez facilement les jeux de données complets à chaque nouvelle phase.
Quel est le risque ?
Sans une gestion souple de la version, vous serez à terme limité dans les visions alternatives, ou vous devrez compenser les manques par des chargements de fichier, un travail complémentaire sur Excel ou le traitement des erreurs de saisie (mauvaise période, mauvaise version…).
2. Documentation du budget
Les fonctions de documentation sont-elles survolées lors de l’évaluation des solutions EPM ? Pourtant, si l’on construit un budget, c’est pour décider d’une part des moyens à affecter et d’autre part pour donner une certaine vision de l’avenir conformément à la stratégie. S’il est imparfait par nature, le budget remplit en général ces deux missions. Mais que vaut-il s’il n’est qu’une somme de chiffres sans explications ?
Il peut être validé et partagé puis rester muet le reste de l’année sans une documentation des hypothèses. Le budget est utilisé comme référence de comparaison, puis il sert de point de départ aux re-prévisions qui doivent permettre de prendre des décisions en cas d’écarts significatifs avec le réalisé. Ces écarts ne sont pas en eux-mêmes un problème, car ils peuvent traduire un changement de l’environnement ou de la stratégie, mais ils le deviennent si on ne peut les expliquer.
Un budget sans documentation ne permettra pas d’identifier la cause des écarts.
Or c’est un des rôles de la direction financière que d’expliquer les causes des écarts. Mais comment faire si on a perdu entre-temps les explications, parce que la personne qui avait saisi un budget est partie depuis lors, parce que les fichiers ont disparu au fond d’un serveur, ou parce que rien n’avait été noté à l’origine ?
Pour être efficace dans la durée, la solution EPM doit permettre de documenter les données pour faciliter plus tard l’analyse des écarts. Saisir des commentaires, charger des fichiers, et surtout les retrouver par la suite. Si l’on copie les données d’une version vers une autre, les commentaires et fichiers associés doivent être copiés également (même s’ils sont supprimés ensuite car devenus obsolètes). L’utilisateur responsable d’une saisie doit être identifiable pour fournir les éclaircissements, même si ses responsabilités et ou ses accès dans l’outil ont changé depuis.
Quel est le risque ?
Sans possibilité de documenter facilement le budget dans l’outil, les justificatifs éventuels seront gérés ailleurs et seront difficiles à retrouver. L’analyse des écarts deviendra alors un exercice de mémoire collective…ou d’inventivité.
3. Gestion du référentiel
Par référentiel, nous entendons tous les niveaux de détail (appelés aussi « données de base ») sur lesquels sont imputés les montants : liste des articles pour le chiffre d’affaires, liste des employés pour les salaires, liste des fournisseurs pour les achats, etc.
Le premier point à vérifier est la facilité de mise à jour pour ajouter des «données de base» au fil du temps. Comment intégrer rapidement de nouveaux clients dans la liste et permettre aux utilisateurs de saisir leur budget pour ces nouveaux clients ? Ceci inclut les «données de base» prévisionnelles, qui n’existent pas encore dans le référentiel de l’ERP ou le CRM mais dont on a besoin lors du budget, sans les créer pour le moment dans ces systèmes.
Le second point est plus complexe : il s’agit de la suppression de ces données de base.
En effet, si vous avez créé un article prévisionnel pour saisir un budget, vous ne souhaitez pas forcément le retrouver dans votre liste d’articles dans les prochaines versions. Un exemple courant : vous voulez supprimer un centre de coût pour lequel il existe un budget antérieur. Vous ne souhaitez plus voir ce centre de coût dans la liste mais vous ne souhaitez pas non plus supprimer les données sur ce centre dans les versions antérieures. De plus, la contrainte informatique d’ « intégrité référentielle » ne permet pas de supprimer purement et simplement le centre de coût de la base de données sans supprimer les données qui lui font référence.
La gestion du référentiel prévisionnel doit permettre d’isoler les valeurs obsolètes ou le rapprocher du réalisé.
Pour couvrir ce point, il faut trouver dans la solution EPM des fonctionnalités natives d’archivage, de renommage de données de base, de réorganisation, ou autre chose qui permette à la fois de ne plus être gêné par cette donnée de base obsolète…tout en la retrouvant quand le besoin se présente.
Dans le cas inverse où une donnée de base « prévisionnelle » devient « réelle », il faut permettre une comparaison entre le budget saisi en fin d’année précédente et le réalisé qui sera chargé en cours d’année. Il faut éviter de faire coexister une donnée de base prévisionnelle sur laquelle porte le budget et une donnée de base réelle différente sur laquelle porte le réalisé. Par exemple, le cas d’un article « Futur produit 25» et de l’article équivalent « Stylo Rouge » créé dans l’ERP. Une solution passe par les tables de correspondance et l’existence d’une clé technique commune modifiable.
Quel est le risque ?
Un référentiel incohérent, difficile à faire évoluer et composé de données actuelles, passées et prévisionnelles, est source de multiples erreurs. Ceci risque d’être compensé par des traitements manuels sur feuilles Excel, soit pour conserver « quelque part » les budgets sur données de base obsolètes, soit par un traitement Excel pour comparer réel et prévision sur la même ligne d’un rapport.
4. Evolution du modèle de données
Le modèle de données représente la relation entre les natures budgétaires à saisir et le niveau de détail associé. On appelle parfois cela un « cube » dans les systèmes décisionnels, composé de « dimensions » (articles, clients, employés, fournisseurs…).
La question ici est de savoir si le modèle créé lors de la mise en œuvre de l’outil pourra facilement évoluer, c’est à dire en peu de temps et d’effort.
Faire évoluer le modèle de données consiste soit à ajouter une dimension, soit à en supprimer, soit à transformer son comportement. C’est un besoin qui est fréquent pour un contrôleur de gestion : on demande aux commerciaux de saisir au budget un chiffre d’affaires par client et par article, mais pour la re-prévision on ne possède pas ce niveau de détail. De même, on peut se rendre compte de la difficulté de saisir un budget par article, et décider dans la version suivante de saisir par famille d’articles. Le changement de niveau de détail doit pouvoir s’appliquer à tout moment, y compris au sein d’un même budget selon l’étape du processus.
Le niveau de détail doit pouvoir évoluer facilement d’une version à l’autre.
Hélas, les solutions EPM reposent souvent sur une structure de données relativement figée, définie lors de la mise en œuvre initiale, sur laquelle sont créées les feuilles de saisie, les calculs, l’intégration de données, etc. L’ajout de dimensions est parfois possible, mais la suppression demeure techniquement plus complexe si le modèle est identique pour toutes les versions. Par ailleurs, les rapports créés sur la base de ce modèle ne fonctionneront plus si la dimension devient inaccessible.
Quelle est la démarche traditionnellement employée pour répondre à ce problème ? Créer un autre modèle connecté au premier, fixer la dimension inutilisée sur une constante « vide » puis agréger toutes les données sur celle-ci, recréer le modèle avec rechargement de l’historique… Compte tenu de la complexité de la démarche on finira par renoncer à le faire évoluer trop souvent.
Certains outils EPM ont prévu cette fonctionnalité et permettent de choisir, pour chaque version de budget, quelles dimensions doivent effectivement être renseignées ou non, pour chaque nature budgétaire, et même s’il est possible de saisir ces dimensions à la fois au total et en détail.
L’évolution du modèle de données comprend aussi la possibilité pour la direction financière de modifier facilement l’ensemble des calculs et règles de gestion.
Quel est le risque ?
L’absence de flexibilité dans la gestion des modèles multidimensionnels amène tout simplement la direction financière à utiliser le modèle mis en œuvre initialement et renoncer à le faire évoluer. Elle fera en sorte de renseigner toutes les dimensions (au pire sur une valeur nulle) et ne viendra en ajouter de nouvelles qu’au prix d’un projet plus ou moins lourd selon les outils.
5. Gestion des accès
Avec l’usage d’un outil EPM, l’accès aux rapports ou aux feuilles de saisie devient un libre-service.
Le premier point à vérifier est la facilité avec laquelle vous pouvez ajouter un nouvel utilisateur, soit manuellement soit grâce aux annuaires d’entreprise, et lui donner les accès qui conviennent. Ceci implique si nécessaire le choix de chaque « donnée de base» (chaque valeur dans la liste) autorisé dans chaque dimension. A un instant T, vous devez par ailleurs être capable de savoir qui a accès à quoi.
Les autorisations sont combinées à la gestion du processus pour connaitre l’accès réel et actuel aux données.
Là encore, la problématique consiste à faire évoluer ces accès dans le temps. Supprimer les accès, changer les autorisations, retrouver qui a fait quoi à un moment donné, etc.
Comme pour le référentiel, il n’est pas possible de supprimer la fiche d’un utilisateur, il faut donc pouvoir le « désactiver » sans perdre l’historique de ses interventions.
Compte tenu de la confidentialité de certaines informations, il faut obtenir facilement un rapport sur les accès et pouvoir les corriger dans la minute, en particulier quand ceux-ci reposent sur un grand nombre de dimensions, écrans de saisie et versions différents.
Par ailleurs, quand on aborde la gestion des accès, on aborde de manière plus large la gestion du processus budgétaire. Il ne s’agit pas seulement de savoir qui possède un accès technique à l’outil et sur quel périmètre, mais qui peut réellement voir et changer quoi compte tenu de la phase du processus.
Par exemple, il arrive qu’on travaille en même temps sur une re-prévision de fin d’année (à partir de septembre) et un budget pour l’année suivante. Pour ce faire, un utilisateur a besoin de connaître le réalisé de l’année antérieure et jusqu’au mois d’août. Il aura donc accès à trois années. Il voit toutes les périodes, mais il ne peut modifier que pour les mois à partir de septembre. Quand le budget est validé pour l’ensemble de son entité organisationnelle, les données ne sont plus modifiables. Ensuite, la direction financière supprime la totalité des accès à la version au profit d’une nouvelle, etc.
Quel est le risque ?
En l’absence d’un contrôle dynamique des accès, avec la clarté suffisante, les risques sont nombreux : absence de confidentialité, modification des données déjà validées, absence d’accès aux périmètres souhaités, gestion en « tout ou rien » des accès, frustration des utilisateurs perdus au milieu de données non pertinentes. Ceci se traduit par une incohérence des données, un processus plus long et un lourd travail de vérification et de rectification par le contrôle de gestion.
6. Intégration avec les autres outils
L’intégration avec les autres outils concerne l’import (référentiel, réalisé, budgets préparés dans un autre outil, fichier Excel…) et l’export (ERP, DataWarehouse, Excel…).
Par défaut, il est évidemment indispensable de pouvoir intégrer l’outil EPM dans votre paysage applicatif, organiser les transferts, procéder aux transformations requises, etc.
Quels sont les points à contrôler pour une utilisation durable ? Là aussi il s’agit de la suppression, de l’ajout et de la transformation des flux de données. Si la suppression ne pose pas de problème puisqu’il n’y a qu’à « couper » le flux, l’ajout et la modification peuvent être plus contraignantes.
Il faut pouvoir identifier rapidement les erreurs de chargement quotidien et anticiper les futures intégrations.
La connexion avec un outil tiers est une partie relativement technique d’un projet de mise en œuvre d’un outil EPM. Pour répondre rapidement au besoin de chargement d’une source, il faut en premier lieu permettre à la direction financière de charger elle-même un fichier de type CSV, parce que le projet d’intégration n’a pas encore abouti ou parce qu’il s’agit d’une opération manuelle ou ponctuelle.
Par ailleurs, même si ce n’est pas l’idéal de l’automatisation auquel on aspire, la question est aussi la suivante : compte tenu de la charge de mise en œuvre, de maintenance, du coût de licence, etc, le chargement automatique présente-t-il un bénéfice par rapport au chargement manuel ? Dit autrement, faut-il mener un projet technique d’intégration pour remplacer une tâche manuelle peu consommatrice de temps ?
Si la réponse est oui, et pour anticiper les besoins, il faut vérifier que les futurs outils pourront s’intégrer avec votre solution EPM grâce à l’existence de méthodes nombreuses (par fichier, connexion directe, Web services), une ouverture large des bases de logiciels propriétaires et la possibilité de faire évoluer les règles de transformation (tables de correspondance, SQL, etc.). Dit autrement, si une nouvelle source vient remplacer une ancienne, il faut vérifier qu’il sera possible de réutiliser ce qui peut l’être dans le flux complet ; des règles de transformation jusqu’au modèle de données.
Enfin il faut pouvoir maintenir l’intégration avec les outils existants. En particulier, la gestion des tables de correspondance (« mapping »), qui permettent de transformer le référentiel d’un système « source » vers celui de votre solution EPM, doit être accessible et rapide. Par exemple, si un nouveau compte comptable a été créé dans votre ERP, il faut pouvoir identifier rapidement si celui-ci n’a pas été « mappé » avec une nature budgétaire de l’EPM, créer ce mapping et relancer le chargement. Ceci est vrai aussi en cas d’export de données.
Quel est le risque ?
Le risque d’un manque de flexibilité sur la question de l’intégration, dans la durée, est la succession de projets d’intégration technique relativement lourds, ou une gestion manuelle des chargements à partir de fichiers. Si les tables de correspondance sont difficiles à gérer, les conséquences peuvent être de longs délais dans la mise à jour des données dus aux corrections successives ou de mauvaises imputations au chargement qui obligent à supprimer les données, corriger et recharger les données. Mais encore faut-il se rendre compte de l’erreur d’imputation…
7. L’architecture technique
Évoquons les deux cas de figure principaux rencontrés actuellement : « on-premise », qui consiste pour l’entreprise à administrer ou faire administrer les serveurs et la base de données, et « cloud », qui consiste à laisser l’éditeur s’en charger à partir de plateformes mutualisées. Il existe aussi des cas où l’éditeur se charge d’administrer un serveur pour le compte du client, ceux où la base de données est « on-premise » mais l’applicatif en « cloud », etc. Nous n’aborderons pas ici les avantages et inconvénients de chacun mais les points à contrôler.
En premier lieu on étudiera la fréquence et la charge des mises à jour du logiciel : celle incombant aux équipes techniques et aux utilisateurs clés. La solution est-elle indisponible à chaque mise à jour et combien de temps ? Faut-il refaire une recette complète ou non (« tests de non-régression ») ? Ceci implique-t-il de former les utilisateurs ?
Quelles sont les perspectives de déploiement interne et la « roadmap » de l’éditeur ?
Par ailleurs, il est utile de traiter les aspects de volumétrie et de performance. Que se passera-t-il si le volume de données devient important ou si le nombre d’utilisateurs vient à augmenter au fil du temps. Quels temps de réponse et quels prix de licences ? Quelles sont les solutions pour réduire la volumétrie des données inutilisées ou accélérer les performances (in-memory, agrégats, etc) ?
Parmi les questions techniques à poser : Si l’outil utilise MS Office, quelles sont les versions pertinentes et comment peut-on anticiper la montée de version de MS Office ou de l’OS rendue nécessaire par l’outil EPM ? Dans le cas où apparaîtraient des besoins que l’outil ne sait pas couvrir, est-il possible de l’étendre avec des développements spécifiques ? Est-il possible d’appliquer des modifications dans les objets du logiciel EPM pour les tester mais sans impacter immédiatement la solution opérationnelle ?
Enfin, on vérifiera avec l’éditeur quelle est sa stratégie autour du produit. L’histoire des solutions EPM est pleine de rebondissements : des rachats, des disparitions, des changements de technologie, etc. Évoquons pour mémoire : le rachat de Cognos par IBM, le rachat et la suppression de Clarity Systems par IBM, la disparition de Microsoft Performance Point, le remplacement supposé de SAP BW-IP par Outlooksoft (initialement sur SQL Server, renommé BPC et recréé sur NetWeaver) avant de voir son retour, mixé avec le front-end de BPC et la base de données HANA, l’apparition des nouvelles solutions cloud telles SAP BusinessObjects Cloud, Anaplan, AssignUp et Adaptive Insights, etc.
On vérifiera auprès de l’éditeur et d’experts indépendants si le choix de la solution est pertinent compte tenu des évolutions technologiques du secteur et de la stratégie de l’éditeur.
Quel est le risque ?
Une mauvaise anticipation sur les aspects techniques peut avoir des conséquences sur les performances, des limites en termes d’utilisation (réduction du nombre d’utilisateurs, de dimensions) et des surcoûts inattendus (mise à jour des postes, projets techniques d’optimisation, serveurs ou licences supplémentaires, etc.).
En conclusion, les outils EPM doivent répondre à une double contrainte : la flexibilité et la rigueur. Pour ce faire, ils proposent en général une « boite à outil » où chaque client peut créer son propre modèle personnalisé, ses écrans de saisie, ses dimensions, ses rapports, etc. Ces solutions sont de plus en plus séduisantes au premier contact, pour convaincre les clients de la facilité de mise en œuvre lors des phases commerciales, mais elles doivent aussi être efficaces dans la durée, sans effort technique et sans surcoût, compte tenu des évolutions possibles des besoins et de l’environnement. En combinant ces qualités, elles permettent aux directions financières des gains de productivité importants et le développement de leur rôle central dans l’organisation.
Les médias du groupe Finyear
Lisez gratuitement :
FINYEAR
Le quotidien Finyear :
- Finyear Quotidien
Sa newsletter quotidienne :
- Finyear Newsletter
Recevez chaque matin par mail la newsletter Finyear, une sélection quotidienne des meilleures infos et expertises en Finance innovation & Digital transformation.
Ses 4 lettres mensuelles digitales :
- Le Directeur Financier
- Le Trésorier
- Le Credit Manager
- The Chief Digital Officer
Finyear magazine trimestriel digital :
- Finyear Magazine
Un seul formulaire d'abonnement pour choisir de recevoir un ou plusieurs médias Finyear
BLOCKCHAIN DAILY NEWS
Le quotidien Blockchain Daily News :
- Blockchain Daily News
Sa newsletter quotidienne :
- Blockchain Daily News Newsletter
Recevez chaque matin par mail la newsletter Blockchain daily News, une sélection quotidienne des meilleures infos et expertises en Blockchain révolution.
Sa lettre mensuelle digitale :
- The Chief Blockchain Officer
FINYEAR
Le quotidien Finyear :
- Finyear Quotidien
Sa newsletter quotidienne :
- Finyear Newsletter
Recevez chaque matin par mail la newsletter Finyear, une sélection quotidienne des meilleures infos et expertises en Finance innovation & Digital transformation.
Ses 4 lettres mensuelles digitales :
- Le Directeur Financier
- Le Trésorier
- Le Credit Manager
- The Chief Digital Officer
Finyear magazine trimestriel digital :
- Finyear Magazine
Un seul formulaire d'abonnement pour choisir de recevoir un ou plusieurs médias Finyear
BLOCKCHAIN DAILY NEWS
Le quotidien Blockchain Daily News :
- Blockchain Daily News
Sa newsletter quotidienne :
- Blockchain Daily News Newsletter
Recevez chaque matin par mail la newsletter Blockchain daily News, une sélection quotidienne des meilleures infos et expertises en Blockchain révolution.
Sa lettre mensuelle digitale :
- The Chief Blockchain Officer