Cher Gemba coach,Par quelles étapes doit-on commencer la mise en place d’un pilotage visuel en développement? La première chose à faire est de discuter avec le chef du service développement produit en quoi le pilotage visuel va changer de manière radicale ses propres pratiques managériales, et de quelle manière. Cela signifie s’accorder sur le fait que :

• Les ingénieurs ont besoin de temps pour réfléchir à ce qu’est une bonne conception – ce qui signifie créer un espace visuel pour matérialiser les débats et ne pas rester esclave du workflow. Le management de l’ingénierie doit s’accorder sur la nécessité pour les ingénieurs de comprendre que résoudre localement une partie d’un problème de développement sans prendre en compte le produit dans sa globalité est contreproductif. Bien des managers en ingénierie prennent pour acquis que si le planning est tenu, et que les revues de jalons sont maintenues, alors le produit sortira bon et à temps, ce qui est juste un non-sens. Un produit réussi est avant tout celui que les clients aiment et veulent, et c’est le résultat d’une conception avisée et minutieuse par des ingénieurs de talent. C’est tout sauf un processus bureaucratique.
• Le travail d’équipe est essentiel à une conception réussie – le travail d’équipe, au sens de « résoudre des problèmes à travers les barrières fonctionnelles ». Les ingénieurs ont non seulement besoin d’un espace de réflexion, mais aussi d’un lieu où se réunir et partager des idées avec d’autres acteurs tels le marketing, le commerce, l’après-vente, la supply chain, la production. Le pilotage visuel est un moyen de montrer les problèmes afin que chacun puisse partager les contraintes des autres, dans le but de stimuler la créativité.

Par conséquent, chaque service d’ingénierie développe son propre pilotage visuel, dont les caractéristiques dépendent de sa courbe d’apprentissage et des problèmes qu’il va choisir de traiter ou de laisser de côté pour plus tard : le pilotage visuel dans sa globalité dépend du chemin choisi.

1. La première étape dans l’introduction du pilotage visuel en développement est donc de clarifier ce que l’on attend d’une telle approche : quels sont les gains escomptés ? Quelles performances doivent être améliorées ?
2. La deuxième étape est d’explorer, avec le responsable ingénierie, les différentes pratiques de pilotage visuel existant dans le domaine du Lean, afin qu’il puisse choisir laquelle expérimenter en premier
3. La troisième étape est de faire croître le pilotage visuel comme on le ferait pour un arbre, ou mieux, un jardin, et de continuer à challenger la manière dont il tient ses promesses, de sorte que le système de management visuel lui-même garde sa dynamique, continue de croître afin de soutenir les ingénieurs dans l’amélioration de leur réflexion pour concevoir des produits meilleurs.

Pour vous aider à démarrer, vous pouvez utiliser les outils de pilotage visuel suivants :

Le Mur

Le premier aspect du pilotage visuel que je mettrais en œuvre en développement serait donc un mur dédié aux clients et aux produits, montrant divers aspects du produit et divers usages qu’en font les clients, des diagrammes de performance, notamment une carte des complaintes, montrant tous les endroits dans le produit qui ne satisfont pas les exigences qualité des clients et dont ils se plaignent. Quand tout se déroule normalement, ce mur client favorise les discussions fondamentales et conceptuelles sur le produit, en particulier :

• Quels sont les standards du produit qui seront reconduits sur la prochaine génération?
• Quelles fonctionnalités doivent être modifiées pour traiter un problème qualité, améliorer une performance de base, et renforcer ce que les clients ne trouvent pas ailleurs ?

Parodier le Kanban

Le deuxième grand thème en ingénierie est le « juste-à-temps » (JAT). En ingénierie comme en production, les managers ont tendance à utiliser des workflows, grâce auxquels ils affichent leurs plannings sur les murs. Habituellement, la seule chose que cela apporte est de stresser certaines personnes qui apparaissent comme des « goulots d’étranglement » (et qui ne sont habituellement pas les ingénieurs les moins efficaces, mais ceux qui ont les problèmes les plus ardus). Méfiez-vous des faux kanbans qui proviennent des pratiques des agilistes du développement soft, et qui ne sont en fait que la représentation sous forme de post’its des étapes du process (tickets, tâches,…) qui s’accumulent en divers endroits du tableau visuel. Cela N’EST PAS du juste-à-temps, c’est juste la pensée ERP placardée sur un mur. En pratique, pour tenter de visualiser le JAT en ingénierie, nous commençons par:

• Un tableau de livraisons, qui montre la prévision de transfert en production de chaque projet (un cercle pour la prévision, un triangle pour un retard, un X pour un point abandonné). On demande ensuite aux ingénieurs de passer le tableau en revue chaque semaine, afin de s’assurer que la date prévisionnelle de transfert n’a pas dérivé. Ici, la difficulté réside dans le fait que les projets à problèmes prennent du retard par rapport à ceux qui n’en ont pas, et finalement ils doivent tous être mis en production en même temps. Une usine peut faire beaucoup de choses, mais pas supporter plusieurs démarrages simultanés en production. Mieux vaut donc surveiller cela de près.
• Un tableau kanban par personne, afin de s’assurer que les ingénieurs ne sont pas coulés par leurs tâches et de garder la gestion des priorités ailleurs qu’à leur poste de travail. Les ingénieurs doivent pouvoir se concentrer sur leur travail, et ne pas papillonner d’un fichier à l’autre. En mettant en place un kanban simple, vous pouvez visualiser en temps réel ce sur quoi les ingénieurs travaillent et garder une file d’attente gérable au lieu de surcharger quiconque avec un en-cours trop important.

Arrêt au premier défaut

Le Jidoka, ou « arrêt au premier défaut », est dans une certaine mesure plus complexe à mettre en œuvre, et là encore le pilotage visuel peut aider, quoiqu’imparfaitement. Le principal problème auquel j’aie été confronté quand j’ai voulu le mettre en œuvre n’était pas tant que les ingénieurs n’appelaient pas quand ils avaient un problème, mais qu’ils détectaient les problèmes trop tard. Pour compenser ce défaut, il faut afficher clairement l’architecture du produit et avoir des discussions régulières sur les interactions entre les différentes fonctions. La communication se fait en général en décrivant les problèmes typiques sur une feuille affichée au format A3. Le but est de dire aux ingénieurs : « quand vous observez cette configuration (comme un alignement de planètes), arrêtez-vous et prévenez votre manager, car l’ignorer peut causer des problèmes plus tard » Pour l’instant, je n’ai jamais trouvé de soft qui révèle automatiquement ce genre de problèmes et je ne sais pas si Toyota a développé des solutions astucieuses pour rendre le travail des ingénieurs plus facile. Par conséquent, utilisez la manière traditionnelle de présenter les problèmes réels ou potentiels quand ils surviennent et assurez-vous que tout le monde est au courant des interconnexions entre les fonctions du produit et des problèmes de fabrication qui doivent être pris en compte très tôt dans le cycle de développement.

Standards de production

Le quatrième thème au cœur du succès du Lean en ingénierie est la notion de standard. Si on regarde globalement, on se rend compte que l’avantage compétitif de Toyota est dans une large mesure bâti sur une stratégie d’étendre sa gamme de produits (produits, pas options) sans créer de nouvelles unités de production. En d’autres termes, Toyota est capable d’introduire un nouveau produit de niche très risqué sans devoir prendre le risque financier d’une nouvelle usine, car il sait l’assembler sur des lignes de productions existantes. On peut imaginer que cela nécessite un minimum de savoir-faire d’ingénierie… Par conséquent, une quatrième zone de pilotage visuel doit être dédiée à la ligne de production sur laquelle vous avez l’intention d’introduire le produit, et aux standards qui doivent être respectés (tels la séquence d’assemblage, les sous-ensembles, …) pour que cela se passe bien. Ceci est très difficile pour la plupart des équipes d’ingénierie, qui ont tendance à penser en termes de développement produit, puis d’industrialisation, puis de production, puis de supply chain. Cependant, créer un espace de partage pour que ces discussions aient lieu dès le début et tout au long du projet procure un avantage considérable à l’entreprise dans sa globalité. Ces standards seront ensuite le miroir des standards que les ingénieurs conservent dans leurs cahiers ou leurs checklists, et qui constituent leur base de connaissances personnelles. Traduit de l’américain par François Lopez Source : http://www.lean.org/balle/DisplayObject.cfm?o=3118

Cet article Pilotage visuel en Développement ? est apparu en premier sur Institut Lean France.