« Mes collaborateurs ne me demandent pas d’aide, pourtant ils ont l’air de galérer »

Pour se rappeler de ce qu’est l’andon, (re)lisez cet excellent article ou celui-ci.

L’andon est un outil extraordinaire qui permet de déclencher la chaîne d’aide managériale afin d’améliorer significativement les performances. Ainsi, quand un collaborateur a un doute ou qu’une situation anormale se produit, il « tire l’andon » : il demande de l’aide pour résoudre son problème. L’avantage de cet outil est qu’il est instantané : l’andon est tiré au moment du doute, et la chaîne managériale ou d’experts peut donc intervenir immédiatement. Cela permet d’éviter de faire subir un temps de réaction au client et du stress au collaborateur.

Que faire quand on réalise qu’un andon uniquement basé sur la capacité des gens à se déclarer en difficulté n’est pas suffisant ?

Souvent, pour les collaborateurs qui débutent dans l’amélioration continue, il est difficile de tirer l’andon et ce pour plusieurs raisons : parce qu’ils n’ont pas (encore) une vision claire de ce qu’est une situation normale ou anormale ; parce qu’ils n’ont pas (encore) confiance en leur chaîne de management ; ou encore parce qu’une fois, la chaîne de management a mal réagi ou n’a pas réagi à un andon (parfois, il suffit d’un…) ; ou que le collaborateur est en fait un prestataire qui craint d’être évincé de sa mission.

Alors, comment établir cette confiance et donner une vision claire à chaque collaborateur de ce qu’est une situation normale ou anormale ?

C’est exactement le cas que j’ai rencontré dans l’équipe de développement que j’accompagne actuellement. Ils n’ont, pour l’instant, jamais tiré d’andon et leurs bacs rouges (=bannettes à problèmes) sont toujours vides… Comme s’ils n’avaient aucun problème.

Pourtant, deux éléments cités plus haut sont, eux, révélateurs du fait que les collaborateurs auraient eu des occasions de tirer l’andon :

1. Le lead time (ou délai de livraison que l’on fait subir au client) : pour mon équipe, les estimations de temps de développement sont systématiquement dépassées, voire doublées. C’est un signe clair qu’au moins un collaborateur a rencontré un ou plusieurs obstacles dans son développement (ou que les estimations sont fausses, mais cette hypothèse a été éliminée). Une résolution de problème nous a permis de cerner le sujet (pour en savoir plus sur la résolution de problèmes, visionnez ce webinaire).
   Dans cette équipe, il s’agit, en résumé, d’un sujet de spécification incomplète (spécification = description de ce qu’il faut coder). Qu’avons-nous fait ? Nous avons établi une check-list qui permet de s’assurer que la spécification contient les bonnes informations avant de commencer un développement ; cela permet d’identifier les cas dans lesquels la situation est normale ou anormale.
2. le « smiley rouge » ou stress du collaborateur : la mesure systématique de la qualité de vie au travail (QVT) des collaborateurs permet aussi de révéler des obstacles. En effet, lorsque l’on mesure la QVT, un collaborateur en difficulté s’identifiera avec un « smiley » rouge. Et la présence d’un « smiley » rouge nécessite de tirer l’andon. Pour fonctionner, ce sujet doit être pris très au sérieux et le moindre élément remonté doit faire réagir le manager qui va alors rechercher une solution pour et avec le collaborateur concerné.
   Dans le cas de notre équipe, l’un des premiers sujets que nous avons traités avec le team leader est celui d’un collaborateur qui n’arrivait pas à accéder à une application essentielle lorsqu’il se trouvait devant son PC.

Comme le montrent ces exemples, l’andon est un excellent outil pour l’apprentissage et l’amélioration mais il nécessite que ses conditions d’utilisation :

1/ soient acceptées par l’ensemble de la chaîne de management,

2/ soient construites, apprises et pratiquées en équipe.

Et chez vous, dans quel cas un coéquipier doit-il tirer l’andon ? Et comment réagit son manager ?