Au fond, que souhaite l’entreprise apprenante ? Sans aucun doute, à concevoir, produire et délivrer de plus en plus vite, au meilleur coût, des produits qui enchantent leurs clients sur la durée. Et cela, dans un contexte éthique et responsable dont la société définit le cadre.

L’ambition est élevée.

Cet article s’intéresse à la réalisation des produits et services et non à leur conception. Dans ce domaine, le lean propose une approche originale et redoutable dont voici les mécanismes :

Définir ce que l’on doit savoir

« Négliger le savoir accumulé jusqu’ici n’est pas la marque d’un esprit d’innovation : c’est un gâchis de talent.” Régis Médina, Institut Lean France

Ce que propose le lean n’est pas la création d’une somme immense de savoirs sur des sujets généraux mais bien au contraire, la création de savoirs sur des sujets spécifiques, propres à ce que l’entreprise ne sait pas bien faire à l’instant présent. Pour sélectionner les sujets d’apprentissage, les entreprises lean s’organisent autour du standard et des écarts au standard.

Le mot « standard » fâche facilement le lecteur et pourtant… Le standard représente, à un moment donné, des aspects variés de l’entreprise :

• la description précise du produit à construire ;
• la meilleure pratique d’une personne ou d’une équipe ;
• la performance opérationnelle d’une équipe.

Le standard est le point de référence, atteint (« ce que nous savons faire ») ou à atteindre (« ce que nous devons apprendre »).

Voici quelques exemples issus du monde des services et de l’informatique dans lesquels j’exerce :

Le standard	L’écart au standard
Traiter tous les virements interbancaires manuels en moins de 24 heures	23 % des virements sont en retard
Rembourser 80 % des frais de déplacement des collaborateurs dans la paye du mois	47 % des frais sont remboursés plus tard
Mettre à disposition un poste de travail informatique opérationnel le jour de l’arrivée	Les postes sont livrés en moyenne 4 jours après l’arrivée du collaborateur
Livrer des évolutions informatiques sans régression	37 % des livraisons ont au moins une régression
Etc…

Découvrir ce qu’il faut apprendre

Nous voici donc confronté à notre écart au standard. Tel qu’il est présenté, il est bien trop générique pour identifier où doit porter l’amélioration.

Dans le cas de la mise à disposition des postes informatiques, le retard peut provenir d’endroits très variés :

• RH : a-t-elle fourni les informations sur le salarié et sa date d’arrivée ?
• Management : a-t-il précisé à quels services informatiques devait accéder le salarié ?
• Immobilier : a-t-il défini à quel poste ou dans quelle zone sera accueilli le salarié ?
• Support informatique de proximité : est-il disponible pour ouvrir l’accès à l’ensemble des ressources locales ?
• Transport : le poste va-t-il être livré au bon moment sur le bon site ?
• Poste de travail : installation de l’environnement, de la politique de sécurité, des services et des applications sur le portable
• Etc…

Dire que le processus de mise à disposition des postes de travail est trop lent ne donne aucune information sur l’endroit où il fonctionne mal. C’est ici qu’interviennent le flux tiré et le jidoka :

• le flux tiré va mettre les différents contributeurs en situation d’agir de façon coordonnée, sans attente, avec fluidité, entre eux ;
• si l’une des étapes dysfonctionne, la personne qui y travaille s’en rend compte immédiatement ;
• elle déclenche l’alerte grâce au jidoka.

C’est ainsi que les collaborateurs définissent de façon dynamique le contour de ce qu’ils doivent apprendre.

Construire le savoir

Le moteur de cet apprentissage est le PDCA, méthode structurée de résolution de problème. Le A du PDCA représente le savoir accumulé :

• A pour Adopte : je sais comment faire
• A pour Abandonne : je sais que cela ne marche pas

De façon intermédiaire, il existe un A pour Adapte : là, je sais que je n’ai pas encore compris ce qui se passe ou comment l’adresser et je vais devoir chercher de nouvelles pistes.

Prenons l’exemple de l’équipe de développeurs qui constate qu’elle livre des régressions[1] dans son code. Que va-t-elle pouvoir apprendre ?

• Si les régressions sont découvertes par les utilisateurs, l’équipe approfondira ses connaissances en stratégie, conception et exécution des tests.
• Si les tests mettent en évidence des régressions, elle pourra par exemple observer sa gestion des branches (l’endroit où l’on dépose du code nouveau qui fera évoluer un logiciel existant). Si celle-ci a des imperfections, l’équipe approfondira sa compréhension de ce sujet complexe jusqu’à le maîtriser.
• Elle pourra aussi s’apercevoir de certaines erreurs de conception logicielle car elle connait finalement assez mal le patrimoine applicatif sur lequel elle travaille et qu’il va falloir le cartographier.

Au fil du temps, les membres de l’équipe auront ainsi accumulé du savoir sur des aspects propres à leur domaine d’expertise (les tests, les branches, la conception logicielle) mais aussi au domaine de l’entreprise dans laquelle ils évoluent (le produit qu’ils développent).

Les 3 bénéfices de cette approche :

1. l’entreprise s’évite les formations sur les sujets que les gens connaissent déjà ou qui ne sont pas en lien avec les sujets rencontrés ;
2. les sujets rencontrés sont traités, au fur et à mesure qu’ils sont identifiés ;
3. trouver les bonnes réponses est un véritable plaisir pour ceux qui participent à la recherche !

A l’heure où la guerre des talents fait rage, proposer des activités aussi satisfaisantes que celles-ci aura bien plus d’impact sur l’attractivité de l’entreprise qu’un baby foot 😊

Diffuser le savoir

Le savoir se diffuse, dans le monde lean, de trois façons :

La plus traditionnelle : le standard évolue, pour intégrer les avancées de la connaissance, et les personnes sont formées à cette nouvelle meilleure façon de travailler.

Standardiser est une bonne approche lorsqu’on est absolument certain d’avoir identifié une famille de problèmes fréquents et répétables à laquelle il est possible de répondre de façon commune.

La plus porteuse de réflexion : le savoir est présenté sous forme de problème résolu.

Plan : J’étais confronté à telle situation, j’en ai trouvé les causes

Do et j’ai expérimenté pour faire disparaitre ces causes

Check : j’ai vérifié l’apport de chacune expérimentation

Act : voilà ce que j’adopte et ce que j’abandonne ;

Celle-ci s’appelle yokoten. Elle présente un avantage certain : ne pas transformer une solution locale en solution globale.

Un exemple : un ensemble de concessions automobiles s’engage à proposer un moyen de déplacement alternatif lorsqu’un client dépose sa voiture pour une révision. Les 4 concessions parisiennes construisent un panel de propositions dont les clients se déclarent réellement satisfaits (>95 %). 2 fois sur 3, ils choisissent un accès illimité au métro et au RER pendant une journée. Il peut être intéressant de partager ces conclusions dans le cadre du yokoten et inefficace d’en faire un standard pour le reste de la France.

La moins directive : la transmission de savoir est réduite à un challenge. L’émetteur de la question partage une partie de son savoir : ce sujet là est clé pour les clients et l’entreprise. Il structure alors la recherche d’innovations internes sur un domaine bien précis.

[1] Une régression correspond au problème suivant : la fonctionnalité marchait comme prévu dans la version précédente mais a disparu, est dégradée ou est moins performante dans la nouvelle version.