Note de choix stratégique : FLOW
FLOW n'est pas le choix d'un outil.
C'est le choix d'un modèle de convergence pour le groupe.
1. L'arbitrage à rendre
Beaumanoir doit arbitrer son modèle de convergence.
Pas seulement une solution IT.
Un modèle qui dit :
- ce qui devient commun ;
- ce qui reste différencié ;
- ce qui doit être gouverné ;
- ce qui peut rester autonome.
Le sujet n'est donc pas uniquement de remplacer SAP ECC, StoreLand, Socloz, NewStore ou d'autres socles historiques.
Le sujet est de construire une capacité durable à faire fonctionner le groupe comme un ensemble cohérent.
2. Le dilemme
Deux mauvaises réponses sont possibles.
| Option | Risque |
|---|---|
| Tout centraliser | Rigidifier les marques, ralentir les métiers, recréer un grand monolithe. |
| Tout laisser autonome | Maintenir les silos, les incohérences de stock, les décisions opérationnelles dispersées et les flux projet. |
FLOW propose une troisième voie.
Construire le commun nécessaire, sans détruire les différences utiles.
3. Le choix FLOW
FLOW concentre les responsabilités critiques qui doivent rester cohérentes à l'échelle du groupe :
- demande ;
- promesse ;
- stock ;
- allocation ;
- décisions métier ;
- événements ;
- contrats de données.
Et FLOW laisse les domaines spécialisés porter ce qui fait leur valeur :
- expériences client ;
- outils métiers ;
- finance ;
- PLM ;
- CRM ;
- WMS / TMS ;
- services spécialisés.
FLOW devient donc la colonne vertébrale opérationnelle du SI.
Pas un nouvel ERP.
Pas un OMS élargi.
Pas une application qui absorbe tout.
4. Pourquoi maintenant
Parce que les irritants convergent.
- SAP ECC, StoreLand, Socloz et NewStore arrivent en limite de trajectoire.
- Le groupe doit intégrer BRD, GBM, Sarenza et les marques dans un modèle plus cohérent.
- Les coûts et adhérences applicatives augmentent.
- Le stock et les demandes doivent être visibles à l'échelle groupe.
- Le fulfillment omnicanal devient un levier business.
- Les flux d'informations doivent sortir de la logique projet pour devenir gouvernables.
- Les roadmaps IT doivent devenir plus consolidées et plus stratégiques.
L'enjeu n'est donc pas seulement de moderniser.
L'enjeu est de rendre la convergence opérable.
5. Ce que ça change
FLOW ne crée pas seulement un nouvel outil.
FLOW change la manière de piloter le SI.
| Avant | Avec FLOW |
|---|---|
| Applications et processus | Responsabilités et capacités |
| Commandes par canal | Demandes transverses |
| Stock par système | Stock unifié exploitable |
| Règles cachées dans les processus | Décisions métier gouvernées |
| Master Data = inventaire d'objets supposés maîtres | Sources de référence et projections gouvernées |
| Flux projet, base à base et batchs Talend à la demande | Interfaces d'échange stables et contrats de données gouvernés |
| Convergence = uniformisation | Convergence = bon niveau de commun |
Le centre de gravité se déplace.
On ne part plus des applications, des documents, des canaux ou des organisations.
On part de la demande à satisfaire.
Autrement dit : la satisfaction client et utilisateur devient le point de départ de l'urbanisme, avant les processus, les documents ou les frontières historiques ERP / OMS.
6. Les arbitrages projet à rendre en premier
La réunion leaders du 30 juin 2026 confirme que certains arbitrages doivent être rendus avant les autres pour continuer le projet.
La question prioritaire n'est pas encore le détail de chaque composant. Elle est de confirmer le nouveau centre de gravité du SI cible.
Pour éviter de mélanger les sujets, les arbitrages sont qualifiés selon trois natures simples.
| Nature | Question posée |
|---|---|
| Positionnement | Où place-t-on les responsabilités structurantes de FLOW dans le SI et dans l'entreprise ? |
| Périmètre | Qu'est-ce que FLOW embarque, délègue, fédère ou laisse hors programme ? |
| Gouvernance | Quels rôles, règles, responsabilités et pratiques doivent être institués pour que la cible fonctionne dans la durée ? |
| Priorité | Nature | Arbitrage | Décision à sécuriser |
|---|---|---|---|
| 1 | Positionnement | Déplacer le centre de gravité de l'ERP vers le Case Management | Confirmer que le SI cible se construit autour de la demande, de la promesse et de la satisfaction client, plutôt qu'autour du document transactionnel ERP. |
| 2 | Positionnement | Réunifier les responsabilités ERP / OMS de décision | Confirmer que les décisions de promesse, allocation, réservation, statuts et exceptions ne doivent pas rester dispersées entre un ERP et un OMS concurrents. La cible est un centre de décision cohérent, pas un nouveau monolithe qui absorberait finance, canaux et exécution. |
| 3 | Positionnement | Placer la responsabilité de la promesse client | Arbitrer si la promesse omnicanale est portée par FLOW ou par C-LOG. Si C-LOG détient la promesse, FLOW devient plus coordinateur. Si FLOW la détient, C-LOG devient une capacité Supply spécialisée raccordée par contrat. |
| 4 | Positionnement | Assumer le découpage Engagement / Demand / Fulfillment / Supply | Expliquer que J'achète et Je vends restent des parcours ou macro-usages, mais ne structurent plus le cœur du SI cible. Le cœur se structure par responsabilités : capter l'intention, qualifier la demande, arbitrer la promesse, exécuter. |
| 5 | Périmètre | Clarifier le périmètre de la plateforme FLOW et celui du programme | Confirmer que FLOW n'embarque pas tout : le cœur plateforme est Demand + Fulfillment. Des applications ou chantiers Engagement et Supply peuvent être nécessaires, et éventuellement portés par le programme FLOW, mais ils restent des domaines adhérents ou des projets connexes selon l'arbitrage de gouvernance. |
| 6 | Gouvernance | Instituer une approche Master Data Management gouvernée | Décider les rôles, règles et pratiques permettant de gouverner les sources de référence, projections et contrats d'échange. L'enjeu est de sortir du réflexe Master Data = inventaire d'objets, de la lecture base à base et de la commande de flux opportunistes. |
Ces arbitrages conditionnent les autres décisions.
Ils doivent être partagés tôt parce qu'ils peuvent être déroutants : ils déplacent la lecture du SI depuis les applications et les processus historiques vers les responsabilités de décision, de périmètre et de gouvernance.
Ils alimentent directement les messages de transformation décrits dans Les changements à conduire.
7. Clarification : informations au repos et en transit
La réunion leaders du 30 juin 2026 a confirmé un point d'adhésion important : l'opposition entre Master Data et Master Data Management gouverné a été comprise côté métier.
Conceptuellement, le Master Data Management cible couvre à la fois les informations au repos et les informations en transit.
Mais pour analyser les problèmes terrain, il faut les séparer. Sinon le message devient abstrait : on mélange le sujet “qui fait référence ?” avec le sujet “comment l'information circule ?”.
Informations au repos : sources de référence et projections
Le problème n'est pas de nommer une liste d'objets maîtres.
Le problème est d'identifier quelle information fait référence, dans quel domaine, pour quel usage, avec quel processus de contrôle et quelles projections de consommation.
Cette lecture évite de réduire le Master Data Management à un inventaire de Master Data.
Elle permet aussi de distinguer la source responsable d'une information, les projections qui la rendent consommable, et les vues qui l'agrègent sans devenir automatiquement maîtres.
Informations en transit : contrats d'échange
Le problème terrain est différent.
Un responsable applicatif peut avoir besoin d'une information, chercher une source dans une autre application, analyser directement sa base de données, rédiger une spécification puis commander à une équipe Flux centralisée un batch Talend de plus.
Ce mode de fonctionnement produit progressivement des flux non gouvernés, difficiles à tracer, à faire évoluer et à réconcilier.
FLOW doit donc traiter la gouvernance des données en transit comme un sujet de fond.
Une base de données applicative n'est pas une ressource publique d'échange. Une application doit proposer des interfaces stables, pilotées, compatibles dans le temps, et protéger son modèle interne.
Le base à base doit être considéré comme une pratique legacy à résorber, pas comme un modèle d'intégration cible.
Cette clarification détaille l'arbitrage de gouvernance prioritaire 6. Elle renforce le principe 7 et la pratique transverse de gouvernance des données en transit.
8. Les arbitrages structurants à instruire ensuite
Une fois le centre de gravité confirmé, la vision FLOW doit être sécurisée par des arbitrages plus détaillés.
- Jusqu'où centraliser la demande, le stock, les projections et les Vues 360 ?
- Quelle autonomie conserver aux marques, canaux et domaines spécialisés ?
- Quelle politique de promesse client adopter : premier arrivé, premier servi, priorisation commerciale, ou règles différenciées par contexte ?
- Quels systèmes sortir, conserver, encapsuler ou réintégrer ?
- Quel niveau d'investissement accepter pour rendre le stock, les événements et les décisions métier gouvernables ?
- Quels échanges critiques doivent sortir de la logique
demande de flux / batch Talend / lecture base à basepour devenir des contrats de données gouvernés ? - Quel catalogue produit FLOW doit-il consommer pour gérer produits conçus et produits importés ?
- Qui est source de référence des informations fournisseur, usine, Agreement, PLM, Finance et Supply nécessaires au calcul des dates de promesse ?
- Quelles responsabilités du module Négoce StoreLand doivent entrer dans FLOW ?
- Quel modèle de gouvernance produit pour piloter FLOW dans la durée ?
9. Point de clarification : Vues 360 et ressources partagées
Les Vues 360 ne doivent pas être lues comme un composant limité au fulfillment.
Elles sont une capacité transverse de lecture, utile autour d'un Case, d'un client, d'un fournisseur, d'une commande, d'une usine, d'un document ou d'une exception.
Elles sont placées dans FLOW parce que FLOW devient le hub des Cases, événements métier, statuts, décisions et projections transverses.
Leur niveau de transversalité peut être plus large que celui du Stock Unifié. Pour conserver un urbanisme lisible, elles restent néanmoins regroupées avec les Shared Business Services de FLOW : toutes ces ressources partagées ne sont pas transverses au même degré, mais elles participent au même besoin de cohérence opérationnelle.
Formule finale
FLOW n'est pas la recherche d'un outil unique.
C'est le moteur de convergence qui construit le commun nécessaire pour rendre l'autonomie utile, gouvernée et durable.
→ Approfondir : Vision détaillée