:: – Article proposé par Patrick JAULENT – ::
Patrick est le co-auteur de l’ouvrage « Objectif performance »
Connaissez-vous la loi des rendements décroissants ?
Formaliser une stratégie c’est bien, l’exécuter c’est mieux. L’exécution d’une stratégie se réalise grâce aux initiatives stratégiques et opérationnelles. Par exemple, si l’organisme a pour objectif stratégique « d’améliorer de X% le revenu des clients sur le segment de marché Y », elle peut décider comme initiative stratégique d’ouvrir des agences pour couvrir le marché Y, ou encore, de mettre en place un outil CRM. Pour soutenir ces initiatives stratégiques, l’organisme peut aussi décider au niveau opérationnel, de créer un groupe de travail chargé de réfléchir sur l’augmentation des ventes.
Le décor étant planté, commençons !
Mais au fait, êtes-vous familier avec la loi des rendements décroissants ?
Pour faire simple, celle-ci déclare qu’à partir d’un certain point, faire plus d’efforts supplémentaires ne produira pas un gain significatif. Mais est-ce vraiment nécessaire de connaître ce fameux point ?
Dans le cadre de l’exécution de la stratégie, j’ai participé en tant que témoin à un groupe de travail chargé de réfléchir au(x) moyen(s) d’augmenter les ventes (cf. mon introduction). Lors d’une réunion de travail le responsable du groupe présenta la démarche à suivre. Ainsi, la première étape consisterait à collecter les données sur les ventes ainsi que les résultats d’enquêtes clients, et d’en faire une analyse rigoureuse (sachant qu’une analyse non rigoureuse ne sert à rien a t-il affirmé). Le responsable expliqua donc longuement que cette étape était un préalable incontournable pour identifier les actions à mener.
J’ai observé dans de nombreuses organisations cette approche qui consiste à faire une analyse approfondie avant de passer à l’action. C’est tellement ancré dans les gènes de ces organisations, que celles-ci formalisent ce type d’approche dans des procédures écrites en s’appuyant sur des principes bien connus : 1. collecter, 2. analyser, 3. décider, 4. agir, 5. contrôler, etc.
Pourquoi chercher la perfection improductive en voulant tout collecter, analyser, décider, faire des plans détaillés avant d’agir ?
J’y vois deux principales raisons :
- La première raison est la peur d’échouer. Alors il vaut mieux tout approfondir car si cela ne fonctionne pas, personne ne pourra reprocher au groupe de travail de ne pas avoir fait son devoir.
- La seconde raison est liée à l’inquiétude des actions à prendre, car elles risquent de perturber les zones de confort : la résistance au changement. Ainsi, une façon d’éviter ce risque est de faire durer les étapes (1,2 et 3) aussi longtemps que possible afin de retarder toute action.
Je me suis alors souvenu de ce que j’avais écrit il y a quelques années sur « l’ingénierie simultanée » où des activités peuvent être organisées en parallèle, à l’image de deux droites qui ne se rejoignent qu’à l’infini.
Ainsi, au lieu de considérer «l’action» comme quelque chose qui suit la collecte des données et leur analyse, pensez comment l’action peut se produire parallèlement à ces activités. (Il faudrait modifier le fameux cycle PDCA de Deming (Plan-Do-Check-Act). (Plan Do, Check, Act), le DMAIC des approches 6 sigma (définir, mesurer, analyser, améliorer, contrôler) afin de rendre ces approches moins séquentielles en effectuant des activités en parallèle. La méthode « lean start-up » inventée par M. Ries préconise la création de prototypes rapides destinés à tester les hypothèses de marché, et utilisant la rétroaction des clients.
En d’autres termes, plutôt que de venir, après plusieurs réunions de travail, avec des recommandations parfaites suite à l’analyse, je vous propose par tester rapidement certaines de vos idées initiales sur une petite échelle – tout en recueillant davantage de données. Vous pourrez ainsi nourrir l’analyse des données clients tout en continuant à mettre en œuvre vos nouvelles idées. Il est clair que les idées d’action qui émergent au début de cette approche itérative sont loin d’être parfaites, mais grâce aux essais sur une petite échelle vous pourrez les améliorer (notion de prototypage). Travailler ainsi réduit également le risque de recommander de mauvaises actions suite à l’évolution inévitable du comportement des clients. Avec une analyse trop poussée, votre temps de réaction est beaucoup trop long et vous dépasserez avez très certainement ce fameux point où le gain n’est plus significatif au regard de l’énergie dépensée. Naturellement toutes les analyses ne sont pas longues et couteuses, je vous propose juste d’éviter la « paralysie de l’analyse ».
En conclusion permettez-moi de citer Patton : « Un bon plan mis en œuvre aujourd’hui, vaut mieux qu’un plan parfait mis en œuvre demain »
Qu’en pensez-vous ?
:: – Article proposé par Patrick JAULENT – ::
Patrick est le co-auteur de l’ouvrage « Objectif performance »
Intéressant même si j’ai l’impression que cela ressemble un peu à de la cosmétique :
Je comprends le « Lean start-up » qui s’inspire des méthodes agiles appliquées aux développements informatiques est basé sur le principe de prototypage et d’itération.
Or pour moi, le prototype (ou pilote) fait partie intégrante de la démarche LSS, ainsi que la démarche itérative qui peut s’apparenter à de l’amélioration continue.
Finalement, il ne s’agit principalement d’une question de temps cycle pour aboutir à un résultat. Mais là aussi, je pense que des méthodes LSS type Kaizen blitz permettent de générer une dynamique pour une mise en oeuvre rapide.
Après je suis totalement en phase avec les raisons qui font que l’analyse dure éternellement et qu’il s’agit souvent d’un prétexte pour ne rien faire. Lorsque l’on démarre un projet, il y a ce momentum qu’il faut exploiter. Lancer rapidement un pilote est effectivement (à mon sens) une de mes meilleures solutions pour éviter les écueils de l’analyse qui traine, et permet en plus de convaincre certains récalcitrants (une fois que le pilote est un succès évidemment)
Pour ma part je pense qu’il faut coupler l’ensemble de ces approches :
> QuickWin
> Blitz Kaizen
> Amélioration itérative convergente
> DMAIC et donc analyse un peu plus approfondie mais ciblée
> …
Je partage cette idée et je redoute les projets IT où l’on prend bien soin de rédiger une bibliothèque entière de spécifications avant de démarrer les développements, afin de se prémunir « faussement » du risque de n’avoir pas pensé à tout!
On a cependant omis de préciser je pense que le LSS laissait une large place au GBS, préconisant ainsi de cibler autant que possible les données à collecter les plus pertinentes ou influentes (on prendra soin bien entendu ensuite de vérifier qu’elles sont bien représentatives de la réalité).
D’ailleurs, la plupart du temps, il est inconcevable de collecter l’exhaustivité des données.
Ensuite dans le LSS, il y a quelques gardes-fou, pour n’en citer qu’un :
un DMAIC « classique » est prévu pour durer environ 6 mois à partager entre les 5 phases en pondérant leurs durées respectives en fonction du type de projet.
Enfin, j’ajouterai que le LSS est une démarche outillée assortie surtout d’un certain état d’esprit. Donc, utiliser les outils sans le fameux état d’esprit, ce n’est pas faire du LSS.
Patton a tout a fait raison, à mon sens.
Etant convaincu qu’il existe une infinité de manière de visualiser une réalité, finalement, je me dis que l’intérêt de la mesure réside certes dans une tentative de trouver la ‘solution’, mais largement autant de bâtir un consensus de groupe, qui vise à ce que l’action aille dans le même sens : en effet, deux personnes allant à la même vitesse en sens opposé ne font pas vraiment avancer le schmilblick. Comme le but, c’est d’avancer, d’apprendre, mesurer, ça sert à avancer, bâtir un accord entre les participants (ex : mettre d’accord un mainteneur et un producteur sur le top 3 actions à prendre sur un équipement est tout un défi): et si mesurer, ça ne servait juste qu’à se lancer ? Donc, comme Patton, rien ne sert de mesurer trop longtemps. Chargez, Mesurez !!!!!