Aller au contenu

Pourquoi FLOW existe

Repère de lecture
Public cible Sponsor, Direction, Architecte
Temps de lecture 3 min
Usage Comprendre la vision, les arbitrages et le vocabulaire cible

FLOW ne naît pas d'une idée théorique de plateforme.

FLOW naît d'un besoin concret de convergence.

FLOW émerge d'une situation très opérationnelle : le groupe doit remplacer ou repositionner des socles structurants, retrouver de la cohérence entre des patrimoines applicatifs différents, et éviter de reconstruire à l'identique les limites du SI actuel.

L'étude Synvance a contribué à objectiver cette trajectoire : StoreLand arrive en fin de cycle côté GBM, SAP structure fortement le fonctionnement BRD, les synchronisations entre applications restent fragiles, et les décisions utiles à la promesse client sont dispersées.

La question de départ n'est donc pas seulement : quels outils faut-il remplacer ?

La vraie question devient : où placer le centre de gravité du SI cible pour rendre la convergence opérable ?

Héritage du groupe : une diversité devenue structurelle

La diversité du groupe n'est pas un accident à corriger.

C'est une réalité structurelle à rendre opérable.

Le Groupe Beaumanoir s'est construit par croissance, acquisitions et rapprochements successifs.

Cette histoire a créé une grande richesse business : marques de mode accessible, enseignes multimarques, retail premium avec singularités de gestion, marketplace, e-commerce, wholesale, B2B international.

Elle a aussi produit un système d'information très hétérogène.

Les héritages diffèrent fortement selon les périmètres :

  • Sarenza s'est construit avec une culture digitale et microservices.
  • Beaumanoir historique repose sur un réseau d'applications autonomes.
  • StoreLand arrive en fin de trajectoire et devient difficile à maintenir.
  • Boardriders porte une culture plus centralisée autour de l'ERP.
  • Socloz, SAP ECC et d'autres briques vieillissantes imposent des coûts, des contraintes et des adhérences fortes.

Le groupe a engagé une volonté d'intégration business, organisationnelle et IT.

Mais cette intégration reste difficile à atteindre avec les outils et modèles actuels.

Les points communs existent pourtant.

Les marques partagent notamment des processus fortement structurés par les saisons, la planification, les achats, les assortiments, le stock, la disponibilité et l'exécution.

Le problème n'est donc pas l'absence de commun.

Le problème est de savoir comment construire ce commun sans écraser les singularités utiles.

Irritants : une cohérence difficile à retrouver

Le SI ne manque pas seulement d'outils.

Il manque d'un lieu où retrouver une cohérence opérationnelle.

Le SI actuel rend certains objectifs de convergence coûteux, fragiles ou difficiles à piloter.

Les irritants principaux sont :

  • Des coûts de licences et de maintenance importants, dans un contexte d'inflation des prix éditeurs.
  • Une rationalisation encore insuffisante du paysage applicatif.
  • Des synchronisations de données trop fragiles entre systèmes.
  • Des cadences de rafraîchissement non uniformes, qui créent des risques d'incohérence.
  • Une difficulté à retrouver une vérité fiable dans une constellation d'applications qui portent chacune une partie des données.
  • Une vision centralisée du stock encore insuffisante, notamment entre stock magasin et stock entrepôt.
  • Une vision centralisée des demandes encore insuffisante, notamment entre demandes B2C, B2B, retours, SAV et exceptions.
  • Une difficulté à optimiser le fulfillment multicanal à l'échelle du groupe.

Ces irritants ne sont pas seulement techniques.

Ils limitent la capacité du groupe à promettre, arbitrer, prioriser, exécuter et expliquer ses engagements de manière cohérente.

La question qui change

Remplacer StoreLand, repositionner SAP ou moderniser les outils existants ne suffit pas si l'on conserve le même modèle mental.

Le risque serait de remplacer des applications vieillissantes par des applications plus récentes, mais de garder les mêmes dépendances, les mêmes flux fragiles, les mêmes duplications et les mêmes arbitrages implicites.

FLOW déplace donc la question :

Avant
    quelle application remplace quelle application ?

Avec FLOW
    quelles responsabilités doivent devenir communes,
    fédérées, spécialisées ou locales ?

C'est ce déplacement qui justifie la suite de la vision détaillée : l'ambition, les ruptures, la plateforme cible, les hotspots et la valeur attendue.


Retour au sommaire · → Page suivante : Ambition