Knowledge Management et faire face au turnover

Tags :
  • MON
  • 2024-2025
  • temps 1
  • Knowledge Managment
Auteurs :
  • Alix Duréault

Un MON explorant la difficulté de la perte de savoir dans l'entreprise liée au départ d'employés.

Pendant la vie d'un projet, il arrive que des chefs de projet se succèdent les uns par rapport aux autres. Cette situation peut arriver pour des mutations internes, un départ ou encore par un besoin de changement. Ces situations peuvent mettre en péril le bon déroulement du projet car elles chausent souvent une perte d'informations concidérable.

Pendant ce MON, je vais donc essayer de comprendre ce qu'est le knowledge management et comment s'assurer de la bonne conservation des informations tout au long de la vie d'un projet.

Introduction

Je me suis intéressé à ce sujet suite à une expérience que j’ai pu avoir lors de l’un de mes stages. Je travaillé dans une entreprise qui gérait plusieurs projets en parallèles sur le long terme. Il y avait plusieurs chefs de projet et chacun d’entre gérait plusieurs projets. Au bout de quelques mois de projet, un des chefs de projet a démissionné et à été remplacé par quelqu’un d’autre. Cette transition n’a pas été facile. Le nouveau chef de projet a découvert quand il est arrivé qu’il manquait certaines informations importantes compliquées à trouver. Les connaissances autour du projet n’ont pas été correctement transmises et certaines ont complétement été perdues.

C’est pour éviter ce genre de situation que j’ai entrepris d’étudier ce sujet. Le but de ce MON est d’identifier des méthodes afin d’éviter une perte de connaissance lors d’un départ d’un membre de l’équipe ou lors du changement de chef de projet.

Source de la perte de connaissances

La perte du savoir et des connaissances de l’organisation n’a pas pour seule source le départ d’employés. Cette perte peut aussi résulter de mauvaises mémoires et routines organisationnelles ou encore de systèmes de mémoire organisationnelle pas assez efficaces.

Le départ d’employés reste cependant l’un des facteurs majeurs de cette perte. En effet, lors de leurs départs, ils emmènent avec eux leur expertise sur les sujets dont ils étaient responsables, leur routine, leur savoir sur les raisons qui ont poussé à prendre telle ou telle décision, leurs bonnes pratiques sur leur poste, leur connaissance sur les succès et difficultés de l’entreprise.

Le départ de ces employés à lui aussi différentes sources : départ à la retraite, promotion, consultants terminant leur missions, réorganisations des équipes, …

Stratégies de rétention de connaissance

Lorsque la recherche “Understanding and managing knowledge loss” a été écrite en 2013, peu d’entreprises avait mis en place de vrai stratégie pérenne pour conserver le savoir. La plupart d’entre elles misaient sur des stratégies réactives, déployées au moment du départ de l’employé.

Eviter les départs

La toute première stratégie que l’on peut mettre en place pour éviter la perte de connaissance lié à un départ est tout simplement d’éviter le départ en question. Dans ce but, plusieurs méthodes peuvent être mise en place :

Cette première stratégie n’est pas complétement full proof. Certains départs sont inévitables comme les départs à la retraite. De plus, on ne peut pas décemment empêcher les employés de quitter l’entreprise.

Identifier les zones à risque

Un deuxième élément de stratégie est d’identifier quels sont les savoirs importants et ceux qui sont les plus propices à être oubliés. Encore une fois, plusieurs stratégies peuvent être mises en place pour cela :

La littérature met en avant 2 types de savoirs qui sont importants à garder : le composant et l’architectural. Le savoir composant est celui qui concerne les routines individuelles, les aspects discrets du travail d’un individu. Le savoir architectural correspond plutôt aux routines qui concernent toute l’équipe, toute l’entreprise qui sont utiles pour coordonner et combiner les différents membres composants de l’équipe. L’expérience montre que, même si ces deux types de savoir sont important, les connaissances architecturelles le sont d’autant plus. En effet, elles provoquent de plus grand dégâts lorsqu’elles sont perdues. Alors que des savoirs dits composants perdus peuvent être retrouvés plus facilement. La bonne stratégie a adopté est donc de diffuser ce type de savoir à travers les équipes, améliorer la coordination entre celles-ci.

Une fois ces zones importantes identifiées, une des premières choses que l’on essaie de faire est d’utiliser les technologies et certains outils afin de formaliser ces savoirs et de créer une documentation solide qui permet de ne rien perdre. Cela est une plutôt bonne stratégie dans un premier temps car elle permet de centraliser une bonne partie des connaissances. Mais elle soulève aussi quelques problèmes. Premièrement, cette documentation doit être régulièrement updater car elle risque sinon de contenir des informations obsolètes et entraîné par la suite des erreurs. Deuxièmement, ce n’est pas parce qu’un savoir a été documenté et rangé dans une base de donnée qu’il va être accessible aux personnes qui pourrait en avoir besoin ou qu’il va être trouvé dans des bases de données trop complexe. Ensuite, il y a aussi un problème du côté du receveur de l’information, va t’elle être compréhensible, interprétée correctement ou avoir assez de crédibilité pour être tout simplement utilisée. Enfin, cette technique est plus ou moins facile à mettre en place : quand il est facile de documenter la taille d’une structure , il le serait bien plus d’expliciter correctement la façon dont un chef de projet va interagir avec les différentes parties prenantes. Ces informations sont aussi très rarement exhaustives. Ainsi, il va falloir développer des stratégies plus complètes pour encadrer aussi ces savoirs dits tacites.

Les savoirs tacites

La partie peut être la plus dure à gérer est toutes les informations tacites, celles qui ne sont pas formulées, pas codifiées, … Un savoir tacite est par exemple, la capacité d’un commercial à comprendre quand est le bon moment pour négocier. Cette connaissance n’est pas codifiable, compliquée à transmettre, c’est un savoir internalisé qui n’est pas explicable par une base de donnée ou un paragraphe explicatif. Concrètement, cela peut être représenté par de l’expertise sur un sujet en particulier, la mémoire organisationnelle de pourquoi telle décision a été prise ou encore la connaissance d’anciens projets de l’entreprise qui pourrait, avec leur retour d’expérience, aider à mieux gérer les nouveaux projets.

Une première manière de ne pas perdre cette composante des savoirs est de capitaliser sur les interactions sociales, les discussions. A travers les interactions humaines, ce type de savoir va se propager à travers les employés et ainsi ce ne sera plus une seule personne qui portera ce savoir et son départ sera moins compliqué à gérer.

Une deuxième méthode serait d’implémenter une stratégie de mobilité, de formation multi domaine et d’implémenter des programmes de rotation sur les postes ou les projets. Cela permet en effet d’améliorer la rétention des savoirs tacites et limiter la perte comme plus de monde est en capacité d’avoir acquis ces savoirs.

Au contraire, une chose à ne pas faire est de vouloir trop codifier et formaliser le savoir. En effet, même si cela est utile dans une certaine mesure, il se trouve que c’est complétement contre-productif pousser à son extrême.

La manière identifié afin de transférer c’est savoirs tacites est la communication. Or cela n’est pas toujours le plus simple. Il faut aussi prendre en compte l’interprétation qui va être faite par le receveur de l’information ainsi que toutes les perturbations qui peuvent arriver et faire perdre une partie de l’information. Les facteurs pouvant perturber la transmission d’un savoir sont entre autre la capacité d’écoute de la personne recevant l’information, les rôles des individus en question, leur relation et motivation à échanger, la façon de communiquer (conversation, mail ou autre), la capacité de transmission de la personne “sachante”, …

Identifier les savoirs cachés

Tout n’est pas aussi beau que d’avoir des connaissances tacites partagées par toute l’entreprise et que les connaissances qui peuvent être codifiés sont documentées de manière exhaustive. Dans la réalité des choses, malgré la mise en place de tactiques, certains savoirs ne sont pas partagés et ils restent la propriété d’une seule personne. Il est alors important de les détecter pour éviter de les perdre lors d’un départ.

Ces connaissances “cachées” sont souvent le fruit de codifications non mises à jour où alors de savoirs tacites non identifiés. En effet, la plupart du temps les savoirs tacites ne sont même pas identifié en tant que tels par les travailleurs. Ils sont utilisés seulement inconsciemment.

Ainsi, les premières stratégies à mettre en place sont la mise à jour de la documentation régulièrement ainsi que l’observation des opérations afin de détecter les savoirs tacites.

Pour mener à bien cette observation, l’article “The knowledge dimension of manufacturing transfers : A method for identifying hidden knowledge” propose une méthode formalisée pour cela.

Outils

Durant ce MON, on a beaucoup parlé d’éléments théoriques et de stratégies sur ce sujet. Mais concrètement, quels sont les outils que l’on peut utiliser ?

Changement de perspective

On vient de définir tout plein de stratégies et quelques outils qui sont possibles de mettre en place pour éviter la perte de savoir. Cependant, tout ne se passe pas toujours comme prévu, ces techniques sont absolues et ne prennent pas en considération plusieurs paramètres comme entre autre la nature des activités de l’entreprise, la collaboration des personnes concernées, leur vision de quels savoirs sont importants et la culture d’entreprise ou du pays.

Sur ce dernier point, l’étude de Heidi Olander et Pia Hurmelinna est très intéressante. Elles ont étudiées 50 entretiens avec des employés de deux entreprises dans plusieurs pays. Sur cette étude, elles se sont concentrés sur la perspective des employés en fonction de leur niveau hiérarchique et de cette influence sur leur perception de l’importance des savoirs et du risque de perte de ceux-ci. Mais leur étude a aussi permis de dégager des tendances entre les différents pays.

Par exemple, en Finlande, le marché du travail est extrêmement stables, les employés ont tendance a rester dans la même entreprise un long moment. Cela réduit le nombre de pertes de connaissances dues à des départs mais cela signifie aussi qu’un départ peut être extrêmement impactant et détrimentaire.

Aux Etats Unis au contraire, le marché du travail est beaucoup plus volatile. L’absence de préavis de départ accentue d’autant plus la perte de savoir car il est d’autant plus difficile de se préparer au départ d’un employé et de former en parallèle le nouvel arrivant.

En Chine la difficulté n’est pas forcément lié au départ d’employé clé mais plutôt au remplacement de ces employés. Il est plus dur pour eux de trouver rapidement des candidats compétents, qui ne sont pas là que pour dorer leurs CVs et qui seront capable d’acquérir complétement les savoirs laissés par leur prédécesseurs.

Legacy Code

Un exemple en dev de ce genre de problème de perte de savoir est le Legacy Code. C’est le code hérité des prédécesseurs et qui au fur et à mesure des années n’est plus touché. Au bout d’un certain temps, on se retrouve avec un code obsolète ou difficile à maintenir mais que l’on va avoir du mal à modifier car le manque de documentation ou de tests automatisées au moment de sa création rende la tâche quasiment impossible. Un petit changement de code peut entraîner des dysfonctionnements parfois imprévus.

Il y a trois types de Legacy Code :

Avoir ce type de code mal entretenu peut causer des problèmes de sécurité, financiers et de temps liés au travail investi dans la remise à jour du code, des problèmes de recrutement.

Si l’on se retrouve face à un tel code, les bonnes pratiques sont d’opérer une refonte du code pour améliorer sa lisibilité, sa compréhension, sa qualité, … Pour cela on peut passer par une agence, cela permet de perdre moins de temps et d’investir moins de compétences en interne.

Pour éviter de créer cette dette technique, il y a quelques bonnes habitudes à mettre en place comme la mise en place d’une documentation claire, d’une méthodologie commune à l’équipe, l’utilisation d’un framework et enfin l’utilisation de tests.

Sources