Avant les interfaces, le mot « produit » avait déjà trois sens

Quatre mots au tableau

Au début du premier atelier, quatre mots revenaient sans cesse.

SAP : le grand système de gestion déjà en place chez le client, où vivaient les données produit, les matières, les anciens codes et leurs exceptions.

PIM : les initiales de Product Information Management, ou gestion de l’information produit. Ce type d’outil centralise descriptions, attributs et catégories avant de les envoyer vers un site, un catalogue ou d’autres canaux.

Akeneo : le logiciel PIM choisi pour ce projet.

SKU : la plus petite unité suivie en stock, souvent une couleur, une taille ou un conditionnement précis. Un SKU peut appartenir à un produit sans être, à lui seul, le produit tel que le client le reconnaît.

Les définitions semblaient tenir. Puis chacun a commencé à parler de « produit ».

Le produit changeait de forme selon la chaise

Pour Marketing, plusieurs SKU pouvaient composer un seul produit visible par le client. Dans SAP, l’histoire avait laissé des lignes distinctes, des codes et des exceptions. Produit regardait le futur catalogue. Les spécialistes de la donnée regardaient ce qu’il fallait préserver.

Sur le schéma, SAP devait envoyer ses données à Akeneo, puis Akeneo les transmettre aux systèmes suivants. Mais aucune flèche ne disait encore quelle définition du produit allait voyager.

Développer les interfaces à ce moment-là aurait fixé une réponse sans résoudre la discussion.

Les ateliers rendaient les problèmes, pas les exigences

Les utilisateurs racontaient les attributs auxquels ils ne croyaient plus, les mises à jour répétées, les créations trop longues et les détours appris avec le temps.

Après l’atelier, nous reprenions chaque récit. Besoin métier pour demain ? Limite de l’outil actuel ? Gêne locale ? À la séance suivante, nous rendions cette lecture au groupe. Certains éléments changeaient de colonne. D’autres disparaissaient.

Le futur PIM commençait ainsi par perdre des exigences plutôt que par en accumuler.

Avant les champs, le modèle

Les consultants seniors dessinaient le modèle de données et construisaient les ateliers où les désaccords importants devaient apparaître. Ils choisissaient les cas limites à montrer et les personnes capables de les trancher.

Une fois le modèle accepté, l’analyste métier le configurait dans l’environnement de développement Akeneo. Les futurs utilisateurs s’installaient ensuite devant l’écran. Ils créaient un produit, modifiaient un attribut, essayaient de terminer leur tâche.

Ce qui paraissait évident sur le tableau ne survivait pas toujours à la souris. L’analyste métier ajustait la configuration, puis le test recommençait. Les interfaces n’étaient pas encore développées : corriger une définition ne demandait donc pas de démonter un échange déjà construit.

Ce qui a été décidé

1. 01

   Distinguer les besoins futurs des habitudes de l’ancien outil

   À partir de quoi

   Travail manuel, attributs peu fiables et contournements quotidiens

   Par qui

   Utilisateurs, Produit, Marketing, analystes métier et consultants seniors

   Comment cela a tenu

   Rendre notre interprétation au groupe lors de l’atelier suivant

2. 02

   Définir produit, SKU et variante

   À partir de quoi

   Définitions contradictoires et exceptions historiques dans SAP

   Par qui

   Spécialistes de la donnée, Produit, analystes métier et responsables du modèle

   Comment cela a tenu

   Confronter les mots à de vrais produits et à leurs cas limites

3. 03

   Éprouver le modèle avant les interfaces

   À partir de quoi

   Le modèle configuré dans Akeneo par l’analyste métier

   Par qui

   Futurs utilisateurs, Produit, Marketing et analyste métier

   Comment cela a tenu

   Faire la tâche, corriger la configuration, recommencer

4. 04

   Décider ce qui doit circuler entre les systèmes

   À partir de quoi

   Une structure produit testée et les contraintes techniques connues

   Par qui

   IT, analystes métier, consultants techniques et équipe de réalisation

   Comment cela a tenu

   Vérifier correspondances, règles et comportement des interfaces

Le jour où les flèches ont enfin servi

Quand le travail d’interface a commencé, le mot « produit » ne changeait plus de forme au milieu de la réunion. Les champs pouvaient encore être complexes ; SAP gardait toujours son histoire. Mais le code n’avait plus à arbitrer silencieusement entre plusieurs définitions métier.

Les systèmes ont commencé à se parler après que les personnes ont cessé d’utiliser le même mot pour dire des choses différentes.