Comptabilité de l'innovation appliquée à SAFe

De Wiki Agile
Aller à : navigation, rechercher

Auteur : Joe Vallone, Principal Consultant, SPCT/SAFe Fellow © 2010-2022 Scaled Agile, Inc.
Source : Applied Innovation Accounting in SAFe
Date : 11/10/2021 (dernière mise à jour)


Traducteur : Fabrice Aimetti
Date : 13/11/2022


Traduction :

5.1 Extended-Guidance-1.jpg
Pour améliorer les résultats des entreprises et responsabiliser les innovateurs, nous devons nous concentrer sur les aspects les plus ennuyeux : comment mesurer les progrès, comment établir des jalons et comment prioriser le travail. Cela nécessite un nouveau type de comptabilité conçue pour les startups - et les personnes qui les tiennent pour comptables.


- Eric Ries, The Lean Startup [1]

Introduction

Note : cet article fait partie de l'Extended SAFe Guidance, et représente le contenu officiel de SAFe qui n'est pas accessible directement depuis la Big Picture.

Le développement de solutions innovantes dans le monde entier est un processus intrinsèquement risqué et incertain. Mais ce niveau d'incertitude incite certaines entreprises à éviter de prendre les bons risques, et lorsqu'elles le font, cela augmente la probabilité qu'elles passent trop de temps et d'argent à construire la mauvaise chose, en se basant sur des données erronées ou des hypothèses non valables. Comme l'a observé Eric Ries, "Et si nous nous retrouvions à construire quelque chose dont personne ne veut ? Dans ce cas, qu'importe que nous l'ayons fait à temps et dans le respect du budget ?"[2]

Malheureusement, les mesures financières et comptables traditionnelles n'ont pas évolué pour répondre à la nécessité de soutenir les investissements dans l'innovation et l'agilité métier. Par conséquent, les entreprises utilisent souvent des indicateurs financiers retardés tels que les profits et pertes (P&L) et le retour sur investissement (ROI) pour mesurer la progression de leurs investissements technologiques. Bien qu'il s'agisse de mesures opérationnelles intéressantes pour regarder dans le rétroviseur, ces résultats interviennent bien trop tard dans le cycle de vie de la solution pour guider le développement réel de la solution. Même la valeur actuelle nette (NPV) et le taux de rendement interne (IRR), bien que plus prospectifs, reposent sur l'estimation de futurs rendements financiers inconnus et sur des hypothèses spéculatives quant aux coûts d'investissement et aux taux d'actualisation. De plus, même lorsqu'ils sont utilisés en conjonction avec une analyse de sensibilité (c'est-à-dire des calculs de type "what if"), ces paramètres financiers ne reflètent ni ne renseignent l'apprentissage obtenu par le développement incrémental de produits. Par conséquent, ces mesures traditionnelles ne sont pas utiles dans notre démarche de livraison itérative et incrémentale et d'agilité métier.

Nous avons besoin d'un meilleur plan - un type différent de cadre de travail économique - qui valide rapidement les hypothèses du produit et augmente l'apprentissage. Dans SAFe, cela se traduit, en partie, par l'application du cycle Lean Startup (voir Figure 1), un cycle hautement itératif qui offre la possibilité d'évaluer rapidement les grandes initiatives et de mesurer la viabilité en utilisant un type différent de mesure financière : la comptabilité de l'innovation.

Innovation-Accounting-F01c-WP.png
Figure 1. Le cycle Lean Startup avec SAFe.

Qu'est-ce que la comptabilité de l'innovation ?

La comptabilité de l'innovation est un terme inventé par Eric Ries dans son ouvrage The Lean Startup. Le cadre de travail de la comptabilité de l'innovation se compose de trois étapes d'apprentissage :

  1. Produit Minimum Viable (MVP) - établir une base de référence pour tester les hypothèses et recueillir des données objectives.
  2. Régler le moteur - ajuster rapidement et se rapprocher de l'objectif, en fonction des données recueillies.
  3. Pivoter ou persévérer - Décider de fournir de la valeur ajoutée, ou de passer à quelque chose de plus intéressant, sur la base de l'apprentissage validé. (La pensée Lean définit la valeur comme un avantage pour le client ; tout le reste est du gaspillage)[2].

Pour valider l'apprentissage et réduire le gaspillage, une boucle de rétroaction rapide est essentielle, également appelée "construire-mesurer-apprendre", comme illustré à la figure 2. L'application de l'apprentissage obtenu à partir du feedback réel des clients permet d'accroître la prédictibilité, de réduire le gaspillage et d'améliorer la valeur pour les actionnaires.

Innovation-Accounting-F02c-WP.png
Figure 2. Boucle de rétroaction "Construire, Mesurer, Apprendre" du Lean Startup.

Indicateurs avancés versus Indicateurs de complaisance

La comptabilité de l'innovation nous invite à nous poser deux questions : 1) Progressons-nous vers notre hypothèse de résultat ? 2) Comment le savons-nous ? Dans The Lean Startup, cette question est connue sous le nom d'"hypothèse du pas de la foi" ; elle exige que nous comprenions et validions notre hypothèse de valeur et de croissance avant d'aller plus loin dans sa mise en œuvre. Cela devient une partie fondamentale du cadre économique qui conduit à un développement efficace de la solution.

Pour répondre à ces questions et prendre de meilleures décisions économiques, nous soutenons la comptabilité de l'innovation en utilisant des indicateurs avancés (leading indicators), des indicateurs actionnables axés sur la mesure des premiers résultats spécifiques à l'aide de données objectives. Les indicateurs avancés sont conçus pour récolter les résultats du développement et du déploiement d'un Produit Minimum Viable (MVP). Ces indicateurs peuvent inclure des mesures financières non standard telles que les utilisateurs actifs, les heures passées sur un site Web, le revenu par utilisateur, le net promoter score, etc.

Il est important de faire attention aux indicateurs de complaisance, qui sont des indicateurs qui ne mesurent pas vraiment le succès ou l'échec potentiel de la valeur réelle d'une initiative. Bien qu'ils soient faciles à collecter et à manipuler, ils ne donnent pas nécessairement un aperçu de la manière dont le client utilisera le produit ou le service. Des mesures telles que le nombre d'utilisateurs enregistrés, le nombre de pages vues brutes, le nombre de téléchargements peuvent fournir des informations utiles ou nous donner bonne conscience quant à nos efforts de développement, mais elles peuvent être insuffisantes pour fournir les preuves nécessaires pour décider si nous devons pivoter ou persévérer avec le MVP de l'initiative.

Il existe des façons concrètes d'éviter d'être trompé par les indicateurs de complaisance et de travailler plutôt à l'évaluation de notre hypothèse. Les tests A/B ou tests fractionnés (split-tests) nous permettent de valider notre hypothèse de résultat à l'aide de données exploitables. Par exemple, le groupe A peut recevoir la nouvelle fonctionnalité et le groupe B ne la reçoit pas. En établissant un groupe de contrôle, nous pouvons évaluer les résultats par rapport à notre hypothèse et prendre des décisions dans le cadre de notre boucle de rétroaction. Nous pouvons également éviter les indicateurs de complaisance en nous concentrant sur les données axées sur le client. Nous pouvons utiliser l'analyse des cohortes pour examiner l'utilisation d'un nouveau produit, d'un nouveau service, d'une nouvelle fonction, etc. au fil du temps en ce qui concerne une cohorte (groupe). Par exemple, supposons que nous voulions voir comment une nouvelle fonctionnalité de notre site Web améliore le taux de conversion en clients payants. Nous pourrions examiner les nouvelles inscriptions par semaine (c'est-à-dire la cohorte) et établir un rapport sur le pourcentage de conversion en clients payants. Nous pouvons analyser ces informations sur une base hebdomadaire et voir si le taux de conversion reste constant pour chaque cohorte (le groupe d'utilisateurs inscrits). Si c'est le cas, nous avons une indication claire de la façon dont la fonctionnalité affecte le taux de conversion. S'il ne reste pas constant, nous avons alors la possibilité d'ajuster le moteur ou de pivoter.

Application de la comptabilité de l'innovation à SAFe

Mesurer les Epics

La mise en œuvre de grandes initiatives tournées vers l'avenir est une opportunité pour les organisations de réduire le gaspillage et d'améliorer les résultats économiques. Dans SAFe, les grandes initiatives sont représentées comme des Epics et sont capturées à l'aide d'une déclaration d'hypothèse épique. Cet outil définit l'initiative, ses résultats attendus en termes de bénéfices, et les indicateurs avancés utilisés pour valider la progression vers son hypothèse.

Exemple d'Epic d'un site Web d'une compagnie aérienne

Prenons l'exemple d'une compagnie aérienne qui souhaite développer un site Web pour l'achat de billets. Il s'agit d'un projet important qui nécessitera beaucoup de temps et d'argent. Avant d'essayer de concevoir et de réaliser l'ensemble de l'initiative, le modèle d'énoncé d'hypothèse de l'Epic doit être utilisé pour développer une hypothèse, tester les hypothèses et acquérir des connaissances sur le résultat attendu (voir Figure 3).

Innovation-Accounting-F03c-WP.png
Figure 3. Énoncé de l'hypothèse d'Epic.

On peut supposer que le site Web contribuera à réduire le volume du centre d'appels et, en fin de compte, à réduire les coûts de la compagnie aérienne, ce qui se traduira par de meilleures marges bénéficiaires par billet vendu. Ainsi, l'une des hypothèses que nous faisons est que le site Web sera plus rapide et plus facile qu'un appel téléphonique au service clientèle.

Pour tester cette hypothèse, nous pourrions livrer une feature incrémentale ou un ensemble de features, c'est-à-dire un MVP qui permet aux clients de rechercher des horaires de vol. Pour valider et mesurer l'efficacité de la ou des feature(s), nous pourrions analyser le volume d'appels ainsi que les types de questions reçues par le service d'assistance. Ensuite, nous pourrions rapidement comparer les tendances des demandes de renseignements sur le site Web par rapport à celles du centre d'appels. De plus, en utilisant les bonnes pratiques DevOps, nous pourrions intégrer la télémétrie dans la feature et analyser l'interaction avec les clients. Les informations présentées à la figure 4 montrent que l'activité du centre d'appels a diminué et que l'utilisation du site Web a augmenté. Ces indicateurs avancés montrent que le MVP semble valider notre hypothèse.

Innovation-Accounting-F04c-WP.png
Figure 4. Télémétrie du centre d'appels.

Les indicateurs avancés peuvent fournir un feedback immédiat sur les tendances observées en matière d'utilisation. En analysant les données objectives, nous pouvons vérifier notre hypothèse et décider de continuer à livrer des features supplémentaires, de régler le moteur ou de pivoter vers autre chose. Ainsi, le MVP de l'Epic et les indicateurs avancés nous permettent de prendre plus rapidement des décisions économiques fondées sur des faits et des découvertes. Il est intéressant de noter que dans la figure 4, la mesure des visites du site peut être considérée comme un indicateur de complaisance. En soi, cette mesure ne nous renseigne pas beaucoup sur le succès de notre MVP ou la viabilité de l'Epic. Cependant, placée dans le contexte des autres mesures, elle nous donne une indication de ce sur quoi les clients passent leur temps lorsqu'ils visitent le site Web.

Exemple d'Epic de véhicule autonome

Grâce à leur lien direct avec un grand nombre d'utilisateurs et leurs interactions, ainsi qu'à leur capacité à faire évoluer rapidement l'interface utilisateur, les sites Web constituent un endroit idéal pour réfléchir à la manière d'appliquer la comptabilité de l'innovation. Cependant, la comptabilité de l'innovation a une applicabilité bien plus large que cela. Prenons un autre exemple, un Epic qui décrit le système de capteurs d'un nouveau véhicule autonome.

Notre hypothèse d'Epic (voir figure 5) est que le système de capteurs va rapidement détecter et nous aider à éviter les collisions avec des objets. Notre hypothèse est que l'information sera fournie assez rapidement pour que le véhicule s'arrête ou prenne des mesures d'évitement (car c'est là tout l'intérêt !).

Innovation-Accounting-F05c-WP.png
Figure 5. Exemple d'Epic pour un véhicule autonome.

Pour vérifier l'hypothèse, nous aimerions savoir si le système de capteurs peut détecter des objets et s'il est effectivement assez rapide pour nos besoins avant de construire le système complet. Nous pourrions construire un seul capteur et un logiciel de capture de données de base pour valider la distance entre l'objet et la vitesse de l'interface du système de contrôle du véhicule. En tant que MVP, supposons que nous installions le capteur à l'avant d'une voiture et que nous le connections à un ordinateur portable à l'intérieur du véhicule. Ensuite, nous plaçons plusieurs objets sur une piste d'essai et conduisons le véhicule vers eux. Nous pourrions utiliser le logiciel pour enregistrer les informations du capteur comme indicateur principal. Nous pourrions également utiliser le logiciel pour mesurer le temps qu'il faut pour que le message soit généré et envoyé à l'interface du système de contrôle du véhicule en utilisant un cadre de simulation au lieu d'attendre que le système de contrôle du véhicule soit construit. Cela nous donnerait une idée assez tôt de la conformité à notre NFR. La figure 6 décrit les indicateurs avancés pour ce système cyber-physique.

Innovation-Accounting-F06c-WP.png
Figure 6. Indicateurs avancés pour les capteurs de véhicules autonomes.

Sur la base des données générées au cours des tests MVP, nous devons répondre à d'autres questions avant de proposer des features supplémentaires pour l'Epic. Peut-être pouvons-nous régler le moteur et voir si nous pouvons diminuer le temps d'envoi des messages. Pourquoi le capteur n'a-t-il pas détecté le panneau routier ? Le fait d'aller plus lentement aurait-il été utile pour les premiers tests ? Que se passe-t-il si nous plaçons le capteur sur le toit de la voiture ? En fonction de la réponse à ces questions et à d'autres, nous devrons peut-être opter pour une autre technologie.

"Échouer rapidement" est une valeur Agile. Cela implique que l'échec dans de petits lots est acceptable, tant que nous en tirons des leçons. Ainsi, l'apprentissage validé devient l'objectif principal du test de l'hypothèse. Comme mentionné précédemment, SAFe utilise le cycle Lean Startup pour évaluer de manière itérative le MVP des Epics et pour pivoter (changer de direction, pas de stratégie), ou persévérer (continuer à avancer) dans la décision par rapport à l'hypothèse de résultats. Cela se fait de manière incrémentale en développant et en évaluant les features de l'Epic. La mesure empirique que nous utilisons pour prioriser les features est le Weighted Shortest Job First (WSJF). En utilisant le WSJF, nous pouvons rapidement évaluer la valeur économique de la feature et la progression globale de l'Epic vers son résultat métier. Cela nous permet de prendre rapidement et de manière itérative une décision de type "pivoter ou persévérer" sur la base de données objectives.

La décision de persévérer indique qu'il existe encore des bénéfices économiques potentiels. Les indicateurs avancés valident notre hypothèse et notre MVP, ce qui entraîne le développement et la livraison de features supplémentaires. La décision de pivoter peut survenir lorsque la valeur livrée est suffisante ou lorsque nous apprenons que notre hypothèse était incorrecte. Décider de pivoter est si difficile que de nombreuses entreprises n'y parviennent pas[2]. Souvent, les entreprises continueront à investir dans une initiative malgré (ou en l'absence) de données prouvant le contraire. Nous avons la possibilité de réduire le gaspillage d'argent et de temps, en utilisant des boucles de rétroaction rapides et des indicateurs avancés pour éviter de travailler sur des features que les clients ne veulent pas ou dont ils n'ont pas besoin.

Il est important de noter que la comptabilité de l'innovation, telle qu'elle est appliquée à SAFe, ne tient pas compte des coûts irrécupérables (c'est-à-dire l'argent déjà investi). Pour pivoter sans pitié ni culpabilité, nous devons ignorer les coûts irrécupérables, comme indiqué dans le Principe SAFe n°1 - Adopter une vision économique. Bien que la budgétisation Lean et Agile puisse allouer des fonds à un flux de valeur dès le départ, nous utilisons le cycle Lean Startup pour évaluer continuellement l'hypothèse de bénéfice en fonction de la valeur fournie plutôt qu'en fonction de l'argent ou du temps dépensé. Par conséquent, l'allocation initiale de fonds n'équivaut pas à la dépense réelle des fonds ; c'est pourquoi la décision de pivoter ou de persévérer est une décision financière d'une importance capitale.

Résumé

La variabilité et le risque font partie de toute grande initiative technologique. Cependant, les indicateurs financiers traditionnels utilisés pour mesurer la valeur de ces initiatives pendant leur développement n'ont pas évolué pour répondre au besoin d'innovation et d'agilité des entreprises. La comptabilité de l'innovation a été développée dans le cadre du cycle Lean Startup pour fournir un apprentissage validé et réduire le gaspillage. Le développement et la mesure d'un Produit Minimum Viable sont utilisés pour valider l'hypothèse, obtenir des résultats et réduire le risque avant d'engager l'investissement dans le système entier. Cette boucle de rétroaction rapide, fondée sur des données objectives et des mesures exploitables, permet un apprentissage progressif. En se concentrant sur les bons indicateurs avancés, on s'assure de prendre la décision vitale de pivoter ou de persévérer. L'utilisation par SAFe de la comptabilité de l'innovation et du cycle Lean Startup permet à l'entreprise de réduire le gaspillage et d'accélérer l'apprentissage tout en améliorant les résultats métiers.

En savoir plus

[1] http://knowledge.wharton.upenn.edu/article/eric-ries-on-the-lean-startup/
[2] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. The Crown Publishing Group, 2011.