Ambition : converger
FLOW ne choisit pas entre système centralisé et applications autarciques.
FLOW construit le socle commun qui apporte de la stabilité au SI et rend l'autonomie cohérente.
Le Groupe Beaumanoir doit réussir une convergence complexe.
Il doit créer du commun entre des marques, canaux, business models et héritages IT très différents, sans perdre les singularités qui font leur valeur.
La réponse ne peut pas être une uniformisation brutale.
Elle ne peut pas non plus être une centralisation ERP classique qui chercherait à faire rentrer toute la diversité du groupe dans un modèle unique.
L'ambition de FLOW est de construire un socle commun là où la cohérence est critique — demandes, stock, promesses, décisions, allocation, exécution, événements et exceptions — tout en laissant les marques, canaux et domaines spécialisés conserver leur autonomie là où elle crée de la valeur.
FLOW porte donc une ambition de convergence fédérée.
Opportunité : converger sans basculer dans un modèle unique
L'opportunité n'est pas de tout centraliser.
Elle est de choisir précisément ce qui doit devenir commun.
L'opportunité du programme est claire : faire converger.
Mais la question centrale est plus difficile : que faut-il faire converger, et jusqu'où ?
Une étude préalable confiée à Synvance a contribué à objectiver les écarts entre les SI et à éclairer les trajectoires possibles.
Une migration vers une solution ERP centralisée unique n'a pas été retenue comme trajectoire évidente.
Les expériences de centralisation ERP dans des groupes multimarques et multi-enseignes sont souvent longues, complexes et risquées.
Pour autant, une forme de centralisation reste nécessaire.
Le groupe a besoin de cohérence sur les demandes, le stock, les engagements, les décisions, les commandes, les événements et l'exécution.
La réponse ne peut donc être ni une mosaïque d'applications autonomes, ni un modèle unique qui rigidifierait tout le groupe.
FLOW propose de construire le bon niveau de commun : rendre communes les responsabilités qui exigent de la cohérence, fédérer celles qui doivent coexister, et préserver ce qui reste spécialisé, différencié ou local.
Centraliser
lorsque la cohérence est critique
Unifier
lorsque le modèle doit être partagé
Standardiser
lorsque la variation n'apporte pas de valeur
Fédérer
lorsque plusieurs modèles doivent coexister
Différencier
lorsque le business l'exige
FLOW doit préserver la richesse business du groupe sans transformer cette richesse en complexité IT.
L'enjeu n'est pas d'uniformiser le business pour simplifier le SI.
L'enjeu est de concevoir un SI capable de porter la richesse business sans l'étendre en complexité applicative.
C'est dans ce contexte que le programme FLOW émerge : non comme la recherche d'un socle unique, mais comme la recherche d'un modèle de convergence capable de créer de la cohérence sans effacer les singularités utiles.
Le sujet n'est donc pas de centraliser par principe.
Le sujet est de rendre explicite ce qui doit devenir commun, ce qui peut rester autonome, et ce qui doit être fédéré pour que le groupe fonctionne comme un ensemble cohérent.
← Page précédente : Pourquoi FLOW existe · → Page suivante : Ruptures