Les chaînes de valeur métier, étape cruciale dans une transformation Agile à l’échelle

Un processus opérationnel peut être décrit sous la forme d’une chaîne de valeur. Son point de départ est une demande qui se poursuit jusqu’à la livraison de valeur au client de ce processus. Il peut regrouper métier et fonctions support (RH, finances, achats, …). Les étapes du processus peuvent s’appuyer sur des systèmes (ensemble d’outils dont IT). Enfin, l’alignement plus spécifique de l’IT avec le métier consiste à mettre en face de chaque processus opérationnel le ou les processus de livraison IT faisant évoluer les systèmes à leur service. (Visualisés à travers des chaînes de valeur de développement).

Chaînes de valeur : aligner l’organisation

L’expérience de mise en œuvre de plusieurs transformations agiles à l’échelle a montré que cette première étape de modélisation des chaînes de valeur, souvent négligée ou accélérée, est une étape clé pour la réussite de la transformation et sa pérennité. Notamment à travers l’embarquement, autrement dit l’implication des métiers.

Cette modélisation de la chaîne de valeur s’effectue lors d’un atelier collaboratif, qui nécessite de s’assurer que :

• Soient réunis l’ensemble des parties prenantes couvrant le processus, ou a minima un groupe représentatif.
• Les bornes (point de départ et point d’arrivée) de la chaîne de valeur soient clairement identifiées.
• L’atelier ne se limite pas à la modélisation de la chaîne de valeur, mais doit se prolonger par une réelle phase d’analyse du processus.
• La chaîne de valeur doit pouvoir décrire non seulement les processus, mais aussi permettre de visualiser les parties prenantes et utilisateurs de chaque processus et sous processus.

Les bénéfices d’une démarche remplissant ces 4 critères sont :

• Une prise de conscience collective et une appropriation du processus dans son intégralité.
• L’identification à l’échelle globale des failles, goulots d’étranglement et des améliorations possibles du processus métier. Couverts ou non par des systèmes IT (par exemple, une tâche manuelle bureautique effectuée par une seule personne détentrice de la connaissance).
• Une aide à la priorisation des évolutions futures basées sur des arguments factuels et alimentant la feuille de route d’évolution de l’architecture. Cela peut avoir un impact sur la structuration et le séquencement de la transformation.
• L’identification des parties prenantes, des entités ou personnes à impliquer dans la mise en place du « Product Management ».
• L’identification de dépendances externes et bornes des processus mal identifiées.

Mes recommandations sont les suivantes :

• Temporiser la suite des étapes de la transformation, le temps de lancer toutes les actions résultantes de cette première analyse, peut constituer un piège bloquant la transformation.
  Si certains leviers sont effectivement à actionner tôt sous peine d’un coût ultérieur, il convient de les séparer d’autres éléments qui pourront être actionnés plus tard dans la transformation.
• Dans le cadre de l’amélioration continue, le processus métier modélisé doit continuer à être visualisé au fur et à mesure de ses évolutions et donner l’opportunité d’améliorations globales en évitant le piège des optimum locaux.
• Il ne s’agit pas ici d’appliquer tel ou tel modèle cible de transformation : la valeur réside dans la réalisation d’un exercice collaboratif facilité par des coachs aux postures adaptées. Ces deux facteurs sont essentiels pour permettre aux parties prenantes de devenir ensemble les acteurs engagés de leur transformation et leur permettre de faire évoluer leurs processus. C’est le prélude à l’agilité dans les métiers et fonctions supports bien au-delà de l’IT.