IT/Données
Chaque KPI, défini une seule fois.
Aurélien
Le détaillant
Un détaillant lifestyle de 12 magasins, trois acheteurs, six mille cinq cents SKU.
Notre détaillant exploite 12 magasins en France dans le segment mode lifestyle multicanal milieu de gamme. L'équipe est structurée : une équipe achats de 3 personnes, un responsable opérations à 1 personne et un merchandiser à 1 personne, qui pilotent environ 6 500 SKU en saison sur les magasins et le e-commerce.
La stack est standard pour le secteur — LCV Mag comme cœur de la gestion retail, Shopify pour le e-commerce, et Excel comme tissu conjonctif entre tout le reste. Cela fonctionne. Jusqu'au jour où ce n'est plus le cas.
"Trois équipes extrayaient le sell-through de trois façons différentes. Chaque lundi, nous débattions pour savoir laquelle était la bonne."
— Responsable opérations
Contexte
Douze fichiers Excel, une entreprise, aucun langage commun.
2024. Le détaillant lifestyle est passé de 6 à 12 magasins en trois ans. Chaque nouvelle fonction — achats, finance, opérations, responsables de magasin — a construit ses propres définitions de KPI dans son propre fichier Excel.
Sell-through signifiait trois choses différentes. La marge était calculée quatre façons différentes. La couverture de stock variait selon l'équipe. Les chiffres de la réunion du lundi ne concordaient jamais, et 30 minutes étaient perdues chaque semaine à décider quelle version était fiable.
Les données étaient correctes. Les définitions ne l'étaient pas.
La problématique
Même KPI, douze tableurs, douze réponses.
Chaque équipe avait des raisons légitimes pour sa définition. L’équipe achats calculait le sell-through sur toute la saison. La finance le calculait sur le trimestre calendaire. Les responsables de magasin le calculaient sur 4 semaines glissantes. Aucun n’avait tort — mais aucun ne concordait.
Quand la directrice retail demandait "quel est notre sell-through ?", elle obtenait trois réponses différentes selon la personne qui répondait. Les décisions étaient prises sur des moyennes négociées, pas sur des chiffres réels.
Trois problèmes aggravaient la situation :
Les mêmes KPI calculés différemment entre les achats, la finance, les opérations et les magasins.
30 minutes par réunion du lundi consacrées à réconcilier les versions.
Décisions retardées jusqu’à ce que tout le monde s’accorde sur le chiffre.
L’entreprise ne manquait pas de données. Elle manquait d’une définition partagée des données.
La solution
Chaque KPI est défini une seule fois dans Solya, puis utilisé partout.
La couche de métriques de Solya est devenue la source unique de définition de chaque KPI retail. L’équipe s’est mise d’accord une fois sur les définitions : sell-through, marge contributive, part du plein tarif, couverture de stock, conversion. Chaque définition était encodée dans l’usine à métriques, avec la logique sous-jacente visible par tous.
À partir de là, chaque tableau de bord, chaque rapport, chaque réunion s’alimentait de la même couche de métriques. Les désaccords sur les chiffres ont cessé. Les désaccords sur la stratégie ont commencé — ce à quoi ils auraient toujours dû servir.
Une définition unique validée par KPI, encodée une seule fois, visible par tous.
Chaque tableau de bord lit la même couche de métriques.
Versionnement conservé — chaque modification enregistrée avec son motif et sa date.
Les définitions ne dépendaient plus des équipes. Elles sont devenues des actifs de l’entreprise.
÷ SUM(units_received)
OVER full_season
Comment nous l’avons fait
Dans la boucle.
La couche de métriques s’exécutait sur l’Intelligence Layer, chaque équipe contribuant aux définitions et consommant les mêmes sorties. Voici comment le système fonctionne, de bout en bout.
01 — Cartographiez chaque définition existante.
Solya a recensé chaque KPI utilisé dans l’entreprise — et chaque variation de son calcul. Douze tableurs ont fait émerger trente-deux définitions distinctes.
02 — Convenez de définitions partagées.
L’équipe a animé trois ateliers pour s’aligner : quelle définition conserver, laquelle retirer, laquelle fusionner. Chaque décision a été documentée.
03 — Encodez dans la metrics factory.
Chaque définition validée a été codée une seule fois dans Solya, avec la logique de type SQL sous-jacente visible pour tous. Le versioning a préservé l’historique.
04 — Connectez chaque dashboard.
Les dashboards, rapports et exports de chaque équipe ont été reconfigurés pour lire depuis la couche de métriques. Achats, finance, opérations, magasins — tous sur la même infrastructure.
05 — Gouvernez dans la durée.
Lorsqu’une équipe avait besoin d’une nouvelle définition ou d’un ajustement, cela passait par la metrics factory. Solya a journalisé chaque modification, avec son motif et sa date.
Les définitions ont cessé d’être spécifiques à chaque équipe. Elles sont devenues des actifs de l’entreprise.
Les impacts
Un chiffre, chaque équipe, chaque réunion.
Après trois mois de fonctionnement sur la couche de métriques partagée, les réunions du lundi de l’entreprise sont passées du débat sur les chiffres à la discussion des actions à mener.
1 source — de vérité pour chaque KPI.
12 → 1 — Tableurs consolidés.
Zéro — Temps de rapprochement par réunion.
32 → 14 — Définitions de KPI distinctes dans l’entreprise.
"Nous avons cessé de nous battre sur les chiffres. Nous avons commencé à nous battre sur la stratégie. C’est un bien meilleur combat."
— Responsable des opérations
Découvrez d'autres cas d'usage
Une seule plateforme. Chaque décision retail.
Stocks, allocation, tarification, planification, exécution — réunis dans une seule couche opérationnelle.
