Management des savoirs / Knowledge management

Depuis longtemps les entreprises se sont penchées sur la question de la gestion des connaissances / management des savoirs (en anglais Knowledge management, ça fait plus savant).

Il existe de nombreux spécialistes du sujet, des "outils" adaptés, on pourrait même dire que les informaticiens se sont accaparés du sujet alors qu'à la base le manager a toujours eu dans sa mission d'organiser la formation des nouveaux arrivants et de veiller à la transmission des savoirs lors des remplacements / mobilités.

Illustration depuis le triangle Savoir / Pouvoir / Vouloir du sommet Savoir

Essayons d'aborder le sujet depuis différents points de vue afin d'affûter notre esprit critique et bien analyser les solutions proposées, voire d'anticiper les problèmes.

Un peu d'historique à partir d'expériences personnelles

Si nous oublions volontairement le passage dans la période scolaire où chacun aborde un certain nombre de matières (du primaire au bac + N, il y a déjà une grande période de formation) et s'approprie de méthodes lui permettant de s'épanouir dans une de son choix pour en faire son métier (c'est l'idéal), il apparaît que l'entrée dans la via dite active donne l'occasion de confronter l'acquis théorique à l'expertise de ceux qui font tous les jours depuis des années avec des "résultats démontrés" donc qui font bien !

Ma plus ancienne expérience sur le sujet remonte fin années 70 où j''étais tombé, par hasard, sur une notice technique des compresseurs commercialisés par une société X, la formalisation de cette notice constituant l'objet du stage IUT pour justement capitaliser et disposer d'un document permettant au personnel d'avoir sous la main le bréviaire ad-hoc. C'est de cette époque que j'ai trouvé un intérêt pour la capitalisation...

Quelques années plus tard, j'ai croisé un chargé de mission (cadre en fin de carrière s'occupant de sujets transverses) qui s'était attaqué au sujet en proposant des "cahiers de préconisations".

La documentation du bureau d'études avait certes les Normes, CdC (Cahiers des Charges) et PE (Procédures d'Essais) pour formaliser les spécifications en complément des Plans (c'était l'époque où il y avait encore des planches à dessins dans les BE), mais pourquoi était-ce spécifié ainsi et pourquoi une solution avait-elle était choisie plutôt qu'une autre ?

La force de son concept résidait dans la mise en oeuvre de la capitalisation : faire formaliser par des jeunes embauchés, donc encore imprégnés du savoir scolaire et capables de rédiger, voire de démontrer, comme au tableau.

Ce duo ancien plein d'expériences travaillant avec un jeune fraichement diplômé permettait non seulement une formalisation de ce savoir mais également contribuait à l'intégration de ce jeune qui de fait allait se retrouver à devoir exposer devant ses futurs pairs le résultat de cette capitalisation.

A l'époque, j'en ai rédigé quelques uns sur les thèmes de mon domaine d'expertise (cf. mon CV). Cette activité complémentaire à la formalisation des CdC et PE pour compléter un passage à des plans fonctionnels permettait de ranger quelque part l'historique des solutions existantes pour les générations futures.

Après son départ, un autre s'est attaqué au sujet, proposant l'expérience partagée organisée sous forme visuelle avec une fiche synthétique par sujet avec essentiellement des dessins (l'illustration plutôt qu'un long discours, c'est tout à fait en phase avec les idées développées dans ce blog).

En plus le format retenu pour les classeurs incitait à les laisser accessibles, le format étant exprès pas adapté aux bibliothèques.

Mais les cahiers en question sont devenus la cible des critiques des gens "pressés" : on ne veut plus de "préconisations", on veut définir les "exigences", d'où des Politiques Techniques, des Listes des Règles à appliquer etc...

L'avènement, du moins l'explosion de l'informatique et le développement des systèmes de gestion documentaire sont venus faire exploser le nombre de solutions avec au passage des pertes en ligne de l'historique (on optimise le temps des scan pour capter les documents mais on oublie de vérifier la pertinence des documents voire la qualité du résultat obtenu : j'ai trouvé des plans qui avaient été pliés lors de leur saisie, la partie dans le pli étant perdue à tout jamais).

Il y aurait beaucoup à dire sur ce processus d'archivage mais ce n'est pas l'objet de ce billet, nous y reviendrons peut-être ultérieurement.

Revenons au savoir et à notre proposition de le classer en 3 catégories : initial / expérience (essais erreurs) / transmission.

Le savoir initial

Nous éviterons de traiter le cas de l'apprentissage, même si ce dernier permet un pont entre l'enseignement et le monde de l'entreprise et permet au passage aux enseignants de progresser dans leur connaissance du monde entrepreneurial mais également aux apprentis d'arriver dans la vie active avec un début d'expérience...

Nous partons du principe, pour simplifier, que le jeune embauché a fait son parcours scolaire et se trouve du jour au lendemain confronté à la "réalité de l'entreprise".

Dans son bagage intellectuel voire dans ses aptitudes on devrait trouver un savoir faire standard :

le statisticien sait comment dépouiller les données,
le soudeur sait régler son poste et réaliser la soudure demandée.

Il faut avouer qu'hélas souvent les gens oublient, dès la porte franchie, qu'ils ont appris des choses et devraient encore savoir faire du calcul élémentaire, genre évaluer la déformation d'une poutre quand ils sont passés par une filière mécanique par exemple.

Mais oser rappeler les lois de la physique à des experts de l'entreprise peut être compliqué, là ce va être un peu de l'expérience de Asch.

Soutenir la physique face à des responsables qui n'ont confiance qu'en leurs habitudes peut même nuire à la carrière.

Une anecdote à ce sujet : mon premier "boulot" m'a fait découvrir un BE où les projets se suivaient avec juste un effet d'échelle.

Le soucis, quand vous augmentez les portées, le dimensionnement des poutres porteuses à la tenue peut conduire à des structures trop flexibles. Vous passez donc à un dimensionnement à la déformation, et là, avec le même type de choix technologique vous arrivez à des poutres très lourdes si faites en profilés type IPN.

Bon, on a fait des études il y a longtemps, donc on dimensionne un petit treillis qui effectivement est beaucoup plus léger, mais comment vérifier la déformation ?

Là le petit jeune sorti de l'IUT sort les méthodes énergétiques apprises, donc calées dans le nouveau savoir initial, explique à l'ensemble des dessinateurs présents comment ça marche, laisse faire les photocopies et retourne à son projet content d'avoir rendu service à l'équipe.

Bon, personne n'avait remarqué le chef de section venu voir l'attroupement : nouvelle méthode qu'il ne pouvait vérifier, en fin de semaine mon contrat était terminé et le chef de groupe désolé. Le chef du personnel trouvant la méthode cavalière m'a tout de même trouvé une nouvelle mission à l'étage du dessous, mais cet incident m'a appris que les chefs n'étaient pas forcément les mieux placés pour faire évoluer les processus de conception.

L'expérience (essais / erreurs)

Pouvoir se faire ses armes sur le terrain en confrontant des hypothèses à la réalité semble nettement plus enrichissant que de reproduire des processus et surtout favorise la créativité.

Si l'on veut innover, ce n'est pas en reproduisant toujours la même chose...

Dans le prototypage rapide il y a implicitement l'idée d'essais / erreurs.

Si on veut que ça marche du premier coup, il suffit de faire la même chose qu'avant qui marchait.

Il y a toutefois des règles à respecter, ce n'est pas au client final de tester si ça marche et il ne s'agit pas de mettre en péril les finances de l'entreprise.

Mais l'entreprise doit permettre des essais et accepter l'erreur : ce qui n'est pas acceptable c'est de refaire la même erreur et de ne pas avoir appris, donc acquis de l'expérience lors de cet essai.

Nous revenons au problème de management, du moins la difficulté avec certains managers qui veulent aller trop vite et brider leurs équipes, mais ça semble changer...

Une anecdote sympa sur un apprentissage du calcul : faire l'expérience d'avoir à utiliser un logiciel avant d'avoir suivi la formation à l'outils.

Bref, vous laissez le jeune ramer pendant tout son calcul : fort de cette expérience, une fois en formation il sera beaucoup plus attentif à ce que dira le formateur car trouvant un intérêt à découvrir ces astuces permettant de gagner un temps précieux.

Autre anecdote, en regardant un jour un montage d'essai où une poutre avait été renforcée de façon latérale, faute de place en hauteur je supposais... mais après discussion avec le technicien j'ai découvert que c'était sur une hypothèse fausse que la réalisation avait été faite : petit rappel de résistance des matériaux aux quelques autres experts passant par là, ils ne m'ont pas fait confiance bien entendu, je les ai donc laissés faire un proto pour vérifier et ils ont dû se rendre à l'évidence que les lois de la physique n'avaient pas évolué pour leur donner raison...

Personnellement, je pense avoir tenu mon rôle de manager de leur permettre de faire l'essai pour qu'ils comprennent la physique derrière le renforcement.

Mauvais souvenir associé, ayant eu la visite du responsable du pôle calcul je lui ai posé la question, j'aurais mieux fait de m'abstenir.

Les logiciels calculent des structures compliquées, mais le calculateur peut ne plus voir de quoi il retourne... L'informatique peut faire perdre les bases, c'est comme pour la règle à calcul, à l'époque de son utilisation avant le calcul électronique, les gens avaient une idée de l'ordre de grandeur du résultat, maintenant une erreur de coefficient peut passer inaperçue.

En échangeant avec les collègues, avec les concurrents, en allant voir ailleurs s'il n'y a pas des solutions dont on pourrait s'inspirer, on acquiert de l'expérience, au bout d'un certain nombre d'années on peut devenir un expert, mais dans tous les cas si on s'est intéressé à son travail on le fera mieux et avec plus d'aisance et de confiance.

Vous noterez au passage que ça peut avoir une incidence sur la motivation, donc sur le vouloir de notre triangle Savoir / Pouvoir / Vouloir.

La transmission du savoir

Là c'est à double sens : le savoir acquis par l'expérience de certains doit être transmis aux autres.

Donc à la prise de poste, au commencement de sa carrière, il est normal d'être formé via ce retour d'expérience.

C'est du savoir faire souvent protégé, donc rarement enseigné en dehors de l'entreprise. Donc acquis / transmis lors de séances de formation / coaching.

Par contre, assurance qualité oblige, il faut que ce savoir soit formalisé.

Sinon, comment savoir si rien n'a été oublié, voire si les éléments transmis sont bien fiables ?

Pour reprendre mon exemple de renfort mal situé, c'était comme ça car les gens pensaient que... mais personne n'a vérifié.

Double sens : quand à son tour on a découvert des pratiques qui marchaient et d'autres pas, il convient de formaliser pour partager l'information, déjà pour éviter que d'autres fassent la même erreur mais surtout qu'au moment du départ (mobilité ou cessation d'activité) on se retrouve à la dernière minute à se poser la question que faut-il formaliser ?

La question est liée à la formation, la formalisation de ce que l'on parle devrait correspondre à la matière transmise par la formation (quelque soit le support et le mode de transmission).

Les croquis (c'est plus simple quand tout le monde peut visualiser sur un schéma simple de quoi on parle), les termes employés, les processus décrits : toute la matière devrait être la même que celle trouvée dans les CdC, PE et autre notices. Il n'y a aucune raison d'avoir à refaire un schéma sous prétexte que le précédent est introuvable.

Et c'est sur ce point que je voudrais conclure ce billet, capitaliser ou faire fructifier son savoir, c'est déjà avoir le savoir quelque part.

L'informatique nous construit de belles bases documentaires, on a maintenant de beaux documents pour décrire ce qu'il faut faire pour gérer la documentation... dont peu de personnes se soucient comment elle est construite !!!

En tant que responsable d'un secteur d'essais, j'ai vu de loin se construire les premiers "dossiers de validation" : vous imaginez un responsable dans le boulot est de collecter les notes relatives à la validation de son projet. Personnellement mon boulot était de tester des idées, voire d'analyser des dysfonctionnements.

Quand on m'a demandé un compte rendu identifié par son numéro, j'ai eu la curiosité de demander pourquoi faire ? Pour mettre dans le dossier ? Ah, bon, dommage il y est écrit que ce n'est pas conforme... je n'ai donc pas transmis le document demandé.

A l'époque les documents étaient au format papier, si tout avait été dans une base documentaire le lien aurait pu être fait sans aucune vérification.

La prochaine fois qu'on vous vantera la facilité à saisir dans une base les documents et l'indexation associée, je vous invite à vous poser la question qui va avoir validé le document ?

Avec l'IA et le big data, on va pouvoir traiter un maximum de documents mais à la question simple comment identifier le bon schéma pour partager une idée, genre fiche "expérience partagée" où allez vous trouver les croquis déjà existants ?

Un moteur de recherche et les bons mots clé... mais combien de dessins et comment tous les modifier si jamais une erreur s'est glissée dans l'original et que ce dernier a été dupliqué n fois ?

Beaucoup de questions potentielles sur la construction du savoir mais pas beaucoup de solutions à ma connaissance dans les domaines techniques. J'aurais sûrement l'occasion d'y revenir.

En dernière anecdote, je reviendrai sur une dernière expérience personnelle : en charge de mon secteur d'essais, l'âge médian était de 53 ans, sous peu 50% des effectifs allaient quitter le secteur. J'ai donc mis en place des cellules métier pour lancer le processus de capitalisation afin d'assurer la pérennité du secteur.

Critiqué au début : quoi, encore aller perdre son temps en réunion ? pendant ce temps qui fait les essais ? ma plus grande satisfaction a été quand certains ont reconnu l'utilité du travail accompli.

Mais bon, chassez le naturel, il revient au galop : d'autres en ont profité ultérieurement pour externaliser les activités ainsi décrites. Ai-je vraiment bien fait ?

Là vous n'aurez pas la réponse, mais souvent je repense au cas du programmeur qui encapsulait son programme source dans l'exécutable de façon à ce qu'il soit le seul à pouvoir le retrouver. Ou à cet autre qui refusait de décrire comment il réalisait son travail, histoire de ne pas perdre sa place.

Dans les deux cas, personnellement j'ai toujours considéré le risque inacceptable, une disparition prématurée du collaborateur seul capable d'exécuter une tâche mettant en péril la structure (maladie, accident etc...) donc oeuvré pour réaliser le scenario comme si il n'était plus là à un moment où je m'y attendais, mais en changeant de point de vue on se rend compte que ce n'est pas équitable.

En tout cas, à la lecture de ce billet, vous devriez avoir identifié la relation entre formation, capitalisation et présentations... tout est lié !

Billet mis à jour par Louis CHATEL le 22/11/2022