Ce dont les ingénieurs de la fiabilité ont besoin dans une GMAO et que la plupart des systèmes n'offrent pas
Les ingénieurs en fiabilité utilisent les CMMS différemment des responsables de maintenance ou des opérateurs d'usine. Leur besoin principal est un historique des pannes — granulaire, structuré et interrogeable — qui permette l'analyse des causes profondes, la validation de l'AMDEC et l'identification des éléments les plus problématiques. La plupart des CMMS collectent des ordres de travail mais pas les données de panne sous une forme exploitable pour l'analyse de fiabilité. La différence tient à la structure des données : un ordre de travail indiquant « remplacement du roulement du compresseur de la ligne 3 » est un historique de maintenance. Un ordre de travail qui enregistre le mode de défaillance (écaillage par fatigue), le composant (bague intérieure), la cause probable (lubrification insuffisante), l'action corrective (remplacement par un roulement amélioré, augmentation de la fréquence de la maintenance préventive) et le temps avant défaillance depuis le dernier remplacement constitue des données de fiabilité. Les CMMS qui obligent les ingénieurs en fiabilité à construire cette structure via des champs personnalisés et l'extraction de données plutôt que via une taxonomie native des modes de défaillance ajoutent une charge analytique importante. Les meilleurs CMMS pour les ingénieurs en fiabilité sont ceux qui capturent les données de panne au moment de la clôture de l'ordre de travail par le technicien — via des listes déroulantes structurées pour le mode de défaillance, la cause et l'action corrective — et non ceux qui reposent sur des notes en texte libre qu'il faut analyser a posteriori.
MTBF, MTTR et identification des équipements défaillants dans la GMAO
Les calculs du Temps moyen entre pannes (MTBF) et du Temps moyen de réparation (MTTR) exigent une qualité de données dans la GMAO que la plupart des organisations sous-estiment. Le MTBF nécessite des horodatages précis des événements de panne — le moment où l'actif a cessé de fonctionner, et non la création de l'ordre de travail. Le MTTR nécessite des horodatages de début et de fin des ordres de travail reflétant le temps réel de réparation, et non le temps de traitement administratif. Dans la plupart des déploiements de GMAO, les techniciens clôturent les ordres de travail des heures ou des jours après l'intervention réelle, ce qui dégrade les deux calculs. Les ingénieurs fiabilité devraient exiger lors de l'évaluation d'une GMAO : détection automatisée des pannes déclenchée par le TRS/OEE ou les données d'arrêt SCADA (éliminant l'enregistrement manuel des événements de panne), clôture mobile des ordres de travail sur l'actif (permettant la capture en temps réel des horodatages), et tableau de bord natif MTBF/MTTR avec visualisation des tendances — et non une étape de calcul par exportation vers Excel. L'identification des mauvais éléments — les 20 % d'actifs responsables de 80 % des temps d'arrêt imprévus — nécessite une GMAO capable de classer les actifs par fréquence de pannes, contribution totale aux temps d'arrêt et coût de maintenance dans une même vue. C'est une fonctionnalité standard des plates-formes GMAO de qualité, mais elle nécessite des données historiques propres et structurées pour produire des résultats significatifs.
La MCR, la maintenance prédictive et le rôle de la GMAO dans les programmes de fiabilité
Maintenance centrée sur la fiabilité (RCM) élabore une stratégie de maintenance pour chaque actif en se basant sur l'analyse des modes de défaillance — le résultat est un ensemble de tâches de maintenance préventive (MP) avec des fréquences et des critères d'inspection spécifiés. La GMAO (CMMS) est le moteur d'exécution du RCM : elle traduit le résultat du RCM en calendriers de MP, suit la conformité et capture les données de défaillance et d'état qui valident ou mettent à jour l'analyse RCM. Le défi d'intégration tient au fait que l'analyse RCM est généralement réalisée dans un outil séparé (Reliability Workbench, Isograph ou XFMEA) et doit être importée dans la GMAO de manière structurée. Les plateformes GMAO disposant d'API ouvertes et d'une capacité d'importation structurée des MP réduisent cette friction d'intégration. Pour les programmes de maintenance prédictive (PdM), la GMAO doit recevoir des alertes de surveillance d'état provenant d'analyses vibratoires, de thermographie ou d'analyse d'huile et générer ou prioriser automatiquement des ordres de travail en fonction de seuils de condition — sans attendre qu'un ingénieur fiabilité crée manuellement un ordre de travail après avoir examiné les données des capteurs. L'architecture intégrée OEE et GMAO de Fabrico relie automatiquement la dégradation des performances de production aux déclencheurs de maintenance, créant une boucle de données qui prend en charge la maintenance basée sur l'état sans nécessiter une couche logicielle PdM distincte.