Portfolio · 03 sur 03 · Maison de luxe

Arbitrer et piloter le produit décisionnel

En tant que Product Owner, j'ai transformé des demandes isolées en un backlog priorisé par la valeur, pendant la modernisation du décisionnel d'une maison de luxe en EMEA.

0

rupture brutale des usages

Les cubes OLAP ont été maintenus pendant la transition vers Power BI.

22 mois

du diagnostic initial à la bascule complète des usages

EMEA

réunie autour d'une même architecture décisionnelle

6 à 8 semaines

par cycle de développement, demandes arbitrées en amont

Le contexte

La migration de Colombus vers Infor M3 imposait de faire évoluer le décisionnel vers Power BI, malgré une capacité de développement limitée et des demandes concurrentes.

L'enjeu

Mutualiser les besoins et éviter les développements redondants, sans interrompre les usages métier.

Quand plusieurs équipes exprimaient un besoin proche, je cherchais d'abord à comprendre ce qui les réunissait, pour concentrer les efforts là où ils créaient le plus de valeur.

Une conviction qui a guidé ma façon de piloter le produit

Mon périmètre

Produit et arbitrage

Porté

Comités entre services, cadrage des MVP, priorisation du backlog et suivi des demandes jusqu'à leur mise en production

Trajectoire de modernisation

Porté

Diagnostic des rapports, définition de la trajectoire et maintien des cubes OLAP pendant la transition

Développements techniques

Coordonné

Migration des rapports SSRS vers Power BI, évolution des flux SSIS et du datawarehouse, réalisées par l'équipe BI

Gouvernance produit

Rendre les demandes visibles et arbitrables

Un circuit partagé, suivi dans Jira et documenté dans Confluence, a donné aux métiers de la visibilité sur leurs demandes et un cadre commun pour les prioriser.

Étape 1 Formaliser Le métier décrit son besoin dans un ticket Jira, estimé avec l'équipe Scrum
Étape 2 · selon la situation du ticket

Clarifier ou regrouper

Les demandes imprécises sont précisées ; les besoins similaires sont rapprochés pour éviter les doublons

Arbitrer

Lorsque la capacité est dépassée, les métiers priorisent les demandes à traiter, en tenant compte de la répartition entre investissement et fonctionnement

Étape 3 Planifier Les demandes retenues entrent dans un cycle de développement de six à huit semaines

Le circuit reprend deux semaines avant la fin du cycle suivant.

Trajectoire technique

Du décisionnel historique à Power BI, sans perdre les métiers en route

Élément historique Ce qu'il est devenu
Rapports SSRSArrêtés lors du passage à Infor M3, puis reconstruits dans Power BI
Flux SSISArrêtés avec les rapports historiques ; leur logique d'alimentation a été reprise dans le nouveau modèle de données
Cube OLAP (vente)Maintenu pendant la transition, puis progressivement abandonné à mesure que les équipes adoptaient Power BI
Rapport ventes et clientelingReconstruit dans Power BI et livré lors du déploiement de l'outil de clienteling, après dédoublonnage des fiches client

Impact

Un backlog partagé

Des demandes rapprochées et priorisées pour favoriser les développements mutualisés

Un MVP défini en amont

Le périmètre et le budget arbitrés avant le lancement des développements

Autres références

02 · Distribution d'articles de sport Transformation ERP et sécurisation des bascules Lire l'étude de cas 01 · Projet interne · Conseil Pilotage de l'IA chez DimVal Lire l'étude de cas

Référence réalisée avant la création de DimVal Conseil, dans le cadre d'une mission en cabinet de conseil (2018 à 2020).

Un système décisionnel à faire converger ?

Parlons d'abord des besoins des différents services et des décisions à prendre. La trajectoire technique vient ensuite.

brahim.djellab@dimval.fr