Une carte simple pour l'innovation à l'échelle

De Wiki Agile
Aller à : navigation, rechercher

Auteur : Steve Blank
Source : A Simple Map for Innovation at Scale
Date : 25/10/2022


Traducteur : Fabrice Aimetti
Date : 30/10/2022


Traduction :

Hokusai-tidal-wave-small.jpg
La semaine dernière, j'ai passé la semaine dans une entreprise internationale du classement Fortune 50 à les observer aux prises avec la disruption. Cette entreprise centenaire compte sept grandes divisions de produits, chacune avec des centaines de produits. Actuellement leader du marché, elle voit surgir de nulle part un nouveau concurrent implacable, doté de plus d'argent, de plus de personnel et d'une technologie plus avancée, qui tente de s'emparer des clients et de gagner des parts de marché.


Cette entreprise était tellement déterminée à faire face à cette menace (elle l'a décrite comme "existentielle pour sa survie") qu'elle a mobilisé toute l'entreprise pour trouver de nouvelles solutions. Ce n'était pas une mince affaire, car les menaces provenaient de plusieurs domaines et de plusieurs directions : comment adopter les nouvelles technologies ? comment convertir les usines de fabrication existantes (et leur personnel) à un ensemble de technologies entièrement nouvelles ? comment mettre en place de nouvelles chaînes d'approvisionnement ? comment devenir visible sur les nouveaux médias sociaux et canaux de communication ? comment se connecter à une nouvelle génération de clients qui n'avaient aucune fidélité à la marque ? comment utiliser les nouveaux canaux de distribution que les concurrents ont adoptés ? comment font-ils ces transitions sans se séparer de leurs clients, canaux de distribution et partenaires existants ? et comment motiver leur plus grand atout - leur personnel - pour qu'il opère avec rapidité, urgence et passion ?

L'entreprise pensait avoir une dizaine d'années pour résoudre ces problèmes avant que son déclin ne devienne irréversible. Cette réunion était un rassemblement semestriel de tous les dirigeants impliqués dans les initiatives de l'entreprise visant à distancer les nouveaux perturbateurs. Ils l'ont appelée "Initiative Tsunami" pour souligner qu'ils luttaient contre le raz-de-marée de destruction créative qui engloutissait leur industrie.

Pour réussir, ils ont compris qu'il ne s'agissait pas simplement de proposer un nouveau produit. Il s'agissait de faire pivoter une entreprise entière - et sa culture. La gamme de solutions à apporter dépasse de loin tout ce que pourrait faire une seule startup.

L'entreprise avait engagé un cabinet de conseil en management réputé qui l'a aidée à sélectionner 15 domaines de changement essentiels sur lesquels l'Initiative Tsunami devait travailler. Mes hôtes, John et Avika, étaient les co-directeurs chargés de superviser ces 15 domaines. Le cabinet de conseil a suggéré d'organiser ces 15 domaines sous la forme d'une organisation matricielle, et la salle de bal était remplie de plusieurs centaines de personnes de toute l'entreprise - des groupes d'action et des sous-groupes composés de personnes de toute l'entreprise : ingénierie, fabrication, analyse et collecte de données sur le marché, canaux de distribution et ventes. Certaines des équipes comprenaient même certains de leurs proches partenaires. Plus d'un millier d'autres personnes travaillaient sur les projets dans des bureaux dispersés dans le monde entier.

John et Avika m'avaient invité à examiner leur processus d'innovation et à formuler quelques suggestions.

Est-ce que ce sont les vrais problèmes ?

C'était l'une des initiatives d'innovation les mieux organisées que j'ai vues. Les 15 sujets avaient tous des leaders d'équipe qui ont présenté des posters, il y avait des présentateurs des ventes sur le terrain et des partenaires qui ont souligné l'urgence et la spécificité des problèmes, et il y avait des sessions en petits groupes où les équipes thématiques ont fait du brainstorming entre elles. Après la fin de la journée, les gens se sont réunis autour du bar pour des conversations informelles. Le fait que même les personnes en congé débattent avec passion de la manière de résoudre ces problèmes témoigne du leadership de John et d'Avika. C'était une démonstration étonnante de l'esprit de corps organisationnel.

Bien que le sujet de chacun des 15 thèmes ait été suggéré par la société de conseil, il a été proposé conjointement avec le groupe de stratégie d'entreprise de la société, et les personnes qui ont déterminé les exigences relatives à ces thèmes ont participé à l'atelier. Non seulement les personnes responsables des exigences étaient présentes, mais une équipe de transition était également présente pour faciliter la livraison des produits de ces équipes thématiques à la production et aux ventes.

Cependant, j'ai remarqué que plusieurs des exigences de la stratégie d'entreprise semblaient être des priorités qui leur avaient été données par d'autres (par exemple, voici les problèmes sur lesquels le directeur financier, le PDG ou le conseil d'administration pense que nous devrions travailler) ou probablement voici les sujets sur lesquels le cabinet de conseil pensait qu'ils devraient se concentrer) et/ou provenaient d'experts en la matière (par exemple, je suis l'expert dans ce domaine. Pas besoin de parler à quelqu'un d'autre ; voici ce dont nous avons besoin). Il semble que le groupe de stratégie d'entreprise ait présenté les problèmes sous la forme d'exigences fixes, par exemple, en présentant les caractéristiques et les fonctionnalités spécifiques que la solution devrait fournir.

Il s'agissait d'un effort majeur impliquant de nombreuses personnes, mais qui n'a pas permis de s'attaquer à la racine des problèmes.

J'ai dit à John et Avika que je comprenais que certaines exigences soient connues et immuables. Cependant, lorsque toutes les exigences sont remises aux équipes d'action de cette manière, on part du principe que les problèmes ont été validés et que les équipes n'ont pas besoin d'explorer davantage l'espace des problèmes par elles-mêmes.

Ces contraintes strictes sur les exigences réduisent la capacité des équipes thématiques à :

  • Comprendre en profondeur les problèmes - qui sont les clients, les parties prenantes internes (ventes, autres départements) et les bénéficiaires (actionnaires, etc.) ? Comment les répartir, priorité de la solution, calendrier des solutions, ensemble minimal de fonctionnalités, dépendances, etc.
  • Déterminer si le problème est un symptôme de quelque chose de plus important
  • Comprendre si le problème peut être résolu immédiatement, s'il nécessite plusieurs produits minimum viables pour tester plusieurs solutions ou s'il nécessite plus de R&D.

J'ai remarqué qu'avec toutes les exigences fixées à l'avance, au lieu d'avoir la liberté d'innover, les équipes thématiques étaient devenues des extensions des groupes de développement de produits existants. Elles étaient piégées dans les mentalités existantes et produisaient probablement beaucoup moins que ce dont elles étaient capables. Il s'agit d'une erreur courante que les équipes d'innovation des entreprises ont tendance à commettre.

Je leur ai rappelé que lorsque les membres de l'équipe sortent de leurs bâtiments et de leurs zones de confort, et qu'ils parlent directement aux clients, aux parties prenantes et aux bénéficiaires, qu'ils les observent et qu'ils interagissent avec eux, cela leur permet d'être agiles, et les solutions qu'ils fournissent seront pertinentes, en temps voulu, et leur développement prendra moins de temps et de ressources. C'est la différence entre admirer un problème et en résoudre un.

En parlant de cela, j'ai réalisé que le fait d'avoir toutes les exigences prescrites est un symptôme de quelque chose de plus intéressant - la façon dont les responsables du sujet et les membres de l'équipe étaient organisés. De mon point de vue, il semble qu'il y ait eu un manque de cadre et de processus communs.

Donner aux domaines thématiques un cadre commun

J'ai demandé à John et Avika s'ils avaient envisagé de proposer aux leaders des équipes thématiques et à leurs membres un cadre conceptuel simple ( une seule image) et un langage commun. J'ai suggéré que cela permettrait aux équipes de savoir quand et comment "idéer" et intégrer des idées novatrices qui accélèrent l'obtention de meilleurs résultats. Le cadre utiliserait les exigences initiales de la stratégie d'entreprise comme point de départ plutôt que comme destination fixée. Voir le schéma.

Je leur ai dessiné un schéma simple et leur ai expliqué que la plupart des problèmes partent de la case en bas à droite.

Validating-problems-FR.jpg


Ce sont des problèmes "non validés". Les équipes utilisent un processus de découverte du client pour les valider. (Une fois les problèmes validés, les équipes passent à la case en bas à gauche et explorent de multiples solutions. Les deux cases du bas sont celles où l'idéation et l'innovation de type brainstorming sur les problèmes/solutions sont cruciales. Il est parfois possible d'accélérer ce processus en faisant appel à l'horizon 3, aux personnes qui sortent des sentiers battus (out-of-the-box thinkers), que toute entreprise a, et de les laisser porter leur regard critique sur le problème ou la solution.

Si une solution est trouvée et résout le problème, l'équipe se dirige vers la case en haut à gauche.

Mais j'ai expliqué que très souvent la solution est inconnue. Dans ce cas, pensez à demander aux équipes de faire une " visite technique sur le terrain". Il s'agit de faire décrire le problème par de multiples sources (fournisseurs, développeurs internes, autres programmes internes) et de faire un débriefing sur la totalité de ce qui a été trouvé. Une visite sur le terrain permet souvent de découvrir que le problème est en fait le symptôme d'un autre problème ou que ces sources le voient comme une version différente du problème. Ou qu'une solution existante existe déjà ou peut être modifiée pour s'adapter.

Mais souvent, il n'existe aucune solution connue. Dans ce cas, les équipes peuvent se diriger vers la case en haut à droite et construire des produits minimum viables - le plus petit ensemble de fonctionnalités à tester avec les clients et les partenaires. Ces tests MVP permettent souvent de tirer de nouveaux enseignements de la part des clients, des bénéficiaires et des parties prenantes - par exemple, ils peuvent dire au développeur du thème que les premiers 20 % du produit livrable sont "suffisants", ou que le problème a changé, ou que le calendrier a changé, ou qu'il doit être compatible avec autre chose, etc. Enfin, lorsqu'une solution est souhaitée par les clients/bénéficiaires/parties prenantes et qu'elle est techniquement réalisable, les équipes passent à la case en haut à gauche.

Le résultat est que les équipes itèrent rapidement pour fournir les solutions souhaitées et nécessaires aux clients dans le temps limité qui reste à l'entreprise.

Destruction créatrice

Les entreprises qui réussissent le font grâce à un effort global associant un leadership inspiré et visionnaire, des personnes motivées, des produits innovants et une mise en œuvre et une passion sans relâche.

Regarder et écouter des centaines de personnes lutter contre le tsunami dans une entreprise mythique a été une leçon d'humilité.

J'espère qu'ils y arriveront.

Les leçons apprises

  • La destruction créatrice et la disruption vont toucher toutes les entreprises. Comment allez-vous réagir ?
  • Les équipes thématiques doivent comprendre en profondeur les problèmes tels que le client les comprend, et pas seulement ce que les exigences de la stratégie de l'entreprise imposent.
    • Cela ne peut être fait sans parler directement aux clients, aux parties prenantes internes et aux partenaires.
  • Il faut se demander si l'équipe de stratégie d'entreprise ne devrait pas être davantage composée de facilitateurs plutôt que de gardiens.
  • Une manière légère de garder les équipes thématiques en phase avec la stratégie de l'entreprise est d'offrir un langage d'innovation commun et un framework de problèmes et de solutions.