Menu
Développer un modèle opérationnel orienté produit, qu’est-ce que ça veut dire ?
Les organisations se tournent de plus en plus vers les modèles opérationnels orientés produits dans le but de soutenir la vision de l’entreprise et l’aider à accomplir ses missions. Dans une publication précédente, nous avons abordé les enjeux et les bénéfices liés à l’adoption de ce type d’approche. Dans cet article, nous allons aborder le volet pratique en définissant, dans les grandes lignes, la manière dont l’informatique doit aborder cette transformation.
Pour commencer, soulignons que la transition vers un modèle opérationnel orienté produit n’est pas un processus uniforme. Elle varie en fonction du contexte propre à chaque organisation, notamment en fonction de sa structure, de sa culture et du niveau de maturité des parties prenantes.
Heureusement, il existe quelques invariants à explorer et à partir desquels l’organisation va pouvoir construire son modèle opérationnel.
Ces invariants sont les axes de réalisation du modèle opérationnel et sont au nombre de trois : l’organisation, la conception des processus (dans notre cas le cycle de vie du produit) et l’opérationnalisation même du processus (le fait de le rendre apte à fonctionner de manière productive). Le modèle opérationnel orienté produit que l’on cherche à concevoir et à déployer doit donc définir la manière dont une organisation envisage de mettre à contribution ses collaborateurs, ses processus et sa technologie pour apporter de la valeur aux clients internes et externes. Pour construire ce modèle, il est possible de nourrir sa réflexion avec des éléments de méthodes éprouvés que l’on pourra trouver dans l’architecture de référence IT4IT™, dans les approches agiles (SAFe®), et dans les pratiques DevOps.
Un modèle opérationnel orienté produit aligne l’organisation du travail sur (toutes) les chaînes de valeur
Le flux de valeur est une notion essentielle pour constituer le portefeuille des produits et des services d’une organisation. Il définit le parcours suivi par un produit ou service du point de vue du client, de la demande initiale à la satisfaction du besoin. Il se concentre sur l’expérience client (qu’il soit interne ou externe) et la création de valeur perçue.
Le corpus de connaissance SAFe® définit deux types de flux de valeur : les « Operational Value Streams (OVS) » et les « Development Value Streams (DVS) ». Cette segmentation est intéressante car elle nous permet d’appréhender l’approche orientée produit dans son ensemble, et pas uniquement du point de vue de l’IT.
Les flux de valeur opérationnels
Ces flux coïncident avec les différents produits ou services que l’organisation met à disposition de ses clients, administrés ou usagers, par le biais des solutions informatiques (produits digitaux internes) créées par les flux de valeur de développement. Un exemple simple est le flux d’achat d’un bien de consommation comprenant : la recherche d’informations, la comparaison des prix, l’achat, la livraison et l’utilisation. Une compréhension approfondie des flux de valeur opérationnels est cruciale pour la conception et la réalisation des solutions informatiques produites par les flux de valeur de développement.
Dans SAFe®, les équipes qui gèrent les flux de valeurs opérationnels sont les « Agile Release Train ».
Il s’agit d’équipes pluridisciplinaires de haut niveau dans lesquelles les gestionnaires de produit occupent une position dominante, car ce sont eux qui doivent définir la stratégie de mise sur le marché d’un produit et d’en diriger l’exécution. Ces équipes coordonnent et alignent les autres équipes (celles qui développent les produits informatiques) afin de fournir la valeur attendue par le client final à travers l’utilisation du produit ou du service.
Les flux de valeur de développement
Ces flux coïncident avec les produits digitaux/solutions informatiques (les termes sont interchangeables) que les acteurs IT mettent à disposition des acteurs métier, afin que ces derniers délivrent les produits et services de l’entreprise au moyen des flux de valeur opérationnels.
Si l’on se réfère de nouveau au modèle organisationnel défini dans SAFe®, la correspondance avec les équipes agiles parait évidente. Dans ce cas précis, nous avons affaire à des groupes pluridisciplinaires qui possèdent toutes les compétences nécessaires pour définir, réaliser, tester, livrer, et exploiter un produit digital. Ce qui les distingue principalement des ARTs, c’est la nature des produits qu’elles développent et le type de clients pour le compte desquels elles travaillent.
L’organisation du travail le long de ces deux types de flux de valeur permet de concrétiser la proposition de valeur du modèle opérationnel orienté produit, à savoir : une meilleure proximité avec les clients et une meilleure qualité du produit, un apprentissage plus rapide, une augmentation de l’efficience collective et une réduction du time-to-market.
La suite de l’exposé se concentre sur les flux de valeur de développement ; ceux qui assurent la gestion du cycle de vie des produits digitaux qui composent la plateforme informatique.
Axe 1 : Aligner le modèle opérationnel orienté produit sur les capacités métier et technologiques
Une façon éprouvée de structurer le modèle opérationnel consiste à regrouper les produits IT qui partagent un même domaine de connaissance métier au sein d’une même équipe. On fait converger vers cette équipe l’ensemble des besoins fonctionnels relatifs à une même capacité métier. L’équipe est chargée de piloter en continu la transformation du portefeuille des produits utilisés pour informatiser la capacité métier en question.
Les produits IT dont on parle ici sont les applications/solutions informatiques qui réalisent les capacités métier impliquées dans l’exécution des flux de valeurs opérationnels à destination des clients de l’organisation. Dans l’exemple ci-dessous (volontairement simplifié), chacune des 3 équipes est associée à une capacité métier de premier niveau et gère le cycle de vie des produits (des solutions informatiques) contribuant à réaliser la capacité. Toutes ces capacités, ainsi que les solutions informatiques sous-jacentes, sont mobilisées dans l’un ou dans les deux flux de valeur opérationnels (achat et utilisation d’un abonnement internet seul ou achat et utilisation d’une offre groupée).
La même démarche peut être envisagée vis-à-vis des capacités technologiques. Une équipe se verra confier la gestion du cycle de vie des produits qui participent à la réalisation d’une même capacité technologique comme : toutes les plateformes logicielles utilisées pour faire de l’Enterprise Content Management, pour gérer les flux d’intégration entre applications, pour développer des solutions informatiques… Cette équipe aura la responsabilité de faire évoluer les produits qui répondent à un ensemble de besoins similaires regroupés dans une capacité non plus métier mais technologique.
Axe 2 : Concevoir le processus de développement des produits digitaux
Maintenant que les équipes ont été constituées, il est important qu’elles utilisent, autant que possible, un processus unifié pour la gestion du cycle de vie des produits digitaux, qu’il s’agisse d’applications métier ou de plateformes technologiques.
Le recours au Framework IT4IT™ comme point de départ dans la définition de ce processus est sans doute une bonne idée dans la mesure où cette réflexion a déjà été menée et a abouti à des résultats concrets dont on peut rapidement tirer profit.
IT4IT™ de l’Open Group est une architecture de référence standard pour la conception d’un modèle opérationnel orienté produit pour l’informatique.
Elle documente, au sens de SAFe®, les sept flux de valeur du développement d’un produit digital, ainsi qu’un ensemble d’activités et de composants fonctionnels spécifiquement conçus pour la gestion du cycle de vie des produits digitaux.
Axe 3 : Instancier le flux de valeur de développement avec les approches agiles et DevOps
Rappelons ici que l’objectif principal du modèle opérationnel orienté produit est de concevoir des organisations et des équipes adaptables, capables d’intégrer continuellement les changements dans les attentes des clients et du marché.
L’adoption des principes agiles est un prérequis essentiel à l’exécution d’un tel modèle. C’est, en effet, l’application de ces principes qui rend possible la livraison rapide d’améliorations critiques via des incréments de valeurs appropriés. Des pratiques agiles conformes aux normes de l’industrie telles que SAFe® doivent par conséquent être intégrées au modèle opérationnel.
Cette exigence d’intégration concerne également la culture et les pratiques DevOps. Elles sont essentielles pour une mise en œuvre efficace du modèle opérationnel orienté produit et doivent être incorporées au cycle de vie du développement du produit, avec les outils et les mécanismes de gouvernance adéquats. C’est la seule façon de garantir la mise à disposition de produits de haute qualité dans des délais de livraison courts. Le recours à DevOps contribue par ailleurs à la réduction des risques de dysfonctionnement lors des livraisons et à l’amélioration de la résolution des problèmes survenant en phase d’exploitation.
Les autres facteurs clés de succès de l’adoption du modèle opérationnel orienté produit.
D’autres points importants doivent être considérés pour réussir la conception et la mise en œuvre d’un modèle opérationnel orienté produit. La liste suivante n’est certainement pas exhaustive, mais elle identifie quelques-unes des actions indispensables à intégrer dans le plan de déploiement.
Une stratégie et un portefeuille de produits gérés activement afin d’entretenir une vision juste des besoins des clients et de diriger les cycles de vie des produits en conséquence.
En pratique, il s’agit d’élaborer une vision à moyen terme sur la manière dont l’entreprise entend développer un avantage concurrentiel sur les marchés qu’elle adresse, ainsi que sur les produits à développer et à maintenir en priorité.
Un positionnement correct des équipes au sein de l’organisation.
Il faut toujours positionner l’équipe dans l’organigramme avec comme objectif de développer une relation étroite avec l’utilisateur du produit. Pour les produits destinés aux clients de l’organisation, on peut supposer que les équipes seront localisées dans une unité métier au plus proche des clients (par exemple, les ventes). En revanche, pour les produits/solutions informatiques qui composent le back-office du Système d’Information (produits digitaux consommés par les clients internes et plateformes technologiques), la gestion du cycle de vie devra être assurée par des équipes spécifiques au sein du département IT.
Des équipes produit stables, dédiées, permanentes et responsables des produits qu’elles délivrent par opposition aux équipes de projet temporaires.
L’orientation produit implique le maintien de l’expertise sur la durée. C’est essentiel pour prévenir les inefficacités et les pertes de connaissances observées fréquemment avec les équipes projets qui sont constituées et dissoutes une fois les projets terminés. Plus on crée d’équipes durables, plus il est facile pour les membres de ces équipes de continuer à collaborer.
Des indicateurs de performance associés aux flux de valeur de développement.
Chacun de ces flux représente un investissement significatif pour l’entreprise. Il est donc normal d’introduire une gouvernance raisonnée au moyen d’un ensemble d’indicateurs clés de performance (KPI) afin d’évaluer la contribution d’un flux de valeur aux résultats commerciaux escomptés.
Une culture qui privilégie la compréhension et le respect des clients, avec des équipes qui ciblent directement leurs besoins et mesurent leur satisfaction.
Il faut encourager les comportements et les habitudes qui vont dans ce sens. Il n’est plus question de récompenser les managers uniquement en fonction de l’étendue de leur contrôle. Les gestionnaires de produit doivent endosser un rôle plus axé sur la gestion des compétences interpersonnelles, la valeur commerciale du produit et l’apprentissage continu. Les règles d’évaluation de la performance individuelle et de rémunération doivent être réajustées. L’implication du département des ressources humaines est bien évidemment prépondérante.
En synthèse
Pour l’IT, un modèle opérationnel orienté produit est un moyen d’organiser les ressources informatiques autour de capacités métier et technologiques (ou de produits) et non plus autour des fonctions informatiques classiques. Son objectif est d’aider l’informatique à améliorer les délais de livraison, à optimiser les coûts et à accroître la qualité.
Mais concrètement, l’adoption d’un tel modèle n’est pas un exercice facile à réaliser. Elle nécessite un changement de culture, un apprentissage continu et une mise en œuvre soigneusement préparée. La phase de préparation consiste à travailler simultanément sur trois dimensions clés : la constitution du catalogue des produits et des équipes, la définition d’un flux de valeur unifié centré sur le cycle de vie du produit et non plus sur celui du projet, et enfin l’opérationnalisation du processus grâce aux pratiques agiles et DevOps.
Comme dans tout projet de transformation organisationnelle, les difficultés et les risques auxquels les équipes seront confrontées sont bien réels. Afin de sécuriser la conception et la mise en œuvre du modèle, il faudra songer à faire appel à des expertises dans le domaine de l’agilité, bien évidemment, mais aussi en architecture d’entreprise et en conduite du changement.
Références
The Importance Of Embracing A Product Operating Model|https://www.forbes.com/sites/forbestechcouncil/2021/01/27/the-importance-of-embracing-a-product-operating-model/
Adaptable Product Operating Model | Deloitte US|https://www2.deloitte.com/us/en/blog/human-capital-blog/2022/product-operating-model.html
Mike Bertha, Author at Metis Strategy|https://www.metisstrategy.com/author/mike/
Value Streams – Scaled Agile Framework|https://v5.scaledagileframework.com/value-streams/
Agile Release Train – Scaled Agile Framework|https://scaledagileframework.com/agile-release-train
