Traverser le gouffre du projet au produit | CIO

[Chris Boyd co-authored this article]

Mener les transformations numériques est la priorité absolue du PDG pour les DSI, selon l'étude 2020 IDG State of the CIO . Pour ce faire, il faut un modèle d'exploitation informatique qui permette aux entreprises et aux TI de travailler ensemble pour naviguer dans un paysage concurrentiel dynamique, un ensemble apparemment infini d'outils numériques et des demandes changeantes des parties prenantes.

Dans notre travail avec les sociétés du Fortune 500, nous avons trouvé l'informatique les organisations qui utilisent le modèle d'exploitation traditionnel «planifier, construire, exécuter» peinent à conceptualiser, à lancer et à maintenir l'élan des transformations numériques. Pour renforcer leur capacité de transformation, les organisations informatiques de tous les secteurs et de toutes les régions se tournent vers des modèles d'exploitation orientés produit ou «informatique basée sur le produit». Lorsqu'elles sont bien faites, les organisations bénéficient d'une agilité accrue, de clients plus satisfaits et de transformations plus réussies.

Définition de l'informatique basée sur les produits

Un produit est une capacité qui prend vie grâce à la technologie, aux processus métier et à l'expérience client qui crée un flux de valeur continu. Des exemples de produits sont le commerce électronique, la chaîne d'approvisionnement ou les RH. Un modèle d'exploitation définit la façon dont une organisation positionne ses employés, ses processus et sa technologie pour offrir de la valeur aux clients internes et externes.

Un modèle d'exploitation orienté produit est donc un modèle dans lequel les ressources informatiques sont organisées autour de capacités commerciales ou de «produits». »Au lieu de systèmes informatiques spécifiques (par exemple SAP, CRM) ou de fonctions (AQ, ingénierie, infrastructure). Dans ce modèle, chaque équipe produit fonctionne comme si elle gérait un produit destiné au marché tel qu'un appareil électronique grand public. Ils développent une stratégie de produit et une feuille de route en étroite collaboration avec l'entreprise qui articule clairement comment ils feront mûrir le produit pour mieux répondre aux besoins des clients et optimiser le positionnement concurrentiel. Chaque fonctionnalité de la feuille de route est alignée sur un résultat commercial mesurable et passe par une phase de découverte rapide pour valider la valeur, l'utilisabilité et la faisabilité avant qu'elle ne soit définie dans un sprint pour obtenir un produit minimum viable.

Moteurs du passage au produit – based IT

La plupart des organisations ont perfectionné leur capacité à fournir lorsque la portée et le résultat souhaité sont statiques, mais éprouvent des difficultés lorsque les étapes suivantes ne sont pas définies ou sont peintes au pinceau. Plusieurs grandes organisations informatiques se sont tournées vers l'informatique basée sur les produits pour lever cette ambiguïté et élever leur rôle de fournisseur de services à partenaire commercial.

Art Hu, le DSI mondial de Lenovo, est l'un des pionniers du passage du projet à au produit. Il a noté dans une récente conversation que son organisation était aux prises avec la question de savoir sur quoi travailler ensuite après avoir terminé une série d'intégrations ERP héritées résultant d'acquisitions. "Le changement de paradigme fondamental pour nous était que le niveau d'incertitude avait changé quand il n'y avait plus un seul impératif", a-t-il déclaré, se référant au projet ERP. «Lorsque nous avons retiré cela, c'était un monde totalement différent et la cascade traditionnelle n'avait plus de sens. Jusqu'à ce que nous, en tant qu'organisation, réalisions cela, les équipes commerciales et mes équipes ont eu du mal. » Les organisations basées sur les produits s'appuient sur l'engagement continu des clients pour éliminer les conjectures du processus de priorisation, ce qui conduit souvent à de meilleurs résultats commerciaux et à une agilité accrue.

L'informatique basée sur les produits cible les principaux changements de comportement

Les DSI ont ciblé les principaux changements de comportement pour accélérer le passage à un modèle d'exploitation basé sur les produits:

Le travail est axé sur la valeur, pas sur les plans

Plans de projet élaborés avec les livrables et les délais fixes encouragent la prévisibilité mais sont rarement équivalents aux résultats commerciaux. Ce travail axé sur les plans donne de plus en plus de découvertes et de livraisons continues, qui cherchent à répondre à deux questions de façon récurrente: que devons-nous construire et comment devons-nous les construire? Un parcours de découverte prend en compte les opportunités, les idées et les problèmes à résoudre. Les équipes s'engagent ensuite avec les clients pour valider que ces idées créent de la valeur (désirabilité), seront utilisées une fois publiées (utilisabilité) et sont réalisables dans le modèle commercial actuel (faisabilité / viabilité).

«Les grandes entreprises qui ont construit une orientation produit commencer par l'opportunité et tirer parti de la pensée de conception pour avoir des conversations basées sur l'empathie pour aller au cœur des problèmes », a déclaré Srini Koushik, CIO / CTO de Magellan Health, lors d'un récent panel de gestion de produits . Les idées qui passent par la découverte sont ajoutées à un backlog de produit et sont réparties en sprints pour la livraison en fonction de la priorité commerciale relative. Les pistes de découverte et de livraison fonctionnent simultanément pour garantir qu'un flux constant d'idées validées et un produit fonctionnel qui stimule les résultats commerciaux sont livrés à la fin de chaque sprint.

Les équipes sont dédiées et de longue date, pas temporaires ou à temps partiel

lors d'une récente session de planification stratégique, un DSI a déclaré que «la transformation n'est pas un travail à temps partiel», notant que des équipes dédiées sont essentielles à la fois pour la transformation numérique et pour construire une orientation produit en informatique. Les équipes qui sont formées projet par projet passent un temps précieux à développer leur expertise en la matière et la chimie du bâtiment, mais sont ensuite dissoutes au moment où elles commencent à atteindre leur rythme de croisière. Les organisations informatiques basées sur les produits, en revanche, favorisent les équipes dédiées qui possèdent un produit de son introduction jusqu'au coucher du soleil, y compris l'exécution de la découverte, de la livraison, des tests et de la maintenance / assistance. Dans ce modèle, les équipes dédiées deviennent de véritables experts dans le domaine et évitent les pièges résultant des transferts intra-organisationnels et des ressources renouvelables.

Les commentaires des clients sont recueillis à chaque sprint, pas seulement à la fin d'un projet

La fréquence accrue et la qualité des interactions avec les clients est une caractéristique de l'informatique basée sur les produits. Idéalement, les clients sont engagés pendant la phase de découverte pour valider les idées et les prototypes, puis fournir des commentaires à intervalles réguliers après la sortie du produit. Si votre client final est une unité commerciale, vous devez vous efforcer d'avoir encore plus d'interactions. Certaines organisations font participer des intervenants commerciaux à des stand-ups quotidiens, et certains peuvent même faire en sorte que leurs propriétaires de produits proviennent directement de l'entreprise plutôt que de l'informatique.

Atticus Tysen, responsable de la sécurité de l'information, de la lutte antifraude et de l'information chez Intuit, en est un autre. pionnier dans le passage du projet au produit. Lors du Sommet des stratégies pour les métis de 2019 il a souligné que les véritables organisations de produits réfléchissent aux questions clés qui démontrent leurs solides relations avec les clients. Par exemple, savez-vous vraiment qui sont vos clients et êtes-vous organisé pour les servir? Avez-vous des mesures pour mesurer le bonheur des clients et montrer que vous travaillez avec eux correctement? "Vous devez avoir des clients si vous voulez avoir une organisation de produits", a déclaré Tysen. «Les chefs de produit sont à bien des égards des gestionnaires de relations.»

Les équipes sont financées à perpétuité, pas projet par projet

Pour bénéficier des avantages d'un modèle d'exploitation centré sur le produit, le financement le modèle doit également changer . Plutôt que de financer un projet pour une durée spécifique en fonction des besoins estimés, les équipes sont plutôt financées sur une base annuelle. Également connue sous le nom de financement perpétuel, cette configuration fournit aux équipes de produits informatiques un financement stable qui peut être réaffecté au fur et à mesure que les besoins de l'entreprise évoluent. Il permet également aux équipes de passer du temps à réduire la dette technique ou à améliorer les processus internes comme bon leur semble, ce qui peut améliorer la productivité et la qualité à long terme.

Premières étapes intelligentes pour commencer le passage à l'informatique basée sur les produits

Voici quelques étapes clés pour commencer le voyage…

Identifier les mesures ciblées et établir une base de référence

Les organisations doivent d'abord et avant tout cibler l'impact commercial lorsqu'elles passent à l'informatique basée sur les produits. Par exemple, un client du Fortune 500 a choisi de mesurer le Net Promotor Score pour évaluer la satisfaction de l'entreprise, la vitesse de l'équipe produit pour évaluer la vitesse de mise sur le marché et le nombre de défauts critiques par produit pour évaluer la qualité. Il est également prudent de créer des métriques qui suivent l'adoption des aspects clés du modèle de travail. Par exemple, vous pouvez suivre le pourcentage d'équipes de produits qui ont développé des feuilles de route stratégiques, ou interroger régulièrement les équipes de produits pour voir combien ont l'impression d'avoir les compétences nécessaires pour réussir dans le modèle d'exploitation basé sur les produits.

Définir vos produits en utilisant une approche de chaîne de valeur

Commencez par identifier les capacités internes et orientées client les plus élevées de l'organisation, telles que le développement de produits, les ventes, le marketing, la chaîne d'approvisionnement, les RH et les finances. Au plus haut niveau, ce sont vos groupes de produits, ou «niveau 1». Si votre organisation est plus petite et possède un domaine technique relativement simple, vous n'aurez peut-être pas besoin de le détailler davantage.

Cependant, nous avons constaté que la plupart des entreprises avec plusieurs unités commerciales et zones géographiques doivent le faire. Au sein du groupe des ventes d'une entreprise SaaS, les processus commerciaux comprendraient probablement des étapes telles que la découverte, le plomb à la trésorerie et la réussite du client (qui comprend l'activation, l'adoption, l'expansion et les renouvellements). Ceux-ci peuvent devenir vos groupes de produits car chacune de ces étapes implique différentes parties prenantes de l'entreprise, des KPI ciblés et des composants technologiques. Cependant, la façon dont vous concevez vos équipes de produits dépendra en fin de compte des subtilités de votre organisation.

En l'absence d'une approche unique, nous suggérons les principes directeurs suivants:

• Établissez une propriété claire: La priorité absolue devrait être de créer des équipes de produits d'une manière qui leur permette de s'approprier véritablement et de se sentir habilité à apporter les changements nécessaires pour mûrir leur produit.
• Aligner avec l'architecture: Autant que possible, les équipes de produits devraient être capables de posséder leurs feuilles de route architecturales et de ne pas avoir de dépendances importantes sur d'autres équipes
• Construire des équipes autour de processus et de technologies similaires : Si le travail est unique et utilise des données, des processus et des technologies différents, créez une autre équipe
• Gardez-le petit : Une équipe produit ne devrait pas avoir plus de 10 personnes.
• Soyez stratégique : Assurez-vous que vos équipes produit couvrent les différents acteurs commerciaux et objectifs stratégiques
• Évoluez en permanence: Les objectifs stratégiques et les priorités commerciales changent souvent, entraînant des changements dans le paysage de l'équipe produit. Désignez un membre de votre organisation pour revoir régulièrement la composition de l'équipe produit afin d'évaluer la nécessité de développer de nouveaux produits, de modifier des produits existants ou de supprimer des produits qui ne correspondent plus aux objectifs stratégiques.

Définissez les rôles / responsabilités de chaque équipe produit [19659012] L'une des clés de l'informatique basée sur les produits consiste à créer des équipes interfonctionnelles qui possèdent les compétences commerciales et techniques nécessaires pour accomplir la plupart des tâches au sein de leurs équipes. Le rôle le plus important dans votre équipe produit sera le Product Owner (ou Product Manager). Qualifiés de licornes par certains, ces individus possèdent le mélange unique de compétences en affaires (stratégie, analyse concurrentielle), techniques (vision architecturale, gestion de projet technique) et en leadership (prise de décision, gestion des parties prenantes) et sont responsables de la conduite de la vision du produit.

Pour remplir ce rôle, de nombreuses organisations procéderont à une évaluation des compétences avec leurs organisations pour déterminer les compétences nécessaires pour réussir, rassembler un inventaire des compétences disponibles et élaborer un programme de formation pour combler les lacunes. Lorsque vous structurez le reste de l'équipe produit, réfléchissez à la façon dont les compétences des autres membres de l'équipe peuvent compléter l'ensemble de compétences du propriétaire du produit afin de créer un solide mélange de compétences commerciales, techniques et de leadership dans l'équipe. Au-delà du Product Owner, vous pouvez avoir un Business Analyst qui sert de Junior Product Owner et prend en charge les données détaillées et l'analyse des processus. Un Scrum Master dirigerait les cérémonies agiles, un responsable technique créerait une architecture de solution et orchestrerait les activités techniques, et une équipe d'ingénierie / d'assurance qualité assurerait la livraison d'un produit de haute qualité.

Définissez les services partagés pour créer de l'échelle

sur les services informatiques qui sont agnostiques BU, nécessaires à toutes les équipes de produits et en demande uniquement à temps partiel par le groupe de produits. Ce sont vos services partagés. Les services partagés se répartissent horizontalement entre les groupes de produits et les équipes. Tout comme les produits, ces groupes spécialisés s'efforcent de mûrir et de développer de nouvelles capacités et d'autonomiser leurs clients (dans ce cas, les équipes de produits elles-mêmes).

Les groupes de services partagés typiques incluent l'architecture d'entreprise, l'infrastructure et le cloud, la sécurité, DevOps, le client / utilisateur Expérience, données et analyses, intégration, gestion de programme / fournisseur et opérations / support informatique. Le Bureau du DPI est un service partagé de plus en plus répandu qui est chargé de définir la stratégie informatique de l'entreprise, de définir des paramètres et de mesurer le succès. Chaque service partagé doit publier un catalogue de services détaillant ses offres et ses processus d'engagement avec un parti pris pour le libre-service (si possible). Les ressources de services partagés peuvent être «prêtées» aux équipes de produits en cas de demande pendant une période prolongée.