Hotspots : les décisions à instruire pour rendre FLOW réaliste
Les hotspots ne contredisent pas la vision.
Ils indiquent les endroits où la vision doit devenir un arbitrage robuste.
La vision FLOW ne peut pas être portée uniquement comme une cible théorique.
Elle doit aussi traiter explicitement les points sensibles du programme.
Un hotspot n'est pas un problème isolé.
C'est un point où plusieurs dimensions se croisent : trajectoire de migration, arbitrage métier, intégration technique, information, finance, gouvernance ou transformation.
Vue synthétique des familles de décisions
Un hotspot n'est pas une difficulté à subir.
C'est un arbitrage structurant à rendre explicite.
| Famille de décision | Hotspots concernés | Question structurante |
|---|---|---|
| Trajectoire de migration | Sortie progressive de SAP ECC | Comment sortir d'un socle monolithique sans créer un big bang ? |
| Décision distribuée | C-LOG, promesse commerciale Wholesale | Où se prennent les décisions de fulfillment, de priorisation et d'allocation ? |
| Intégration et temps réel | Stock temps réel, capacités technologiques des systèmes réintégrés | Les systèmes autour de FLOW savent-ils exposer APIs, événements, statuts et réconciliation ? |
| Informations produit et amont | PLM, catalogue, Article / EAN ; fournisseur, usine et Agreement | Quel catalogue et quel modèle de rôles FLOW consomme-t-il pour vendre, acheter, promettre et exécuter ? |
| Gouvernance de l'information | Sources de référence, projections, contrats de données | Comment passer d'un inventaire de Master Data et de flux projet à des responsabilités gouvernées au repos et en transit ? |
| Gouvernance métier | Promesse Wholesale, règles, Agreements | Comment absorber les variations métier sans multiplier processus et applications ? |
| Périmètre fonctionnel | Module Négoce StoreLand | Quelles responsabilités doivent être reprises dans FLOW, et lesquelles doivent rester dans un domaine consommateur ? |
Cette lecture permet de ne pas voir les hotspots comme une simple liste de sujets.
Elle montre les catégories d'arbitrages à sécuriser pour rendre FLOW opérable.
Trajectoire de migration : sortie progressive de SAP ECC
Le monolithe SAP ECC ne se découpe pas comme une application modulaire.
La trajectoire de sortie doit être pensée comme un sujet d'architecture, pas seulement comme un planning de migration.
Le périmètre BRD s'appuie fortement sur SAP ECC.
La nature monolithique de cette solution rend une migration progressive vers FLOW plus difficile qu'un simple remplacement par lots fonctionnels.
Le risque est de devoir arbitrer entre :
- Une trajectoire de migration longue et complexe.
- Des adhérences fortes entre finance, stock, commandes et exécution.
- Une difficulté à découper proprement les responsabilités.
- Une bascule trop large ou trop risquée.
Ce hotspot impose de clarifier très tôt quelles responsabilités doivent sortir de SAP ECC, lesquelles doivent rester articulées avec SAP Finance, et dans quel ordre la migration peut réellement être sécurisée.
Décision distribuée : C-LOG et fulfillment
Distribuer l'exécution est normal.
Distribuer la décision sans gouvernance claire crée des promesses incompatibles.
C-LOG ne doit pas être lu seulement comme un outil logistique ou un composant d'intégration.
Il porte déjà une partie des décisions de fulfillment : orientation, exécution, stock entrepôt, transport, événements et capacités opérationnelles.
Si FLOW porte une partie de la décision liée à la demande, et C-LOG une partie de la décision liée à l'exécution, le risque est de distribuer la décision sans gouvernance claire.
L'atelier C-LOG du 30 juin 2026 fait apparaître un arbitrage plus large : si l'OMS C-LOG prend en charge complètement les magasins et l'omnicanalité, la promesse client devient largement détenue par la filiale logistique ; si l'OMS est remonté au niveau FLOW, C-LOG devient plutôt une capacité Supply spécialisée ; si un autre OMS est ajouté pour les usages non couverts, la cohérence de promesse et l'intégration deviennent beaucoup plus difficiles.
Cela peut produire :
- Des choix incompatibles entre demande et exécution.
- Des erreurs d'aiguillage.
- Des promesses impossibles à tenir.
- Une optimisation locale au détriment de l'optimisation globale.
- Une difficulté à expliquer pourquoi une décision a été prise.
Ce hotspot impose de définir précisément la frontière entre décision de demande et décision d'exécution, le propriétaire cible de la promesse client omnicanale, ainsi que le contrat d'échange entre FLOW et C-LOG.
Intégration et fraîcheur : stock temps réel
Un stock unifié n'est utile que si les mouvements remontent assez vite.
La promesse omnicanale dépend donc aussi des capacités événementielles du POS, des WMS et des partenaires logistiques.
Le Stock Unifié n'a de valeur opérationnelle que si les mouvements de stock remontent avec une fraîcheur suffisante.
Or cette fraîcheur ne dépend pas seulement de FLOW.
Elle dépend aussi de la capacité des systèmes qui observent ou provoquent les mouvements de stock à les transmettre rapidement.
Les systèmes concernés sont notamment :
- Le Point of Sale, porté par une application éditeur.
- Les solutions logistiques opérées par des entreprises externes ou des filiales.
- Les WMS, transporteurs, partenaires et systèmes d'exécution qui manipulent physiquement le stock.
Pour tendre vers un stock temps réel, ces systèmes devront accepter de publier les mouvements de stock en événementiel, en asynchrone court.
Ce hotspot impose donc de clarifier :
- Les capacités événementielles réellement disponibles côté POS et solutions logistiques.
- Les contrats d'événements nécessaires.
- Les exigences de fraîcheur par usage métier.
- Les responsabilités en cas de retard, perte ou incohérence d'événement.
- Les mécanismes de rattrapage et de réconciliation.
Sans cette capacité, FLOW pourra consolider une vision de stock, mais pas garantir une décision de promesse, d'allocation ou de fulfillment suffisamment fiable à l'échelle omnicanale.
Capacités technologiques : réintégrer les systèmes existants
Réintégrer un outil existant ne suffit pas : il doit savoir dialoguer avec la colonne vertébrale FLOW.
API, événements, statuts, documents et réconciliation deviennent des prérequis d'architecture.
FLOW ne vise pas à réécrire tous les services existants.
Il doit pouvoir réintégrer les outils qui portent une valeur métier spécifique, par exemple CBS, le SAV Client Sarenza, des outils fournisseurs ou des systèmes logistiques spécialisés.
Mais cette réintégration suppose des capacités techniques minimales.
Un service existant peut être métier-pertinent, mais difficile à conserver s'il ne sait pas exposer des APIs, publier des événements, partager ses statuts, corréler ses objets avec les Cases ou participer à la réconciliation.
Ce hotspot impose de clarifier :
- Les capacités API nécessaires.
- Les événements métier attendus.
- Les statuts et jalons à exposer.
- Les identifiants de corrélation.
- Les documents à produire, consommer ou référencer.
- Les mécanismes de reprise, rejeu, supervision et réconciliation.
- Les critères permettant d'arbitrer : conserver, encapsuler, faire évoluer, remplacer ou rapatrier certaines responsabilités dans FLOW.
Le hotspot Stock temps réel est un cas critique de cette problématique, mais il ne doit pas porter tout le sujet.
Catalogue produit : FLOW ne peut pas dépendre d'un PLM unique
Le PLM est essentiel pour concevoir certains produits.
Il ne peut pas devenir le catalogue unique de tout le SI.
Beaumanoir dispose d'un PLM structurant pour gérer les collections, les fiches produits, les grilles taille / couleur, les échanges avec les fournisseurs et les engagements industriels très tôt dans la saison.
Ce modèle est adapté aux produits conçus dans le processus historique de collection.
Mais d'autres stratégies existent, notamment avec Sarenza ou certaines collections Boardriders : l'entreprise peut acheter des produits déjà designés par les fournisseurs, fournis directement sous forme de variantes produit avec EAN, parfois sans respecter les nomenclatures taille / couleur du PLM historique.
Le hotspot est donc le suivant : FLOW devra gérer à la fois des produits conçus et des produits importés.
La question n'est pas seulement produit.
Elle touche à la frontière entre conception amont, catalogue d'exécution, achat, vente, promesse et fulfillment.
FLOW doit clarifier s'il doit connaître la structure du PLM ou consommer un catalogue au niveau Article / EAN, suffisamment riche pour exécuter, mais découplé des variations de processus de conception de saison.
Ce hotspot impose de clarifier :
- La granularité produit minimale nécessaire à FLOW.
- Le rôle du Product Agreement Catalog.
- La frontière entre PLM, PIM, catalogue d'exécution et FLOW.
- La gestion des produits conçus et des produits importés.
- La gouvernance des nomenclatures taille / couleur.
- Le découplage entre processus de conception amont et capacités Demand / Fulfillment.
Fournisseur, usine et Agreement : séparer les rôles
La fiche fournisseur SAP n'est pas forcément le bon modèle cible.
FLOW doit distinguer fournisseur, usine, agent, entité de facturation, Agreement et capacité Supply.
L'atelier Boardriders du 29 juin 2026 a mis en évidence une tension forte autour du modèle fournisseur.
Chez BRD, les fournisseurs sont créés manuellement par l'équipe Finance. Les fiches portent notamment des partner functions, une Transportation Zone, des entités de facturation, des intermédiaires et des usines avec leurs lead times.
Le référentiel officiel est SRM, mais il est orienté usine et ne semble pas synchronisé aujourd'hui. Cette situation crée une différence avec GBM, où les Agreements sont plutôt associés à des fournisseurs.
Le sujet n'est pas de choisir définitivement entre un modèle fournisseur et un modèle usine. L'enjeu est plutôt de sortir d'un paramétrage monolithique et de distribuer la configuration dans les domaines responsables : parfois le fournisseur orchestre l'opération vers l'usine, parfois la commande opérationnelle doit cibler directement l'usine, et les habilitations SRM doivent suivre ces responsabilités réelles.
Le critère décisif est le calcul des dates de promesse. La configuration cible doit permettre de déterminer une date fiable à partir du bon fournisseur, de la bonne usine, du bon Agreement, du bon lead time, du bon contexte PLM / SRM et des contraintes d'exécution.
Cela implique une cartographie des informations et des flux : SRM, PLM, module Négoce, Finance, Supply et FLOW doivent clarifier qui est source de référence de quelle information, quelle projection est consommée par la décision Case Management, et quelle fraîcheur est nécessaire.
Le hotspot peut se résumer ainsi :
GBM
commande passée à un fournisseur
Agreement associé au fournisseur
BRD
commande passée à une usine
autres rôles retrouvés via partner functions
SAP concentre dans un même paramétrage des notions qui relèvent de domaines différents : stock, lead time, conditions de prix, responsabilité juridique, facturation, transport, PLM et relation fournisseur.
FLOW doit donc clarifier s'il consomme une fiche fournisseur enrichie ou s'il sépare les responsabilités par domaine : Party, usine, Agreement, Finance, Fulfillment Network, Supply Service Registry, PLM, habilitations SRM et calcul de promesse.
Ce hotspot ne paraît pas infranchissable, mais il impose un travail de cartographie précis. Il a aussi un impact de roadmap côté CBS : l'outil devra probablement évoluer pour voir les usines ou sites de production, et pas seulement les fournisseurs, si cette granularité devient nécessaire à la promesse et à l'exécution.
Une adhérence doit être instruite explicitement : CBS est-il la SRM cible du Groupe Beaumanoir, le premier lieu de recensement des fournisseurs et usines, ou un domaine spécialisé de suivi achat, collaboration fournisseur et conformité documentaire consommant une source de référence externe ?
Master Data Management : sources, projections et contrats
Faire du Master Data Management ne consiste pas à dresser un inventaire d'objets supposés maîtres.
Il faut identifier qui fait référence, comment l'information circule et qui gouverne les contrats d'échange.
La vision FLOW suppose une gouvernance Master Data Management plus exigeante que la master data historique.
Le sujet doit être séparé en deux lectures pour rester compréhensible sur le terrain :
- Les informations au repos : sources de référence, projections, vues, responsabilités et processus de contrôle.
- Les informations en transit : contrats de données, producteurs, consommateurs, fraîcheur, qualité, supervision, reprise et compatibilité.
Ce hotspot est important parce qu'il touche directement la manière de travailler.
Si chaque responsable applicatif analyse une base de données, spécifie un flux et commande un batch à une équipe centralisée, le SI produit mécaniquement des dépendances difficiles à gouverner.
FLOW doit donc faire évoluer la pratique vers des interfaces d'échange stables et pilotées.
Une base de données applicative doit rester protégée par son application ; elle n'est pas une ressource publique d'échange.
Promesse commerciale : prioriser sans rompre les engagements
Prioriser un client ne consiste pas seulement à lui donner du stock.
Cela peut décaler les autres commandes et rompre des promesses déjà perçues comme acquises.
La pratique Wholesale observée côté BRD repose sur une logique de priorisation des meilleurs clients.
Cette logique est très différente d'une approche “premier arrivé, premier servi”.
Dans une logique de priorisation, une nouvelle commande d'un client prioritaire peut consommer un stock insuffisant et décaler dans le temps des commandes déjà enregistrées pour des clients moins prioritaires.
Le sujet n'est donc pas seulement : “qui a droit au stock ?”
Le sujet est aussi : “quelle promesse a déjà été donnée, à qui, et peut-on la déplacer ?”
Côté Beaumanoir, l'adage “premier arrivé, premier servi” porte une autre philosophie : lorsqu'une promesse est faite, elle doit être tenue.
Ces deux modèles ne sont pas simplement deux règles de stock.
Ils traduisent deux manières différentes de gouverner la relation commerciale, l'allocation, la priorité et la responsabilité de la promesse.
FLOW doit donc clarifier explicitement :
- Si une promesse peut être déplacée après avoir été donnée.
- Qui a le droit de provoquer ce déplacement.
- Quels clients, canaux ou agreements peuvent être prioritaires.
- Comment les commandes décalées sont identifiées, expliquées et traitées.
- Comment éviter qu'une optimisation commerciale locale dégrade la confiance globale dans la promesse.
Ce hotspot montre pourquoi FLOW doit être capable de gérer des règles métier explicites.
La plateforme ne doit pas seulement dire : y a-t-il du stock ?
Elle doit aussi pouvoir dire : ce stock peut-il être réservé à un client prioritaire, même si cela décale d'autres engagements ?
C'est typiquement le genre de variation métier que FLOW doit absorber sans multiplier les processus ou les applications spécifiques.
Module Négoce StoreLand : découper avant de reprendre
Le module Négoce n'est pas un bloc à reprendre tel quel.
C'est un révélateur de responsabilités mélangées entre engagement commercial et Demand & Fulfillment.
Le module Négoce de StoreLand porte plusieurs responsabilités : client, assortiment, commercial agreement, catalogue, prix, conditions commerciales et commandes d'achat.
Certaines relèvent plutôt du design commercial et d'Engagement.
D'autres peuvent relever de FLOW si elles participent au cycle de vie transverse d'une demande, à l'approvisionnement, à la promesse, à l'allocation ou à l'exécution.
Le hotspot n'est donc pas de savoir si FLOW doit reprendre “le module Négoce”.
Il est de découper les responsabilités pour savoir ce qui doit être repris, réintégré, consommé ou laissé dans un domaine consommateur de la plateforme.
Ce hotspot impose de clarifier :
- Les responsabilités Négoce réellement candidates à FLOW.
- La frontière entre commercial agreement, catalogue, commande d'achat et promesse.
- Les capacités à généraliser pour toutes les marques GBM.
- La manière de traiter la convergence intra-GBM entre marques premium outillées et marques opérées plus manuellement.
- Le rôle du Product Agreement Catalog comme point d'interface potentiel entre Engagement et FLOW.
Synthèse des hotspots
La synthèse des hotspots n'est pas une liste de risques.
C'est la carte des arbitrages qui conditionnent la crédibilité de FLOW.
| Hotspot | Famille de décision | Ce que FLOW doit clarifier |
|---|---|---|
| Sortie progressive de SAP ECC | Trajectoire de migration | Découpage des responsabilités, trajectoire de sortie, articulation avec Finance |
| C-LOG | Décision distribuée | Frontière demande / exécution, contrat de décision, gouvernance des arbitrages |
| Stock temps réel | Intégration et fraîcheur | Événements POS et logistiques, fraîcheur attendue, contrats d'événements, réconciliation |
| Capacités technologiques des systèmes réintégrés | Intégration des services existants | APIs, événements, statuts, documents, corrélation, réconciliation, trajectoire d'encapsulation ou remplacement |
| Catalogue produit et PLM | Informations produit et amont | Granularité Article / EAN, Product Agreement Catalog, frontière conception / exécution, nomenclatures |
| Fournisseur, usine et Agreement | Informations fournisseur et Supply amont | Rôles fournisseur / usine / agent / facturation, SRM, PLM, Agreements, lead times, dates de promesse, sources de référence, CBS comme SRM cible ou domaine spécialisé, séparation des responsabilités SAP |
| Approche Master Data Management | Gouvernance de l'information | Sources de référence, projections, contrats de données, rôles data, sortie des flux opportunistes et du base-à-base |
| Promesse commerciale Wholesale | Gouvernance métier | Règles, policies, allocation, promesses déplaçables ou non, priorisation client |
| Module Négoce StoreLand | Périmètre fonctionnel | Responsabilités à reprendre dans FLOW, responsabilités Engagement, commandes d'achat, Product Agreement Catalog |
À retenir
La valeur de cette page n'est pas de lister les difficultés.
Elle est de montrer les arbitrages à sécuriser pour que FLOW tienne réellement sa promesse.
Ces hotspots montrent que FLOW n'est pas seulement un outil cible.
FLOW est aussi un cadre d'arbitrage pour traiter les tensions réelles de convergence du groupe.
Ils obligent à rendre explicites les choix qui conditionnent la crédibilité de la plateforme : trajectoire, gouvernance des décisions opérationnelles, intégration, informations, promesse et gouvernance.
← Page précédente : Solution · → Page suivante : Valeur attendue