Lors de la conférence Enterprise 2.0 de Boston en 2011 (la transformation numérique s’appelait encore Entreprise 2.0 à cette lointaine époque), j’ai eu la chance de rencontrer l’excellente Rachel Happe. Lassée de la vie corporate, la brillante Rachel a décidé de lancer et d’animer la Community Roundtable, une engeance qui a pour vocation d’offrir un espace de réflexion et de partage aux Community Managers, et de proposer un modèle de suivi de la maturité des organisations sur ce sujet.
Lors d’une de nos discussions sur la conduite du changement, elle m’expliqua de sa voix particulière, chantante et brisée, ponctuée de ses rires à la tonalité grave mais à la joie communicative, que ce qu’elle cherchait dans une équipe était ces fameux “aha moments”. Ces moments magiques de révélation durant lesquels les personnes ont une épiphanie qui leur fait d’un seul coup changer de perspective sur un sujet, comprendre l’utilité de telle ou telle approche ou encore le nature impérative d’un changement.
Il existe dans le lean une pratique quotidienne qui permet de provoquer volontairement ces moments de révélation, ces épiphanies. Un outil redoutable dans une conduite du changement qui ne dit jamais son nom ni ne s’embarrasse de concepts compliqués.
Il s’agit du Gemba, la pratique qui consiste à aller sur le terrain, là où la valeur est créée, pour confronter ses croyances à la réalité des faits. Une pratique qui n’a de cesse de m’émerveiller et voici pourquoi …
Cautériser les fausses croyances
Lors d’une masterlass sur le sujet du coaching, Régis Médina est revenu sur l’intuition première de Taiichi Ohno : apprendre c’est surtout challenger en permanence nos croyances ; la méthode scientifique (déclinée sous la forme du PDCA dans le monde du business) est la voie. L’outil que Ohno n’a eu de cesse de mettre en avant pour éliminer les fausses croyances c’est de soumettre celles-ci à la réalité indocile. Pour cela on doit emmener tout le monde sur le Gemba, c’est à dire là où la valeur pour le client est créée.
Régis utilise l’image suivante : les fausses croyances sont des connexions neuronales que nous devons cautériser : et pour cela nous avons notre fer à souder chirurgical : amener les personnes voir les faits et les pièces. Exemple de fausses croyances sur lesquelles il est nécessaire d’opérer et les interventions terrain correspondantes :
- “Si tout le monde est occupé à 100%, on optimise l’efficacité des équipes” : on va voir le nombre de pièces sorties
- “Les équipes travaillent bien, c’est moi qui les ai choisies” : on va voir les problèmes de qualité et on en challenge les causes
- “Pour produire plus il faut plus de monde” : analyse des gaspillages
- “nos procédures sont connues et pratiquées par tous” : observations terrain des gens qui font, analyse des problèmes de qualité
- etc …
Mais tout cela est la théorie, passons à des exemples concrets …
Exemple 1 : voir les pièces
Contexte
Une équipe Intégration (développement IT d’interface Web) prend en entrée des maquettes soumises par l’équipe UI/UX (interface graphique et Expérience utilisateur) pour leur restituer les pages intégrées sur un site web.
Problème
Sur le projet précédent, l’équipe UI a remonté 33 anomalies sur la version livrée par l’équipe intégration. L’impact sur le projet : 10 jours pour la recette complète au lieu des 5 prévus. Un écart de 5 jours de délais : un superbe problème.
Causes
Nous sommes donc allés sur le Gemba avec la chef de projet et avons analysé chacune des 33 erreurs avec le développeur. Ce qu’il apparait de cette analyse sont les deux causes principales suivantes :
- 15 erreurs proviennent de problèmes de mise en page (des marges verticales et horizontales différentes, une croix de fermeture d’un bloc HTML mal positionné, des titres qui ne sont pas au bon format etc …). Constatant ces obstacles, on travaille avec les deux parties pour se mettre d’accord et clarifier le passage de bâton entre les deux métiers. L’UI rédige ainsi une checklist avec un certain nombre de critères qui permet au développeur de valider seul une livraison avant de la soumettre à l’UI.
- 9 erreurs proviennent de l’animation de quelques composants du site. Lorsque l’on creuse on voit que des animations ne sont pas assez “rapides” ou assez “fluides”. Ce qui a une signification pour le designer UX mais reste très vague pour le développeur.
Contre-mesures
Constatant ces obstacles, on travaille avec les deux parties pour se mettre d’accord et clarifier le passage de bâton entre les deux métiers. L’UI rédige ainsi une checklist avec un certain nombre de critères qui permet au développeur de valider seul une livraison avant de la soumettre à l’UI.
On se met aussi d’accord sur un standard de comportement pour les composants d’animation : un module accordéon doit s’ouvrir en 500 ms. La fluidité est garantie par un algorithme d’animation non linéaire (lent puis rapide puis lent – désolé je n’ai pas le nom ni les valeurs en tête) pour donner une impression de naturel et retirer la sensation robotique et heurtée d’une vitesse linéaire.
Résultats
Grâce à ce travail (qui a pris 2 heures à 3 personnes) l’équipe concernée a transformé la situation. Au départ celle-ci était confuse et conflictuelle, avec une interface entre les deux métiers saturée d’implicites, dans laquelle chacun reste sur ses positions. A l’arrivée, la situation est beaucoup plus claire et explicite : on connait les sujets à traiter, on travaille sur leurs causes et les solutions que, ensemble, l’équipe va mettre en place.
Résultat : nous avons réduit sur la livraison suivante le nombre d’anomalies de 33 à 14 et la durée du temps de recette à 10 à 5 jours. Sur ces 14 anomalies, 6 sont encore liées à des problèmes de mises en page et 2 à des problèmes d’animation. La checklist et le standard sont tous deux modifiés par l’équipe dans une session suivante. Une session dans laquelle chacun a le sourire, travaille de façon collaborative et se sent complètement acteur de l’amélioration. L’animation suivante ne comporte que 2 retours et ne prend que 1 heure à valider par l’équipe UX : la non qualité est réduite de 95% et le délai de 10 jours à une heure.
Voir l’amélioration est bien sûr une satisfaction. Mais constater le changement radical de la dynamique collaborative en est une autre, encore plus gratifiante.
Exemple 2 : voir le processus
Contexte
Nous sommes chez un acteur du numérique, sur le déploiement d’une l’application en ligne. Les équipes édito font une travail très poussé et très précis sur les différents textes de cette application. Les responsables pays ont en charge la traduction et mise en ligne pour les autres pays.
Problème
Deux obstacles sont identifiés au sein de cette équipe. Le premier est que les traductions sont souvent littérales et perdent l’intention initiale. Le second est que le temps de déploiement est trop long (un jour par pays, l’idéal serait une demi journée).
Observations
Avant de partir dans une grande solution générique décidée en salle de réunion, nous allons avec la chef de projet sur le terrain pour comprendre les difficultés de l’équipe. Nous observons deux responsables pays, une italienne, appelons la Ornella et une danoise, appelons la Nina.
Ornella va très vite. Elle dispose de deux écrans qu’elle utilise de façon optimale : un écran pour les données sources (un fichier excel) et un pour la destination (le CMS – Content Management System). Deux heures ont déjà été passées sur les deux premières phases de son processus : 1/la traduction et 2/la création des URLs (pour l’optimisation SEO). Elle peut se consacrer pleinement à la troisième, la mise à jour du CMS. Elle a 7 blocs (textes + photo) à créer. En 45 mns d’observation elle en crée 6, tous validés : elle nous montre comment elle valide sa mise à jour. Elle nous présente au passage quelques petits obstacles mineurs dans le fichier source que la chef de projet (qui réalise le brief, i.e l’entrant d’Ornella) ignorait complètement et note avidement pour la prochaine version. Nous notons la chef de projet et moi qu’il y a, parmi la trentaine de petits textes éditoriaux, 6 dans lesquels il y a une intention particulière, intention que la traduction en italien n’a pas du tout pris en compte. Bref : en 3 heures le travail est accompli, mais avec des pertes au niveau de la traduction, pertes que notre responsable pays n’a pas identifiées.
Nina la danoise n’a pas préparé les traductions ni les URLs. Elle ne sait pas du tout comment traduire les trente petits textes éditoriaux. Elle sait que ceux-ci sont parfois lestés d’intentions mais elle ne sait pas lesquels précisément. Du coup elle avance lentement faisant tour à tour traduction, création d’URLs et mise à jour du CMS, puis hésitant encore, revient à la traduction et donc à l’URL. Ce qui ne lui permet pas d’optimiser l’utilisation de ses deux écrans sur deux applications. Ce qui aussi lui met plusieurs problématiques en tête au même moment : traduction, création d’URL, mise à jour du CMS, vérification etc … Elle souffle beaucoup car ne sait pas comment traduire exactement les textes. Même ceux qui ne sont pas codés avec des intentions particulières. En 42 mns elle finalise 1 seul bloc et en démarre 3 autres qu’elle ne termine pas et sur lesquels elle reviendra plus tard, quand elle aura les idées plus claires sur les traductions.
Causes validées
En voyant cela, la chef de projet réalise plusieurs choses. La première est que sur les traductions, certaines responsables pays avancent lentement, comme en terrain miné. Elle comprend que pour le prochain projet elle devra pointer de manière très spécifique les textes “chargés” d’intention pour éviter que les responsables pays ne perdent du temps sur TOUS les textes. Elle doit aussi préciser ces intentions avec des analogies précises pour permettre aux responsables pays de trouver des traductions adéquates.
Contre-mesures
Elle demande à la responsable des éditos de venir présenter les animations pour expliquer 1/les textes sur lesquels prêter une attention particulières et 2/ leurs intentions. Elle va aussi corriger les petits obstacles remontés par Ornella.
Enfin, elle échange avec la responsable de l’équipe de déploiement international, et explique les obstacles rencontrés par Nina. Elles décident d’expérimenter le processus d’Ornella (1.Traduction 2. URL 3. CMS) sur l’ensemble de l’équipe pour éviter les écueils vécus par Nina alors qu’elle peinait en faisant les trois en même temps. La cible fixée par la responsable est claire : on doit pouvoir réaliser la prochaine animation en 3 heures par responsable pays. Soit pour 14 responsables : 14 x 3 =42 heures ce qui représente un total de 6 jours plutôt que 9 observés sur l’animation précédente. Si l’on dépasse, cela signifie qu’il reste des obstacles à éliminer : les responsables pays devront les remonter lors du prochain projet.
Résultats
Résultats sur l’animation suivante : 6,25 jours de charge au total (au lieu de 9) : une réduction de 30% du temps de réalisation. Mais surtout : des responsables pays qui ont retrouvé le sourire dans le travail grâce à cette expérimentation qui a été vécue comme “fun” et grâce à l’amélioration constatée : on ne compte plus autant de souffles de dépit.
Enseignements
Avec ce Gemba, cette observation sur le terrain, la chef de projet a pu dresser un constat factuel sur tous les obstacles qui empêchent cette équipe de réussir, obstacles qu’elle même peut aider de façon très significative à résoudre. L’objectif est bien sûr d’aider les responsables pays à faire les choses bien et plus vite. Mais surtout à le faire de façon fluide et avec le sourire car elles seront mises en situation de savoir qu’elles font un bon travail, à chaque étape.
God is in the house
Lors de chacune de ces deux expériences, le “dieu du Gemba” était avec nous comme le dit Régis. La réalité est apparue dans tout son inconfort. Mais l’équipe l’a affrontée et en a tiré des idées d’amélioration spécifiques, explicite et collégiales, destinées à résoudre des obstacles bien précis. Une approche vertueuse et éclairante qui, je me répète, n’a de cesse de m’émerveiller en ce qu’elle rend les obstacles actionnables par les équipes : le vrai empowerment si vous voulez mon avis.
Comment provoquez-vous les épiphanies, ces aha moments dans vos missions de conduite de changement ?
