Aller au contenu

Principe 1 — Construire le bon niveau de commun

Repère de lecture
Public cible Architecte, Métier, Sponsor
Temps de lecture 4 min
Usage Guider les décisions de conception et vérifier la cohérence des arbitrages

Introduction

FLOW est né d'une volonté de convergence exprimée à plusieurs reprises au sein du groupe.

Cependant, les travaux d'analyse ont montré que convergence ne signifie ni centralisation complète, ni uniformisation des marques, des enseignes ou des business models.

L'enjeu consiste à identifier ce qui doit être partagé à l'échelle du groupe et ce qui doit rester sous la responsabilité des marques, des enseignes ou des domaines métier.

La convergence recherchée par FLOW repose donc sur un équilibre entre :

  • mutualisation et autonomie ;
  • centralisation et subsidiarité ;
  • règles communes et spécificités locales ;
  • gouvernance groupe et gouvernance métier.

Principe

Rendre commun ce qui doit être cohérent.

Préserver ce qui différencie réellement.

Fédérer ce qui doit coexister.

FLOW ne cherche pas un niveau unique de convergence.

Pour chaque responsabilité, FLOW doit décider explicitement ce qui devient commun à l'échelle du groupe, ce qui doit être fédéré entre plusieurs modèles, et ce qui reste différencié parce que cela crée de la valeur métier.

Ce que convergence ne signifie pas

Converger ne signifie pas :

  • imposer un seul système à tout le groupe ;
  • imposer un seul processus à toutes les marques ;
  • imposer une règle unique à tous les business models ;
  • supprimer les spécificités utiles ;
  • centraliser toutes les décisions.

Ce que convergence signifie pour FLOW

Converger signifie construire le bon niveau de commun pour chaque responsabilité.

Cela implique :

  • identifier les responsabilités qui exigent une cohérence groupe ;
  • rendre communes les capacités critiques ;
  • unifier les modèles qui doivent être partagés ;
  • standardiser lorsque la variation n'apporte pas de valeur ;
  • fédérer lorsque plusieurs modèles doivent coexister ;
  • clarifier les responsabilités ;
  • permettre plusieurs business models ;
  • préserver l'autonomie métier lorsqu'elle crée de la valeur ;
  • fournir un cadre commun permettant d'intégrer de nouvelles marques ou acquisitions.

Ce que nous avons observé chez GBM

GBM possède une histoire très retail, construite autour de marques et d'enseignes fortement différenciées.

Cette histoire s'est traduite dans le système d'information par une forte ségrégation : historiquement, une instance Storeland par marque.

Ce modèle a permis de préserver :

  • les spécificités des marques ;
  • les règles propres aux enseignes ;
  • les modes de fonctionnement locaux ;
  • les différences de business model.

Mais ce modèle a aussi montré ses limites.

L'apparition de l'application UR est un signal important : malgré la séparation des Storeland, GBM a dû créer un applicatif centralisé pour gérer certaines demandes et leur cycle de vie.

UR montre donc qu'il existe un besoin de gouvernance centralisée ou mutualisée pour certaines responsabilités qui dépassent le périmètre d'une marque.

Ce que nous avons observé chez BRD

Boardriders a suivi une trajectoire plus orientée plateforme.

La convergence autour de SAP, l'utilisation de NewStore, l'appui sur Maersk et des partenaires logistiques montrent une volonté de structurer des capacités plus transverses.

BRD apporte ainsi une preuve intéressante : la mutualisation est nécessaire pour traiter des processus multi-marques, multi-canaux et multi-pays.

Mais cette approche reste incomplète.

Certaines responsabilités demeurent dispersées ou dupliquées : par exemple, NewStore et SAP peuvent parfois intervenir sur des décisions proches ou concurrentes.

La mutualisation ne suffit donc pas si les responsabilités, les règles de décision et les périmètres de gouvernance ne sont pas clairement établis.

Enseignement commun

GBM et BRD partent de trajectoires différentes.

GBM montre les limites d'un modèle trop ségrégé.

BRD montre les limites d'une mutualisation qui ne clarifie pas suffisamment les responsabilités.

Les deux trajectoires convergent vers la même nécessité : construire une plateforme fédérale capable de rendre communes certaines responsabilités tout en préservant l'autonomie nécessaire.

Conséquences pour FLOW

FLOW doit permettre :

  • de construire le bon niveau de commun pour chaque responsabilité ;
  • de mutualiser les capacités réellement communes ;
  • de préserver les spécificités utiles ;
  • de clarifier les responsabilités entre groupe, marques, domaines et partenaires ;
  • de permettre plusieurs business models ;
  • d'éviter à la fois la prolifération des silos et l'uniformisation excessive.

À retenir

Converger, ce n'est pas tout centraliser.

Converger, ce n'est pas tout uniformiser.

Converger, c'est construire le bon niveau de commun.

La logique FLOW consiste à rendre communes les responsabilités qui exigent de la cohérence, afin de préserver ce qui différencie réellement les marques, les canaux et les business models.