ERP & MES : Pourquoi vos données de production sont fausses

    Vous préférez lire ? La retranscription intégrale de la vidéo est disponible juste en dessous pour parcourir les idées clés facilement.

    Pourquoi vos opérateurs sabotent vos données MES (et comment y remédier en 3 clics)

    Vos opérateurs sabotent vos données de production dans votre ERP et dans votre MES sans le vouloir. J'ai rencontré ce cas à plusieurs reprises dans mes missions et j'aimerais vous partager une solution concrète pour enfin avoir des données de production fiables, sans surcharge pour vos opérateurs. Au contraire, en leur simplifiant le travail.

    Vous avez dépensé des centaines de milliers d'euros dans un MES dernier cri. Pour ceux qui l'ignorent, MES est un acronyme pour Manufacturing Execution System. C'est un logiciel qui pilote en temps réel l'exécution de la production dans l'atelier en faisant le lien entre les machines, les opérateurs et d'autres systèmes de management comme les ERP, la qualité, la maintenance.

    Vous avez organisé des formations, créé des procédures claires pour tracer chaque arrêt machine. Et pourtant, quand vous ouvrez le tableau de bord, 75% des arrêts sont classés dans "Autres problèmes" ou "Problèmes indéterminés". Ou alors, les opérateurs sélectionnent toujours le premier problème de la liste.

    Vos analyses tombent à l'eau et vos décisions sont basées sur du bruit.

    Le problème n'est pas vos opérateurs. C'est votre interface qui les pousse à mentir.

    Le piège invisible

    La scène classique dans votre atelier : la ligne s'arrête. L'opérateur sait exactement ce qui se passe. Un capteur défaillant sur le convoyeur 3, par exemple. Il a déjà appelé la maintenance. Dans sa tête, c'est clair.

    Mais maintenant, il doit renseigner le système. Il ouvre l'écran et une liste déroulante apparaît : 50 causes d'arrêt, peut-être 80, organisées par ordre alphabétique ou pire encore, par code numérique.

    Il commence à scroller. Il cherche le mot "capteur". Dix secondes passent, 15 secondes passent. La maintenance arrive et le chef d'équipe veut redémarrer. L'opérateur n'a pas le temps.

    Alors il clique sur "Problème électrique" parce que c'est assez vague et que c'est en haut de la liste. Ou il clique toujours sur le même code qu'il a mémorisé depuis 3 ans, parce que c'est rapide et parce qu'il est sous pression. Personne ne lui a jamais reproché ça.

    Vous croyez avoir un problème de discipline. Vous avez un problème de design : l'UX design, l'interface utilisateur et l'expérience utilisateur.

    La charge cognitive

    Parlons neuroscience. Votre cerveau fonctionne comme une batterie. Chaque décision consomme de l'énergie mentale. Les chercheurs appellent ça la charge cognitive. Plus une tâche demande d'effort et d'attention, plus elle épuise vos ressources mentales.

    Quand vous présentez 60 options à lire, comparer et évaluer, vous créez une surcharge. L'opérateur doit maintenir en mémoire de travail ce qu'il cherche tout en scannant visuellement la liste. Il doit éliminer les mauvaises options une par une. C'est épuisant pour lui et c'est lent.

    Le résultat est prévisible. Le cerveau cherche un raccourci. Il prend la première option acceptable, pas la bonne option. L'acceptable. C'est un mécanisme de survie cognitive, ce n'est pas de la paresse.

    Maintenant, multipliez ça par 15 arrêts par jour par 20 opérateurs. Vous venez de leur voler 3 heures de temps collectif juste pour remplir des formulaires. Et en bonus, vos données sont inutilisables.

    Votre ERP a été conçu par des informaticiens qui voulaient tout catégoriser, mais personne n'a pensé à l'humain qui utilise le système sous pression, avec des gants, debout, au milieu du bruit des machines.

    La solution par arborescence

    La solution existe déjà. Imaginez : vous rentrez dans un restaurant. Le serveur vous tend un menu de 80 pages. Tous les plats sont mélangés : entrée, dessert, plat chaud, salade, tout en vrac. Vous allez paniquer. Vous allez mettre 15 minutes ou plus à choisir et probablement commander la première chose lisible par pur épuisement.

    Maintenant, imaginez qu'il vous pose trois questions simples : viande, poisson, végétarien ou pâtes ? Vous répondez viande. Bœuf, poulet, porc ou agneau ? Vous dites bœuf. Grillé, mijoté ou en sauce ? Vous dites grillé.

    En trois clics, vous avez trouvé exactement ce que vous vouliez. Sans effort, sans stress.

    C'est exactement le même principe que vous devez appliquer avec les codes arrêt.

    Au lieu d'une liste de 60 causes, construisez une arborescence sur trois niveaux :

    Niveau 1 : Quatre catégories larges

    • Panne mécanique

    • Problème matière

    • Réglage opérateur

    • Autres

    L'opérateur choisit en 2 secondes.

    Niveau 2 : Quatre sous-catégories selon son choix
    Si c'est une panne mécanique, par exemple :

    • Moteur

    • Convoyeur

    • Capteur

    • Outillage

    Ça lui prend 2 secondes de plus.

    Niveau 3 : Quatre précisions finales adaptées au contexte

    Vous passez de 60 choix simultanés à 64 possibilités finales réparties sur trois niveaux. Mais l'opérateur ne voit jamais plus de quatre options à la fois. Son cerveau traite l'information instantanément. Plus d'hésitation, plus de scan mental épuisant. Et surtout, plus de données pourries.

    Ce que ça change vraiment pour vous

    Avec cette approche, les données deviennent enfin exploitables. Vous pouvez enfin faire un vrai Pareto, identifier les vraies causes racines et investir au bon endroit.

    Mais surtout, vous arrêtez de traiter vos opérateurs comme des robots administratifs. Vous reconnaissez que leur attention est une ressource limitée et précieuse. Vous concevez des outils qui respectent leur charge mentale et leur contexte de travail réel.

    Et bizarrement, quand vous faites ça, la qualité de la donnée explose. Parce que vos opérateurs veulent bien faire. Ils connaissent leur machine. Mais si vous leur demandez l'impossible dans un contexte de pression, ils vont prendre des raccourcis. C'est humain, c'est prévisible, c'est normal.

    L'action terrain : par où commencer dès lundi

    Vous n'allez pas refondre votre MES en une seule nuit, mais vous pouvez tester une ligne pilote.

    Étape 1 : Choisissez la ligne la plus critique ou celle qui génère le plus d'arrêts mal renseignés.

    Étape 2 : Réunissez trois personnes

    • Votre responsable IT (si possible, adaptez à votre situation)

    • Vous-même

    • Surtout, un opérateur de cette ligne

    Étape 3 : Sortez les données des trois derniers mois. Identifiez les 20 codes d'arrêt les plus fréquents.

    Étape 4 : Avec l'opérateur, organisez ces codes en arbre de décision. Posez-lui la question : "Si tu devais choisir entre ces quatre catégories en 2 secondes, tu mettrais lesquelles ?" Construisez la structure avec lui.

    Étape 5 : Testez pendant 2 semaines. Comparez la qualité des données avant/après.

    Si ça marche, déployez progressivement cette méthode sur les autres lignes.

    Vous verrez la différence. Parce que vous aurez arrêté de demander à vos équipes de faire le travail d'un analyste pendant qu'elles gèrent la production. Vous leur donnez un outil qui respecte leur temps, leur énergie mentale et leur expertise.

    C'est un système plus efficace parce qu'il est plus humain.

    --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---