Lean et agilité chez LesFurets.com

 

Récit d’une visite chez l’éditeur d’un comparateur d’assurances et de crédit à la consommation qui intègre progressivement la pensée agile et Lean dans ses processus, en identifiant de nouvelles possibilités d’amélioration.

Une traduction de Frédéric Buono du texte de Catherine Chabiron publié en anglais sur Planet-Lean.com

J’entre dans l’open space débordant d’activité. À l’extérieur, une fantastique terrasse surplombe les toits de Paris. Je visite LesFurets.com, une entreprise qui a trouvé le moyen de faire le boulot pas très passionnant de nous trouver une couverture d’assurance. Les sites web de comparaison sont devenus très populaires ces dernières années, en offrant les meilleures offres de voyage, tarifs d’hôtel et vols. LesFurets.com compare et sélectionne la meilleure police d’assurance pour votre voiture, votre vélo ou votre maison (ils ont aussi commencé à couvrir le financement, les soins de santé et l’accès à Internet).

Je suis ravie d’en apprendre davantage sur ce monde du web, loin des cravates et des costumes trois pièces, lors de ma rencontre avec Dimitri Baeli, le CTO (directeur technique) de la société. Dimitri est un agiliste reconnu et co-organisateur de la conférence FlowCon, mais il est également passionné par la pensée Lean. En fait, dans ses opérations quotidiennes sur LesFurets.com, Dimitri a réussi à faire le lien entre agile et Lean.

Avant de vous parler de mon gemba avec Dimitri, un mot sur le nom de la société. En Français, le « furet » est une petite créature notoirement agile qui peut se déplacer avec aisance et rapidité dans n’importe quel environnement. Ils étaient souvent utilisés comme assistants de chasse et ils étaient si habiles que le terme «fureter» a été inventé pour désigner la découverte d’informations par le biais d’une recherche incessante. C’est un nom plein de sens pour la société, dont les publicités télévisées utilisent des furets parlants.

LesFurets.com a une mission très claire : être LA place de marché pour comparer et acheter des services. La valeur ajoutée pour l’utilisateur final est de décrire ses besoins d’assurance une fois pour toutes – au lieu de devoir répéter son histoire à chaque compagnie d’assurance – et d’obtenir une comparaison de prix utilisable. Pour le partenaire commercial, la valeur ajoutée est l’acquisition d’énormes volumes d’acheteurs potentiels déjà qualifiés.

Dimitri et moi-même commençons à discuter du client de l’entreprise : est-ce que ce sont les entreprises partenaires qui paient LesFurets.com pour chaque nouveau contrat signé sur leur site Web ? Si oui, quel est le statut de l’utilisateur du site ? L’utilisateur final n’est-il qu’une « matière » en train de subir un processus de transformation à travers LesFurets.com ? Le site Web ressemble-t-il à une chaîne de production livrant un produit fini à la compagnie d’assurance sélectionnée – sous la forme d’un acheteur prêt à signer ? Le concept est intéressant, mais le risque ici est de passer à côté de l’essentiel : si LesFurets.com projette de devenir LA place de marché des services en ligne, cela signifie que les clients ciblés sont les utilisateurs réels du site Web. Comme dans un supermarché, LesFurets.com attire des prospects dans son magasin, leur propose des produits parmi lesquels choisir et aide les acheteurs potentiels à en choisir un. Contrairement aux supermarchés, cependant, ils ne collectent pas l’argent, mais orientent les acheteurs potentiels vers le producteur réel, moyennant des frais. Mais cela ne signifie pas que le client réel est le payeur. Du point de vue du Lean, nous considérons les utilisateurs comme les principaux clients. Les compagnies d’assurance et les autres fournisseurs de services publics sont des partenaires commerciaux et non des clients.

Ce qui est clair dans l’esprit de Dimitri, c’est que LesFurets.com doit comprendre, à chaque étape du processus de transformation, ce que “bon du premier coup” et “bonne qualité” signifient pour l’utilisateur.

Avec la croissance de l’entreprise LesFurets.com, des silos de compétences ont commencé à émerger. Cela a peu à peu éloigné les développeurs des clients. Les requêtes et les plaintes des utilisateurs sont généralement gérées par le marketing et ne sont transmises aux développeurs que lorsqu’un utilisateur prend le temps d’expliquer une référence de véhicule manquante ou de décrire un bug. Par conséquent, il est essentiel pour les développeurs de prendre la main sur le forum de discussion à tour de rôle pour comprendre ce qui préoccupe les clients. En aidant les clients et en répondant à leurs questions, les développeurs peuvent voir ce qui ne fonctionne pas dans la façon dont le site Web est utilisé et le réparer.

Par exemple, le temps de réponse du site une fois que les utilisateurs ont rempli le formulaire en ligne avec leurs spécificités : au lieu d’une approche séquentielle stricte – «répondez d’abord à toutes les questions, nous nous vous connecterons ensuite aux partenaires» – la cartographie des différents partenaires Web est activée pour la comparaison de prix dès que les données clés sont saisies. Cela permet à l’utilisateur de compléter ensuite le formulaire avec d’autres données non nécessaires au traitement du prix. Au moment où l’utilisateur a rempli le formulaire avec les données clés, les prix traités sont disponibles et le temps de réponse n’est plus perçu comme étant trop long.

Comment le savoir est-il créé ?

Comme indiqué dans le graphique ci-dessus, le site Web est disponible à 99,99 % (un élément clé pour attirer et fidéliser les utilisateurs). Une à trois nouvelles versions sont mises en production chaque jour, via un processus DevOps (création automatisée et tests unitaires de nouvelles fonctionnalités mises en œuvre par les développeurs, tests d’intégration et déploiement automatisés). Lorsqu’ils sont conçus de manière robuste et que leur utilisation est maîtrisée, les outils numériques sont magiques : ils peuvent produire un flux pièce à pièce sans se soucier de SMED. La supervision est également un aspect clé du travail, bien que plus traditionnel en informatique, avec un contrôle permanent de la disponibilité du site et du temps de réponse, mais également des bases de données et de l’architecture informatique elle-même.

« Je considère les livraisons DevOps quotidiennes comme une espèce de zone de préparation des camions en expédition », déclare Dimitri. « Elles sont une occasion de vérifier que tout ce que nous avons fourni pour cette livraison informatique est impeccable. »
LesFurets.com, dirigé par Dimitri, est passé d’une livraison informatique par mois, à une par semaine, et maintenant à au moins une par jour. Cela a clairement lissé le travail des équipes de production, réduit le temps nécessaire pour fournir de la valeur ajoutée au site Web et incité les équipes à penser en termes de petits lots autonomes au lieu de larges versions regroupant tout. C’était un changement de paradigme complet : tout le monde était d’accord sur le fait que les bugs devaient être corrigés immédiatement, mais les nouvelles fonctionnalités étaient perçues comme « pouvant attendre ». Dimitri a réussi à embarquer toutes les équipes sur des livraisons informatiques quotidiennes en démontrant que la valeur ajoutée non livrée était un gaspillage et qu’elle entraînait des coûts.

Ce qui m’intéresse le plus, dans cette discussion Lean et agile, c’est la convivialité et l’efficacité du site lui-même. Comment améliorer en permanence l’offre dans un monde en mutation rapide ? Et qu’avez-vous besoin d’apprendre pour y arriver ?

Je commence une longue conversation avec Dimitri à ce sujet, juste devant le tableau montrant les améliorations et les nouvelles fonctionnalités en cours de développement pour le site Web. « Nous utilisions initialement Scrum et déplacions nos cartes de développement d’une colonne à l’autre (demande -> analyse -> développement -> version). Mais il s’agissait d’un flux poussé et la plupart des discussions finissaient par être axées sur l’effort ou le coût du développement. »
En effet, chaque carte détaille le développement attendu et les efforts nécessaires (classés de XS à XL, comme dans les tailles de vêtements). Le problème, comme le voit maintenant Dimitri, est que leur approche Scrum s’appuyait sur des gros lots (sprints), mixant fonctionnalités majeures et petites améliorations : les tâches les plus légères devaient attendre pour être mises en production que les tâches complexes soient prêtes, et ces dernières peinaient à sortir dans le sprint.
«Avec le Lean et le flux tiré, nous avons beaucoup réfléchi à la question et nous avons fini par changer notre approche», me dit Dimitri. Lui et son équipe ont commencé à employer le Kanban (enfin, ce que l’agile appelle kanban) : des idées d’améliorations du site s’empilaient en provenance du Marketing et de la gestion du site web, mais elles étaient développées sous forme de mini-projets (dans l’informatique traditionnelle, les projets contiennent un grand nombre de fonctionnalités majeures fournies dans une seule version). A présent, ces fonctionnalités sont réparties en lots autonomes (réduction de la taille du lot), la valeur attendue pour l’utilisateur étant ajoutée à la carte de développement (encore une fois, évaluée de XS à XL).

«En fait, l’expérience nous a appris que plus la taille du lot est petite, plus nous pouvons obtenir l’amélioration en ligne rapidement. Mais nous étions toujours plus agiles que Lean, car nous estimions que notre travail était terminé dès qu’il était correctement livré. Nous avons donc ajouté une colonne – Analyse en Live – pour vérifier si le changement produisait l’effet escompté », explique Dimitri.

Les discussions peuvent désormais se concentrer sur la valeur et les priorités (un effort XS offrant de la valeur XL devrait être la première des priorités) et l’Analyse en Live aide les développeurs à vérifier l’efficacité d’une idée ou l’efficacité et la qualité du code.

Cependant, en regardant ensemble le tableau, Dimitri et moi pouvions toujours repérer certains éléments Lean essentiels manquant à l’approche :
• Les cartes kanban déjà analysées mais non encore développées s’entassaient dans la colonne Analyse, bien au-delà de la capacité de développement immédiate (signe évident d’un flux poussé).
• Il n’était pas possible au premier abord de repérer ce qui était en retard ou ce qui ne l’était pas. Les cartes ne portaient aucune indication de dates ou de cibles. Nous nous attendions à voir les progrès réalisés par rapport au takt time (ou au moins, en mode Agile, par le biais d’un burndown chart).
• Il y a une intention claire derrière le fait de déplacer des cartes kanban en papier sur un tableau blanc au XXIe siècle, au lieu de suivre les tâches dans un système informatique (ce qu’elles font de toute façon sur JIRA – un outil d’attribution de tâches) : et c’est d’ouvrir un espace de réflexion collaborative et de kaizen (que devons-nous apprendre pour surmonter ce problème ?). Si les éléments susmentionnés ne sont pas visibles, les développeurs risquent de ne pas voir l’importance du tableau par rapport à JIRA et de s’en tenir à leurs outils de collaboration en ligne, où ils peuvent facilement déplacer les cartes d’activité d’une étape à l’autre jusqu’à leur achèvement.

L’Agile est trop souvent perçu comme un processus ritualisé pour construire de manière fluide et efficace, mais ce qui a été perdu avec le temps, c’est la pratique régulière de la résolution de problèmes, étape par étape, et du kaizen, afin de développer la collaboration mais également les compétences métier. Comment partager cela ?

Prendre le temps, flexibilité et jidoka

Nous décidons de passer à une autre activité clé pour la crédibilité du site web – l’intégration et le suivi de nouveaux partenaires.

Ici encore, les cartes kanban permettent de suivre les tâches et de parcourir les étapes séquentielles du processus, telles que les spécifications, les formules et les exceptions, les correspondances de prix, etc.
Mais Dimitri a conservé deux plans du même tableau au fil des mois et il est intéressant de voir comment il a évolué.
La première photo montre une ligne pour chaque développeur, poussant les tâches étape par étape : ce type de gestion visuelle est axée sur les ressources (charge de travail, affectation des tâches) et les processus. C’est véritablement une fabrication à la commande en flux poussé.

Au fil du temps, quatre changements (Lean) majeurs ont été apportés au tableau :

1. Comme dans le tableau heijunka d’une usine, les lignes se concentrent maintenant sur les produits à livrer plutôt que sur les ressources, et le délai de livraison prévu est indiqué à chaque étape. Les temps cibles n’étaient pas présents dans la version initiale du tableau.
2. La notion de bon du premier coup est introduite, notamment sur la qualité des données collectées en amont avec le partenaire (à gauche).
3. Une livraison d’un produit fini par semaine est calculée à droite. La collaboration est le seul moyen de s’assurer que ce délai est respecté.
4. Tout problème empêchant de respecter le takt time est mis en évidence et commenté.

En observant les deux versions du tableau, je peux voir les principales différences dans l’approche. Tout d’abord, l’accent est mis sur la régularité de l’effort (lissage) et sur le respect du rythme client (takt time), et non sur les processus internes et l’utilisation des ressources. Ainsi, si un produit fini ne peut pas être livré cette semaine et ne peut donc pas être retiré du tableau pour déclencher un «réapprovisionnement» (un nouveau partenaire à intégrer), il reste visible pour tout le monde. Cela montre que le problème doit être résolu.

Deuxièmement, un tableau heijunka affiche également le but ultime du Lean: la capacité à livrer un mix de produits (tâches), à tout moment, puisqu’un peu de tout est produit tout le temps. Pour LesFurets.com, cela nécessite de l’agilité pour passer d’un partenaire à un autre, d’une étape à une autre, si l’on est bloqué avec des données manquantes ou si une action du partenaire est en attente.

Pendant que nous discutons de cette question, Dimitri et moi-même pouvons voir d’autres pistes d’amélioration: avons-nous la bonne taille de lots (produits livrables) ? Dimitri confirme avoir identifié 50 actions différentes qu’un développeur doit maîtriser pour intégrer correctement un nouveau partenaire.

Et sommes-nous certains de produire un peu de tout chaque jour?

Et comment suivons-nous le temps de production par rapport aux attentes utilisateurs et aux progrès de nos concurrents ? Dimitri a quelques chiffres en tête : « Aujourd’hui, il faut six mois pour intégrer un partenaire en assurance. Au cours de ces six mois, le développement prend vraiment un mois. Et le vrai temps d’exécution au cours de ce mois ne représente que 10 jours ouvrables». Cela signifie-t-il que le temps de développement n’est pas vraiment un problème par rapport aux longs échanges contractuels ou à l’obtention des bonnes données d’entrée ? Peut-être, mais que se passerait-il si 10 jours de travail pouvaient être transformés en 1 jour de travail bon du premier coup? Cela n’attirerait-il pas davantage de partenaires potentiels et n’élargirait-il pas l’offre aux utilisateurs, rendant ainsi le site plus attrayant ?

D’autres questions sont soulevées : que signifie «faire les choses correctement» pour chacune de ces tâches ? Quelle est la compétence clé requise ici lorsque nous mappons les champs de données du partenaire avec ceux du site Web LesFurets.com ? Comment pouvons-nous apprendre des erreurs de livraison? Comment partageons-nous ce que nous apprenons ? Je peux voir quelques tentatives de Kaizen pour y remédier, mais elles ne font que commencer.

Nous passons enfin à l’équipe qui supervise l’activité avec les partenaires existants. Une nouvelle question se pose ici, lorsque nous regardons l’affichage qui suit la production des services Web de chaque partenaire : si le traitement des services Web d’un partenaire rencontre des problèmes, tirons-nous l’andon? Si un ou plusieurs partenaires clés pour la comparaison de prix ne sont pas disponibles, interrompons-nous la ligne et / ou alertons-nous l’utilisateur ? À quoi ressemble le jidoka dans cet environnement?

Mon Gemba avec Dimitri se terminant, nous esquissons rapidement toutes les questions complexes soulevées dans cet environnement agile, à partir du Toyota Production System.

Il reste encore de nombreuses questions en suspens ici, alors que certaines ont déjà été abordées de front – telles que l’introduction du takt time clients et les petits lots. LesFurets.com connaît une croissance rapide (croissance à deux chiffres au cours des cinq dernières années) et s’étend à de nouveaux marchés, et il est clair pour moi que cela n’aurait pas été possible sans affronter des vérités dérangeantes et changer la mentalité de l’entreprise sur la façon dont marchent les choses. Mais le Lean offre clairement des opportunités d’amélioration encore à découvrir.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s