« Une carte simple pour l'innovation à l'échelle » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (8 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: Steve Blank]] | [[Category: Steve Blank]] | ||
[[Category: Portail Startup]] | [[Category: Portail Startup]] | ||
[[Category: Découverte Produit]] | |||
Auteur : Steve Blank<br /> | Auteur : Steve Blank<br /> | ||
Source : [https://steveblank.com/2022/10/25/a-simple-map-for-innovation-at-scale/ A Simple Map for Innovation at Scale]<br/> | Source : [https://steveblank.com/2022/10/25/a-simple-map-for-innovation-at-scale/ A Simple Map for Innovation at Scale]<br/> | ||
| Ligne 10 : | Ligne 11 : | ||
Traduction :<br /> | Traduction :<br /> | ||
<br /> | <br /> | ||
[[Fichier:Hokusai-tidal-wave-small.jpg|border|right|300px|link=]]La semaine dernière, j'ai passé la semaine dans une entreprise internationale du classement Fortune 50 à les observer aux prises avec | [[Fichier:Hokusai-tidal-wave-small.jpg|border|right|300px|link=]]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é.<br /> | ||
<br /> | <br /> | ||
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 ?<br /> | 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 ?<br /> | ||
| Ligne 34 : | Ligne 35 : | ||
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.<br/> | 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.<br/> | ||
<br/> | <br/> | ||
Ces contraintes strictes sur les exigences réduisent la capacité des équipes | 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. | * 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 | * 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. | * 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 | 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.<br/> | ||
<br/> | <br/> | ||
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.<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
'''''Donner aux domaines thématiques un cadre commun'''''<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
[[Fichier:Validating-problems-FR.jpg|link=|border|center]]<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
Si une solution est trouvée et résout le problème, l'équipe se dirige vers la case en haut à gauche.<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
'''''Destruction créatrice'''''<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
Regarder et écouter des centaines de personnes lutter contre le tsunami dans une entreprise mythique a été une leçon d'humilité.<br/> | |||
<br/> | |||
J'espère qu'ils y arriveront.<br/> | |||
<br/> | |||
'''''Les leçons apprises'''''<br/> | |||
* 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. | |||
