Dans nombre d’entreprises, le modèle de management a besoin de trouver un (et pas forcément le) coupable en cas de problème. Les exemples sont multiples et malheureusement très courants. Le respect et l’apprentissage, deux valeurs du Lean Management, permettent de réduire significativement cette stigmatisation qu’impose la recherche dudit fautif. Le cas suivant est une démonstration parmi d’autres que l’état d’esprit Lean, associé à une technique de résolution de problème, aide à désamorcer des situations qui peuvent se transformer en sanction.

Contexte

Le cas qui nous concerne se déroule dans un service informatique lors d’une intervention programmée en heures ouvrées sur une plate-forme de pré-production. Sa finalité est de valider un mode opératoire avant de l’exécuter sur la plate-forme de production. Action tout à fait normale quand il s’agit de sécuriser les services des clients hébergés sur la plate-forme de production.

L’opérateur exécute les tâches de son intervention. Peu de temps après, des alertes sont remontées par les outils de supervision de la plate-forme de production. Plusieurs clients appellent les équipes support niveau 1 pour se plaindre de l’indisponibilité de leurs applications. L’équipe de l’opérateur analyse rapidement la situation et découvre que l’intervention a été réalisée non pas sur la plate-forme de pré-production, mais sur la plate-forme de production ! L’opération de retour-arrière est opérée et la communication interne et vers les clients fait état d’une erreur humaine. Tout le monde est content, le coupable est identifié.

Goudron et plumes pour le coupable

Cet incident a permis de détecter que le mode opératoire n’était pas adapté à la plate-forme de production, c’est déjà un bon point mais les services de plusieurs clients ont été interrompus pendant plusieurs minutes, ce qui, pour les clients, est inacceptable.

L’équipe, en s’arrêtant à l’erreur humaine, se met naturellement des œillères (ou fait l’autruche) pour ne pas voir les vrais problèmes et comprendre pour quelle raison l’opérateur en est arrivé à se tromper de plate-forme. L’équipe estime avoir terminé son travail d’analyse et le sujet est clos. L’opérateur n’a pas correctement réalisé son travail et son manageur lui fait savoir. Sans compter que cet incident sera pris en compte dans son évaluation annuelle. L’opérateur rentre la tête dans les épaules et fait le dos-rond. Intérieurement, il se dit que la prochaine fois, il n’ira pas donner un coup de main pendant qu’il réalise des opérations. Sa motivation baisse et pour les clients qui connaissent l’équipe, il passe pour un vilain canard.

Et si on s’occupait du problème ?

Le sujet était sensible, car un des clients utilisant les services de cette plate-forme avait mandaté son service « Audit » suite à des précédents qui rendaient ses fonctionnalités instables durant les jours et les heures les plus critiques pour son entreprise. J’ai décidé de procéder à un 5P (les « 5 pourquoi ») pour comprendre l’origine du problème et ne pas rester sur la stigmatisation du collaborateur. Il en est ressorti que :

• l’opérateur avait préalablement réalisé une intervention non critique (ce qu’on appelle « changement standard » en ITIL) sur la plate-forme de production ; sa console était donc connectée à cette plate-forme ;
• l’opérateur a été interrompu au début de sa procédure pour aider une autre personne sur une tâche plus urgente ;
• il a repris son intervention en étant persuadé de s’être déjà connecté à la plate-forme de pré-production alors qu’il l’était encore à la plate-forme de production ;
• il n’a pas su faire la distinction entre les 2 plates-formes car il n’y avait pas d’élément visuel pour l’alerter.

La cause racine n’est donc pas l’erreur humaine, mais l’impossibilité pour l’opérateur, dans un moment de surcharge d’activité, de faire simplement et rapidement la distinction entre les 2 plates-formes. L’action de correction a été de modifier les paramètres des consoles pour afficher un bandeau en lettres rouges quand les opérateurs sont connectés à une plate-forme de production. En Lean, on appelle cela un poka-yoke (détrompeur). Ce changement est devenu un standard dans ce service et dans d’autres via le principe du Yokoten.

Que dit le Toyota Way ?

Les 2 piliers du Toyota Way sont

• Amélioration continue (challenge, kaizen, genchi genbutsu) ;
• Respect des personnes (respect, teamwork).

Malheureusement, très souvent, seul le premier pilier est mis en pratique (avec plus ou moins de réussite) par les entreprises qui se lancent dans le Lean. Le deuxième (« Respect des personnes ») a un sens bien plus fort que d’être poli, aimable et dire bonjour à ses collaborateurs.

Dans cet exemple, avec l’usage du 5P (que beaucoup prétendent déjà utiliser pour identifier l’erreur humaine comme cause racine…) et le respect des personnes (au sens Lean : donner les moyens aux employés de réussir leur travail), il est sans conteste possible d’établir des relations bienveillantes permettant d’apprendre et de sortir de la stigmatisation, vecteur de stress, de perte de confiance, de mal-être, de perte de sens dans le travail et, pour finir, un niveau de qualité des produits / services en baisse.

Pour terminer, je citerai Masaaki Imai

Progress is impossible without the ability to admit mistakes

Et vous, en cas de problème, cherchez-vous un coupable ou mettez-vous l’équipe en situation de voir, comprendre et apprendre ?