Faire venir la donnée aux décideurs : d'un ERP fermé à un reporting automatisé

Le projet en 30 secondes

1. Tout est dans l'ERP. Mais ça ne veut pas dire que l'information est disponible.

Ce projet est parti d'une situation que je trouve assez classique.

L'entreprise possède énormément de données:

Les dossiers sont dans l'ERP. Les données financières sont dans l'ERP. Les informations opérationnelles sont dans l'ERP.

Sur le papier, tout est là, mais pourtant, lorsqu'un manager voulait obtenir une information précise, le processus pouvait rapidement devenir beaucoup plus long.

Il fallait faire une demande à la personne ou au service ayant accès aux bonnes données.

Cette personne devait ouvrir l'ERP, lancer les bonnes extractions, récupérer les fichiers, les nettoyer, les retravailler dans Excel, construire ou actualiser un tableau croisé dynamique, appliquer les bons filtres puis transmettre le résultat.

Selon les disponibilités et la complexité de la demande, obtenir une réponse pouvait donc prendre du temps.

Le plus frustrant était que le problème recommençait à la demande suivante.

Les données existaient toujours.

Mais il fallait refaire une partie du chemin permettant de les transformer en information exploitable.

C'est là que j'ai commencé à me poser une question assez simple :

Pourquoi aller chercher manuellement une information à chaque fois, alors qu'on pourrait construire une fois le chemin qui permet à cette information de venir jusqu'à nous ?

2. Faire venir la donnée plutôt qu'aller la chercher

Cette idée ne m'était pas complètement étrangère.

Lors d'une expérience précédente dans un environnement Data beaucoup plus structuré, j'avais découvert quelque chose qui avait changé ma manière de regarder Excel et le reporting.

Un fichier Excel n'était pas obligé d'être alimenté par quelqu'un qui télécharge un fichier, le copie au bon endroit et recommence la semaine suivante.

Il pouvait être connecté à une source.

Power Query pouvait récupérer la donnée, la transformer et alimenter le reste du fichier.

Cela paraît évident lorsqu'on travaille quotidiennement avec ces outils.

Ça l'était beaucoup moins pour moi lorsque je l'avais découvert.

Et surtout, cela change complètement la question.

Je ne cherchais plus à construire :

un meilleur fichier Excel.

Je cherchais à construire :

un chemin fiable entre la donnée source et l'utilisateur final.

C'était l'idée.

Restait un petit problème : l'ERP n'avait absolument pas été conçu pour me faciliter la tâche.

3. Premier obstacle : un ERP très fermé

L'accès aux données était beaucoup plus contraint que dans l'environnement Data que j'avais connu auparavant.

Pas de connexion Power Query évidente.

Pas d'accès direct à la base.

Pas d'API facilement exploitable dans le cadre de mon projet.

J'ai donc commencé par explorer les solutions plus classiques.

Pouvait-on construire une connexion directe ?

Passer par une couche Data ?

Utiliser une solution proposée autour de l'ERP ?

Techniquement, différentes pistes pouvaient exister. Mais elles n'étaient pas nécessairement accessibles, adaptées ou proportionnées au besoin.

Il fallait donc trouver autre chose.

Et surtout, il fallait travailler avec ce que j'avais réellement à disposition.

Une chose était certaine :

l'ERP savait exporter des CSV.

À ce moment-là, ça ressemblait simplement à une fonctionnalité d'export.

C'est finalement devenu la porte d'entrée de toute l'architecture.

4. Le déclic est venu du stockage des exports

J'ai commencé à travailler avec plusieurs extractions.

Trois requêtes notamment m'intéressaient parce qu'elles contenaient des informations complémentaires : financières, comptables et opérationnelles.

Je pouvais donc lancer mes requêtes dans l'ERP et obtenir mes CSV.

Mais ces exports n'étaient pas obligés de rester de simples fichiers à manipuler manuellement.

Un emplacement intermédiaire accessible depuis mes outils de travail permettait de récupérer les fichiers générés par l'ERP.

C'était le pont qu'il me manquait.

D'un côté, j'avais un ERP dont l'accès direct à la donnée était limité.

De l'autre, Excel et Power Query.

Entre les deux, les exports CSV pouvaient servir d'interface.

Je n'avais pas besoin de créer une intégration complexe entre les deux systèmes.

Le chemin pouvait être construit à partir des mécanismes déjà disponibles.

5. Connecter Power Query directement aux exports

Une fois ce pont identifié, j'ai ouvert Excel.

Puis Power Query.

Au lieu d'importer manuellement le contenu d'un CSV dans un classeur, j'ai créé une connexion vers les fichiers présents dans l'emplacement intermédiaire.

Premier fichier.

Puis deuxième.

Puis troisième.

Je disposais maintenant de trois requêtes Power Query correspondant aux différentes extractions de l'ERP.

À partir de là, tout changeait.

Les CSV n'étaient plus des livrables qu'il fallait ouvrir et manipuler.

Ils devenaient des sources de données.

Power Query pouvait aller les chercher.

Je pouvais ensuite appliquer les transformations nécessaires :

• supprimer ce qui n'était pas utile ;

• normaliser les formats ;

• corriger les types de données ;

• préparer les champs nécessaires aux analyses ;

• harmoniser les différentes sources.

Les trois extractions possédaient également des informations permettant de les rapprocher.

J'ai donc commencé à les fusionner.

Trois requêtes indépendantes sont progressivement devenues un dataset cohérent.

Cette étape a été importante parce qu'elle m'a fait comprendre que je pouvais aller beaucoup plus loin que mon besoin initial.

J'avais désormais une chaîne permettant de récupérer et transformer automatiquement une partie importante de la donnée.

Restait à décider ce que j'allais en faire.

6. Ne pas recréer le même problème dix fois

La solution la plus évidente aurait été de construire directement un dashboard à partir de ces requêtes.

Puis un deuxième.

Puis un troisième.

Mais cela aurait progressivement créé une nouvelle version du problème initial.

Chaque fichier aurait possédé sa propre logique.

Chaque nouveau reporting aurait dû récupérer, transformer et gérer ses données.

Et au bout d'un moment, j'aurais eu plusieurs fichiers différents qui reconstruisaient chacun une partie du même travail.

Je voulais quelque chose de plus central.

L'idée a donc été de créer une base historique de référence.

Pas une base de données au sens traditionnel du terme.

Un fichier central suffisamment structuré pour jouer ce rôle dans l'environnement dont je disposais.

J'y ai intégré environ deux années d'historique issues des différentes extractions.

Cela représentait un volume significatif de données consolidées.

Ce fichier n'avait pas vocation à être un joli dashboard, il devait faire une chose et la faire correctement :

conserver une version propre, consolidée et réutilisable de la donnée.

Ensuite, les différents outils de reporting pouvaient venir se connecter à lui.

Ce choix a complètement changé la logique du système.

Un nouveau besoin de reporting ne signifiait plus forcément :

« Repartons de l'ERP. »

Il pouvait simplement signifier :

« Connectons-nous à la donnée que nous avons déjà préparée. »

7. Deux années d'historique, oui. Les réextraire tous les mois, non.

Une fois la base centrale construite, un autre problème est apparu.

Importer deux années d'historique une première fois est acceptable.

Recommencer à chaque actualisation ne l'est pas.

Cela aurait été lent, inutile et difficile à maintenir.

J'ai donc construit une logique différente.

L'historique existant reste en place.

Lors d'une nouvelle actualisation, seules les périodes récentes nécessaires sont extraites.

Les nouvelles données sont ensuite comparées à l'existant avant d'être intégrées.

Une logique de contrôle et d'anti-doublons permet d'éviter d'ajouter plusieurs fois les mêmes enregistrements.

J'ai notamment utilisé VBA pour automatiser certaines de ces opérations.

Le principe devient alors :

historique existant + données récentes contrôlées = nouvel historique.

Et non :

suppression de tout + réimportation de deux ans.

C'est une petite différence d'architecture qui devient très importante lorsque le volume commence à augmenter.

8. À ce stade, je n'avais toujours pas construit de dashboard

Et c'est justement ce que je trouve intéressant dans ce projet.

Une grosse partie du travail était déjà faite avant même de choisir le premier graphique.

Le chemin entre l'ERP et Excel existait.

Les différentes sources étaient nettoyées.

Les données étaient rapprochées.

L'historique était centralisé.

La logique d'actualisation existait.

Maintenant seulement, il devenait pertinent de réfléchir à la restitution.

J'ai donc construit un premier outil de pilotage autour de cette base.

Le fichier venait récupérer avec Power Query uniquement les données dont il avait besoin.

Puis ces données étaient chargées dans Power Pivot.

Et une nouvelle étape du projet commençait.

9. Construire un modèle de données plutôt qu'un énorme tableau

Lorsque les données commencent à être nombreuses et que les analyses se multiplient, travailler directement dans une seule immense table devient rapidement limitant.

J'ai donc construit un modèle en étoile.

Au centre : les données principales.

Autour : différentes dimensions permettant de les analyser.

Par exemple :

• une dimension Date ;

• une dimension Client ;

• une dimension Fournisseur ;

• et d'autres axes nécessaires aux analyses.

Les relations entre ces tables permettaient ensuite au modèle de comprendre comment les différentes informations étaient liées.

Schéma conceptuel d'un modèle en étoile, les données sont inventées

À partir de ce modèle, j'ai commencé à construire les mesures nécessaires avec DAX:

Totaux.

Répartitions.

Comparaisons temporelles.

Indicateurs de pilotage.

Analyses par client, période, fournisseur ou autres dimensions métier.

C'est ici que Power Pivot devient particulièrement puissant.

Une fois le modèle correctement construit, il devient possible de regarder la même donnée sous de nombreux angles sans reconstruire les calculs à chaque fois.

10. Et seulement maintenant : les graphiques

Une fois la couche Data prête, construire le dashboard devenait presque la partie visible de l'iceberg.

J'ai utilisé les outils que les utilisateurs connaissaient déjà :

Excel, tableaux croisés dynamiques, graphiques et segments.

Les différents TCD reposaient sur le même modèle de données.

Les filtres permettaient d'explorer l'activité.

Les mesures DAX calculaient automatiquement les indicateurs.

Et certaines interactions supplémentaires pouvaient être simplifiées avec VBA.

L'utilisateur final n'avait évidemment pas besoin de comprendre tout ce qui se trouvait derrière.

Il voyait simplement un dashboard.

Il pouvait sélectionner une période.

Choisir un client.

Comparer différents éléments.

Changer un filtre.

Et surtout :

actualiser

11. Le bouton « Actualiser » est presque la finalité du projet

J'aime beaucoup cette idée parce qu'elle résume finalement le projet entier.

Pour l'utilisateur final, la meilleure automatisation est souvent celle qu'il ne voit pas.

Il n'a pas besoin de savoir qu'il existe plusieurs extractions.

Il n'a pas besoin de comprendre les jointures Power Query.

Il n'a pas besoin de connaître la structure de l'historique.

Il n'a pas besoin de savoir comment fonctionne le modèle Power Pivot.

Il n'a pas besoin de lire une mesure DAX.

Il veut simplement pouvoir répondre à sa question.

C'est tout.

Le système complexe est derrière.

L'expérience utilisateur, elle, doit rester simple.

Actualiser → filtrer → comprendre.

C'est ce contraste entre la complexité du flux et la simplicité du résultat qui m'intéresse particulièrement dans ce projet.

12. Une fois le pipeline construit, le premier dashboard n'est plus la finalité

Le premier reporting a permis de répondre à un besoin concret.

Mais la vraie valeur du travail réalisé se trouvait ailleurs.

J'avais maintenant une source centrale réutilisable.

Cela signifiait qu'un nouveau besoin n'obligeait plus nécessairement à reconstruire tout le chemin depuis l'ERP.

Un autre fichier pouvait venir interroger l'historique.

Un autre reporting pouvait utiliser une partie différente de la donnée.

Une nouvelle analyse pouvait être construite sans demander une nouvelle extraction complète.

Le pipeline devenait donc progressivement une brique commune à plusieurs usages.

Et c'est là que le temps investi au départ commence réellement à produire de la valeur.

On ne construit plus seulement un fichier.

On construit une infrastructure légère permettant d'en créer plusieurs.

13. Le résultat : passer de « demander » à « actualiser »

Le changement le plus important n'est pas le nombre de graphiques disponibles.

C'est la manière d'accéder à l'information.

Avant

Un manager a une question.

Il sollicite une fonction support.

La bonne extraction doit être lancée.

Les données doivent être préparées.

Un fichier ou un TCD doit être produit.

Puis l'information peut être transmise.

Après

Le manager ouvre son outil.

Il actualise les données.

Il applique ses filtres.

Il obtient son information.

Mais le changement de fonctionnement, lui, est très concret.

Une partie des demandes répétitives peut disparaître.

Les fonctions support peuvent consacrer moins de temps à reproduire des extractions similaires.

Et les managers gagnent en autonomie pour explorer les informations dont ils ont besoin.

14. Le système n'était pourtant pas encore totalement automatisé

À ce stade, j'avais automatisé une grande partie du chemin.

Mais pas tout.

Il restait une intervention humaine importante tout au début :

quelqu'un devait encore ouvrir l'ERP et lancer les extractions CSV.

Une fois les fichiers disponibles, le reste du pipeline pouvait prendre le relais.

Mais ces quelques clics existaient toujours.

Et plus j'utilisais les données de l'ERP dans différents projets, plus cette étape devenait agaçante.

Toujours la même séquence d'actions.

Toujours les mêmes manipulations répétitives.

Je me suis donc posé exactement la même question que pour le reste du projet :

si cette tâche est toujours identique, pourquoi est-ce encore moi qui la fais ?

Cette question donnera naissance à un autre projet : la construction d'un robot RPA capable de piloter directement l'ERP et de réaliser lui-même certaines extractions.

15. Les limites font partie de l'architecture

Comme pour l'application métier que j'ai développée sur un autre projet, je ne considère pas que cette architecture soit parfaite.

Elle est adaptée à un environnement et à un besoin.

Elle dépend encore d'exports CSV.

Elle utilise Excel comme une partie importante de l'écosystème.

Elle possède donc les limites naturelles d'Excel lorsque le volume et la complexité augmentent.

La structure des exports doit également rester suffisamment stable pour que les transformations continuent à fonctionner correctement.

Et dans un environnement disposant d'une infrastructure Data moderne totalement accessible, je ne construirais probablement pas exactement le même système.

Mais ce n'était pas l'environnement disponible.

C'est une distinction qui me paraît importante.

La meilleure architecture théorique n'est pas toujours la meilleure solution pour une entreprise donnée.

Parfois, la bonne solution consiste à utiliser intelligemment les outils déjà présents pour supprimer rapidement une quantité importante de travail manuel.

C'est exactement ce que ce pipeline cherchait à faire.

16. Ce que je retiens de ce projet

Ce projet m'a confirmé quelque chose que j'avais commencé à comprendre lors d'une expérience précédente :

un dashboard ne commence pas par un graphique.

Il commence beaucoup plus loin derrière.

À l'endroit où la donnée est créée.

Puis il faut comprendre comment elle sort.

Où elle passe.

Comment la récupérer.

Comment la nettoyer.

Comment la rapprocher d'autres informations.

Comment conserver son historique.

Comment la modéliser.

Et seulement après, comment l'afficher.

C'est pour cette raison que je trouve parfois étrange de commencer un projet de reporting par :

« Qu'est-ce qu'on veut mettre sur le dashboard ? »

Bien sûr que la question est importante.

Mais j'aime commencer encore plus tôt :

« Où se trouve l'information et combien d'interventions humaines sont nécessaires avant qu'elle arrive jusqu'au dashboard ? »

Parce qu'on peut construire le plus beau Power BI ou le plus beau fichier Excel du monde.

S'il faut trois heures de manipulations avant de pouvoir l'actualiser, une grosse partie du problème est toujours là.

Sur ce projet, le dashboard est donc presque la partie la moins importante.

Ce que j'ai réellement construit, c'est le chemin permettant à la donnée d'arriver jusqu'à lui.

Et si vos équipes passent encore leur temps à préparer la donnée ?

Extraire un CSV.

Le nettoyer.

Copier des colonnes.

Fusionner plusieurs fichiers.

Recréer le même TCD.

Envoyer le résultat.

Puis recommencer la semaine suivante.

Ces actions prises individuellement semblent souvent trop petites pour justifier un projet.

Mais lorsqu'elles sont répétées par plusieurs personnes, toutes les semaines ou tous les mois, elles finissent par représenter énormément de temps.

C'est précisément ce que je cherche dans un processus :

les manipulations que tout le monde considère comme normales simplement parce qu'elles ont toujours été faites comme ça.

Puis j'essaie de construire le chemin qui permettra de ne plus avoir à les faire.