La plupart des organisations traitent le matériel de formation comme un fichier Word. Il y en a un qui est le bon, et les précédents sont quelque part : une boîte mail, un disque partagé, un dossier appelé ancien, une armoire au bureau du site. Cela tient jusqu'au jour où quelqu'un pose une question qui contient une date.
La question est toujours une variante de la même chose. Sur quelle version de la procédure cette personne a-t-elle réellement été formée, en mars, à cette adresse. Et dans un réseau de plus de quelques sites, la réponse honnête est en général que personne ne peut le dire.
Cela dépasse largement les réseaux de franchise. Les entrepreneurs avec des équipes sur les chantiers de clients, les groupes de production avec plusieurs usines, les sociétés de facility, les chaînes de magasins, les agences qui placent des personnes chez des dizaines d'utilisateurs : toute organisation où la même instruction doit exister dans plus d'un bâtiment a ce problème, et les organisations certifiées l'ont sous une forme qui est auditée.
L'enregistrement qui ne peut pas répondre à la question suivante
Un enregistrement de fin de formation est une affirmation : cette personne a suivi cette instruction à cette date. En soi, cela ressemble à une preuve, et cela survit sans difficulté à la première question lors d'un audit ou d'une inspection.
Cela survit rarement à la deuxième. Si la procédure a été revue en février et que l'enregistrement indique que quelqu'un a suivi "l'instruction de sécurité" en janvier, l'enregistrement vous dit que la personne a été instruite sur quelque chose. Il ne vous dit pas qu'elle a été instruite sur ce qui est actuellement affiché au mur. Si un collègue d'un autre site a suivi la même instruction portant le même nom en avril, les deux enregistrements sont identiques et décrivent deux contenus différents.
C'est tout l'argument en faveur de la gestion des versions, et cela n'a rien à voir avec l'hygiène logicielle. Sans version attachée, un enregistrement prouve qu'un événement a eu lieu. Avec une version attachée, il prouve ce que cet événement contenait. Ce sont deux affirmations différentes, et seule la seconde vaut quelque chose quand quelque chose a mal tourné.
Ce que le document signé doit réellement désigner
Le droit belge rend cela concret d'une manière particulièrement utile.
Le Codex art. I.2-11, deuxième alinéa, 9° impose à l'employeur d'organiser l'onthaal (accueil et introduction structurés) de chaque travailleur débutant, de désigner un ervaren werknemer (travailleur expérimenté) chargé de l'accompagner, et de faire signer par le membre désigné de la ligne hiérarchique un document en son nom propre attestant que les informations et instructions nécessaires en matière de welzijn op het werk (bien-être au travail) ont été fournies.
Lisez cela comme une exigence de preuve plutôt que comme une formalité. Une personne nommément désignée signe une déclaration portant sur un contenu. Si le contenu derrière cette déclaration n'est pas suivi, la signature est attachée à quelque chose que personne ne peut reconstituer : les instructions telles qu'elles existaient ce jour-là, dans la version que ce site détenait à ce moment. Deux travailleurs entrés à six semaines d'intervalle peuvent détenir des documents signés identiques décrivant des instructions matériellement différentes, et rien dans le dossier ne le dira.
Le Codex art. I.2-21 ajoute la raison pour laquelle cela continue d'arriver. La formation doit être répétée et adaptée à mesure que les risques évoluent, et elle est déclenchée à nouveau par un changement de fonction, de nouveaux équipements de travail ou une nouvelle technologie. Autrement dit, le contenu est censé changer. Un système qui suppose le contraire va forcément dériver.
Aux Pays-Bas, il n'existe aucune forme de preuve prescrite. L'Arbowet n'exige pas de signature et quiconque prétend le contraire l'a inventé. Mais l'Arbowet art. 8 lid 4 impose à l'employeur de veiller au respect des instructions données, et veiller au respect d'une instruction que vous ne pouvez pas identifier précisément est une affirmation, pas une pratique.
La question VCA 4.1 suppose que le contenu derrière la liste ne bouge pas
Pour les entreprises certifiées, la même faiblesse apparaît dans le dossier d'audit.
La question 4.1 est une question must. Elle exige des toolboxmeetings répartis sur l'année, couvrant les thèmes VGM pertinents, les modifications des règles et procédures, et les constats issus des enquêtes d'incident. La preuve demandée par le référentiel est littérale : la liste des dates et des sujets abordés, et les listes de présence.
Regardez ce qu'est cette liste de sujets. C'est un ensemble d'étiquettes. "Travail en hauteur", "la procédure de chargement révisée", "les constats de l'incident sur le site deux". Une étiquette est un renvoi, et le référentiel suppose discrètement qu'elle renvoie à une seule chose. Quand quatre sites enregistrent tous la procédure de chargement révisée et que deux d'entre eux ont présenté la version retirée un mois plus tôt, le dossier est complet, les listes de présence sont signées, et l'enregistrement est faux d'une manière qu'aucun auditeur ne peut voir et qu'aucun responsable ne peut corriger après coup.
La question 4.1 nomme aussi les modifications des règles et procédures comme contenu obligatoire, ce qui signifie que le référentiel vous demande explicitement d'enseigner l'écart. Vous ne pouvez pas enseigner un écart sans savoir de quelle version part chaque site.
La dérive est un échec de déploiement, pas une préférence
Dans la pratique, les sites ne décident pas d'utiliser un contenu ancien. La dérive s'installe discrètement.
Un site était en plein déploiement quand la mise à jour est arrivée et a terminé l'ancienne. Un responsable a gardé une copie papier parce que la tablette de ce local n'est pas fiable. Un manager parti avait une variante locale que personne ne connaissait. Une mise à jour a été publiée le vendredi d'une semaine où ce site manquait de personnel.
Chacune de ces situations appelle une correction différente, et aucune n'est un e-mail de rappel. Ce qu'elles ont en commun, c'est qu'elles ne sont corrigeables que si quelqu'un peut les voir. Une vue par site indiquant quelle version est actuellement active, à côté de la version que chaque personne a suivie, transforme quatre situations invisibles en quatre petites tâches opérationnelles.
Le chiffre à surveiller n'est pas le pourcentage de complétion. C'est la dispersion des versions actives dans le réseau. Une seule version partout signifie que le dernier changement est arrivé à destination. Trois versions dans cinquante sites signifient que le dernier changement est encore en cours, quel que soit le chiffre de complétion.
Quand une version publiée s'avère erronée
C'est le cas auquel tout le monde pense en premier, et ce n'est vraiment qu'une application de la discipline décrite plus haut.
Une mise à jour part le lundi. Le mercredi, quelqu'un remarque que l'étape quatre est ambiguë, ou qu'une valeur a été reprise de l'ancien processus, ou qu'un contrôle a sauté lors de la révision. À partir de ce moment, chaque complétion supplémentaire ajoute une personne correctement enregistrée comme formée sur la mauvaise chose.
Trois choses doivent se produire, dans cet ordre. Arrêter la diffusion de la mauvaise version, pour que le nombre de personnes concernées cesse d'augmenter. Identifier exactement qui l'a suivie, ce qui n'est possible que si les complétions portent une version. Réinstruire ce groupe précisément, plutôt que d'arroser à nouveau tout le réseau, ce qui apprend à tous les autres que vos mises à jour ne sont pas fiables.
Ensuite, notez ce qui s'est passé. Pas pour la forme : la note expliquant ce qui a changé, quand cela a été détecté et qui était concerné est précisément le document qui rendra l'enregistrement corrigé lisible pour un auditeur un an plus tard. Un historique de complétions avec un trou et sans explication paraît pire que l'erreur d'origine.
Qui publie, et qui modifie la source
La plupart des mauvaises versions ne sont pas des erreurs de rédaction. Ce sont des trous d'approbation : quelqu'un disposant des droits de modification a corrigé quelque chose de raisonnable et cela est passé en ligne sans deuxième lecteur.
Séparez les deux droits. Toute personne proche du terrain peut proposer une modification de la procédure source, parce que ce sont ces personnes qui remarquent que la réalité a bougé. Publier vers le réseau est une autorisation distincte, détenue par peu de personnes, avec un deuxième approbateur obligatoire sur les contenus où une erreur coûte cher : instruction de sécurité, procédures d'hygiène et d'allergènes, tout ce qu'un règlement client encadre.
Traiter une mauvaise version dans Aristotl
Trouvez la version qui a mal tourné. Chaque version publiée porte un horodatage et une note de modification. Une chute soudaine des scores au test de connaissances d'un module est en général le moyen le plus rapide de repérer quelle publication a introduit le problème, avant que quiconque ne le signale avec des mots.
Restaurez la dernière version correcte. La restauration rend la version précédente active sur tous les sites en une seule fois. Les personnes en cours de parcours voient le contenu restauré au module suivant ; personne n'a besoin qu'on lui dise d'arrêter.
Réattribuez les personnes qui ont suivi la mauvaise version. Filtrez les complétions par version, sélectionnez ce groupe, et réattribuez avec un délai court. Ces travailleurs restent signalés jusqu'à ce qu'ils terminent la version corrigée, de sorte que l'export reflète l'état corrigé plutôt que l'affirmation d'origine.
Conservez la trace. Les versions antérieures restent accessibles au lieu d'être écrasées, chaque complétion est étiquetée avec la version suivie, et le tableau de bord affiche la version active par site. L'export qui en sort répond directement à la question datée : cette personne, cette version, cette date, ce site.
Sortez un enregistrement de l'an dernier
Prenez n'importe quel enregistrement de formation datant de douze mois et essayez d'établir à quelle version de la procédure il se rapporte. Apportez le résultat à une démo, et nous vous montrerons le même enregistrement avec une version dessus, ce qui fait la différence entre un dossier et une preuve.