Quotidien finance innovation, innovation financière journal
Financial Year with Finyear
 
 
 
 


              

Développer des gens avant de produire des pièces





Développer des gens avant de produire des pièces
"Développer des gens avant de produire des pièces" est l'un des préceptes fondamentaux du lean avec lequel il est bien entendu difficile d'être en désaccord. Toutefois, comme pour beaucoup de principes du lean, passer d'une compréhension théorique à une mise ne oeuvre pragmatique n'a rien d'aisé et implique souvent de remettre en cause des réflexes profondément ancrés.

Par exemple, lorsque l'on tente de mettre en oeuvre le lean dans de grandes structures (groupe industriel ou de services, administration, etc.), il paraît logique de définir un programme qui passe par :

* la définition d'un modèle de "chantier" (kaizen) adapté à la culture de l'entreprise et au type d'activité ;
* le rôdage de ce chantier sur une unité "pilote" ;
* un "déploiement" sur les autres unités ;
* l'accompagnement de cet ensemble par une démarche systématique de "formation au lean" (des managers, des opérateurs, des services support, etc.)

C'est d'ailleurs en les structurant de cette manière que la plupart des consultants vendent leurs programmes. Et cela paraît logique.

Ré-examinons ce programme à la lumière du précepte visant à "développer des gens". En premier lieu, qui développe-t-on en procédant de la sorte ? Le consultant qui le met en oeuvre, pour sûr, puisqu'il aura l'occasion de répéter des chantiers dans diverse structures et gagnera donc en expérience et en savoir-faire lean. Mais qu'en est-il des unités et du personnel de l'entreprise ? Les membres de l'unité pilote engrangent une dose de savoir-faire lean, mais se retrouvent bien vite abandonnés et doivent "pérenniser" par eux-mêmes les changements, tant bien que mal - et plutôt mal que bien, si l'on s'en réfère à l'expérience : le lean ne se maintient que par l'amélioration continue et par la visite régulière de "sensei" dans les unités. Quant aux autres unités, trop souvent, elles reçoivent un paquet bien formaté de "solutions-types", à l'élaboration desquelles elles n'ont même pas eu le privilège de participer, et qu'elles doivent appliquer sans prendre le temps de se les approprier et de comprendre en quoi elles contribuent à résoudre les problèmes qu'elles se posent.

Prenons au sérieux l'injonction "développer des gens avant de produire des pièces." Cela implique en premier lieu de développer en interne des experts lean. Plutôt qu'à des consultants, ce sera à eux de travailler avec les unités opérationnelles pour mettre en oeuvre le lean, de sorte que les connaissances acquises soient maintenues et développées au sein de l'organisation. Et quand ces "experts" internes vont travailler avec une unité, quel est leur interlocuteur ? Ou, pour reprendre les termes du "développement de personne", qui y sera développé ? Le responsable de l'unité ? Un correspondant fonctionnel ad hoc ? Et, en second lieu, une fois l'amélioration continue lancée dans l'unité, comment continuer à développer les personnes (responsable ou correspondant local) qui ont commencé à s'initier au lean ? Si les chantiers sont le lieu par excellence de la création de savoir et de sa transmission, rien n'est plus indiqué que de les impliquer fortement dans le déploiement à d'autres unités. La vision lean d'un programme de changement repose sur la construction d'une pyramide de gens formés les uns par les autres, et non pas sur un planning de "passages à la moulinette" des unités opérationnelles. La différence est considérable...

Pourquoi cette vision d'une chaîne d'apprentissage du lean, les premiers lancés et les plus rapides formant les suivants, qui eux-mêmes initient de nouvelles personnes, etc. est-elle contre-intuitive ? Pourquoi semble-t-elle si fragile ? Pourquoi les entreprises hésitent-elles tant à voir leurs programmes lean de cette manière-là ? L'une des difficultés de fond que nous avons à prendre à coeur les implications de "développer des gens avant de produire des pièces" tient à la vision traditionnelle de la localisation de la connaissance. Usuellement, on imagine que la "véritable" connaissance technique réside dans les bureaux des experts fonctionnels, les "ruches", les services informatiques, bref, dans des pôles de connaissance spécialisés dont on espère qu'ils sont les plus à même de se maintenir à la frontière de l'excellence (on pourrait d'ailleurs interroger les sous-bassements de cette foi dans l'excellence par la spécialisation, qui dérive de la vision de la division du travail proposée par Adam Smith dans un tout autre domaine et dont la transposition à des tâches créatives et fortement couplées au reste de l'entreprise ne va pas de soi). Les unités opérationelles (usines, comptoirs ou guichets) ne sont que des extensions mécaniques qui doivent appliquer les préceptes formulés par les détenteurs de cette connaissance ; les opérationnels sont traités par le mépris, et ne doivent surtout pas chercher à interpréter les directives des experts, car ils auraient toute chance de les dénaturer en les mésinterprétant. Les jambes courent quand la tête le décide, sans se poser de question...

Mettre en place le lean pour de bon implique de bousculer cette vision des choses. En effet, pour le praticien lean, la connaissance réside dans le fonctionnement même des processus de travail. Il n'y a pas de connaissance pertinente qui soit "désincarnée", hors des processus. Certes, les entreprises lean ont toujours besoin d'experts fonctionnels, et doivent naturellement animer ces experts pour les développer. Cependant, fondamentalement, la connaissance n'a de sens que lorsqu'elle est opérationnalisée en tant que résolution de problèmes concrets, sur le terrain. Formulé de manière générale, cela semble évident, mais les implications opérationnelles sont considérables.

En premier lieu, chaque unité a pour objectif de devenir un centre pointu d'expertise de ses propres process, et elle doit donc avoir la possibilité de faire appel à des experts qui lui soient externes (qu'ils soit centraux ou hors de l'entreprise) pour résoudre les problèmes spécifiques qu'elle rencontre.

En deuxième lieu, comment "développe-t-on" quelqu'un ? S'agit-il de le faire assister, dans une douillette salle de séminaire, à divers cours et conférences ? Voilà qui ne serait guère compatible avec l'esprit du gemba ! Dans le modèle lean, développer quelqu'un passe par lui faire résoudre des problèmes concrets et opérationnels qui se posent à l'entreprise ; le rôle du "sensei" est de choisir, parmi les problèmes qui se posent à l'entreprise et en fonction des progrès de la personne qu'il instruit, celui qui se prêtera le mieux à l'apprentissage.

En troisième lieu, les "outils lean" ne prennent leur sens que quand on les voit comme le support de méthodes permettant de développer les gens. Par exemple, en usine, le lean insiste sur la réaction rapide face aux problèmes (c'est une des dimensions du jidoka): on ne laisse pas un opérateur seul face à un problème, on ne laisse pas produire des mauvaises pièces, on ne laisse pas une machine arrêtée, etc. Même sans avoir de solution fondamentale immédiate sous la main, on trouve une contre-mesure immédiate. Est-ce par culte de la réactivité ? Pas vraiment : tous ceux qui en ont fait l'expérience vous le diront, cette attitude met soudainement une pression infernale sur les services supports (logistique, maintenance, ingénierie, méthodes, informatique, etc.) Ceux qui avaient l'habitude d'organiser leur travail à leur rythme sont désormais constamment "dérangés" par des appels au secours du terrain, et les listes d'actions à réaliser explosent. Bref, la réaction rapide sert à développer les services supports en leur fournissant un flux continu de problèmes opérationnels à résoudre.

Il y a là un message important pour les pilotes d'un programme de "mise en oeuvre du lean" : la mise en place d'un outil ne sert que si le "développement des gens" a effectivement lieu, c'est-à-dire si les problèmes qu'on leur soumet sont effectivement résolus. Le danger est que si la réalisation des actions se met à traîner parce que les services techniques sont saturés, superviseurs et opérateurs vont vite se lasser de signaler les problèmes, entamant la crédibilité de la démarche. Le problème est donc de générer un flux régulier de problèmes et de solutions, ce qui est le coeur de l'amélioration continue

Source : http://lean.enst.fr


Dimanche 22 Janvier 2006
Notez






Recevez la newsletter quotidienne


évènements


Lettres métiers


Livres Blancs