Une approche adaptative pour évaluer les besoins de contrôle de gestion dans une entreprise

Une approche adaptative pour évaluer les besoins de contrôle de gestion dans une entreprise

Introduction

Dans la norme UNI 11618, liée à la figure de l’expert en contrôle de gestion, on parle de compétences liées aux outils informatiques, car le contrôleur les utilise quotidiennement et doit donc avoir des notions liées à ce domaine, qui partent de l’architecture de l’information, à l’ERP, en passant ensuite par celles spécifiques au contrôle de gestion, à l’informatique individuelle, sans oublier les statistiques appliquées, la Business Intelligence, le Big Data et l’Intelligence Artificielle, des sujets très actuels et de plus en plus importants. Dans la norme sont donc également indiquées les compétences et sensibilités « numériques » qui doivent être complémentaires pour la réalisation d’objectifs importants d’un contrôleur qualifié et professionnel, comme, par exemple, l’utilisation d’outils d’information pertinents, le contrôle du système de collecte des données et des systèmes d’information connexes, la capacité et la flexibilité dans l’utilisation de différents langages (informatiques et non informatiques). La composante informatique est donc fondamentale pour les activités d’un contrôleur qui doit s’interfacer quotidiennement avec des sujets qui utilisent différents systèmes de gestion, qui doit être capable d’interagir avec des experts en informatique afin de pouvoir apporter son soutien dans la résolution des problèmes liés aux outils et apporter sa contribution à l’amélioration du système et des processus de gestion. C’est dans cette optique qu’a été développé le projet « Sélection de logiciels« , un groupe de travail constitué par des experts du secteur en collaboration avec Assocontroller, dans le but de fournir un outil d’analyse des différents produits offerts par le marché ; les participants ont défini les « paramètres » qu’ils considèrent utiles pour évaluer les logiciels de contrôle de gestion afin de soutenir tous ceux qui ont l’intention de changer leur système de gestion ou qui doivent en choisir un parmi ceux disponibles sur le marché national et international.

Développement du projet

Le point de départ a été d’essayer de comprendre les besoins réels des entreprises pour mettre en place un outil de gestion en leur sein, et pour ce faire, nous avons dû procéder à la définition des principaux domaines fonctionnels qui opèrent dans ces réalités. En effet, au sein d’une même entreprise, il existe des fonctions qui ont des caractéristiques et des activités différentes des autres, de sorte qu’un logiciel, pour être considéré comme valide, doit pouvoir répondre à tous les besoins que chaque responsable de fonction manifeste dans son travail quotidien.

Les domaines thématiques qui ont été analysés par le groupe de travail sont les suivants :

    • .

    • Production
    • Ventes
    • Trésorerie
    • Logistique

.

Après avoir identifié les fonctions sur lesquelles se concentrer, nous avons procédé à l’identification des « dimensions » dans lesquelles diviser les domaines thématiques. Le marché, en effet, présente une constellation d’activités extrêmement différentes les unes des autres, en termes de taille, d’organisation, de gestion et de développement ; en outre, dans un même secteur, il peut y avoir des entreprises qui opèrent chacune avec leurs propres caractéristiques et produits spécifiques ; par conséquent, pour tester la validité d’un logiciel, il est nécessaire de le « lâcher » dans les différentes réalités, en essayant de voir comment il répond aux besoins variés et changeants des utilisateurs.

Les « dimensions » analysées pour ce projet étaient les suivantes :

  • Organisation. Compte tenu des différences considérables entre les entreprises ayant des volumes d’activité différents, le « chiffre d’affaires » a été pris comme paramètre de référence, de manière à déterminer trois catégories d’entreprises : les « petites » (avec un chiffre d’affaires inférieur à 2 M€), les moyennes (avec un chiffre d’affaires compris entre 2 et 50 M€) et les grandes (avec un chiffre d’affaires supérieur à 50 M€).
  • Modèle d’entreprise (avec un chiffre d’affaires supérieur à 50 M€).
  • Modèle commercial. En ce qui concerne le modèle économique, nous avons essayé de regrouper les entreprises en autant de catégories de taille représentant toutes les grandes réalités : uniquement commercial, uniquement services et productif et commercial.
  • Modèle économique.
  • Type de production.

L’étape suivante a consisté à identifier les éléments clés de chaque domaine thématique ; chaque fonction, en effet, étant différente et ayant des besoins distincts, nécessite un suivi avec ses propres paramètres et avec des unités de mesure spécifiques. Le projet est basé sur un modèle adaptatif, les besoins considérés comme importants pour chaque activité ne sont donc pas exhaustifs. Avec la phase de « test » et le « calibrage des poids », il s’agissait également de fournir un espace pour les modifications ou les ajouts que les utilisateurs pourraient souhaiter apporter pour le développement ultérieur de cet outil.

La Production, par exemple, a été divisée en deux macro-processus : « gestion logistique » et « traçabilité », pour ensuite vérifier les fonctionnalités possibles du logiciel envisagé pour chacun des deux processus. Pour les premiers, les variantes des coûts de personnel, la consommation standard et budgétaire des matériaux et la gestion des retraits/consommation du magasin ; pour les seconds, la détection des heures homme/machine, le budget de production, l’estimation des commandes/emplois, la prévision de production, le calcul du coût du produit en fin d’année, la gestion des non-conformités, les coûts de la non-qualité, le contrôle de la formation des employés et les variantes de l’efficacité standard et budgétaire.

En ce qui concerne Ventes, en revanche, nous avons essayé d’identifier les principales spécifications en examinant les aspects organisationnels, la gestion de scénarios et de commandes multiples (comme le suivi des campagnes publicitaires, des événements, etc.), l’intégration avec les systèmes CRM, la comparaison des données finales et budgétaires entre différents objets de référence (par exemple, les zones géographiques, les produits, les clients, les clients, etc.), la comparaison du coût de production, le calcul du coût final du produit, la gestion des coûts de non-conformité, le contrôle de la formation du personnel et les variantes d’efficacité standard et budgétaire. (par exemple, les zones géographiques, les produits, les clients, les canaux de vente, etc.) et au niveau global ; mais aussi en utilisant des drilldowns sur les données budgétaires (budget par zone géographique, par produit, par client, etc.), sur les données finales, sur la possibilité de construire des cubes multidimensionnels (par exemple : chiffre d’affaires du produit α par rapport au client A dans la zone géographique 1) et sur la formulation d’hypothèses, de plans et de budgets. En ce qui concerne l’analyse, le logiciel doit pouvoir calculer les écarts (de volumes, de prix, de mix), les marges (par produit/service, par client, etc.), les KPI adaptés à la mesure des performances de l’entreprise et garantir également un système de reporting « sur mesure » (compte de résultat par produit, par client, etc.).

Pour la Trésorerie, cinq macro-processus ont été identifiés : 1) le contrôle et le suivi de l’activité de la Trésorerie, en fonction des objectifs prédéfinis ; 2) l’analyse des relations avec les banques ; 3) le suivi des coûts de la Trésorerie ; 4) un système d’indicateurs de performance ; 5) l’analyse des risques. Pour évaluer le logiciel de contrôle et de suivi des activités de trésorerie, il est nécessaire de vérifier si l’outil prévoit également la rédaction automatique du tableau des flux de trésorerie, du tableau de financement et de la position financière nette. Un logiciel valable, en effet, doit permettre à l’utilisateur de charger le budget de la trésorerie, le cash-flow, la position financière nette, de télécharger les rapports correspondants et d’analyser les écarts. En ce qui concerne les relations avec les banques, les spécifications contrôlées sont : les découverts, les instruments utilisés pour couvrir les risques de change, le contrôle des relevés de compte (en particulier de la bonne application des conditions contractuelles établies), le calcul du taux d’intérêt moyen en date de valeur et les frais de compte. En ce qui concerne le suivi des coûts de la trésorerie, les variables examinées sont l’incidence sur le chiffre d’affaires, les frais de personnel, les consultants, les frais bancaires, les intérêts et les autres frais financiers en fonction des différents instruments financiers adoptés par l’entreprise. Le logiciel doit pouvoir gérer un système d’indicateurs de performance tels que le ratio de liquidité (ratio de test d’acidité), le ratio de disponibilité (ratio actuel), les jours de paiement des clients (DSO) et les jours de paiement des fournisseurs (DPO), les jours en stock (DIO), le cycle de conversion de la trésorerie (CCC), la rotation du crédit, le ratio de la dette financière et l’indépendance financière. Enfin, compte tenu des nouvelles exigences introduites par la loi sur la crise des entreprises, un système de contrôle de la gestion de la trésorerie doit également être en mesure de calculer le DSCR (Debt Service Coverage Ratio) afin de mettre l’entreprise en mesure de remplir les obligations prescrites concernant la valeur que prend cet indicateur. Comme dernière spécification, la possibilité de pouvoir analyser le risque par le biais de contrôles des premières notes, des rapprochements bancaires, des relevés de comptes clients, des dettes envers les fournisseurs, des retenues à la source et des contributions payées ou à payer, ainsi que des modalités de paiement effectuées par rapport à celles envisagées.

L’activité de la Logistique doit pouvoir être contrôlée par l’analyse : des marchandises entrantes et sortantes (selon leurs différents types), des activités directes et indirectes du personnel, des inventaires, du calcul de la rotation des entrepôts, des délais et des temps d’arrêt. Pour le suivi des coûts dans le domaine de la logistique, les incidences sur le chiffre d’affaires ont été prises en compte : frais de personnel, frais d’expédition, consultants et frais de transport. Pour ce domaine également, il doit être possible d’analyser les objectifs fixés en fonction du budget de l’entrepôt, en établissant des rapports ad hoc avec les éventuelles divergences ; en outre, le logiciel doit également proposer une analyse des bons de livraison incorrects, des écarts entre les marchandises non conformes par rapport à celles qui sont arrivées et du temps du personnel en cas de non-conformité. Les indicateurs de performance qui peuvent être utiles pour cette fonction sont l’évolution du rapport entre le transport et les recettes, le pourcentage (%) d’expéditions non programmées, le délai moyen de livraison des produits dans l’entrepôt, les retards par rapport aux délais convenus et le niveau moyen des stocks.

Le dernier domaine à analyser est celui de la Recherche et développement, qui doit être suivi pour chacune de ses activités spécifiques et pour chaque projet, en fonction du risque encouru, ce qui permet d’analyser les coûts avec un système d’indicateurs de performance et d’évaluation des performances individuelles et collectives.

Après avoir défini les domaines d’analyse, on a établi les métriques à utiliser pour l’évaluation des paramètres, en attribuant un poids de 1 à 10 à chaque fonctionnalité requise par le domaine thématique spécifique. Le poids a ensuite été défini pour chaque valeur des trois dimensions (taille de l’organisation, modèle d’entreprise et type de production). Le résultat obtenu est un ensemble de scores, pour chaque caractéristique requise du logiciel d’application, qui a permis de déterminer un jugement final et global – grâce à l’utilisation d’un algorithme – sur l’efficacité et le degré de couverture de l’outil analysé.

Les notes qui peuvent être utilisées sont les suivantes :

  • Insuffisant
  • Suffisant
  • Bien
  • Excellent

Le choix d’utiliser seulement quatre jugements et non une échelle de 1 à 10, a été le résultat d’intenses raisonnements et comparaisons entre les membres du groupe, afin d’arriver à un champ plus restreint des mesures des poids pour obtenir des notes plus homogènes ; en outre, une plus grande possibilité de choix aurait déterminé une plus grande dispersion des jugements et le compromis de leur signification. La présence de trois jugements positifs et d’un seul jugement négatif facilite la pondération des poids ; en effet, si un sujet indique une spécification comme « insuffisante », celle-ci est considérée comme écartée ; on arrive ainsi à une mesure qui ne rend pas compréhensible pour les sujets concernés le poids réel de chaque jugement exprimé dans le système. Comme nous l’avons déjà mentionné, nous avons opté pour un modèle adaptatif afin d’améliorer et de développer l’outil grâce aux expériences et au retour d’information de ceux qui le testent ; par la suite, quelques années après la première évaluation, un questionnaire sera préparé, pour être reproposé aux utilisateurs, afin d’adapter les pondérations et les paramètres en fonction des jugements reçus. Les critères d’évaluation ont été donnés sur la base de l’expérience partagée des membres du groupe, mais seront révisés en fonction du retour d’information des différents tests qui seront réalisés ponctuellement.

Afin de mieux comprendre le fonctionnement de l’algorithme d’évaluation, l’ensemble du projet peut être analysé à l’aide d’un exemple : dans chaque macro processus de chaque domaine thématique, les spécifications appropriées ont été identifiées (par exemple, la traçabilité pour la production) auxquelles les évaluations relatives ont été associées avec une échelle de 1 à 10 selon leur importance, sur la base des différentes dimensions.

La section transversale relative à la dimension « entreprise » est présentée ci-dessous :

Ces notes ont été utilisées pour calculer le résultat maximal que la spécification individuelle pouvait atteindre : si, par exemple, la mention « excellent » était associée à une valeur de 6, la section ci-dessus deviendrait la suivante, multipliant ainsi l’échelle de 1 à 10 par le poids défini pour la note la plus élevée.

Pour arriver à la notation finale, on a donc pris la note de l’utilisateur pour une spécification donnée (dans cet exemple « suffisante »), et on lui a associé le poids défini pour l’algorithme (donc 2), multiplié par l’échelle initiale de 1 à 10 :

De cette manière, en additionnant ensuite toutes les valeurs de chaque colonne pour chaque spécification (ligne), on obtient le score obtenu par le logiciel, que l’on compare au résultat maximal calculé précédemment, ce qui permet d’obtenir la note finale.

Si l’on reprend l’exemple, le processus macro de production a obtenu 179 points pour une petite entreprise, 426 pour une moyenne et 511 pour une grande ; les notes les plus élevées qu’il aurait pu obtenir auraient été 234, 534 et 690. Si l’on ne tenait compte que de cette dimension, on pourrait donc dire que le classement du logiciel analysé est de 76% pour une petite entreprise, de 80% pour une moyenne et de 74% pour une grande ; l’algorithme, en revanche, a été conçu pour évaluer trois dimensions simultanément, dont les scores sont additionnés et comparés aux valeurs globales maximales.

En conclusion, sur la base de l’exemple cité, le logiciel testé a obtenu un score de 83% pour une grande entreprise opérant dans la production de masse (modèle économique).

Le modèle construit pour l’analyse de l’évaluation des logiciels a été conçu comme un outil qui évolue à travers les expériences et les commentaires reçus des utilisateurs, donc, dans un futur proche, les coefficients seront calibrés en fonction des réponses des utilisateurs. Le processus d’attribution de la note est réalisé en tenant compte de deux  » points de vue  » : le premier, celui du groupe de travail composé de professionnels du secteur qui ont établi les paramètres et les valeurs en fonction de leurs propres compétences acquises au cours des années d’activité ; le second, celui de ceux qui doivent s’interfacer quotidiennement avec l’outil d’analyse, avec leurs propres problèmes, points forts et utilisateurs qui ont des niveaux/éducation, mais aussi des expériences professionnelles différentes. L’objectif était donc de combiner les compétences techniques des experts avec les opinions de ceux qui s’occupent quotidiennement des logiciels de gestion.
En conclusion, l’objectif du projet est de le tester autant que possible, afin qu’il puisse être testé directement sur le terrain et modifié/corrigé si nécessaire, en tenant compte des besoins exprimés par ceux qui l’ont testé.

Les commentaires sont fermés.