Selon l’enquête 2023 Finance Leaders Survey de Prophix, 92 % des responsables financiers ont déjà automatisé la moitié de leurs tâches quotidiennes ou espèrent les numériser d’ici la fin 2023.
Et vous, où en êtes-vous ?
Chez Limpida, la qualité est clé - nous appliquons ce principe simple à nos propres processus et avec au moins autant de rigueur à ceux de nos clients.
Cela veut dire que, surtout autour d’un sujet tel que l’accélération d’un processus, nous avons développé une méthodologie nous permettant de nous assurer à tout moment de la cohérence du résultat fourni.
Nous commencerons toujours par analyser et comprendre le processus existant. Cette phase d’analyse et de compréhension est cruciale pour tous les acteurs (même vos experts) afin de bien mesurer l’objectif de la démarche, les points potentiellement problématiques ainsi que l’ensemble des parties prenantes.
En parlant d’un processus tel que l’élaboration budgétaire, nous devons garder en tête que certes il s’agit de consolider rapidement beaucoup de données afin d’en tirer les bonnes conclusions - le tout sans oublier qu’à la fin (au moins avant l’arrivée de l’IA surpuissante) c’est l’être humain qui tire des conclusions et qui décide.
Cela veut dire également que lors de cette étape nous séparons les sujets data des sujets “humains” car s’ils représentent un point de friction, la façon de les traiter n’est absolument pas la même.
Une fois le processus analysé et compris, nous nous attaquerons avec vous à la construction d’un modèle de données cible.
Pendant cette étape nous nous poserons ensemble les questions pertinentes visant à nous assurer d’aboutir sur un modèle qui soit suffisamment complet pour répondre aux questions sans être trop chargé afin d’éviter toute complexité de compréhension.
Maintenant que l’on sait où on veut aller (ça semble évident mais il est important de le formaliser) nous allons commencer à rassembler les pièces du puzzle.
La mission sera de trouver pour toutes les parties de notre modèle de données cible une source adéquate permettant de l’alimenter en données, qu’elles soient internes ou externes - on saura l’intégrer dans notre processus !
Et maintenant - le vrai travail commence ! Pour l’instant nous aurons co-construit, défini, beaucoup réfléchi et imaginé des choses. Nous rentrons à ce moment dans la phase de production qui permettra d’obtenir la colonne vertébrale qui sera la logique de transformation et de consolidation des données de leurs sources jusqu’à la destination finale.
Pendant cette étape nous allons, fort de nos analyses précédentes, connecter les sources entre elles afin d’alimenter le modèle final en respectant les best practice en termes de modélisation.
Nous l’aurons dit - beaucoup de sources différentes, des règles de gestion, des calculs. Comment je m’assure que la donnée en sortie correspond bien à ce que nous souhaitons obtenir ?
Globalement on peut dire que l’on aurait deux choix - on se définit une routine de contrôle à effectuer manuellement (un peu chronophage mais ça peut marcher) ou alors on se dote d’un outil (l’exemple viendra un peu plus tard) qui permet d’automatiser cela pour nous. Cette étape consistera à définir des tests de cohérence à positionner tout au long de la chaîne de transformation qui nous informerons de façon automatisée de la moindre incohérence trouvée.
Là nous nous adressons au plus techniques parmi vous - la méthodologie que nous proposons repose sur des outils clés permettant de mettre même le code data sous contrôle de version - ainsi nous assurons une continuité de service maximale car même la modification la mieux anticipée peut entraîner des problèmes - si nécessaire on saura remonter dans le temps sans problème le temps de trouver la bonne solution.
Pour résumer, notre méthode s’appuie sur plusieurs concepts clés dont nous ne dérogerons pas - la co-construction avec nos clients, la compréhension des enjeux business et la qualité des données.
La méthodologie énoncée et expliquée repose sur notre expérience des années passées et s’articule autour d’un certain nombre d’outils informatiques indispensables à sa réussite. Un des outils que nous utilisons et recommandons vivement est DBT - Data Build Tool - brièvement énoncé auparavant.
Vous allez vous demander, que fait cet outil et en quoi peut-il nous aider ? Nous allons essayer de répondre aux deux questions de manière très simple à travers un exemple. Imaginons un cas assez classique - nous souhaitons extraire de notre ERP (SAP, SAGE, ...) le grand livre comptable afin de s’en servir comme point de départ pour la construction de notre budget. Nous sommes des grands admirateurs et utilisateurs d’Excel chez Limpida - dans ce cas précis nous atteindrons pourtant très rapidement sa limite.
Que va-t-il se passer ?
Dans notre fichier Excel, nous créons des onglets, des formules, des liens entre différents morceaux de notre donnée, nous en rajoutons et une des collaboratrices nous propose d’ajouter un axe d’analyse - excellente suggestion ! Seul problème, nous avons tellement bien avancé que changer notre fichier Excel serait vraiment difficile et comment vérifier que nous ne dégradons pas la qualité de nos données en le faisant ? Si nous devons tout vérifier à la main, nous y passerons notre week-end...
Vous vous êtes déjà retrouvé dans cette situation ? Pas de panique, vous n’êtes pas seul. Beaucoup de contrôleurs de gestion passent par là.
Tout d’abord, DBT (comme son nom l’indique) est un outil de construction - il s’insère sur une multitude de Data Warehouse, cloud ou on-premise. En utilisant cet outil, nous aurons principalement gagné sur trois points.
DBT propose (et met à jour lui-même) un graphique de dépendances entre les différents morceaux d’analyse que nous avons créés et combinés. Vous l’aurez compris, plus jamais vous partirez à la recherche de l’onglet que votre collaboratrice a masqué après avoir renommé sa plage. (avis aux amateurs d’Excel). Plus sérieusement, grâce à DBT vous pouvez ajouter l’axe d’analyse souhaité par votre collaboratrice, en ayant une vision très claire des impacts que cela aura sur votre modèle de données.
L’erreur est humaine il paraît - par conséquent nous en faisons tous. Est-ce que la bonne approche est la recherche du zéro erreur ? La France a essayé lors du dernier mondial, Messi l’a pourtant remporté avec l’Argentine. Fort de ce constat, essayons une autre approche qui serait la mise en place de tests réguliers à différents moment du processus de calcul. Or à moins d’avoir des fonds illimités, cela va rapidement coûter cher, au-delà du côté répétitif de la tâche.
Afin d’adresser cela DBT offre plusieurs tests standard à mettre en place (colonne unique, non vide...) et la capacité de développer ses propres tests métier. Une fois le modèle bien compris grâce au graphique de dépendances, nous allons traduire un maximum de règles de gestion en tests automatisés afin que la donnée soit validée à chaque mise à jour.
Reprenons notre exemple, et plus particulièrement l’ajout d’un axe d’analyse. Sécurisé par DBT, nous l’ajouterons sereinement à notre modèle de données et à défaut d’être sûr de ne pas faire d’erreur (ça arrive aux meilleurs), DBT nous dira où se trouve l’erreur. Il n’y aura pas de mise à jour avec des données fausses non maîtrisées et en plus nous aurons gagné du temps car nous pouvons corriger notre erreur de suite plutôt que de passer beaucoup de temps à la trouver.
Quoi ? Version comment ? Et pourquoi du code ?
Les amateurs de GitHub et compagnie peuvent sauter cette partie - seule information importante pour vous, DBT propose l’intégration native avec GitHub ou Lab selon vos préférences.
Pour les moins techniques parmi nos chers lecteurs, vous vous rappelez de votre fichier Excel VersionFinaleVraimentV32.5 ? Nous exagérons à peine, pourtant nous sommes tous passés par là, en faisant une modification on aimerait quand même bien garder une trace.
Merci aux développeurs DBT, ils ont mis en place exactement ce principe en mettant les requêtes SQL générées par DBT sous contrôle de version en utilisant les meilleurs outils du marché. En français cela veut dire que si nous faisons une erreur dans notre requête, ou mieux encore notre collaborateur, non seulement nous saurons précisément qui l’a faite (oui ça s’enregistre et oui on n’hésite pas à lui dire) mais surtout en quelques clics et sans sueur froide nous saurons revenir en arrière afin de faire mieux.
En résumé, et pour être honnête, comparer DBT à un fichier Excel est une caricature assez brutale car ce sont deux extrêmes. En revanche, elle permet de bien illustrer les bienfaits d’un outil pareil qui vous fera gagner du temps tout en favorisant la collaboration. Fini les comparaisons des versions de chacun pour savoir qui a raison.
Vous vous direz après tout ce qu’ils nous ont expliqués, pourquoi limites et précautions ? Malheureusement si, il n’existe pas de solution miracle non plus.
Tout d’abord quand on parle data il faut être conscient du fait que si vous mettez de l’incohérence à la source - à moins d’être magicien- vous aurez de l’incohérence à la sortie. Autrement dit, la première précaution à avoir consiste à toujours être très critique avec les sources que l’on utilise, surtout celles qui viendraient de l’extérieur.
Une autre limite à s’imposer est également la vigilance à ne pas abuser des tests. Comme ça devient facile d’en faire, on a vite fait d’en mettre partout et d’aller de plus en plus vers un niveau d’exigence très élevé. Or si plus rien ne se calcule parce que j’ai un écart d’arrondi d’un centime c’est quand même dommage.
En deçà des limites plutôt d’ordre technique, parlons de la plus grande à énoncer : l’humain. Qu’il s’agisse du développeur DBT ou du collaborateur comptable qui saisit dans l’ERP, la qualité des données doit être l'affaire de tous. Si vous voulez réellement aller vers l’excellence avec un modèle de données toujours disponible et robuste, n’oubliez pas qu’avant tout ce sont les femmes et les hommes dans votre entreprise qui le crée et l’alimente.
.png){kind=small}
