Ce que la gestion des chaînes de valeur gère vraiment

La gestion des chaînes de valeur révèle où la valeur ralentit entre l’idée et le client, puis aide les dirigeants à corriger le système.

La gestion des chaînes de valeur, ou VSM, est souvent présentée comme une nouvelle catégorie de tableaux de bord, d’intégrations et d’outils de portefeuille. C’est passer à côté de l’essentiel. Il s’agit d’une discipline de gestion qui permet de voir comment une idée devient un résultat pour le client, de repérer où le processus ralentit, puis de corriger le système plutôt que de simplement demander aux équipes de travailler plus vite.

À retenir

  • Une chaîne de valeur couvre tout le parcours entre un besoin reconnu et un résultat mesurable pour le client.
  • La VSM vise à améliorer le système de livraison, pas seulement la productivité de chaque équipe.
  • La cartographie révèle les files d’attente, les transferts, les reprises, les dépendances et les délais d’approbation que les métriques d’équipe ne montrent pas.
  • Les métriques de flux, les métriques DORA et les mesures de résultats répondent à des questions différentes. Elles ne devraient pas être réduites à un seul indicateur.

Une chaîne de valeur dépasse largement l’équipe de livraison

Une chaîne de valeur est l’ensemble des activités nécessaires pour transformer un besoin en quelque chose que le client peut utiliser et dont il peut tirer un bénéfice.

Dans le développement logiciel, ce parcours peut comprendre :

  1. La recherche client ou la rétroaction des opérations
  2. La priorisation et le financement
  3. La découverte produit
  4. L’architecture et l’évaluation des risques
  5. Le développement et les essais
  6. La mise en production
  7. L’adoption, le soutien et la mesure des résultats

Ces chaînes existent déjà dans la plupart des organisations. Elles ne sont simplement pas gérées comme des systèmes cohérents.

Chaque fonction s’occupe plutôt de sa portion :

  • Le produit suit la feuille de route.
  • L’ingénierie suit la livraison.
  • Les équipes de risque suivent les approbations.
  • Les opérations suivent les incidents.
  • Les finances suivent les budgets.
  • La direction suit les objectifs stratégiques.

Chacune de ces perspectives peut être exacte, alors que le système de livraison dans son ensemble demeure lent et imprévisible.

Une fonctionnalité peut prendre quatre jours à développer, mais quatre mois à atteindre le client. Améliorer la productivité des développeurs ne réglera pas le problème si le reste du temps est consacré à attendre une décision, un environnement, une approbation ou la disponibilité d’une autre équipe.

Voilà le premier apport de la VSM : elle déplace l’analyse de l’équipe vers la circulation de la valeur.

La cartographie rend les délais invisibles visibles

La cartographie d’une chaîne de valeur reconstitue le parcours réel du travail, du besoin initial jusqu’au résultat attendu.

Le but n’est pas de produire un beau diagramme de processus. Il faut représenter ce qui se passe réellement, y compris les étapes qu’on préfère généralement ne pas montrer dans un modèle opérationnel.

Pour chaque étape, les équipes devraient déterminer :

  • Qui effectue le travail
  • Quelle information est nécessaire
  • Combien de temps le travail actif exige
  • Combien de temps le dossier attend
  • Ce qui provoque des reprises
  • Quelles dépendances bloquent régulièrement l’avancement
  • Si l’étape crée de la valeur pour le client, facilite la livraison ou existe seulement en raison du modèle opérationnel actuel

Du besoin client à la valeur réalisée

Ajuster Besoin du client Choisir et financer Explorer et concevoir Développer et valider Déployer et favoriserl’adoption Mesurer le résultat Qu’avons-nousappris?
La VSM examine l’ensemble du système, y compris l’attente et les boucles de rétroaction entre les étapes.

L’indicateur le plus révélateur est souvent le rapport entre le temps de travail actif et le temps total écoulé.

Prenons un changement qui demande :

  • 12 heures d’analyse
  • 30 heures de développement et d’essais
  • 6 heures de mise en production
  • 27 jours civils au total

Le travail lui-même a pris 48 heures. Le client, lui, a attendu près d’un mois.

C’est dans cet écart que se trouve le véritable problème de gestion.

On peut y trouver des files d’approbation, des spécialistes surchargés, des responsabilités mal définies, des évaluations de sécurité réalisées trop tard, des environnements d’essai partagés, des fenêtres de déploiement rigides ou du travail lancé avant que l’organisation soit prête à le terminer.

Aucun de ces problèmes n’apparaît dans un graphique de vélocité.

La VSM relie la stratégie à la livraison sans les confondre

La direction et les équipes de livraison parlent souvent du même travail dans des langages incompatibles.

La direction parle de :

  • Croissance
  • Exposition au risque
  • Fidélisation de la clientèle
  • Réduction des coûts
  • Engagements stratégiques

Les équipes de livraison parlent de :

  • Récits utilisateurs
  • Fonctionnalités
  • Anomalies
  • Mises en production
  • Dépendances
  • Dette technique

La VSM établit un lien traçable entre ces niveaux.

Un objectif stratégique devrait mener à une décision d’investissement. Cet investissement devrait financer des initiatives ou des paris produit. Ces paris devraient progresser dans le système de livraison. Leur mise en production devrait ensuite produire des données sur l’adoption ou l’impact.

Ce lien est essentiel, parce qu’un travail terminé n’est pas nécessairement un travail utile.

Une équipe peut livrer toutes les fonctionnalités promises sans améliorer l’expérience client. Elle peut déployer plus souvent tout en investissant dans le mauvais produit. Elle peut réduire son temps de cycle pendant que l’adoption continue de reculer.

La VSM pose donc deux questions distinctes :

  1. Avec quelle efficacité le travail circule-t-il dans le système de livraison?
  2. Le travail livré a-t-il produit le résultat recherché?

La première concerne le flux. La seconde concerne la valeur réalisée.

Une organisation saine mesure les deux.

Les métriques doivent servir au diagnostic, pas à la décoration

La VSM n’exige pas un indicateur universel. Elle exige un petit ensemble de mesures capables de répondre à différentes questions de gestion.

Les métriques de flux expliquent comment le travail avance

La vélocité du flux mesure le nombre d’éléments de valeur terminés pendant une période donnée.

Elle peut soutenir la planification de la capacité et les prévisions, à condition que les éléments soient suffisamment comparables et que la mesure ne devienne pas un quota de rendement.

Le temps de flux mesure la durée nécessaire pour qu’un élément passe d’un point de départ défini jusqu’à sa livraison.

Le point de départ est déterminant. Mesurer à partir du début du développement peut aider une équipe. Mesurer à partir de la demande du client peut révéler un problème organisationnel beaucoup plus important.

La charge du flux mesure le travail en cours.

Un volume élevé de travail en cours ne constitue pas seulement un irritant pour les équipes. À l’échelle de la chaîne de valeur, il crée des files d’attente, augmente les coûts de coordination, retarde la rétroaction et affaiblit la crédibilité des priorités.

L’efficacité du flux compare le temps de travail actif au temps total écoulé.

Une faible efficacité indique généralement un problème d’attente plutôt qu’un problème d’exécution. Cette distinction change complètement la solution à mettre en place.

La répartition du flux montre comment la capacité est distribuée entre les fonctionnalités, les anomalies, la dette technique, la réduction des risques et les autres catégories de travail.

Elle permet de vérifier si les priorités annoncées se reflètent réellement dans les investissements. Une direction peut affirmer que la résilience est prioritaire alors que presque toute la capacité demeure consacrée aux nouvelles fonctionnalités.

Les métriques DORA décrivent la capacité de livraison logicielle

La fréquence de déploiement, le délai de livraison des changements, le taux d’échec des changements et le temps de rétablissement aident les équipes à comprendre leur performance en livraison logicielle.

Ces mesures sont utiles, mais elles ne représentent pas toute la chaîne de valeur.

Une équipe peut exceller en déploiement tout en étant ralentie par une priorisation laborieuse, un financement annuel, une propriété fragmentée ou une découverte produit déficiente.

Les métriques DORA décrivent des composantes importantes du moteur. Elles ne disent pas si l’organisation a choisi la bonne destination.

Les mesures de résultats indiquent si le travail a eu un effet

Les résultats à mesurer dépendent du produit et de l’hypothèse mise à l’épreuve.

On peut notamment mesurer :

  • L’adoption
  • La réussite d’une tâche
  • La fidélisation
  • La conversion
  • La réduction des demandes de soutien
  • La réduction du temps de traitement
  • La diminution des anomalies échappées en production
  • La protection des revenus
  • La réduction des risques opérationnels ou réglementaires

Ces mesures devraient être liées à une hypothèse explicite.

« Nous croyons qu’en simplifiant ce processus, nous réduirons le nombre de demandes abandonnées » est mesurable.

« Livrer la refonte du processus au troisième trimestre » est un engagement de livraison, pas un résultat.

Pourquoi les transformations échouent sans vision de bout en bout

Plusieurs transformations agiles ou numériques améliorent les cérémonies sans améliorer la circulation de la valeur.

Les équipes adoptent Scrum. Les portefeuilles passent à une planification trimestrielle. La direction reçoit de nouveaux tableaux de bord. Jira devient plus uniforme. Pourtant, les changements importants n’atteignent pas les clients plus rapidement.

Le problème vient souvent du fait que la transformation s’arrête aux frontières des équipes.

Les délais les plus coûteux se trouvent fréquemment entre les équipes :

  • Le produit attend le financement.
  • L’ingénierie attend l’architecture.
  • L’architecture attend une décision d’affaires.
  • Les essais attendent un environnement.
  • Le déploiement attend une fenêtre prévue au calendrier.
  • Les clients attendent la formation ou la migration.
  • La direction attend un rapport qui arrive après le moment où la décision devait être prise.

Une équipe ne peut pas éliminer dans sa rétrospective une file d’attente de portefeuille qu’elle ne contrôle pas.

La VSM porte ces contraintes au niveau où elles peuvent être gérées. Elle donne aux dirigeants une raison de revoir le financement, la gouvernance, la structure des équipes, les politiques d’approbation ou la répartition des responsabilités, plutôt que d’exiger une autre hausse de productivité des équipes de livraison.

Cette distinction est particulièrement importante dans les milieux réglementés.

Certains contrôles sont obligatoires. L’attente, le dédoublement et les responsabilités floues ne le sont pas.

Un contrôle qui protège réellement l’organisation doit demeurer. Un contrôle qui demande à cinq groupes d’examiner les mêmes preuves devrait être repensé.

La VSM ne justifie pas de tout centraliser

Une dérive fréquente consiste à transformer la VSM en vaste programme de reddition de comptes.

Une équipe centrale achète une plateforme, intègre tous les outils de livraison, impose des dizaines de champs obligatoires et construit un tableau de bord pour la haute direction. Les équipes consacrent davantage de temps à entretenir les données. Les décisions, elles, ne changent pas.

Ce n’est pas de la gestion des chaînes de valeur. C’est de la surcharge administrative sous une nouvelle étiquette.

Une bonne démarche de VSM crée assez de visibilité commune pour permettre aux équipes et aux dirigeants d’agir.

Elle devrait notamment aider à répondre aux questions suivantes :

  • Où le travail passe-t-il la majorité de son temps?
  • Quelle dépendance provoque le plus de retards récurrents?
  • Combien de travail est commencé comparativement à ce qui est terminé?
  • Quels investissements consomment de la capacité sans produire de preuve de valeur?
  • Les risques, les anomalies et la dette technique sont-ils financés volontairement ou seulement après une escalade?
  • Quelles étapes de gouvernance réduisent réellement le risque, et lesquelles servent surtout à prouver qu’une réunion a eu lieu?

L’objectif n’est pas de créer un modèle numérique parfait de l’organisation.

L’objectif est de prendre une meilleure décision opérationnelle.

Comment commencer sans acheter une plateforme

Commencez par une seule chaîne de valeur et un seul résultat client.

Ne tentez pas de cartographier toute l’entreprise. Choisissez un produit, un service ou un parcours de livraison récurrent qui compte vraiment et dont le rendement pose clairement problème.

Ensuite :

  1. Définissez le client et la valeur qu’il recherche.
  2. Entendez-vous sur le début et la fin de la chaîne de valeur.
  3. Réunissez des représentants du produit, de l’ingénierie, des opérations, du risque et de toute fonction qui intervient régulièrement dans le parcours.
  4. Reconstituez le chemin réel à partir d’exemples récents.
  5. Mesurez le temps actif, l’attente, les reprises, le travail en cours et les principales dépendances.
  6. Repérez la contrainte qui a le plus d’effet.
  7. Modifiez une politique, un transfert, une file d’attente ou un déséquilibre de capacité.
  8. Vérifiez si le flux et les résultats pour le client s’améliorent.

Les outils deviennent utiles lorsque l’organisation comprend ce qu’elle souhaite observer et gérer.

Acheter la plateforme en premier revient souvent à automatiser la confusion déjà en place.

Questions fréquentes

La gestion des chaînes de valeur et la cartographie des chaînes de valeur sont-elles la même chose?

Non. La cartographie est une technique de diagnostic. La gestion est une pratique continue qui touche la mesure, le financement, la gouvernance et l’amélioration de la chaîne de valeur.

Une carte peut révéler que le travail attend deux semaines avant d’être approuvé. La VSM détermine qui est responsable de cette contrainte, ce qui doit changer et si l’intervention a fonctionné.

La VSM s’applique-t-elle seulement aux organisations logicielles?

Non. Le concept vient de la gestion Lean et s’applique à tout flux répétable qui produit de la valeur pour un client.

Les organisations technologiques l’ont adopté parce que la livraison numérique traverse souvent plusieurs fonctions spécialisées, outils, mécanismes d’approbation et environnements opérationnels.

La VSM remplace-t-elle Scrum, Kanban, SAFe ou DevOps?

Non. Ces approches interviennent à des niveaux différents et répondent à des problèmes distincts.

Scrum peut structurer l’inspection et l’adaptation d’une équipe. Kanban peut améliorer le flux. DevOps peut améliorer la livraison logicielle. SAFe peut coordonner le travail dans une grande organisation.

La VSM fournit la vue de bout en bout nécessaire pour vérifier si l’ensemble de ces pratiques produit réellement une valeur plus rapide et plus fiable.

Quelle est l’erreur la plus fréquente en VSM?

Traiter la VSM comme une initiative de visibilité plutôt que comme un engagement de gestion.

La visibilité permet de voir la file d’attente. La gestion permet de la supprimer.

Lors de votre prochaine revue de livraison, choisissez une initiative importante et demandez combien de jours ont été consacrés au travail actif, puis combien ont été perdus dans l’attente.

La réponse vous en dira davantage sur votre système de livraison qu’une autre diapositive présentant un pourcentage d’avancement.