2-M Logo2-M
Switch to English

Business Central · NAV · AX · Finance & Operations

Votre ERP enregistre très bien. Répondre est un autre métier.

Les chiffres sont dans la base, exacts et complets. Ce qui manque, c'est la couche qui leur redonne le sens que l'application ajoutait à l'affichage.
Business Central, en SaaS
BC
Dynamics NAV, sur site
NAV
Dynamics AX, sur site
AX
Finance & Operations, cloud
F&O

Le point de départ

Vos données sont justes. Leur sens reste à reconstruire.

Un ERP est conçu pour écrire vite et sans perte. Son modèle de données suit cette contrainte : les libellés sont rangés à part, les sociétés cloisonnées, les codes abrégés, et une partie de ce que l’utilisateur voit à l’écran est calculée au moment où il le regarde.

Une extraction fidèle des tables rapporte donc des données justes et inutilisables telles quelles. C’est le piège le plus fréquent : le rapport se construit, il affiche des nombres, personne ne voit d’erreur, et les totaux ne correspondent à rien de ce que le contrôle de gestion connaît.

Notre travail commence là. Reconstruire les calculs que l’application faisait, rapprocher les référentiels des différentes sociétés, et vérifier chiffre par chiffre avant que quiconque s’appuie dessus.

Les quatre

Ce qui change d'un ERP Microsoft à l'autre

Ils partagent une marque, pas un modèle de données. La voie de sortie et le piège principal diffèrent pour chacun.

Voies d'extraction et points de vigilance par ERP
ERPFormeComment sortir les donnéesLe piège principal
Business CentralSaaSAPI OData, ou export incrémental vers un lac de données quand les volumes dépassent ce que les quotas d’API acceptent.Les FlowFields, calculés à l’affichage, sortent vides de toute extraction.
Dynamics NAVSur siteAccès direct à la base SQL, sans intermédiaire ni quota, ce qui reste la voie la plus confortable.Un jeu de tables par société, préfixé par son nom : la consolidation se construit table par table.
Dynamics AXSur siteAccès direct à la base SQL, avec un modèle de données qui n’a rien de commun avec celui de NAV.Les sociétés cohabitent dans les mêmes tables, séparées par une colonne : un filtre oublié double les chiffres.
Dynamics 365 Finance & OperationsCloudSynchronisation vers Dataverse puis vers un lac ou vers Fabric ; la base applicative reste fermée.La forme des données publiées suit les entités, pas les tables : les correspondances se retrouvent.

Le cas le plus connu

Les FlowFields, et pourquoi ils sortent à zéro

Dans Dynamics NAV et Business Central, certains champs ne contiennent rien. Le solde d’un client, l’encours d’une commande, le stock disponible : ce sont des FlowFields, calculés à la demande à partir d’autres tables. Le champ existe dans la structure, la base ne le stocke pas.

Une extraction les rapporte donc vides, et le rapport construit dessus affiche des zéros ou des totaux partiels sans jamais signaler d’erreur. Nous les repérons à l’inventaire, nous lisons leur formule de calcul dans l’application, et nous les reconstruisons en mesures DAX, ce qui a l’avantage de les rendre lisibles et modifiables, ce qu’ils n’étaient pas.

Le terrain courant

Plusieurs sociétés, plusieurs ERP, un seul chiffre

Vos systèmes arrivent tels quels dans une première couche, horodatés. Une deuxième couche aligne les référentiels, plans de comptes, dimensions et clients, et tranche les doublons. Une troisième pose une définition unique par indicateur. Les rapports, Excel et vos applications lisent ensuite tous la même chose.

Ce qui ne change pas

Quatre chantiers communs aux quatre ERP

Quelle que soit la génération, les mêmes quatre sujets décident de la réussite du projet. Aucun n’est technique.

Les chantiers communs à toute consolidation d'ERP
Le chantierCe qui se joue
Le plan de comptesDeux entités qui codent différemment le même compte produisent deux totaux, tous les deux justes.
Les dimensions analytiquesCentre de coût, projet, activité : leur signification varie d’une entité à l’autre plus souvent qu’on ne le croit.
Les tiersLe même client porte plusieurs codes selon la société qui l’a créé. C’est le premier chantier d’une consolidation.
La profondeur d’historiqueUne reprise sur dix ans réveille des règles de gestion abandonnées depuis, et des exercices que personne ne sait plus expliquer.

Questions fréquentes

Ce qu'on nous demande sur la donnée d'ERP

Pourquoi la donnée d’un ERP demande-t-elle une compétence particulière ?

Parce qu'un ERP est construit pour enregistrer des transactions de façon sûre, pas pour répondre à des questions. Son modèle est normalisé pour l'écriture : les libellés vivent dans des tables séparées, les sociétés sont cloisonnées, et une partie des chiffres affichés à l'écran est calculée au moment de l'affichage plutôt que stockée. Extraire les tables donne donc des données exactes et inexploitables en l'état. Le travail consiste à reconstruire le sens que l'application ajoutait.

Que sont les FlowFields, et pourquoi posent-ils problème ?

Dans Dynamics NAV et Business Central, un FlowField est un champ dont la valeur est calculée à la demande à partir d'autres tables : le solde d'un client, par exemple, est la somme de ses écritures. Le champ existe dans la structure, il est vide dans la base. Une extraction le rapporte donc à zéro, et le rapport paraît fonctionner. Nous les repérons à l'inventaire, nous lisons leur formule de calcul, et nous les reconstruisons en mesures DAX dans le modèle sémantique.

Nous avons plusieurs sociétés sur le même ERP. Est-ce le même travail ?

Le raccordement, oui. L'alignement, non. Et c'est lui qui fait le projet. Il faut décider ce qu'un compte, une dimension et un client veulent dire pour l'ensemble, alors que chaque entité a construit ses codes indépendamment. Cet arbitrage se mène avec vos équipes financières et métier ; nous en sortons une table de correspondance, et une réconciliation chiffre par chiffre avant toute bascule.

Nos ERP sont différents d’une filiale à l’autre. Est-ce jouable ?

Oui, et c'est notre terrain le plus courant. Un NAV historique dans une filiale, un Business Central récent dans une autre, un AX ailleurs : chacun sort ses données par sa propre voie, puis tous rejoignent la même chaîne. Le point dur n'est pas la diversité des connecteurs, c'est de faire dire la même chose à des référentiels construits séparément.

Faut-il migrer vers Business Central avant de faire de la BI ?

Non, et c'est même souvent l'inverse qui rend service. Un projet décisionnel mené sur l'existant révèle l'état réel des référentiels et la façon dont les règles ont divergé, ce qui est exactement le travail de préparation d'une migration. Les entreprises qui enchaînent les deux dans cet ordre abordent la migration avec une cartographie qu'elles n'auraient pas eue autrement.

Travaillez-vous avec les intégrateurs qui déploient l’ERP ?

Régulièrement. Un intégrateur ERP connaît le métier de son client et le paramétrage de la solution ; la couche décisionnelle demande d'autres réflexes : modélisation dimensionnelle, arbitrage des règles et performance des modèles. Nous intervenons sur cette couche, aux côtés de l'équipe qui porte l'ERP, sans empiéter sur son terrain.

Deux heures pour regarder votre ERP et vous dire ce qui est faisable.

Onze collaborateurs expertsSaint-Priest, près de Lyon

Un atelier de cadrage avec un consultant : nous ouvrons votre inventaire de sources, nous repérons les FlowFields et les référentiels qui divergent, et nous vous donnons une architecture cible et un ordre de grandeur.

Demander un atelier de cadrage

Atelier de cadrage · 2 heures · offert · près de Lyon ou à distance

Nos technologies

Microsoft FabricPower BIPower AppsPower AutomateMicrosoft Partner