ERP à deux niveaux : S/4HANA Public Cloud dans la filiale pendant que le siège garde son ERP

En bref : une filiale n’a pas à attendre l’ERP du groupe. Avec un ERP à deux niveaux, elle exploite S/4HANA Public Cloud comme ERP local complet, pendant que le siège reste sur ECC ou S/4HANA Private Edition. Cela fonctionne si quatre questions sont tranchées au préalable : où passe la frontière entre les niveaux, à qui appartient chaque objet de données de base, comment l’intercompagnie s’enregistre réellement et qui répond des interfaces à deux heures du matin.

Une conversation que nous avons environ une fois par mois. La filiale suisse a dépassé ce qu’elle exploite : peut-être un vieil ECC dans lequel le groupe n’investit plus, peut-être un ERP local que la maison mère tolère, parfois un parc de tableurs qui effraierait n’importe quel réviseur. Ils veulent avancer. Et quelqu’un à Stuttgart ou à Milan annonce que le groupe ne touchera pas à son ERP avant 2030.

À première vue, cela ressemble à une impasse. Ce n’en est pas une. C’est le cas d’école de l’ERP à deux niveaux, et ce cas d’école fonctionne discrètement depuis des années.

Ce que signifie concrètement l’ERP à deux niveaux

Le premier niveau, c’est le siège. ECC, S/4HANA private edition, ce que le groupe a construit pendant une décennie. On y trouve la comptabilité de groupe, la consolidation, généralement le référentiel fournisseurs et le référentiel articles global.

Le deuxième niveau, c’est la filiale, qui exploite S/4HANA Public Cloud. Elle mène l’activité locale de bout en bout : ventes locales, achats locaux, stocks locaux, clôture légale propre.

Les deux sont reliés par une liste de processus volontairement courte. Achat et vente intercompagnie. Reporting de groupe. Les objets de données de base que le groupe gouverne réellement. C’est à peu près tout. SAP décrit les modèles de déploiement (siège et filiale, services centraux, écosystème de la chaîne logistique) et les contenus d’intégration préconfigurés sur sa page thématique consacrée à l’ERP à deux niveaux avec S/4HANA Public Cloud.

Ce que l’on manque le plus souvent, c’est ce que le modèle à deux niveaux n’est pas. Ce n’est pas un système satellite alimentant un vaisseau amiral. La filiale dispose d’un ERP complet, capable de clôturer et d’être audité. Elle ne traîne simplement pas vingt ans de modifications du groupe.

Pourquoi cela convient particulièrement au cas suisse

La Suisse produit cette configuration plus que d’autres marchés, pour des raisons structurelles prosaïques. Beaucoup d’entités suisses sont la filiale rentable, encombrante et hors zone euro d’un groupe DACH ou italien plus grand. Assez grandes pour avoir de vrais besoins ERP, assez petites pour que la feuille de route du groupe ne les priorise pas.

S’y ajoutent les exigences locales que le système de groupe gère de toute façon mal : la QR-facture, les fichiers de paiement ISO 20022 vers une banque suisse, la TVA aux taux suisses, un périmètre salarial qui n’a rien de commun avec l’allemand. Une entité suisse sur un ECC allemand porte typiquement un petit tas de contournements locaux sur exactement ces points, entretenus par une personne proche de la retraite.

Le modèle à deux niveaux transforme ces contournements en périmètre standard dans un système qui inclut une version pays suisse, avec le traitement de la QR-facture. C’est souvent la vraie motivation, et c’est une bonne motivation.

Les quatre décisions dont dépend le résultat

Tout le reste relève du détail de mise en œuvre. C’est sur ces quatre points que les projets se gagnent ou se perdent, et tous les quatre sont des décisions métier déguisées en questions techniques.

1. Où passe la frontière entre les niveaux

Pas « quels modules », mais quels processus s’arrêtent à la frontière. À écrire processus par processus, avec un nom en face.

La version qui fonctionne : la filiale assume l’order-to-cash, le procure-to-pay, les stocks et sa propre clôture légale. Le groupe assume la consolidation, la trésorerie de groupe et les objets de données de base qu’il gouverne réellement.

La version qui échoue : le groupe garde « juste la tarification » ou « juste le référentiel clients » parce que quelqu’un y tient, et dès lors chaque commande client locale exige un aller-retour vers un système situé dans un autre pays, avec une autre fenêtre de maintenance. Nous avons vu des configurations de ce type : la saisie des commandes de la filiale dépendait d’un traitement nocturne dans le centre de données de la maison mère, si bien qu’un client créé le mardi après-midi ne pouvait être facturé que le jeudi. Personne n’avait conçu cela. Cela s’était accumulé.

2. À qui appartient chaque objet de données de base

Un propriétaire par objet, répliqué en lecture seule dans l’autre sens. Écrivez le tableau, validez le tableau, puis ne le renégociez pas chaque trimestre.

Une répartition qui tient dans la plupart des groupes :

Objet	Propriétaire	Sens
Référentiel fournisseurs (fournisseurs groupe)	Niveau 1	Vers le bas, lecture seule au niveau 2
Référentiel articles produits finis	Niveau 1	Vers le bas, champs locaux additionnels au niveau 2
Clients locaux	Niveau 2	Local uniquement
Prix et conditions locaux	Niveau 2	Local uniquement
Plan comptable	Niveau 1	Vers le bas, avec mappage
Centres de coûts locaux	Niveau 2	Vers le haut pour le reporting

La règle sous le tableau : rien n’est bidirectionnel. Dès qu’un objet est maintenu dans les deux niveaux, vous avez intégré une situation de compétition dans votre clôture mensuelle, et elle ressortira trois trimestres plus tard sous la forme d’un écart d’arrondi que personne ne saura expliquer.

3. Comment l’intercompagnie s’enregistre réellement

Le point que l’on valide sans discussion en atelier et qui dévore ensuite huit semaines de tests.

Le groupe vend à la filiale, ou la filiale revend aux clients du groupe, et les deux parties ont besoin de documents concordants, de prix de transfert concordants, d’un traitement fiscal concordant et d’un calendrier concordant. Public Cloud embarque de bons contenus standard pour l’intercompagnie. Elle les embarque avec des opinions sur la façon dont le processus devrait se dérouler, et ces opinions ne correspondront pas au processus sur mesure que le groupe utilise depuis vingt ans.

À trancher en conception, pas en test : qui émet la facture, à quel prix de transfert et qui l’entretient, quelle devise et quel cours, comment se fait l’élimination au niveau du groupe, et ce que fait un retour intercompagnie. Écrivez le rapport de réconciliation avant d’écrire l’interface. Si vous ne savez pas décrire comment vous prouveriez la concordance des deux côtés en fin de mois, vous n’êtes pas prêts à construire.

4. Qui répond des interfaces à deux heures du matin

Le point organisationnel, celui que l’on saute parce qu’il n’est pas amusant.

La frontière entre niveaux suit exactement une ligne de l’organigramme. L’informatique du groupe répond du niveau un. L’informatique locale ou un partenaire répond du niveau deux. Les interfaces se trouvent précisément sur la couture, ce qui signifie qu’à deux heures du matin le dernier jour ouvré du mois, quand le lot de factures intercompagnie n’est pas arrivé, ce n’est l’incident de personne.

Nommez un propriétaire unique pour la couche d’intégration, avec supervision, alertes et un chemin d’escalade qui atteint un être humain des deux côtés. SAP Integration Suite vous donne l’outillage et les contenus à deux niveaux. Elle ne vous donne pas de service de piquet. Celui-là, vous devrez l’écrire vous-mêmes.

Ce que cela coûte

Je ne vous donnerai pas de chiffre, car tout chiffre sans votre périmètre relève du théâtre. La forme, en revanche, reste constante sur les projets que nous avons menés.

Les licences Public Cloud pour une filiale sont modestes face à l’empreinte d’un ERP de groupe, et la mise en œuvre est réellement plus courte qu’un projet de premier niveau, puisque le périmètre standard est tout l’intérêt de la démarche. Là où le modèle à deux niveaux coûte plus qu’une estimation naïve, c’est la couche d’intégration et la conception du processus intercompagnie. Budgétez-les comme un véritable chantier avec un véritable responsable, pas comme une ligne en fin de liste.

L’autre coût honnête : vous exploitez désormais deux ERP. Deux cycles de version, deux cycles de test, deux dispositifs de gouvernance des données de base. Public Cloud reçoit deux releases majeures par an, que le groupe soit prêt ou non. C’est un atout, et c’est aussi un engagement. Si personne dans l’organisation ne veut porter ce rythme, le modèle à deux niveaux sera malheureux quelle que soit la qualité de sa construction.

Quand le modèle à deux niveaux est la mauvaise réponse

Trois cas où nous le disons franchement.

Le groupe est déjà engagé sur S/4HANA à environ dix-huit mois, filiale incluse dans le périmètre. Les deux niveaux deviennent alors un détour : vous construisez une frontière, vous l’exploitez brièvement et vous la démontez.

La filiale n’est pas vraiment une activité distincte. Si elle partage clients, prix, stocks et personnes avec la maison mère au point que la « frontière » couperait à travers les opérations quotidiennes, vous ne concevez pas deux niveaux, vous concevez une ligne de faille.

Personne ne le porte localement. Le modèle à deux niveaux exige une filiale capable d’assumer son propre ERP, mise à jour semestrielle comprise. Si l’équipe locale se résume à deux personnes qui ont déjà un travail à plein temps, cela doit figurer honnêtement dans le dossier d’investissement, plutôt que d’être découvert au neuvième mois.

Où intervient la CX, car c’est généralement la même conversation

La plupart des filiales qui viennent nous voir pour cela ne posent pas seulement une question ERP. Elles la posent parce que l’équipe commerciale ne voit pas le stock, ou que l’équipe de service ne voit pas la commande. Les deux niveaux sont un bon moment pour régler cette question, puisque vous définissez la frontière de toute façon.

Sales Cloud V2 se raccorde au niveau deux, pas au système du groupe. Les commerciaux de la filiale consultent le stock, les prix et les commandes de la filiale, c’est-à-dire ce contre quoi ils vendent réellement. L’alternative, pointer le CRM vers l’ERP du groupe par-dessus la frontière, réintroduit exactement la latence pour laquelle vous aviez construit le niveau deux.

C’est sur cette couture que nous passons le plus clair de notre temps, et c’est aussi là que les projets à deux niveaux réussissent ou déçoivent en silence. La frontière ERP et la frontière CX doivent être la même frontière. Lorsqu’elles ne le sont pas, l’équipe commerciale travaille sur une version de la vérité et la finance clôture sur une autre. Nous expliquons séparément pourquoi la pile SAP intégrée de S/4HANA Public Cloud et Sales Cloud V2 est rentable et pourquoi il importe qu’un seul partenaire réalise le côté ERP et le côté CRM.

Par où commencer

Ne commencez pas par une sélection de système. Commencez par la liste des processus et le tableau des données de base ci-dessus, dans une salle où le groupe et le local sont présents ensemble. Deux jours, menés honnêtement, vous diront si les deux niveaux sont votre réponse et approximativement ce que cela coûtera. Au passage, cela fait remonter tôt les questions politiques, et c’est précisément le but.

Si vous souhaitez un cadre structuré, notre assessment de readiness S/4HANA dure cinq jours à prix fixe et se déduit de la transformation en cas de mandat. Et si la question du groupe reste ouverte, la vue d’ensemble de la transformation présente l’architecture cible vers laquelle nous travaillons.

Une chose mérite d’être dite clairement : attendre le groupe est aussi une décision, et rarement la moins chère. Chaque année que la filiale passe sur un système dans lequel personne n’investit est une année de contournements que quelqu’un devra tôt ou tard démêler.