Il y a quelque temps, j’ai assisté à une réunion chez un important éditeur de logiciel français, dans laquelle un dirigeant est venu à la rencontre d’une équipe produit. Cette équipe est en charge du support, de la maintenance et de l’évolution DU produit « vache à lait » de l’entreprise. Cela veut dire qu’une partie conséquente du chiffre d’affaire de la société vient du progiciel historique géré par cette équipe de quelques personnes.

Cette rencontre avait pour but de « remotiver » l’équipe et de la “réaligner” sur leurs challenges actuels et futurs. Je suis sûr que cela vous parle ^^. Je vous propose un petit retour sur cette réunion, et de ce qui s’en est suivi lorsque j’ai posé un regard Lean sur la situation.

« Remotivation et réalignement »

Les guillemets sont volontaires (et il va y en avoir beaucoup). Le discours se voulait « factuel » pour réaligner les équipes et les motiver à mieux faire. Le dirigeant a commencé par une sensibilisation sur le fait que l’équipe travaillait sur un progiciel qui souffrait d’une « faible satisfaction client ». En effet, “beaucoup” de clients se plaignaient d’un déploiement « trop long ». « D’autres » se plaignaient d’une « mauvaise documentation ». De plus, « certains » gros marchés ont été perdus.

Je ne sais pas vous, mais à ce moment-là, je n’ai personnellement pas gagné en motivation. Mais rassurez-vous, le discours s’est ensuite ouvert sur des axes de progression pour « mieux faire ». En effet, l’accent a ensuite été mis sur le fait de devoir « améliorer la qualité », « accélérer le déploiement », et « mieux travailler ensemble ». Ha c’est bon, on est sauvé, on a des choses à faire.

Je ne pense pas vous surprendre sur le fait que cette suite d’invectives n’a pas réellement motivé l’équipe, et ne l’a certainement pas alignée sur quoi que ce soit. Peut-être que le dirigeant pensait que l’équipe faisait volontairement un produit de « mauvaise qualité » et qu’elle s’affairait chaque jour à « augmenter le temps de déploiement » ou à rédiger de “mauvaises documentations” ?

Le problème est que ce dirigeant, avec qui j’ai échangé par la suite, ne connaissait pas l’équipe. Il est venu lui parler après avoir pris connaissance d’une enquête de satisfaction de grande ampleur auprès de l’ensemble des clients. La volonté de chercher des causes générales pouvant régler tous les problèmes d’un coup se heurte à celle de chercher des éléments actionnables par l’équipe. Et c’est pourtant cette dernière proposition qui lui permettrait d’améliorer réellement la situation.

Le résultat est là : l’équipe est sortie de cette réunion frustrée, plutôt démotivée et totalement incomprise. Une personne a démissionné peu après, et d’un point de vue Lean, ceci est le premier problème réel depuis le début de cet article (il est mesurable).

Le regard Lean

Comprendre le problème

Le souci avec ce genre de discours est que l’on confond problème et souci. En pensant énumérer des problèmes, on énonce une liste de soucis qui sont ni quantifiables, ni actionnables et donc très frustrants pour l’équipe. Quand on annonce que « beaucoup de clients se plaignent d’un déploiement trop long« , quel est le problème ? Autrement dit, est-ce qu’on comprend suffisamment le problème pour définir ce que représente sa résolution ? Dans notre exemple, est-ce que « un peu de clients font des remarques sur un déploiement un peu long » est un objectif de réussite (SMART) ?

La première chose à faire quand on est dans une démarche Lean est de clarifier le challenge que l’on souhaite réussir. Et pour se faire, nous allons comprendre les problèmes… Les vrais problèmes.

Ainsi, après avoir insisté longuement, le dirigeant a accepté de me consacrer un peu de son précieux temps. Pour ne rien vous cacher, cela s’est passé lors d’un déjeuner pour ne pas trop perturber son agenda. Avec son autorisation, je suis également allé à la rencontre du support, de certains clients et du middle management. Après quelques jours, voici ce qu’il en est ressorti :

• « manque de satisfaction client » s’est transformé en : Nous avions une satisfaction historique de 6 / 10 depuis plus de 10 ans. Elle est passée à 5 cette année.
• « déploiement trop long » s’est transformé en :
  • Le temps d’intervention pour déploiement d’une nouvelle version dure aujourd’hui 5 jours, les clients ne veulent pas passer plus de 2 jours car cela mobilise leurs équipes sur place et perturbe l’activité des utilisateurs.
  • Les déploiements sont accompagnés de 3 coupures de service pouvant durer jusqu’à une heure. Les clients n’en veulent plus car pendant ce temps, les utilisateurs perdent leurs outils. Et cela a des conséquences lorsque les utilisateurs travaillent 24/7.
• « Mauvaise documentation » s’est transformé en « les clients passent jusqu’à une heure à retrouver les infos qu’ils souhaitent »
• « certains gros marchés perdus » s’est transformé en : sur 37 nouveaux marchés supérieurs à xxx€, 7 ont été perdus.

Clarifier le challenge

L’avantage de cette approche, c’est que maintenant, les problèmes sont quantifiés et clairs. On a alors pu clarifier les conditions de réussite avec le manager et l’équipe :

• Un retour à une satisfaction client de 6 / 10.
• Une durée de déploiement de 2 jours.
• Un déploiement avec 0 coupure de service.
• Une documentation permettant aux clients de trouver l’information qu’ils souhaitent en 2 minutes.
• 0 nouveaux marchés perdus.

Et soudain, on commence à toucher du doigt ce que veut dire « le droit de réussir » promis par le Lean. Sans lui, le travail de l’équipe serait comme une partie de foot sans cage.

« Grâce au Lean, les collaborateurs n’ont pas le devoir de réussir leur journée, mais ils en ont le droit »

Marie-Pia Ignace

Apporter du soutien et accompagner

Le challenge étant maintenant clair, l’équipe peut alors comprendre ces écarts qui existent entre ce que l’on souhaiterait et la dure réalité. Et pour arriver à cela, ils seront soutenus, encouragés et accompagnés par leur manager qui utilisera le questionnement pour chercher les causes de ces écarts. Par ce geste, il met en valeur l’essence du Lean : comprendre ce que l’on a à apprendre.

Petite aparté : cela est probablement l’élément le moins facile du Lean. Les ingénieurs sont souvent des personnes curieuses en quête d’apprendre plein de choses. Mais le Lean, par la clarification des conditions de réussite et de la situation, les obligera à apprendre ce qui est nécessaire et non ce qu’ils souhaitent. C’est là un enjeu majeur du management qui doit faire en sorte de toujours les amener sur les bons sujets en faisant sans cesse le lien avec les conditions de réussite et la raison de leur existence.

Pour avancer sur les différents sujets, le manager de l’équipe et moi-même sommes allés sur le terrain, avec l’équipe, afin de comprendre les raisons de ces écarts. Par ce geste, on montre à l’équipe qu’il est nécessaire d’apprendre pour améliorer la situation et qu’on est là pour les aider. On leur montre qu’avoir un problème n’est pas grave, c’est même plutôt normal. Par contre “ce qui est grave, vis-à-vis du client et de l’équipe elle-même, c’est de ne pas s’occuper des problèmes rencontrés” nous disait Jean-Philippe Douet dans son article et si on ajoutait du Lean dans la rétro de sprint ?. Et en y allant tous les jours, on leur montre également que cet apprentissage doit avoir lieu chaque jour (pas uniquement 2 heures en fin de sprint ^^).

En allant sur le terrain ainsi, l’aspect “actionnable” nous saute alors aux yeux.

Problème de satisfaction client

Pour améliorer la satisfaction client, nous avons demandé à l’équipe comment faire pour comprendre pourquoi des clients ont mis en dessous de 6. L’équipe a alors eu une idée dingue, totalement disruptive avec l’idée de trouver de supers solutions sur des slides en salle de réunion : appeler les clients en question pour leur demander. Un sujet déjà abordé dans l’article voir notre client avec un regard Lean, l’entretien client est une des clés de la satisfaction client dans la démarche Lean. Les clients ont été satisfaits d’être appelés et de se sentir écoutés. Mais surtout, ils nous ont laissé des éléments extrêmement tangibles et actionnables pour améliorer la situation. On est loin de l’injonction “il faut mieux faire”.

Problème de temps de déploiement et d’arrêt de service.

Pour comprendre ce problème, nous sommes allés voir les ops dans le but d’observer un déploiement et comprendre comment le temps était dépensé. L’équipe a identifié des temps d’attente à des moments précis du processus de déploiement. Ils ont également avoué avoir sous-estimé certaines étapes de processus, notamment concernant la reprise de données d’une ancienne version. Ils ont également noté certains éléments longs pouvant être automatisés ou parallélisables. 

Enfin, elle a mis le doigt sur les fameuses étapes de déploiement nécessitant un arrêt de service. Après investigation, il s’avère qu’il s’agissait de vieux scripts de mise à jour des droits de base de données, nécessitant des redémarrages du SGBD. Après avoir consulté la DBA, nous avons compris que ces scripts étaient fait pour une ancienne version d’Oracle qui n’est plus utilisée depuis plusieurs années. La nouvelle version permet, après quelques modifications, de faire la même chose “à chaud”, c’est-à-dire sans redémarrage des bases, et donc sans interruption de service.

Problème de documentation

Nous avons également contacté les clients se plaignant de la documentation. Après quelques appels, on comprend rapidement que la documentation en question est celle qui touche les versions mensuelles de maintenance. Les tickets traités dans la version sont listés dans la documentation qui représente alors une bonne vingtaine de pages. Les clients se plaignent d’avoir à chercher manuellement les tickets qui les concernent dans cette liste indigeste, dans laquelle le nom des clients demandeurs n’est évidemment pas affiché.

Problème de perte de marché

Enfin, nous avons contacté le service commercial et les clients afin de comprendre la raison des marchés perdus. Des échanges qui ont révélé des problèmes hors de portée de l’équipe pour la grande majorité d’entre eux. Une opportunité pour le manager d’aller chercher des améliorations à d’autres étapes de la chaîne, et de répandre la pratique de l’amélioration.

Une fin un peu rapide

J’ai malheureusement terminé ma mission auprès de cette équipe peu après. Je suis donc désolé de décevoir vos attentes de résultats, mais je n’ai pas d’information sur les conclusions de cette histoire. J’en suis également extrêmement frustré. 

Ce dont je suis certain, c’est qu’à mon départ l’équipe avait des éléments extrêmement tangibles et actionnables (contrairement à la suite d’invectives du départ). Je n’ai donc que peu de doute sur le fait que l’équipe a pu s’améliorer de manière très significative et redorer son blason.

Ce que je sais cependant grâce aux réseaux sociaux, c’est que le manager en question est devenu manager du nouveau produit phare de l’entreprise, celui vers qui se tourne aujourd’hui tous les regards.

Cet article a inspiré un chapitre de Culture Kaizen – La transformation des petits matin, livre blanc d’OCTO Technology.