« Pourquoi selon toi la qualité et le juste-à-temps sont-ils les deux piliers du Lean ? Parce qu’en travaillant la qualité tu améliores ta marge et en travaillant le flux tu travailles ta trésorerie. C’est tout simple à comprendre : le Lean adresse les deux sujets principaux de l’entreprise. »

Nous étions assis à un restaurant à Saint-Lazare un midi de septembre avec Michael Ballé. Comme à son habitude, il trouvait à redire sur la qualité du service. Puis il me dit cette fulgurance ci-dessus qui me laissa sans voix pendant de longues minutes.

Je lui avais proposé de nous rencontrer car j’allais démarrer l’accompagnement d’un groupe de dirigeants. Sachant qu’il faisait cela depuis de longues années, j’avais besoin de ses lumières. C’est, à ce jour, la chose la plus formidablement puissante que l’on m’a dite sur la gestion d’une entreprise. En effet, lorsque l’on évite les problèmes de qualité on évite les surcoûts qui grèvent la marge. Et lorsque l’on travaille en flux on limite la trésorerie au strict nécessaire. Deux piliers que je garde toujours à l’esprit lorsque j’accompagne des dirigeants.

Voyons maintenant cela en action avec un cas très concret. Il s’agit d’une PME de services numériques (Keepeek) qui propose une solution intégrée de DAM (Digital Asset Management) aux entreprises. Le produit est excellent mais l’entreprise est contrainte de freiner ses commerciaux car les équipes opérationnelles ont du mal à répondre à la demande client et livrer les implémentations de la solution, adaptées aux besoins de l’industrie et de l’entreprise …

Clarifier le problème

L’équipe de Professional Services regroupe six chefs de projet chargé d’un portefeuille de clients (une dizaine chacun). Elle s’appuie pour la customisation sur une équipe Intégration de 8 ingénieurs, développeur, intégrateur et testeurs. La situation est assez confuse. Chaque chef de projet souhaite faire passer les tâches qui concerne ses projets en priorité au niveau de l’équipe Intégration. Les livraisons de projet sont très souvent décalées. Le chefs de projets ont l’impression de ne pas y arriver à force jongler avec toutes ces contraintes différentes.

Le regard Lean va apporter deux éléments extrêmement clairs et permettre de clarifier la situation :

1. Sur les douze premières semaines de l’année, l’entreprise a démarré 36 nouveaux projets clients mais n’en a livré que 24  ;
2. La non-qualité (bugs trouvés en phase de tests ou remontés par le client) coûte 30% de la charge des projets d’intégration ;

Les conditions de la réussite s’énoncent alors simplement  :

1. livrer 3 projets par semaine pour être au rythme du client ;
2. réduire la non-qualité pour baisser le coût de l’intégration et pouvoir libérer du temps pour en livrer davantage.

Comprendre ensemble

Au cours de l’atelier que nous organisons, l’équipe s’accorde sur le planning des 4 semaines à venir en fonction des dates de livraisons prévues.

Dans un second temps, elle regarde à travers des cas récents les causes de décalage de livraison. Pour plusieurs des cas, c’est en raison des documents juridiques non envoyés par le client. Pour d’autres c’est un problème d’URL de ressources. Pour une troisième catégorie c’est parce que la recette du client dure bien plus que la semaine prévue. L’équipe identifie rapidement des contre-mesures qu’elle va pouvoir tester pour traiter ces sujets : demander au client dès le tout début du projet qu’il sollicite le service juridique pour avoir les bons documents à temps ; ajouter dans leur formulaire de capture des besoins une demande spécifique sur le format des URL ; prendre rendez vous avec le client pour lancer la recette avec elle ou lui.

Ensuite, l’équipe travaille sur des tickets avec des problèmes de qualité : elle identifie une dizaine de contre-mesures pour améliorer celle-ci : tester avec des photos aux trois formats (paysage, portrait et carré ; tester avec des intitulés de ressources très longs etc …)

Enfin, à la lecture des retours clients, l’équipe identifie des sujets faciles qu’elle peut prendre en charge pour répondre à des petits mécontentements exprimés. Le sujet qui revient le plus est qu’une fois la partie projet terminé et livré, l’interlocuteur change et ils ne savent plus qui ils doivent contacter en cas de problème. Ils mettent à jour leur kit de pilotage de projet et modifient le support de présentation de Réunion de Run avec une diapositive spécifique exprimant clairement le nom du nouvel interlocuteur (au sein de l’équipe Support).

Voir ensemble

Suite à l’atelier, l’animation va radicalement changer de nature.

Avant la mise en oeuvre du Lean, au point du matin qui intègre les trois équipes (CP, Intégration, Exploitation), chacun énonce les projets sur lesquels il a travaillé la veille et ceux sur lesquels il va travailler aujourd’hui. Le Kanban Jira est suivi de la gauche vers la droite avec les chefs de projet qui insistent sur l’importance de leur sujet et peuvent parfois se voir comme les clients des deux autres équipes. Comme très souvent dans les points d’animation agiles (Scrum ou Kanban ou autre) on ne sait pas bien ce qu’on doit réussir aujourd’hui.

Après la mise en oeuvre du Lean, à chaque lancement de point du matin, le directeur de projet en charge de l’équipe Professional Services rappelle les 3 (ou 4 – en fonction des engagements pris au préalable avec les clients) projets de la semaine et ceux de la semaine suivante. Et il demande si on va y arriver, et ce qui pourrait nous en empêcher. Le pilotage du Kanban se fait ensuite de la droite vers la gauche : on est tous engagé pour sortir des tickets. Le responsable exploitation n’est plus la dernière roue du carrosse mais celui qui parle en premier et qui explique les obstacles qu’il peut avoir pour passer en production les tâches nécessaires à la complétude des projets de cette semaine et la suivante. La dynamique de ce point d’animation quotidien si important a complètement changé.

Agir ensemble

Avec cette animation et un pilotage avec 3 indicateurs (nombre de projets sortis, qualité, satisfaction client) l’équipe va découvrir mille choses. En questionnant ses clients, elle va se rendre compte que bien souvent si la recette prend tant de temps c’est parce que les clients ont perdu le login / password et n’ont pas pensé à les redemander pris dans le rythme du quotidien (ils sont souvent dans de très grandes entreprises). Ils vont aussi se rendre compte que leurs clients ne savent pas nécessairement comment s’y prendre. Ils vont donc leur confier un cahier de recette pour préciser les points importants à vérifier.

En travaillant sur la cause des projets non-livrés, les chefs de projet vont se rendre compte de façon factuelle et spécifique de cette impression diffuse qu’ils avaient jusqu’alors : s’ils savent piloter un projet, ils ne savent pas piloter chaque semaine leur portefeuille de projets. En effet, 43 % des projets non livrés sont dus au fait qu’ils ont une vision différente du statut du projet avec le client et qu’ils ont manqué des échéances. Ils construisent alors un pilotage (soit en management visuel soit sur Trello) qui va leur permettre de suivre chacune des échéances de chacun de leur projet sur les semaines à venir. Chaque semaine, le directeur de projet les coache sur le pilotage de leurs échéances en utilisant cet outil. Cela leur permet de s’assurer qu’ils ont les bonnes priorités sur la semaine et qu’il ne reste pas d’angle mort.

En travaillant sur la qualité, ils vont se rendre compte que 60 % des projets n’ont pas les entrants attendus lorsque le travail d’intégration démarre. Ce qui cause de nombreux aller-retours. Ils vont aussi se rendre compte que 26,5 % des retouches sont dues à des changement de specs une fois le projet lancé, changement facilement anticipables. Un travail très proche entre intégration et chefs de projets va permettre rapidement de diviser par deux ce taux de non-qualité d’entrants. Les développeurs vont aussi voir que 25 % des bugs sont dus à des manques de tests des besoins clients exprimés sur le formulaire de capture des besoins. Ils les testeront systématiquement. Enfin ils mettront en place une checklist de tests ergonomiques pour éviter les nombreux bugs dus à cette famille de cause.

Résultats

L’équipe est passée de 2 projets sortis par semaine à 3,5. Le taux de non-qualité interne (identifié par l’équipe recette) a diminué de 43 % et externe (remonté par le client) a été divisé par 9. La productivité de l’équipe intégration (nombre de tâches livrées) a augmenté de 30 %.

Ce qui se passe lorsque l’on sort davantage de projets c’est que l’on facture davantage. Celle-ci n’a pas augmenté de 75 % (1,5 projets supplémentaires / 2 initiaux) car une partie des projets (environ un quart) est payée intégralement au démarrage. Toutefois cela représente un gain significatif pour l’entreprise. Celle-ci étant bénéficiaire avant le Lean (disons qu’elle obtenait un résultat net de 100 – le chiffre est inexact mais les échelles sont correctes), ce gain est de la marge nette. Il s’avère qu’il représente une somme de 30 par mois, environ 300 par an, ce qui fait un résultat net de 400 en fin d’année.

Voilà comment, en faisant travailler les équipes sur les bons sujets, liés 1/ à la qualité et 2/ au flux tiré par le rythme du client, on multiplie par 4 le résultat d’une PME du numérique et on illustre les propos de Michael qui ouvrent ce billet.

Enseignements

Comme toujours dans le Lean, les résultats ne sont qu’un by-product. Ce qui nous intéresse ce sont les enseignements que valident ces résultats.

La mise en oeuvre d’un flux tiré (sortir les 3 projets de la semaine) a permis d’aligner l’équipe sur les bonnes priorités mais surtout, comme le dit sans cesse Michael Ballé, de comprendre « qui doit apprendre quoi pour réussir ».

Les chefs de projet ont du apprendre à mieux piloter à la semaine leur portefeuille de projets et à mieux aider leurs clients en phase de lancement (documents juridiques) ou en phase de recette.

Les développeurs ont appris à mieux travailler avec les CP pour s’assurer qu’ils ont les bons entrants et qu’ils posent les bonnes questions pour éviter les changements de specs (qui étaient au final souvent de même nature). Ils ont aussi appris à mieux tester le fonctionnel et les différents aspects ergonomiques de cette belle solution logicielle.

Le directeur des projets a lui appris à coacher ses chefs de projet pour les aider à réussir. La nature de son poste a changé et il s’est révélé dans ce nouveau rôle.

Retrouvez nos formations au Lean et à l’agilité sur www.efidev.com l’institut de formation d’Operae Partners.