3 façons d’éviter le trafic sur la route de l’informatique basée sur les produits

Dans l’éternel besoin de rapidité, les leaders du numérique poursuivent leur passer de l’orientation projet à l’orientation produit. Cependant, ce changement n’est pas une initiative « préparez-le et oubliez-le ». Cela nécessite une évolution soutenue et continue qui conduit souvent les DSI à se demander : est-ce que notre équipe fait cela parce que c’est à la mode, ou sommes-nous là pour apporter des changements significatifs ?
Définir et déployer un modèle opérationnel de produit n’est que le début d’un long chemin semé de détours et de détours. Et votre capacité à conduire des changements significatifs dépendra en fin de compte de votre capacité à naviguer dans trois réalités une fois la table mise.
Réalité 1 : Vous n’avez pas (beaucoup) de propriétaires de produits dans l’informatique
Les propriétaires de produits qui réussissent ont une combinaison unique de sens des affaires, de savoir-faire technique et de compétences en leadership. Une absence de maturité dans l’un de ces traits peut engendrer une crise existentielle pour l’informatique basée sur les produits. Dans nos conversations avec les DSI, l’une des choses les plus courantes que nous entendons est qu’il n’y a pas assez de Product Owners qualifiés.
De nombreuses organisations ont lancé des bootcamps de gestion de produits ou des «académies numériques» pour inverser la tendance et doter leurs équipes des outils dont elles ont besoin pour réussir en tant que propriétaires de produits. Amir Arooni, vice-président exécutif et directeur informatique de Discover Financial Services, à 13 milliards de dollars, a lancé une académie technologique pour donner à ses ingénieurs un ensemble de compétences plus diversifié et pour freiner l’idée que « les développeurs sont comme des travailleurs sur une chaîne de production qui produisent du code plutôt que des problèmes créatifs ». des solveurs qui peuvent aider à innover. Ce programme de formation couplé à une orientation produit en informatique porte ses fruits : un pilote mobile récent a abouti dans une augmentation de la productivité de près d’un tiers sans augmentation des effectifs.
D’autres organisations peuvent choisir de recruter des propriétaires de produits directement auprès des unités commerciales et des fonctions, en les combinant avec leurs homologues informatiques dans une unité cohérente qui brise le mur perçu entre l’entreprise et l’informatique.
Que vous poursuiviez un bootcamp de gestion de produits, que vous recherchiez des propriétaires de produits auprès d’unités commerciales ou que vous poursuiviez quelque chose de complètement différent, soyez prêt à investir dans la formation pour vous assurer que les nouvelles équipes de produits ont les compétences nécessaires pour réussir.
Réalité 2 : Les unités commerciales et les fonctions doivent avoir leurs empreintes digitales sur le modèle
Faire évoluer votre modèle d’exploitation informatique dans le vide, sans intégrer les unités commerciales et les fonctions dans le giron, peut créer de petites victoires, mais cela finira par ne pas atteindre les résultats transformateurs que vous recherchez. Pour des retours hors normes dans la mise en œuvre, engagez les BU et les fonctions en amont et permettez-leur de poser leur empreinte sur les composants suivants du modèle opérationnel :
- Vision. Expliquer ce que signifie travailler dans un modèle d’exploitation basé sur les produits et comment cela aidera à résoudre les problèmes commerciaux connus. Le Chief Digital Officer d’un client de la santé a lancé le changement de son organisation en distribuant une note, co-écrite par un président de BU, pour expliquer la vision en langage commercial et décrire comment le nouveau modèle opérationnel accélérerait le travail d’intégration des personnes, des processus , et les aspects technologiques d’une fusion récente.
- Taxonomie des produits. Présentez une ébauche des équipes de produits qui, selon vous, seront nécessaires pour prendre en charge les capacités actuelles et émergentes tout au long de la chaîne de valeur, puis amenez rapidement le leadership BU et fonctionnel dans la conversation pour obtenir des commentaires. Assurez-vous de respecter les nuances des produits et des processus afin de ne pas aliéner vos homologues BU et fonctionnels. Par exemple, obtenez les commentaires de la BU avant de supposer que le processus lead-to-cash pour plusieurs unités commerciales peut être pris en charge par une seule équipe produit. Partagez la justification de votre taxonomie de produits avec vos homologues et négociez un ensemble initial de produits qui trouve le bon équilibre entre l’autonomie et l’échelle de la BU. Revoyez régulièrement la taxonomie pour identifier les opportunités de combiner ou de scinder les équipes de produits existantes, ou de créer de nouvelles équipes de produits pour soutenir l’évolution du modèle commercial.
- De nouvelles façons de travailler. Les évolutions vers une informatique basée sur les produits sont souvent étroitement associées à des efforts de transformation agile qui introduisent de nombreux nouveaux rôles, responsabilités et processus. Si vous souhaitez déployer un nouveau processus d’admission, ou si vous souhaitez que la BU participe à la planification trimestrielle et à la priorisation du backlog, laissez-les vous aider à concevoir le processus. Cela leur donne la peau dans le jeu et évite la perception que la queue remue le chien. En même temps, sachez que les choses pourraient ne pas fonctionner parfaitement tout de suite. Une tendance des directeurs fonctionnels à contacter directement les ingénieurs logiciels au lieu de passer par le propriétaire du produit, par exemple, peut créer de graves gestion de la capacité enjeux pour une entreprise qui prend le virage. Il est important de relever ces défis rapidement et directement pour s’assurer que toutes les parties prenantes évoluent dans la même direction.
Réalité 3 : Un changement de modèle opérationnel nécessite que la finance évolue avec vous
Si l’objectif du passage à l’informatique basée sur les produits est de disposer d’équipes de produits autonomes et responsabilisées qui recherchent les opportunités les plus intéressantes, vous ne pouvez pas laisser les finances vous ralentir avec des processus d’approbation automatique. Les leaders numériques doivent établir un partenariat étroit avec la finance pour démontrer les avantages d’un financement basé sur les produits modèle pour eux et pour l’organisation dans son ensemble.
Lors d’une récente conversation avec Maya Leibman, vice-présidente exécutive et directrice des systèmes d’information d’American Airlines, elle a noté que les modèles de financement traditionnels basés sur des projets « ont été conçus pour vous faire abandonner. Il y avait tellement de montagnes à gravir que c’était presque devenu un jeu d’endurance. Elle a poursuivi en disant qu’avant d’adopter le financement des produits, de nombreuses équipes utilisaient des dollars de maintenance pour des projets uniquement pour éviter le processus d’approbation.
Le nouveau modèle de financement basé sur les produits d’American Airlines fournit un flux de financement constant et réduit les approbations inutiles. L’équipe de produit d’expérience d’embarquement, par exemple, additionne les coûts de technologie et de processus qui entrent dans le maintien et l’amélioration de l’expérience d’embarquement chaque année, puis reçoit ces fonds à dépenser à sa discrétion pour faire mûrir l’expérience. Non seulement cela a amélioré la vitesse et le débit, mais cela a également fourni au financement une plus grande visibilité sur les coûts et de nouvelles façons de hiérarchiser les investissements. Ross Clanton, directeur général de la transformation technologique d’American Airlines, a souligné une percée qui s’est produite dans le département des finances à la suite du nouveau modèle de financement : « Ils pouvaient voir dans la » boîte noire « des coûts d’exploitation maintenant, pas seulement les coûts de croissance. nous avons soumis dans le modèle basé sur des projets.
Le passage à un modèle opérationnel de produit est un changement culturel et opérationnel majeur. Lorsqu’elle est bien mise en œuvre et améliorée en permanence, elle peut se traduire par une mise sur le marché plus rapide, plus d’innovation et de meilleures expériences client. Mais la route n’est pas facile et les DSI doivent être prêts à mettre la main à la pâte. Tenir compte des réalités ci-dessus dans vos plans peut vous aider à contourner de nombreux embouteillages sur la route de l’utopie du produit.
Source link