Améliorer le travail d’une équipe : histoire d’une amélioration continue

Peu importe le but qui vous anime vous avez compris qu’il fallait que vos équipes travaillent différemment. Maintenant il reste à savoir comment vous y prendre.

Vous avez réussi à identifier les problèmes voire d’éventuelles solutions, vous avez compris qu’il valait mieux co-créer votre plan avec les personnes concernées plutôt qu’avancer seul et ce malgré les difficultés à engager les gens dans une telle démarche, en tout cas dans un premier temps.

Maintenant vous aller vous heurter à ce qui rebute beaucoup de monde et fait qu’elles se résignent avec fatalisme à ce que les choses fonctionnement mal

1°) Il y a énormément de sujets à traiter

2°) Une fois un sujet traité un autre survient

3°) Lorsqu’un sujet est traité il ne l’est jamais pour longtemps : il faut soit améliorer soit recommencer au bout d’un certain temps.

L’amélioration n’est pas un « one shot »

Un projet d’amélioration ne devrait jamais être un « one shot », quelque chose qu’on fait, qu’on termine et qu’on peut alors laisser en état. C’est une donnée qui nous vient du monde industriel mais c’est encore plus vrai quand on parle du travail des humains et a fortiori dans l’économie de la connaissance.

Si on peut considérer qu’un processus industriel peut être « stable » pendant un certain temps et qu’on peut se contenter d’en améliorer les composants au fil du temps, un processus mettant en jeu des flux d’information et leur traitement individuel et collaboratif n’est presque jamais stable. Non seulement, bien sûr, on peut l’améliorer au fil du temps mais en plus il peut se reconfigurer en permanence sous l’influence du cas à traiter, des ressources et compétences disponibles, de nouvelles technologies à disposition etc. Les deux sont semblables dans l’esprit mais le second a un cycle de vie « stable » infiniment plus court.

Améliorer le travail d’une équipe c’est donc

1°) Améliorer les processus au sens large (formels, informels, rigides, flexibles, au niveau de l’individu et du collectif…)

2°) Améliorer chaque partie d’entre eux

3°) Y inclure en permanence des éléments nouveaux et ôter des éléments obsolètes.

Effectivement c’est une démarche dont on ne verra, par définition, jamais la fin. Mais ça ne veut pas dire qu’on ne peut pas avancer sur les sujets un à un.

Cela doit de plus se faire dans un contexte qui a ses contraintes :

1°) La démarche d’amélioration mobilise des ressources en plus de leur travail. Il ne faut pas que le « business quotidien » fasse oublier le fil du projet d’amélioration et qu’on se dise qu’on avancera « quand on aura le temps ». On doit changer la roue du camion pendant qu’il roule.

2°) Il faut aller vite. Comme je l’ai dit plus haut le contexte évolue en permanence et prendre 6 mois pour apporter une réponse à un problème qui a disparu ou s’est transformé entre temps n’est pas une solution.

3°) Il faut donner de la visibilité aux équipes. Si on veut les impliquer et qu’elles y croient elles doivent voir que les choses avancent, que les idées deviennent réalité, que les délais sont tenus.

Autant de choses qui font que beaucoup préfèrent s’accommoder de choses qui ne fonctionnent pas en se disant « de toute manière je n’arriverai jamais à changer les choses ».

C’est un problème auquel j’ai été confronté et j’ai construit au fil du temps un mode opératoire de manière empirique. Il n’a pas la prétention d’être une recette magique mais il a l’avantage de fonctionner.

1°) Sourcer idées et problèmes et alimenter le dispositif

Au tout début j’ai eu des discussions individuelles avec chaque membre de mon équipe mais aussi avec les membres d’autres équipes avec lesquelles les interactions étaient fréquentes sachant que ce qu’on ferait chez les uns aurait un impact chez les autres et que régler des problèmes des uns demanderait également de mobiliser les autres. Ma question était simple : « qu’est ce qui t’empêche de faire ton travail aussi bien que tu le pourrais ».

Cela a suffit à « amorcer la pompe » pour de longs mois.

Ensuite on a pu améliorer le dispositif avec deux choses.

1°) Un formulaire en ligne pour faire remonter des problèmes ou des idées classées par thématiques : dysfonctionnements des outils et des process, améliorations à la manière dont on travaille, retours d’expérience sur un raté ou une réussite majeure dont on doit apprendre pour que cela ne se reproduise plus ou pour généraliser une bonne pratique, points de frictions au quotidien…

2°) Une réunion bi-mensuelle qui sert également à capter un certain nombre de sujets.

2°) Donner du rythme et de visibilité : traiter les sujets de manière « pseudo-agile

Je dis pseudo agile car les puristes pourront me reprocher de ne pas aller assez loin dans l’esprit et de bafouer certaines règles. Mais mon objectif n’était pas de faire de l’agile pour faire de l’agile, simplement de trouver un dispositif qui fonctionne pour donner du rythme quitte à faire du « quick and dirty » qu’on améliorera au fil du temps.

Les différentes données ainsi collectées finissent dans un « board » tenu, selon ce que vous avez sous la main dans votre entreprise et vos préférences, dans une application comme Trello ou JIRA.

On divise alors le temps en « sprints » de 15 jours ou un mois (15 jours pour moi) et de manière très simple, en début de sprint, « on » décide ce qu’on va traiter durant le sprint, on le basse de la colonne « to do » à la colonne « en cours » et lorsque c’est fini dans la colonne « terminé ».

L’idée est donc de ne faire que des choses qui peuvent être accomplies en 15 jours donc parfois cela impose de redécouper certains gros sujets en plusieurs petits.

La décision de traiter tel ou tel problème pourra revenir au manager de l’équipe ou être collective, suivre des règles de priorisation formelles ou non. En ce qui me concerne j’ai commencé à alimenter et décider seul pour amorcer la pompe, le « collectif » n’est venu que progressivement au fil du temps.

Au départ j’étais responsable de 99% des tâches, maintenant je peux commencer à en distribuer quelques unes.

Tous les 15 jours une réunion permet de faire le point sur les différents chantiers.

3°) Une réunion bi-mensuelle pour se parler et informer

Je ne suis pas un adepte de la réunionnite, loin de là, et il y a pleins d’autres manières d’informer et échanger avec une équipe que tenir des réunions régulières. Pour autant cela m’a semblé nécessaire vu le but poursuivi.

J’ai donc instauré une réunion d’une heure qui se tient tous les 15 jours. Y sont conviés de manière « obligatoire » les membres de mon équipe directe et de manière facultative les managers des équipes avec qui notre travail respectif « interfère ».

Le sujet : « améliorer la manière dont on travaille ». Hors de question de parler ici des projets en cours, des clients, des performances des uns et des autres. Ca n’est pas une réunion « business » (il y en a bien assez comme cela) mais plutôt une réunion sur « comment on fait tourner le business ».

L’ordre du jour :

• Suivi des améliorations en cours
• Point d’information sur des sujets divers à venir ou qui peuvent les concerner (un chantier qui s’amorce au niveau de l’entreprise sur tel ou tel sujet, une décision qui progresse sur un sujet que nous avions amorcé et où on était en attente de choix faits par ailleurs…).
• Retour sur le fonctionnement des initiatives précédemment réalisées : on a changé quelque chose il y a 15 jours, un mois, est-ce que cela fonctionne comme attendu, faut il améliorer quelque chose, voire abandonner et faire machine arrière car finalement notre idée n’était pas si bonne…
• Intervention de « guest stars ». Par exemple faire intervenir la personne en charge du RGPD et des données pour qu’ils comprennent l’importance de ces sujets dans leurs propres modes opératoires, de la direction financière pour partager nos points de vue sur le reporting nécessaire et alléger/améliorer les pratiques actuelles…)
• Questions diverses.

Maintenant que la chose s’est bien mise en place je constate que :

• C’est peut être une des réunions à laquelle ils assistent avec le plus de plaisir car cela les concerne directement au quotidien et sont écoutés.
• Cela permet à des départements qui travaillent beaucoup ensemble mais ne parlent jamais de « comment on travaille ensemble » au travers de silos de le faire.
• D’ailleurs les 2 managers d’autres équipes qui sont pourtant « optionnels » viennent à chaque fois. Cela permet de parler des décisions prises chez les uns qui auront un effet chez les autres et d’avoir des alliés plutôt que des opposants quand vous annoncez qu’un process qui concerne plusieurs métiers doit être refondu et que vous allez vous en occuper.
• Les discussions sur les différents sujets entrainent des échanges qui en font émerger d’autres. Mais, surtout, elles permettent de créer des consensus…à condition de laisser les gens parler et aller au bout de leurs idées sans les interrompre. Parfois certains avaient des idées très précises de ce qu’ils auraient aimé mais ont fini par réaliser par eux-mêmes que les satisfaire à 100% allait créer des problèmes chez les autres et donc qu’il valait mieux mettre de l’eau dans leur vin.

Bref un moment d’échange et de décision visiblement apprécié et qui permet de faire avancer les choses. Ce que j’en retiens c’est le commentaire d’un participant « c’est sympa car c’est des sujets dont on ne parle jamais, on nous parle toujours de notre travail mais on ne nous consulte jamais sur la manière dont on le fait et comment l’améliorer ».

Dit autrement « on est responsable des résultats de notre travail mais on n’a rien à dire sur la manière dont on y parvient ».

Un dispositif scalable

Je décris ici ce qu’un manager peut faire à son niveau sur un périmètre où il a assez de latitude d’action. Mais on peut « emboiter » ce type d’approche sur plusieurs niveaux afin de coordonner le choses au niveau des équipes, départements, de l’entreprise.

On peut imaginer que certains sujets « remontent » car nécessitent une décision à plus haut niveau ou encore que d’autres redescendent pour être adaptés « localement ».

En ce qui me concerne c’est un peu ce qui s’est passé. Ce système de fonctionnement par sujet, par « ticket » est en place au niveau du Comex pour des sujets d’amélioration globaux et je voulais faire redescendre cette pratique pour adresser des sujets propres à mon département. Je ne cache pas qu’avoir un pied à chaque étage aide à coordonner…

Conclusion

Pour l’instant le dispositif me semble tenir ses promesses et remplir ses objectifs.

A savoir

• Faire exister le sujet de l’amélioration de nos pratiques et ne pas seulement en parler quand nos missions quotidiennes nous en laisse le temps…c’est à dire jamais ou de manière trop décousue. Sur ce point l’adoption d’une approche de type « pseudo agile » a été essentielle avec une obligation de montrer des choses à intervalle régulier.
• Eviter l’effet tunnel, avancer par petits pas mais avancer.
• Montrer aux équipes que les choses avancent et donner du rythme.
• Responsabiliser le manager. Quand des choses restent trop longtemps « en cours » c’est sa faute.
• Impliquer les équipes.
• Casser les silos sur des sujets qu’on ne peut régler seul dans son coin.

Mais on n’est jamais exempt de critiques et aucun dispositif n’est jamais parfait. Pour avoir échangé à ce propos avec des confrères d’autres entreprises j’ai entendu deux choses.

La première est que mettre en place ce dispositif et l’animer demande trop de temps au manager. Peut être mais dans ce cas je me demande à quoi sert le manager. Ne s’intéresser qu’aux résultats (qu’on veut sans cesse améliorer…) sans se questionner sur comment on les obtient n’est pas durable. Soit on ne met la pression que sur les gens et à la fin ça casse, soit on abdique en ce disant qu’on attendra que l’entreprise prenne la décision d’imposer le changement. A mon avis c’est fuir ses responsabiilités.

La deuxième c’est qu’au final cela revient à demander à des managers ou des dirigeants de « traiter des tickets » comme un vulgaire service client. Et alors ? Un manager ou un dirigeant ne sont pas dans une tour d’ivoire ou du papier de soie. Justement, plus on monte en responsabilité plus le métier devient de régler ce qui ne va pas. De manière générale ce qui va bien dans une entreprise est le résultat du travail des collaborateurs, ce qui va mal est du ressort du manager qui doit le régler et est responsable vis à vis de son équipe. D’une certaine manière cela s’inscrit dans une logique de service employé en étendant le périmètre de la « réponse continue » que Josh Bersin appliquait principalement aux RH. Mais on reparlera prochainement de manière plus large de ce que j’appelle la « ticketisation de l’entreprise« .

Image : amélioration continue de Photon photo via Shutterstock