Pratiquer une approche systématique de résolution de problème permet de générer de la connaissance pour l’amélioration continue d’un produit ou d’un service. C’est aussi ce qui en fait un outil de développement personnel.
Le cycle PDCA suit simplement les étapes de la méthode scientifique. Partant d’un problème formulé comme un écart de performance : « Plan » élabore une hypothèse de cause et une approche de résolution expérimentale ; « Do » mène l’expérience ; « Check » recueille les mesures ; « Act » interprète les résultats et pérennise les actions désormais appropriées.[1]
Démarrons par un exemple, simple, pour un aperçu de sa structure:
- Plan
- Problème: pour une équipe de testeurs de logiciels, la productivité en nombre de tests exécutés par jour est de 15 alors qu’elle devrait être à 28.
- Causes observées: en observant les testeurs au travail, le manager découvre des causes du ralentissement de l’exécution des tests :
- Configuration incorrecte : les services web de taxation, sollicités par les tests automatisés et manuels, tournent sur des numéros de port qui changent très souvent. En effet, ils sont régulièrement modifiés par une autre équipe. Par conséquent, plusieurs tests échouent et les testeurs n’avancent pas bien.
- Données de tests incomplètes : plusieurs paramètres sont manquants dans les profils utilisateurs créés pour les tests car les testeurs ne les connaissent pas bien. Lorsqu’un test échoue, dans le doute ils analysent très longuement la situation.
- Idées d’actions, mise en œuvre: Installer des instances dédiées des services web, pour les tests. Former les testeurs, de façon régulière, tout en assurant l’activité. Voir la productivité de l’équipe et créer un management visuel.
- Do
- Le manager planifie des séances de 20mn pendant lesquels il travaille avec chaque testeur, au poste de celui-ci. Ensemble ils créent les profils utilisateurs nécessaires pour ses tests. Le testeur apprend ainsi à le faire.
- Un ingénieur système, spécialement détaché, installe de nouvelles instances des services web de taxation et crée des scripts de monitoring pour s’assurer de leur disponibilité, pour les tests, avec la bonne configuration.
- Le manager crée un management visuel qui montre l’avancement de l’exécution des tests, avec les problèmes rencontrés. De plus, il suit et partage un indicateur de productivité journalière avec l’équipe.
- Check
- Le dernier relevé de la productivité de l’équipe, montre 26.
- Act
- Le manager fait désormais le tour des testeurs trois fois dans la journée, sur leur plateau, pour voir et résoudre les problèmes. L’équipe se donne ainsi une chance d’atteindre sa productivité du jour.
Définition
Je préfère l’explication[1] qui dit que le cycle PDCA démarre avec :
- L’étape du « Plan », dans lequel le porteur étudie en profondeur un problème ou opportunité, pour le comprendre du plus grand nombre de points de vue possibles. Il l’analyse (quantitativement, si possible), pour trouver les causes racines, développer une ou plusieurs idées pour remédier au problème ou saisir l’opportunité, et élaborer un plan de mise en œuvre
- Dans l’étape du « Do », le plan est mis en œuvre le plus rapidement possible et avec prudence
- L’étape du « Check » consiste à mesurer les effets de la mise en œuvre et à les comparer à la cible ou à la prédiction
- Le « Act » fait référence à l’établissement du nouveau processus, solution ou système comme standard si les résultats sont satisfaisants, ou à la prise de mesures correctives s’ils ne le sont pas.
Origine
Le PDCA est en réalité une reformulation, faite par des managers japonais, du cycle du mathématicien W. Edwards Deming. Ce cycle est connu sous le nom de PDSA (Plan – Do – Study – Act). Il faut noter qu’il existe une différence significative entre le PDCA et le PDSA de Deming.
Contactez-nous pour échanger sur la manière de conduire un PDCA.
[1] Je suis parti de la définition de « Understand A3 thinking » par Durward K. Sobek II et Art Smalley.
Inscrivez-vous pour recevoir mes prochains articles.
[newsletter_form type=”minimal”]
Leave a Reply