La demande arrive en général sous une forme technique. Un franchisé, ou un responsable d'entrepôt, ou un directeur d'usine demande l'accès au système de formation pour voir qui, dans son équipe, a terminé quoi. Le siège dit oui sur le principe, puis passe quatre mois à ne pas décider ce que cette personne peut faire exactement.
Ce retard n'est pas de l'incompétence. Sous la demande d'accès se trouvent quatre questions organisationnelles que la plupart des groupes n'ont jamais tranchées explicitement, et un logiciel ne peut pas y répondre. Ce guide porte sur ces questions ; l'outillage est la moitié facile.
Il est formulé autour des franchisés parce que la tension y est la plus vive, mais le besoin est identique pour quiconque dirige un site à l'intérieur d'une structure plus large. Un responsable d'entrepôt veut savoir qui a été instruit sur la nouvelle règle de rayonnage. Un responsable de production veut savoir quels opérateurs sont habilités pour la ligne de lundi. Un responsable de magasin veut savoir si les quatre personnes de samedi ont fait la procédure de caisse. Même question, autre bâtiment.
La loi nomme déjà la personne que vous hésitez à faire confiance
Il vaut la peine de le soulever tôt, car cela transforme la conversation d'une faveur en une obligation.
En Belgique, le Codex art. I.2-15 oblige l'employeur à organiser l'onthaal de chaque travailleur et à le confier à un membre de la ligne hiérarchique. L'art. I.2-11, deuxième alinéa, 9° va plus loin : le membre désigné de la ligne hiérarchique signe, sous son propre nom, un document attestant que les informations et instructions nécessaires en matière de bien-être au travail ont été données, et un travailleur expérimenté est désigné pour accompagner le nouvel arrivant.
Le nom sur ce document n'est pas celui d'un gestionnaire de formation au siège. C'est le membre de la ligne hiérarchique là où le travail se fait, c'est-à-dire, dans un groupe multi-sites, le responsable de site. Quand il demande à voir si son nouvel arrivant a été instruit, il ne demande pas un confort. Il demande à voir un devoir que le Codex a placé sur lui personnellement.
Cela ne veut pas dire qu'il faut tout lui donner. Cela veut dire que la position par défaut s'inverse : la question n'est pas pourquoi cette personne devrait avoir accès, mais ce qui justifierait de le lui refuser.
Quatre questions à trancher avant que quiconque n'obtienne un compte
Séparez-les délibérément. Les organisations qui les traitent comme une seule finissent soit avec un responsable de site qui ne peut rien faire, soit avec un responsable qui réécrit discrètement une procédure centrale.
Qui peut voir ? Les registres d'achèvement de qui, les résultats de questions de connaissance de qui, l'historique de qui, et par-dessus quelle frontière. La question bon marché, et celle qu'on restreint le plus souvent à l'excès.
Qui peut attribuer ? Si un responsable de site peut placer une formation existante devant l'un de ses collaborateurs avec une échéance, ou doit en faire la demande au siège.
Qui peut créer ? S'il peut écrire quelque chose lui-même, et si oui, si cela reste local ou entre dans la bibliothèque partagée.
Qui peut modifier ce qui existe ? Concrètement : que se passe-t-il quand un responsable de site estime qu'une instruction centrale est mauvaise.
Répondez-y dans cet ordre. Chacune concède plus que la précédente, et la quatrième n'est en réalité pas une question de droits.
Voir coûte moins cher qu'on ne le pense
On remet couramment aux responsables de site un PDF mensuel au lieu d'une vue, sur des motifs rarement examinés.
L'objection habituelle est la comparaison : donnez à un responsable une vue sur les autres sites et il va comparer et discuter. Le résultat le plus fréquent est pire, à savoir qu'un responsable qui ne voit rien suppose que son site va bien. La frontière la plus sûre n'est pas de cacher les données mais de limiter la population : visibilité complète sur les personnes dont il est responsable, et le réseau seulement en agrégé, voire pas du tout.
La deuxième objection est la vie privée, et elle mérite plus de respect. Les registres de formation sont des données à caractère personnel, et un responsable qui voit l'achèvement de personnes qui ne lui rapportent pas dispose d'un accès qu'il ne peut pas justifier. Cela plaide pour limiter la vue à la ligne de rapportage, pas pour la refuser. Délimitez étroitement, puis soyez généreux à l'intérieur de la délimitation.
Ce dont un responsable de site a besoin est réduit et stable : qui est en retard, sur quoi, pour quand, et qui est nouveau et donc pas encore habilité. Une vue affichant ces quatre éléments, sur un téléphone, remplace le courriel de statut hebdomadaire, et le siège cesse d'être l'intermédiaire de données qu'il ne faisait que transmettre.
L'attribution est le moment où la délégation devient réelle
Regarder ne change rien sur le terrain. Attribuer, si, et c'est là que la plupart des groupes calent.
L'argument pour, c'est le calendrier. Un responsable de site sait le mardi que quelqu'un passe sur une autre machine le jeudi. Si attribuer l'instruction exige une demande au siège, cela se produit après le changement ou pas du tout. Le Codex art. I.2-21 nomme le changement de fonction et les nouveaux équipements de travail comme déclencheurs de formation, et ces moments sont visibles sur le site et invisibles au centre.
L'argument contre ne porte pas vraiment sur l'attribution. C'est la crainte qu'un responsable attribue la mauvaise chose, ou rien. Les deux sont des problèmes de supervision avec une réponse de supervision : les attributions sont visibles vers le haut. L'Arbowet art. 8 lid 4 fait du contrôle du respect des instructions une obligation patronale à part entière, donc que le siège observe ce que les sites attribuent n'est pas du micromanagement mais l'exécution d'une obligation distincte.
Accordez l'attribution depuis la bibliothèque centrale. Gardez la bibliothèque elle-même hors de portée.
Créer est la frontière qui exige une règle explicite
Ici la réponse diffère réellement d'une organisation à l'autre. L'erreur est de la laisser implicite.
Les sites ont du vrai contenu local : la configuration de ce bâtiment, l'itinéraire d'évacuation de cet étage, la machine de cette ligne, le client dont les règles s'appliquent à cette adresse. Rien de cela n'a sa place au centre, et interdire aux sites de le produire signifie qu'il sera produit quand même, sous forme d'une feuille plastifiée que personne au siège ne voit.
La règle qui fonctionne : le contenu local peut être créé, reste local, et n'entre jamais par défaut dans la bibliothèque partagée. Si un contenu local est assez bon pour être généralisé, sa promotion est un acte délibéré de la personne qui détient la bibliothèque, pas un effet de bord de quelqu'un qui appuie sur enregistrer. Cette asymétrie, facile à créer localement et difficile à publier centralement, est ce qui empêche une bibliothèque de devenir un disque partagé en un an.
Quand un responsable de site dit qu'une instruction centrale est mauvaise
C'est la quatrième question, et celle à laquelle on tente de répondre par les droits. C'est impossible.
Un responsable de site qui estime qu'une procédure centrale ne convient pas à son bâtiment a en général raison sur le bâtiment et souvent tort sur la procédure. L'instruction peut exister pour une raison que personne n'a expliquée : un régulateur, un contrat client, une condition d'assurance, un incident sur un site qu'il n'a jamais vu. Si le modèle de droits lui permet de la modifier, la raison disparaît avec le texte, en silence, sur un site, là où personne ne regarde.
S'il ne le lui permet pas et qu'il n'existe pas non plus de voie pour la contester, il se passe quelque chose de pire. Le site suit informellement une version maison, le texte central reste intact et mauvais, et l'écart entre l'écrit et le fait grandit jusqu'à ce qu'un audit ou un incident le trouve.
La réponse est donc un processus, et aucune de ses trois parties n'est technique. Un propriétaire nommé pour chaque procédure centrale, afin qu'il y ait quelqu'un à qui s'adresser. Une voie assortie d'un délai de réponse annoncé, car une contestation qui n'obtient pas de réponse en quinze jours apprend au site à ne plus rien remonter. Et une règle intérimaire : tant que la contestation est ouverte, la version centrale s'applique, sauf si le responsable de site la juge dangereuse, auquel cas il arrête l'activité et escalade le jour même.
Les groupes qui appliquent cela constatent que le volume de contestations est bien inférieur à ce qu'ils craignaient et que celles qui arrivent valent la lecture. Les groupes qui ne le font pas découvrent leurs versions maison pendant un audit.
Là où la plateforme intervient
Deux courtes remarques sur l'outillage, courtes parce que la conception organisationnelle ci-dessus est la moitié la plus difficile et la plus durable.
Si une plateforme prend en charge les accès délimités, on peut donner à un responsable de site une vue limitée à ses propres collaborateurs, plus le droit d'attribuer depuis la bibliothèque centrale sans pouvoir la modifier. Si elle prend en charge du contenu local qui reste hors de la bibliothèque partagée, la règle de création ci-dessus peut être imposée et pas seulement convenue. Savoir si une plateforme donnée fait les deux, et avec quelle netteté, est une question à poser directement à un fournisseur et à faire démontrer plutôt que décrire.
Ce qui rend la délégation utile dans Aristotl de toute façon, c'est le registre en dessous : achèvement, résultats des questions de connaissance et version par personne, par site et par rôle, exportables et lisibles sur un téléphone, ce qui compte car un responsable de site n'a pas plus de bureau que son équipe.
Posez-le d'abord sur votre propre organigramme
Avant de regarder un logiciel, prenez un site et écrivez, pour la personne qui le dirige, les réponses aux quatre questions ci-dessus. Apportez cela en démonstration. La conversation sur ce qu'une plateforme doit imposer est courte une fois que celle sur qui décide de quoi a eu lieu.