Comment gaspille-t-on l'énergie et l'intelligence de nos équipes ?

Par Xavier Perrin (xperrin@xp-consulting.fr)

Dans la plupart des ouvrages récents consacrés au lean, on ajoute un 8ème gaspillage (muda) aux "7 gaspillages suivant Toyota". En effet, à côté de la surproduction, des temps d'attente, des stocks inutiles, des corrections, des déplacements inutiles, des transports et des procédés de fabrication, on cite "l'intelligence inexploitée" des employés. On pense alors aux cols bleus, cantonnés aux seules activités de fabrication, et dont on oublie de solliciter les idées et propositions. Dans ce schéma traditionnel, penser est d'abord la mission des cols blancs. Même si beaucoup reste à faire en la matière, cette vision rétrograde tend heureusement à disparaître. Les cercles de qualité, les chantiers kaizen, les réunions quotidiennes au poste travail et autres QRQC(1) ou AIC(2) sont autant d'opportunités pour chacun d'exprimer ses idées pour résoudre les problèmes et améliorer la performance.

Cependant, le fait de donner la parole, de faire participer, d'impliquer, et même de "challenger" les employés ne signifie pas qu'on fait le meilleur usage de leur intelligence. J'observe même trop souvent que toute cette énergie créatrice est gaspillée au cours de séances de travail aussi inefficaces qu'inutiles. Et je ne parle pas ici de l'inefficacité due aux réunions mal conduites : le problème est facile à identifier et on trouve une offre pléthorique de formations et coaching pour corriger ce défaut (certes, il y a encore beaucoup à faire dans certaines entreprises !). Je veux parler des heures de travail et de discussions perdues faute de donner aux employés une vision suffisamment claire de ce qu'on attend d'eux. Je vais illustrer mon propos avec deux situations rencontrées récemment dans deux entreprises industrielles.

Dans la première de ces entreprises, on observe une prolifération d'applications informatiques – des feuilles de calcul la plupart du temps – adossées à un ERP. Dans cette situation, l'ERP sert de base de données et chaque fonction extrait les informations qui l'intéresse et les traite avec son application ou tableur favori. Parfois même les données sont gérées indépendamment de la base de données de l'ERP, sans qu'on puisse en garantir la cohérence et l'intégrité. La direction est consciente du problème et aimerait bien que l'ERP soit utilisé comme tel (un système intégré) et qu'on élimine les applications "satellites". Un groupe de travail est donc constitué avec pour mission de cartographier les applications utilisées et d'étudier la possibilité d'utiliser prioritairement les modules de l'ERP, voire, si ça n'est pas possible, de définir comment ces applications devraient être interfacées à l'ERP.

La phase de cartographie est généralement bien menée et le groupe de travail est efficace : il y a peu de désaccords quand il s'agit simplement de recenser et décrire ce qui existe. C'est quand on aborde la question de l'utilisation des fonctionnalités de l'ERP que les choses se compliquent. On observe alors l'émergence de deux camps : d'un côté les tenants de la vision "tout ERP" – ce sont généralement les représentants des fonctions transversales comme le supply chain management – et de l'autre côté les défenseurs des applications métiers, bien plus performantes à leurs yeux que les solutions proposées par l'ERP. Ces différences de vues se traduisent par des réunions houleuses et peu productives. Lorsque le groupe de travail présente ses conclusions à la direction, c'est pour demander son arbitrage entre les visions de chacun des deux camps. Comme l'écrivait très bien ce génial penseur industriel qu'était Auguste Detœuf (1883-1947)(3) "J’ai souvent vu des techniciens avoir des avis contraires, je n’en ai jamais vu avoir tort." On imagine la perplexité de nos directeurs, bien embarrassés par ces conclusions… Pour y voir plus clair, ils demandent au groupe de travail d'approfondir ses analyses. On peut facilement présager de l'efficacité des réunions à venir…

Dans le second exemple, un groupe de travail a pour mission de réduire le temps de passage et les encours d'un atelier. On déroule la démarche habituelle qui consiste d'abord à identifier les flux de l'atelier afin de pouvoir ensuite les cartographier (VSM)(4). Le groupe de travail identifie 7 flux, ce qui révèle une complexité peu favorable à la logique de "mise en ligne". Cependant, des idées sont proposées qui permettraient de réduire les 7 flux à 3 flux seulement. Un plan d'actions est donc construit et des pilotes sont nommés pour explorer les solutions proposées. Lors de la réunion suivante, chaque pilote expose le résultat de ses investigations. L'un d'entre eux nous explique alors que la solution proposée n'est finalement pas réalisable car les surcoûts qu'elle implique sont prohibitifs. Le débat est lancé et chacun y va de son point de vue et de ses arguments pour défendre ou combattre la solution. A la fin de la réunion, la question n'est pas tranchée… en définitive, le groupe n'apporte pas de solution, et les 7 flux sont toujours là, et on est tenté de conclure qu'on ne pourra pas aller plus loin…

Dans les deux exemples, on voit que l'énergie et la bonne volonté des groupes de travail n'ont finalement pas permis de progresser. Ils n'ont rien créé, ils n'ont pas inventé les solutions qu'on espérait. Et pourtant, chacun a fait preuve de bonne volonté et défendu son point de vue en toute bonne foi.

Pourquoi un tel gaspillage d'intelligence ?

La cause d'un tel gaspillage est la formulation du problème par les managers. Dans le premier cas, si la direction est convaincue de l'intérêt de l'intégration de tous les processus dans l'ERP, elle ne doit pas missionner un groupe de travail pour étudier la faisabilité d'une telle solution. Elle doit d'abord formuler clairement sa vision en des termes tels que "Notre vision est que d'ici trois ans, tous les processus seront intégrés dans notre ERP". La mission du groupe de travail est alors d'identifier tous les obstacles à la mise en œuvre de cette vision et de concevoir les solutions qui permettront de les lever. Le débat entre les pros et les antis n'a plus lieu d'être. Il ne s'agit plus de démontrer pourquoi il vaut mieux garder une application métier. Il s'agit d'inventer, étudier et proposer les solutions et conditions qui permettront à terme de travailler avec l'ERP.

Dans le cas de la seconde entreprise, en posant le problème ainsi : "Notre vision est d'avoir 3 flux au maximum pour organiser des flux continus sans files d'attentes", la mission du groupe de travail devient claire : identifier les obstacles à cette vision, et imaginer les solutions qui permettent de les lever et les conditions requises pour y arriver. L'énergie et l'intelligence du groupe de travail pourra se focaliser sur les bons sujets. Quand le groupe rencontrera la direction pour présenter ses conclusions, ce ne sera pas pour dire que ce n'est pas possible. Il permettra à la direction d'exercer sa vraie mission : décider d'allouer les ressources nécessaires pour mettre en œuvre les solutions proposées par le groupe de travail, ou, le cas échéant, de différer les dites solutions si l'entreprise ne dispose pas de ces ressources

En conclusion, il est facile de gaspiller l'énergie et l'intelligence de nos équipes. Mais il est tout aussi facile de créer les conditions nécessaires pour libérer cette énergie et cette intelligence : il suffit de savoir ce qu'on veut et de le demander clairement ! Quoique… savoir ce qu'on veut ne semble pas si facile visiblement. Mais c'est une autre histoire !

A ce propos, Je recommande vivement la lecture de "Toyota Kata" (5) , de Mike Rother, qui développe très clairement l'approche de Toyota pour tirer le meilleur parti de l'énergie créatrice de ses employés.

___________________________________________

(1) Quick Response Quality Control

(2) Animation à Intervalles Courts

(3) Propos d’O.L. Barenton, confiseur, Paris, Éditions du Tambourinaire, 1948

(4) Value-Stream-Mapping

(5) Toyota Kata: Managing People For Improvement, Adaptiveness, and Superior Results, Mike Rother, Mc Ggraw Hill, 2010