Redressement ERP dans le FMCG : un reporting unifié avec SAP Analytics Cloud

Cette étude de cas s'adresse aux directeurs financiers et aux responsables informatiques qui font tourner plus d'un ERP sans parvenir à obtenir un jeu de chiffres unique. En bref : un projet de reporting transfrontalier à l'arrêt, entre Oracle à Singapour et SAP au Royaume-Uni, a été redressé en six mois. Cinq choses l'ont permis. Un comité de pilotage réduit, doté d'une vraie autorité. Un périmètre ramené aux rapports qui pilotent les décisions. Des définitions communes aux deux systèmes. SAP Analytics Cloud comme couche de reporting unique. Et des relais locaux plutôt que de la formation en salle. Si vous êtes dans la même situation, commencez par la gouvernance et les définitions, pas par le débat sur l'outil.

L'histoire commence par un projet d'analytique ERP à l'arrêt dans un groupe FMCG (biens de grande consommation) bien connu, dont le siège est à Singapour. Le groupe détenait 26 % d'une entreprise britannique de boissons énergisantes. Malgré cette participation minoritaire, la maîtrise de la gestion revenait à Singapour : la stratégie arrêtée en Asie au niveau du conseil déterminait donc le reporting et la planification au quotidien en Europe.

La technologie compliquait les choses. Singapour utilisait Oracle ERP. Le Royaume-Uni utilisait SAP ERP. Chacun fonctionnait de son côté, et ensemble ils créaient un problème de reporting qui avait déjà englouti des mois d'efforts.

Les chiffres concordaient rarement. Les rapprochements s'éternisaient pendant des jours. Même le reporting de base sur le chiffre d'affaires donnait des résultats différents selon le système consulté.

Dans les six mois qui ont suivi le début de la mission de redressement, ce qui ressemblait à une initiative ratée est devenu un modèle de reporting transfrontalier auquel la finance et les opérations faisaient toutes deux confiance.

Avant le redressementAu relancement

GouvernanceAvant le redressementGrand comité de pilotage, décisions repousséesAu relancementSeulement les vrais décideurs, qui tranchent en réunion

PérimètreAvant le redressementUn tableau blanc de demandesAu relancementLes rapports qui pilotent les décisions

DéfinitionsAvant le redressementMême libellé, sens différent dans chaque ERPAu relancementChiffre d'affaires, coûts et marge validés

ReportingAvant le redressementRapprochement Excel qui prenait des joursAu relancementDonnées Oracle et SAP dans un seul modèle de SAP Analytics Cloud

AdoptionAvant le redressementFormation en salle, puis retour à ExcelAu relancementRelais locaux, une équipe à la fois

Le tableau résume la situation de départ et la façon dont chaque problème a été résolu.

Défi	Impact	Résolution avec SAP Analytics Cloud
Deux ERP : Oracle à Singapour, SAP au Royaume-Uni	Les chiffres ne concordaient pas ; le rapprochement prenait des jours	Les deux alimentaient un modèle de reporting unique
Responsabilité du reporting floue entre les pays	La stratégie en Asie entrait en conflit avec les données opérationnelles en Europe	Des KPI standard faisaient que les deux entités rapportaient les mêmes indicateurs
Reporting du chiffre d'affaires lent	Les chiffres variaient selon le système source, ce qui retardait les décisions	Une planification et un reporting unifiés ont raccourci le cycle
Planification désalignée	Singapour fixait la stratégie ; le Royaume-Uni exécutait sur d'autres hypothèses	Des modèles de planification partagés ont aligné les deux activités

Le reporting sur deux ERP

Avec Oracle à Singapour et SAP au Royaume-Uni, le reporting donnait l'impression de gérer deux entreprises distinctes. La finance extrayait le même indicateur de chaque système et obtenait des réponses différentes. Lors d'une revue mensuelle, Singapour a présenté un chiffre d'affaires, et le Royaume-Uni l'a aussitôt contesté avec un autre. La discussion a duré plus longtemps que la revue.

Les gens se repliaient sur Excel parce que cela paraissait plus sûr : des heures d'exports, de rapprochements et de fabrication de leur propre version de la vérité. À court terme, cela fonctionnait ; cela a créé des retards chroniques dans le reporting du groupe. Mon article sur les raisons pour lesquelles les directeurs financiers se rabattent encore sur Excel décrit ce schéma plus largement.

La consolidation de fin de mois

La fin de mois était le plus difficile. Un coût classé sous « opérations » dans un ERP se retrouvait parfois sous « administration » dans l'autre. J'ai vu un jour un brouillon de consolidation où la même dépense apparaissait deux fois sous des rubriques différentes. Cela a tué la confiance dans les chiffres. Les résultats tardifs sont devenus la norme, et quand le groupe publiait enfin, des révisions suivaient la plupart du temps.

Le reporting opérationnel

Les problèmes dépassaient la finance. Oracle suivait les expéditions, SAP suivait les stocks, et il n'existait aucune source unique. Un responsable d'entrepôt m'a raconté avoir reçu trois rapports de stock différents en une semaine, avec trois soldes différents. Il riait en le disant, mais cela ralentissait de vraies décisions. Le réapprovisionnement prenait du retard, et les retards d'expédition étaient plus difficiles à expliquer parce que les opérations ne se fiaient pas aux tableaux de bord.

Le débat sur l'outil

Choisir un outil de reporting est devenu un projet à part entière. Certains responsables appréciaient le profil de coût de Power BI ; d'autres poussaient pour SAP, à cause de sa feuille de route plus longue. J'ai assisté à un atelier dont la moitié du temps est passée sur « pourquoi SAC et pas Power BI » plutôt que sur les besoins de reporting. Le débat a duré des mois et a épuisé l'élan.

La résistance des utilisateurs

Même une fois les premiers tableaux de bord en ligne, l'adoption est restée faible. Je me souviens d'avoir regardé quelqu'un, pendant une réunion de la finance, ouvrir un tableau de bord, y jeter un œil, le fermer et retourner à sa feuille Excel. Personne n'y a trouvé à redire. Les gens faisaient confiance à ce qu'ils connaissaient, et les tableaux de bord n'avaient pas encore gagné cette confiance.

Remettre la gouvernance à plat. Les réunions semblaient interminables et les participants repartaient sans savoir qui avait tranché. La direction a réduit le comité de pilotage aux vrais décideurs. Les séances sont devenues plus courtes et plus décisives, et les escalades atteignaient vite les bonnes personnes. Ce n'était pas parfait, mais les choses ont commencé à avancer. Mon guide sur la conduite d'un comité de pilotage SAP expose les mêmes principes.

Reprendre le périmètre en main. On se disputait sans cesse sur les chiffres qui avaient leur place dans la vue du groupe, et la liste des exigences était devenue ingérable. Je me souviens d'un tableau blanc d'atelier couvert de demandes de bout en bout, dont la moitié sans lien avec une décision réelle. Le cadrage qui a fonctionné : le reporting n'a qu'à couvrir ce qui pilote les décisions. Une fois cela admis, la livraison a pris de la vitesse.

Une communication qui parle aux gens. Les premiers points d'avancement étaient génériques, si bien que la finance, les opérations et l'informatique en retiraient chacune une interprétation différente. Nous sommes passés à des points d'avancement sur mesure : les échéances de reporting pour la finance, les changements de processus logistique pour les opérations, une feuille de route technique pour l'informatique. Les gens ont commencé à poser de meilleures questions, parce que les messages parlaient leur langage.

Des relais locaux. La formation seule n'avait pas suffi : les gens suivaient les séances et retournaient à Excel le lendemain matin. Le changement est venu des relais locaux, des collègues déjà crédibles dans leur équipe, qui expliquaient les tableaux de bord de façon informelle, avec leurs propres mots. J'ai assisté à l'une de ces séances et la différence était frappante. Les gens posaient des questions qu'ils n'auraient jamais posées en salle de formation. L'adoption s'est améliorée une équipe à la fois.

Le tableau résume ce qui a changé et pourquoi cela a fonctionné.

Axe	Ce qui a changé	Impact
Remise à plat de la gouvernance	Comité de pilotage réduit aux vrais décideurs ; séances plus courtes et plus tranchées	Décisions prises en réunion ; escalades rapides
Maîtrise du périmètre	Exigences ramenées au reporting qui pilote les décisions	Moins de débats, modèles de données plus clairs, moins de cibles mouvantes
Communication sur mesure	Points d'avancement distincts pour la finance, les opérations et l'informatique	Chaque équipe a compris ce qui comptait pour elle ; la confiance est revenue
Relais locaux	Coaching entre pairs en petits groupes plutôt que formation formelle	L'adoption a progressé équipe par équipe ; la dépendance à Excel a baissé

Quand la sélection de l'outil s'est enfin conclue, SAC l'a emporté, en partie parce qu'il pouvait réunir les données Oracle et SAP dans un seul modèle sans gros développements spécifiques. Cela a fait retomber la tension du débat. Les rapports reflétaient les changements bien plus vite que l'ancien cycle d'exports. Une contrôleuse financière a dit que c'était la première fois qu'elle n'avait pas à attendre une actualisation nocturne des données pour commencer sa journée.

La première fois que le responsable financier a vu les données Oracle et les données SAP côte à côte dans un même tableau de bord, un poids s'est levé. Ce moment a clos le débat.

SAC couvrait aussi plus que la finance. Les opérations voulaient une vue de la logistique et des entrepôts, et les RH voulaient de la planification des effectifs. Avoir la planification, le reporting et la visualisation sur une seule plateforme a fait la différence entre un correctif tactique et une fondation durable. Les modèles prédéfinis ont donné à l'équipe une longueur d'avance, même si certains paraissaient génériques, et la rapidité de cette première livraison a rétabli la confiance après des mois de retard.

Un point technique si vous comptez reproduire cette conception. Les connexions de données en direct de SAC sont limitées aux sources SAP telles que SAP HANA, BW, S/4HANA, BPC embedded, les univers BusinessObjects et SAP Datasphere. Les données non SAP, comme celles d'un ERP Oracle, arrivent en général par une connexion d'import, un univers ou une couche de données intermédiaire. Décidez de cette architecture tôt, car elle détermine la fraîcheur des chiffres de chaque côté.

Le premier jalon a été le modèle de données. Oracle et SAP devaient alimenter une même structure, ce qui était plus difficile qu'il n'y paraissait. Des champs portaient le même libellé mais ne voulaient pas dire la même chose dans chaque système. Il a fallu des semaines de rapprochement des définitions avant que la finance s'accorde sur ce que signifiaient réellement le chiffre d'affaires, les coûts et la marge.

Les tableaux de bord ont été déployés par étapes. La finance d'abord, puis les ventes et les opérations, chacun avec des rapports construits autour de son travail réel. Les premières versions étaient trop rigides. Les utilisateurs l'ont dit, et ils avaient raison. Les tableaux de bord se sont améliorés, et des KPI validés ont remplacé ce qui était des disputes mensuelles permanentes.

Le relancement s'est terminé en six mois. Pour la première fois, les données Oracle et SAP se trouvaient dans un seul modèle au sein de SAC. Les disputes de rapprochement ont diminué, et les dirigeants examinaient les chiffres sans attendre la circulation de fichiers Excel.

Des cycles de planification qui prenaient des semaines ne prenaient plus que des jours. Les planificateurs pouvaient modéliser des scénarios et les comparer au réalisé. Certains responsables voulaient plus de détail que les tableaux de bord n'en donnaient, mais le simple fait qu'ils fassent confiance aux chiffres était déjà important.

Un responsable d'entrepôt a mentionné que, pour la première fois, les niveaux de stock de son rapport correspondaient à ce que montrait la finance. Cet alignement discret entre les services était le vrai indicateur. Personne n'a demandé à revenir à l'ancien processus.

Le tableau liste les erreurs qui ont bloqué le projet et l'enseignement de chacune.

Erreur	Ce qu'elle a provoqué	Enseignement
Gouvernance floue	Réunions sans fin, aucune décision, retards qui s'accumulent	Redéfinir tôt les rôles et les droits de décision
Dérive du périmètre	Les objectifs de reporting changeaient sans cesse	Garder un périmètre serré, lié aux décisions
Ignorer les utilisateurs	Les utilisateurs ont perdu confiance et l'adoption a ralenti	Impliquer les utilisateurs tôt et leur donner du contexte
Personnalisation excessive	Du temps perdu à reconstruire des rapports	Partir des modèles et des connecteurs standard ; personnaliser plus tard
Conduite du changement insuffisante	La formation a manqué sa cible ; les vieilles habitudes ont tenu	Faire intervenir tôt des relais locaux et du coaching entre pairs

Trois enseignements dominent les autres. La gouvernance compte plus que l'outil : sans responsabilité claire dans un environnement multi-ERP, le reporting s'effondre quelle que soit la plateforme. Alignez les définitions de données avant de choisir l'outil : le débat Power BI contre SAC passait à côté du sujet, car aucun outil ne répare des définitions qui ne concordent pas. Et la conduite du changement décide de l'adoption : sans relais ni communication ciblée, les tableaux de bord seraient restés inutilisés.

Trois choses changeraient si le même travail démarrait aujourd'hui.

Une couche de données s'intercalerait entre SAC et les sources. SAP Datasphere, qui fait désormais partie de SAP Business Data Cloud, donne un accès fédéré aux sources SAP et non SAP, avec un modèle sémantique par-dessus. Dans un cas à deux ERP comme celui-ci, harmoniser les données Oracle et SAP dans cette couche est plus propre que de le faire dans chaque story SAC. Cela donne aussi à SAC une connexion en direct au modèle harmonisé.

Les questions en langage naturel remplaceraient certaines constructions de tableaux de bord. La requête en langage naturel de SAC et Joule permettent à la finance de demander, par exemple, le chiffre d'affaires par région pour le trimestre, Singapour contre le Royaume-Uni. Aucune story n'a besoin d'être construite d'abord. Cela accélère le travail une fois les données harmonisées. Cela ne comble pas un écart de définitions.

La discussion commerciale partirait du contrat ERP. Vérifiez ce que votre contrat ERP cloud inclut déjà en matière d'analytique avant de négocier SAC. La planification complète de SAC fait l'objet d'une licence distincte, et les environnements hybrides, avec une entité sur un ERP cloud et une autre non, demandent toujours une analyse attentive des licences.

La remise à plat de la gouvernance, la discipline sur le périmètre, les relais locaux et la communication sur mesure ne changeraient pas. Ces schémas valent quelle que soit la technologie. Le travail humain qui consiste à faire rapporter les mêmes chiffres par deux ERP ne s'automatise pas. Pour en savoir plus sur SAC lui-même, consultez mon guide SAP Analytics Cloud.

Pourquoi le projet de reporting ERP de ce groupe FMCG s'est-il enlisé ?

Singapour tournait sous Oracle et le Royaume-Uni sous SAP, et chaque mois la finance recousait les chiffres à la main. Cela prenait des jours et personne ne se fiait entièrement au résultat. Les revues s'enlisaient quand Singapour présentait un chiffre et que le Royaume-Uni le contestait avec un autre. Le comité de pilotage était aussi trop grand, si bien que personne ne prenait de décision. Les coûts montaient, la confiance baissait et le projet dérivait.

Qu'est-ce qui a changé la direction du redressement ?

La direction a reconnu que le projet était bloqué et validé un plan de redressement. Le comité de pilotage a été ramené à un petit groupe de vrais décideurs, les priorités ont été fixées, SAP Analytics Cloud a été retenu comme outil de reporting unique, et la communication a été adaptée à chaque public. Les réunions sont passées de la recherche de coupables à la suite à donner, et les gens ont commencé à croire que le projet pouvait aboutir.

Comment SAP Analytics Cloud a-t-il géré à la fois Oracle et SAP ?

SAC a réuni les données Oracle et SAP dans un modèle de reporting unique : les deux apparaissaient côte à côte dans un même tableau de bord, sans fichiers de rapprochement manuels. Voir les deux systèmes dans une seule vue a été le moment qui a mis fin au débat sur l'outil. À noter que les connexions en direct de SAC ne prennent en charge que des sources SAP ; les données Oracle arrivent en général par une connexion d'import, un univers BusinessObjects ou une couche de données comme SAP Datasphere.

Pourquoi les utilisateurs ont-ils d'abord résisté aux tableaux de bord ?

Les tableaux de bord ont été lancés sans assez de contexte métier. On disait aux utilisateurs d'utiliser SAC, mais personne ne leur montrait comment cela s'appliquait à leur travail quotidien, et la formation était générique. Les gens font confiance à ce qu'ils connaissent, et les tableaux de bord n'avaient pas encore gagné cette confiance. Les relais locaux, qui les expliquaient avec leurs propres mots, ont changé la donne.

À quoi ressemble un redressement réussi du reporting ERP ?

Ce n'est presque jamais une seule chose. Ici, il a fallu une remise à plat de la gouvernance, une réduction du périmètre, des définitions validées, une communication sur mesure et des relais entre pairs, le tout ensemble. SAC a aidé parce qu'il a réuni les deux ERP dans un seul modèle sans gros développements spécifiques, mais la technologie seule n'aurait pas sauvé le projet. Six mois plus tard, ceux qui attendaient son effondrement présentaient des tableaux de bord qu'ils avaient construits eux-mêmes.