Points clés
Voir les types d'ordres de travail que ces alertes devraient générer.
Dans une usine typique, le système OEE surveille la ligne et le CMMS surveille l'actif. Les deux voient des « temps d'arrêt », mais chacun en voit une version différente. Le côté OEE capture chaque arrêt au‑dessus d'un certain seuil. Le côté maintenance ne capture que ceux qui sont devenus des ordres de travail.
L'écart entre ces deux chiffres, généralement de 20 % à 40 % du temps d'arrêt total, est l'endroit où vivent les petites pertes récurrentes. Ces petites pertes sont aussi là où se trouvent la plupart des améliorations réalisables.
La raison de cet écart n'est pas qu'une équipe fasse le mauvais travail. C'est que les deux systèmes n'ont pas de définition partagée de « cet arrêt nécessite un ordre de travail ». L'opérateur décide, le superviseur décide, parfois personne ne décide, et les règles dérivent d'une ligne à l'autre.
Un modèle opérationnel de maintenance est l'ensemble des règles explicites qui transforment chaque événement OEE en un résultat binaire: un ordre de travail s'ouvre, ou non.
Un système OEE sans une taxonomie propre des classes de perte n'est qu'un chronomètre agrégé. Le modèle opérationnel commence par regrouper chaque arrêt en un ensemble stable de classes, généralement de sept à dix. Exemples courants: changement de série, micro‑arrêt, mécanique mineure, électrique/capteur, rupture d'alimentation en matière, rejet qualité, dépassement planifié, piloté par l'opérateur.
La liste exacte importe moins que le fait que la même liste soit utilisée partout, à chaque équipe, sur chaque ligne. L'article sur les KPI de fabrication couvre les familles de KPI sous‑jacentes auxquelles cette taxonomie se rattache.
Chaque classe a besoin d'une règle : à quelle durée ou quelle fréquence cet événement devient‑il un ordre de travail ? Les seuils sont presque toujours erronés le premier jour et sont ajustés entre la deuxième et la sixième semaine. Ce qui importe, c'est que la règle existe et soit visible. Exemples de premiers seuils typiques :
Les règles de seuil par regroupement (« 3 fois en 8 heures ») tendent à attraper les petites pertes récurrentes que les seuils sur un seul événement manquent. Elles sont le type de règle à plus fort rendement à ajouter.
Chaque classe de perte a un responsable nommé, pas un département. Les problèmes mécaniques mineurs et électriques reviennent au responsable maintenance. Les changements de série et les pertes pilotées par l'opérateur reviennent au responsable production. La rupture d'alimentation en matière revient au planificateur. Le rejet qualité revient au responsable qualité.
Le responsable n'effectue pas nécessairement la réparation, mais il possède la tendance et le seuil. Lorsqu'une classe dépasse le seuil, le responsable agit en premier.
La règle la plus importante et la plus souvent oubliée. Lorsqu'un événement OEE ouvre automatiquement un ordre de travail, deux choses doivent se produire dans la même minute: le technicien maintenance voit l'ordre de travail sur un appareil mobile, et l'enregistrement OEE est lié à l'ordre de travail afin que la clôture remonte.
Sans ce lien bidirectionnel, le modèle opérationnel dégénère en « l'OEE génère du bruit, le CMMS l'ignore » en l'espace d'un trimestre. Un CMMS prêt pour le terrain sur le téléphone du technicien est ce qui permet que cela fonctionne.
L'article sur les systèmes de gestion des ordres de travail approfondit les éléments en jeu.
Parce que les règles de seuil par regroupement attrapent le même défaut qui se déclenche trois fois avant que qui que ce soit ne le remarque, les petites pertes récurrentes, celles actuellement invisibles, commencent à apparaître dans l'arriéré maintenance avec un véritable parcours de résolution.
La plupart des usines constatent que cette catégorie seule représente souvent une part importante, fréquemment 15‑25 %, des temps d'arrêt non planifiés une fois exposée. Voir le traitement approfondi dans notre article sur l'analyse des causes profondes en fabrication .
Lorsque chaque événement OEE pertinent devient un ordre de travail, le CMMS voit enfin la population complète des défaillances. Le MTBF et le MTTR commencent à refléter la réalité au lieu du sous‑ensemble que les opérateurs ou superviseurs décidaient d'escalader. L'effet en aval est que les programmes de maintenance préventive peuvent être ajustés à partir de données de panne réelles plutôt que des recommandations des fournisseurs.
Parce que l'événement OEE et l'ordre de travail partagent un identifiant, le responsable production et le responsable maintenance regardent la même ligne. La réunion matinale passe de « qui a le bon chiffre » à « quelle classe de perte a bougé la semaine dernière ».
Ce changement unique est le déverrouillage opérationnel que recherchent la plupart des usines de taille intermédiaire lorsqu'elles achètent un système OEE, et il ne provient presque jamais du seul logiciel OEE.
Une erreur fréquente est de déployer 30 règles déclencheuses lors de la mise en production. La moitié sont mauvaises, toutes créent du bruit, l'équipe maintenance désactive l'intégration à la troisième semaine. Commencez avec cinq ou six règles. Ajoutez‑en une par semaine en fonction de ce qui est manqué.
Si l'ordre de travail se clôture mais que l'événement OEE reste « ouvert » dans le registre des pertes, les chiffres OEE et CMMS divergent à nouveau, parfois en quelques semaines. La clôture doit circuler dans les deux sens. C'est là que de nombreuses configurations OEE + CMMS bricolées échouent en pratique.
Si une classe déclenche un ordre de travail mais qu'aucun responsable nommé ne suit la tendance, l'ordre est réalisé, la perte se répète et rien ne change. Le responsable nommé est ce qui transforme le volume en amélioration.
Le modèle opérationnel ci‑dessus peut être implémenté sur n'importe quelle architecture bien instrumentée, mais la raison pratique pour laquelle les usines de taille intermédiaire ont du mal à le faire fonctionner est qu'un outil OEE et un CMMS séparé partagent rarement un lien propre événement/ordre de travail.
Fabrico a été construit autour de ce transfert exact: chaque événement OEE vit dans la même base de données que les ordres de travail, la hiérarchie d'actifs et la taxonomie des pertes, de sorte que les règles déclencheuses et les chemins de clôture existent par défaut plutôt que comme une intégration personnalisée.
Si vous voulez voir à quoi ressemble un modèle unifié appliqué aux données de votre propre ligne, réservez une démo et nous la parcourrons avec vous.
Non, mais le problème du flux de clôture est difficile à résoudre proprement à travers deux systèmes séparés. Les usines sur des piles séparées ont généralement besoin d'une couche middleware ou d'une étape de réconciliation manuelle qui s'érode en l'espace d'un trimestre. Une plateforme unifiée supprime ce risque.
Cinq ou six. La tentation est de définir toutes les règles dès le premier jour ; la réalité est que la plupart des règles nécessitent 4 à 6 semaines de données réelles avant que le seuil soit correct. Un petit ensemble de départ ajusté durant le premier trimestre vaut mieux qu'un ensemble complet déployé à froid.
Opérationnellement, le directeur d'usine. Le responsable maintenance et le responsable production possèdent chacun des classes. Sans un propriétaire unique du modèle au niveau de l'usine, les seuils dérivent, les responsables nommés tournent sans passation et le modèle se dégrade.
Très peu au début. L'opérateur enregistre toujours les arrêts de la même manière. Ce qui change, c'est que le système décide désormais si chaque arrêt devient un ordre de travail, donc l'opérateur n'a plus à prendre ce choix poste après poste. Avec le temps, l'opérateur voit moins de petites pertes récurrentes car les règles déclencheuses les attrapent plus tôt.
Deux chiffres : la part des temps d'arrêt non planifiés qui a un ordre de travail lié (objectif : au‑dessus de 80 % sous 90 jours), et le nombre roulant d'ordres de travail générés par les règles de seuil par regroupement (doit rester non nul ; s'il tombe à zéro, les règles ne capturent plus rien de nouveau).
Connexion
Blog
