Nous l’évoquions la semaine dernière, le PDCA – ou roue de Deming – est une méthode développée depuis les années 50. Ne serait-elle pas un peu obsolète dans le cadre des développements actuels, notamment lorsque l’on s’organise autour d’une méthode Agile ?
Ou bien au contraire n’est-ce pas là l’outil idéal pour travailler en runs ?
Le PDCA classique
Commençons par faire un tour d’horizon du PDCA dit classique avant de l’évaluer la semaine prochaine face aux nouvelles exigences de l’Agile.
Il comprend 4 étapes bien distinctes :
Plan = planifier
C’est là que l’on vient écrire ce que l’on va faire, qui va le faire, et pour quand. En général, 3 petites colonnes… Mais énormément de travail en amont. En effet, il a été nécessaire de caractériser le problème à traiter, d’en analyser les causes, de définir les actions qui pourront effectivement supprimer ces causes.
Cette étape doit être faite avec rigueur, et il est important de prendre le temps de bien faire les analyses – ce qui est difficile lorsque vous avez un client exaspéré ou un responsable de site au bord de la crise de nerf sur le dos en permanence. C’est le moment d’appliquer la maxime « Allons lentement car nous sommes pressés »
Mon astuce pour garder la main sur mon planning : mettre en place un bulletin d’information régulier, qu’il soit écrit ou oral, en présentiel, par email ou par téléphone, avec une fréquence et un horaire défini. Et s’y tenir. « Je m’engage à diffuser l’avancée du plan d’action 2 fois par jour à telle heure et telle heure. Le reste du temps, laisser moi travailler ! »
Autre point à ne pas oublier : le planning – inclus dans l’expression anglais « plan ». L’étape suivante – le Do – va prendre du temps, et les actions vont devoir s’intégrer dans des agendas souvent déjà bien chargés : évaluation et tri des stocks chez les fournisseurs, temps disponible sur les lignes de production pour intervention, nécessité de qualification après modification… Tout doit être évalué et consigné. Une bonne planification prend en compte l’enchainement des actions, et permet un suivi régulier de l’avancement du plan d’action
Do = faire
Sur le papier, c’est la phase la plus simple : on exécute ce qui a été posé dans le plan d’action pendant la phase « Plan ». Oui mais… 2 facteurs entrent en jeu à ce moment-là
- Il y a tout d’abord la loi de Murphy qui dit que tout ce qui est susceptible d’aller mal, ira mal. C’est pour cela que l’on prend un buffer de +25% sur les délai dans la définition d’un plan d’action… et que l’on passe pour d’incorrigibles pessimistes.
- Le second facteur, c’est que le quotidien s’invite dans le jeu, et que des actions pour lesquelles on était très motivées il y a quelques semaines peuvent devenir une vraie corvée si l’on est dans une phase de surcharge, ou si d’autres incidents sont venus se rajouter sur la pile.
Nous avons parlé la semaine dernière de l’importance de mettre des niveaux de criticité sur chaque action, et cela prend tout son sens lorsque l’on doit jongler avec plusieurs plans ou plusieurs responsabilités divergentes, et que l’on doit donc faire des choix pour ses actions prioritaires.
Dans cette phase, il est important d’avoir des points d’avancement réguliers pour s’assurer que le plan avance bien. La fréquence dépend de la gravité du problème et des délais consignés dans la phase plan. A nous de choisir le bon rythme, et … de s’y tenir.
Autre point important : Avoir un sponsor avec le bon niveau de décision pour que le plan avance, et l’impliquer. Que celui qui n’a jamais participé à une réunion de « report d’actions » lève la main… Ce sont ces réunions de suivi où tout le monde vient annoncer qu’il n’a pas fait ses actions de la semaine, mais les fera la semaine suivante. Les plans d’action gérés de cette façon périclitent. La solution tient dans l’engagement du sponsor et sa capacité à être présent à chaque réunion. Que ce soit un représentant du client ou un responsable de site, il doit être en mesure de trancher si les priorités se chevauchent ou de re-confirmer les attendus si certains points n’avancent pas.
Check = Vérifier
Faire – Do – ne suffit pas. Il faut s’assurer que les actions entreprirent ont bien réglé le problème initial.
Je me souviens avoir passé des heures sur le tri de vis pour supprimer toutes les pièces avec une bavure sur la tête… pour ensuite constater que le problème persistait, et que nous n’avions pas toutes les causes premières. (Un problème d’ovalisation de la tête non identifié avant d’avoir évacué la tête de pareto que représentait la bavure)
Vérifier, cela veut dire à la fois s’assurer que les actions prévues ont été faites, mais aussi que qu’elles ont permis la correction définitive du problème initial.
Et si ce n’est pas la cas ? Et bien on recommence. Pas toujours facile sur les plans d’action au long court, mais pas d’autre solution. Il faut reprendre l’analyse à partir des nouveaux constats : recherche et confirmation de nouvelles causes premières, définitions des actions à entreprendre pour les corriger, mise à jour du plan d’action.
Act = Capitaliser
Nous y voilà, c’est la dernière phase, la capitalisation.
Après 20 ans d’Assurance Qualité Fournisseurs, je ne compte plus le nombre de fois où j’ai vu le laconique « Mettre à jour l’AMDEC » dans la colonne correspondant à cette tâche… Parfois, il y a une précision sur quelle AMDEC… Et de temps en temps un responsable et un délai.
Capitaliser arrive à la fin d’u long processus, pas facile de garder les troupes sur le pont, surtout si d’autres priorités sont apparues depuis l’incident initial.
Pourtant cette phase est celle qui permet effectivement l’amélioration continue. A planifier, comme le reste. Il faut un responsable dont on prend en compte la charge et les priorités, un délai cohérent avec les besoins de l’entreprises (souvent la mise en place de nouvelles lignes de production ou de nouveaux produits), et une vérification de la réalisation de l’action.
Pour cela, notre format de PCDA ne comporte qu’une seule colonne « Done » mais nous aurions pu prendre le partie de vérifier aussi l’efficacité. Nous reviendrons sur ce point plus longuement la semaine prochaine dans le cas des PDCA associés à des runs.
La phase de capitalisation se doit encore d’être la plus exhaustive possible. On pense généralement « mise à jour de la documentation » et « produits similaires en production ». Mais avez-vous une routine en place pour alerter tous les projets en cours dès qu’un nouveau défaut est identifié ? J’ai rencontré cette situation plus d’une fois : un défaut a été corrigé avec un plan d’action conséquent… et réapparait lors de la mise en production d’un nouveau produit. C’est très démoralisant pour le personnel de production, et souvent cela coute cher à l’entreprise. Cela ne justifie-t-il pas de passer un peu de temps sur chaque incident dans les équipes projet ?
Le PDCA à l’ère de l’Agile
Nous venons de faire un tour complet du PDCA dit classique, celui utilisé depuis les années 50.
La semaine prochaine, nous allons aborder le PDCA expérimental, et passer un peu de temps sur les notions de Check et de Act lorsqu’il est utilisé pour des runs Agile.
The Floating Mushroom 