Points clés
Un enregistrement de défaillance d'équipement est la documentation structurée d'un seul événement de panne, enregistrant l'actif, le mode de défaillance, la cause, la méthode de détection, le début et la fin de l'immobilisation, le temps de réparation et les pièces utilisées. Des enregistrements cohérents et codés constituent les données brutes derrière le MTBF, le MTTR, la disponibilité OEE et les analyses de fiabilité comme la FMEA.
Un enregistrement de défaillance d'équipement est la documentation structurée d'un seul événement de défaillance sur un seul actif. Il répond à ce qui a échoué, comment cela a échoué, pourquoi cela a échoué, combien de temps il est resté arrêté, ce qui a été fait pour le réparer et quelles pièces ont été consommées. Un enregistrement = une panne, horodaté et codé afin d'être compté, trié et analysé ultérieurement.
Un enregistrement de défaillance n'est pas la même chose qu'un ordre de travail. L'ordre de travail est l'instruction pour effectuer la réparation. L'enregistrement de défaillance est la preuve de fiabilité que la réparation laisse derrière elle. Comme le dit Reliabilityweb, sans données de défaillance précises « tout ce que vous avez, c'est un système de tickets d'ordres de travail », et la même source note que « sans modes de défaillance tout ce que vous avez, ce sont une série de codes ». L'enregistrement est ce qui transforme un ticket fermé en données exploitables.
Cela importe car presque tous les indicateurs de fiabilité que votre usine rapporte sont construits sur ces enregistrements. Si les enregistrements sont vagues, devinés ou codés de manière incohérente, alors le MTBF, le MTTR et la composante disponibilité de l'OEE sont tous bâtis sur du sable.
Un enregistrement de défaillance complet capture l'actif, la défaillance elle-même, le calendrier, la réponse et les ressources. L'absence de l'un de ces éléments rompt un calcul en aval. Le tableau ci-dessous montre les champs clés, ce que chacun capture, et la défaillance de qualité de données la plus courante pour ce champ.
| Champ | Ce qu'il capture | Ce qu'il alimente | Problème courant de qualité des données |
|---|---|---|---|
| ID d'actif | L'équipement exact, jusqu'au niveau du composant | Pareto par actif, classement de criticité | Enregistré contre une ligne parente, pas contre l'unité défaillante |
| Mode de défaillance | Le symptôme observé (ex. : palier grippé, moteur surchauffé) | FMEA, analyse des motifs de défaillance | Texte libre au lieu d'une valeur codée |
| Cause | La raison sous-jacente (ex. : désalignement, contamination) | Analyse des causes profondes, prévention des défaillances récurrentes | Cause devinée, vide ou confondue avec le mode |
| Méthode de détection | Comment la défaillance a été détectée (opérateur, alarme, inspection) | Scoring de détectabilité dans la FMEA | Non enregistrée du tout |
| Début / fin d'immobilisation | Quand l'actif s'est arrêté et a repris la production | Disponibilité OEE, temps d'arrêt total | Arrondis ou renseignés a posteriori à partir de la mémoire |
| Temps de réparation | Temps actif de travail à la clé pour restaurer la fonction | MTTR | Confondu avec le temps d'immobilisation total |
| Pièces consommées | Composants et quantités utilisés | Analyse des coûts, planification des pièces de rechange | Enregistrées après coup, incomplètes |
| Action entreprise | Travail correctif réalisé | Bibliothèque de remèdes, réutilisation des connaissances | Fusionnée dans le champ cause |
Un point subtil mais critique : le temps d'immobilisation et le temps de réparation sont des champs différents. L'immobilisation est la totale du chronomètre entre l'arrêt et le redémarrage, incluant l'attente d'un technicien et l'attente de pièces. Le temps de réparation est le travail de réparation actif uniquement. Les stocker séparément permet ensuite de distinguer un problème de lenteur de réponse d'un problème difficile à réparer.
Parce que le mode de défaillance est ce qu'un technicien observe et la cause est ce qu'il infère. Le mode est généralement correct. La cause est souvent une meilleure estimation. Si vous les fusionnez dans une même case, vous ne pourrez jamais distinguer une observation fiable d'une hypothèse optimiste, et la qualité de vos données se dégradera silencieusement.
Les séparer permet aussi de répondre à la question de fiabilité la plus précieuse : le même mode revient-il toujours pour la même cause ? Reliabilityweb décrit le piège explicitement, avertissant que « le nouveau palier que vous venez d'installer pourrait lâcher 2 à 3 mois plus tard parce que la véritable cause n'a pas été résolue. » Ce sont les champs séparés qui font ressortir ce schéma.
Un code de défaillance est une valeur standardisée, sélectionnable dans une liste déroulante, qui classe une défaillance au lieu de la décrire en texte libre. Une taxonomie codée transforme des milliers de pannes en un jeu de données comptable. Le texte libre les transforme en un tas de notes non recherchables.
La norme de référence ici est la ISO 14224, la norme internationale pour la collecte et l'échange de données de fiabilité et de maintenance des équipements. Elle définit un langage commun de fiabilité : une taxonomie d'équipements en couches plus des catégories normalisées de données de défaillance couvrant les données d'équipement, les données de défaillance telles que la cause et la conséquence, et les données de maintenance telles que l'action de maintenance et le temps d'arrêt. Même en dehors du secteur pétrole et gaz où elle a vu le jour, l'ISO 14224 est la référence pour structurer les enregistrements de défaillance afin qu'ils se regroupent en un jeu de données statistiquement valide (ISO 14224:2016).
La leçon pratique pour toute usine : construisez un vocabulaire contrôlé de modes de défaillance et de causes par classe d'équipement, appliquez-le via des listes déroulantes et rendez le champ mode de défaillance obligatoire avant la clôture d'un ordre de travail correctif. Cette seule règle fait plus pour la qualité des données que n'importe quel outil d'analytique.
Les enregistrements de défaillance sont les données d'entrée des indicateurs de fiabilité principaux. Chaque indicateur est un ratio simple, mais chaque terme de ce ratio provient directement de vos enregistrements, ce qui explique pourquoi la qualité des enregistrements détermine la qualité des indicateurs.
| Métrique | Formule | Champs d'enregistrement consommés |
|---|---|---|
| MTBF (Mean Time Between Failures) | Temps de fonctionnement total / nombre de pannes | Nombre de défaillances, temps de fonctionnement entre enregistrements |
| MTTR (Mean Time To Repair) | Temps de réparation total / nombre de réparations | Champ temps de réparation, nombre de défaillances |
| Disponibilité OEE | Temps de production / temps de production planifié | Début et fin d'immobilisation sur chaque enregistrement |
Les formules sont volontairement simples. Le MTBF est le temps de fonctionnement total divisé par le nombre de pannes, et le MTTR est le temps de réparation total divisé par le nombre de réparations (LogicMonitor). Notez que les deux dépendent d'un compte précis des défaillances. Si les petits arrêts ne sont pas enregistrés, votre nombre de défaillances est trop bas et le MTBF semble artificiellement bon. Si les horodatages d'immobilisation sont imprécis, la disponibilité est erronée. Pour un traitement plus approfondi, voyez nos guides sur le MTBF et le MTTR et sur les arrêts non planifiés.
Une Failure Mode and Effects Analysis (FMEA) n'est valable que par l'historique de défaillance dont elle est issue. La FMEA classe les risques en utilisant la sévérité, l'occurrence et la détectabilité. Vos enregistrements de défaillance fournissent les données réelles d'occurrence (la fréquence d'apparition de chaque mode) et les données de détection (comment la défaillance a été détectée). Sans enregistrements codés, ces scores ne sont que des opinions. Avec eux, ce sont des preuves.
Des enregistrements propres alimentent également le classement de criticité des actifs et vous permettent de construire un programme de maintenance préventive piloté par les données plutôt qu'une estimation calendaire. Un mode de défaillance récurrent sur un actif critique est le déclencheur type pour convertir une réparation réactive en une tâche PM planifiée.
Le problème le plus courant est la cause devinée : un technicien clôt le travail, choisit une cause plausible dans la liste déroulante et passe à autre chose. Le second est les enregistrements manquants entièrement, où les arrêts courts ne sont jamais consignés. Ensemble, ils corrompent à la fois les données de cause et le nombre de défaillances, ce qui explique pourquoi Reliabilityweb rapporte que « 70 % de toutes les installations CMMS n'ont jamais réalisé avec succès une analyse de défaillance basique. »
Utilisez cette liste de contrôle pour auditer votre propre discipline d'enregistrement des défaillances :
La plupart des enregistrements de défaillance CMMS sont saisis après coup par un technicien qui reconstitue ce qui s'est passé. Fabrico change la source des données. Parce que Fabrico se connecte directement aux automates (PLC) des machines, les horodatages de début et de fin d'immobilisation sont capturés automatiquement depuis la ligne, et non saisis manuellement, de sorte que les données de disponibilité alimentant l'OEE sont précises plutôt qu'arrondies.
Pour le champ le plus difficile, la cause, Fabrico utilise la vision par ordinateur pour capturer la véritable cause de l'immobilisation au moment où l'arrêt se produit. Cela élimine le principal risque de qualité des données dans tout modèle de données de fiabilité : une cause devinée saisie des heures plus tard. La panne devient alors un ordre de travail numérique priorisé et prêt en pièces sur le téléphone du technicien, avec des checklists appliquées par QR, de sorte que l'action corrective et les pièces consommées sont capturées pendant l'exécution du travail, et non mémorisées après coup.
Le résultat est une boucle fermée du défaut à la réparation où l'enregistrement de défaillance est un sous-produit du travail, exact par construction. En tant que plateforme construite dans l'UE avec résidence des données dans l'UE, Fabrico conserve ces données de fiabilité à l'intérieur d'un périmètre de gouvernance clair. [INSÉRER ÉLÉMENT DE PREUVE VÉRIFIÉ - opérateur à confirmer]
Si vos enregistrements de défaillance sont pleins de causes devinées et d'horodatages arrondis, vos chiffres MTBF et OEE ne sont que des estimations. Voyez comment Fabrico capture la véritable cause et transforme chaque panne en données propres prêtes pour l'analyse.
Un ordre de travail est l'instruction pour effectuer une réparation. Un enregistrement de défaillance d'équipement est la preuve de fiabilité structurée que la réparation laisse derrière elle : l'actif, le mode de défaillance, la cause, l'immobilisation, le temps de réparation et les pièces. L'un enregistre ce qu'il faut faire, l'autre enregistre ce qui s'est passé et pourquoi, afin que cela puisse être compté et analysé ultérieurement.
Au minimum : ID d'actif, mode de défaillance (le symptôme observé), cause (la raison sous-jacente), méthode de détection, début et fin d'immobilisation, temps de réparation, pièces consommées et action entreprise. Le mode de défaillance et la cause doivent être des champs séparés et codés, et l'immobilisation doit être stockée séparément du temps de réparation actif.
Parce que le mode de défaillance est ce qu'un technicien observe et est généralement correct, tandis que la cause est ce qu'il infère et est souvent une hypothèse. Les garder séparés permet de distinguer les observations fiables des suppositions et de mettre en évidence si le même mode revient en raison de la même cause non résolue.
Le MTBF est égal au temps de fonctionnement total divisé par le nombre de pannes, et le MTTR est égal au temps de réparation total divisé par le nombre de réparations. Les deux proviennent directement des enregistrements de défaillance : le nombre de défaillances, le temps de fonctionnement entre défaillances et le champ temps de réparation. Des enregistrements inexactes ou manquants faussent les deux métriques.
ISO 14224 est la norme internationale pour la collecte et l'échange de données de fiabilité et de maintenance des équipements. Elle définit une taxonomie commune d'équipements et des catégories normalisées de données de défaillance, incluant la cause de la défaillance, la conséquence et le temps d'arrêt, afin que les enregistrements se regroupent en un jeu de données statistiquement valide. C'est la référence pour structurer les enregistrements de défaillance de manière cohérente.
Le problème le plus courant est une cause devinée : le technicien choisit une valeur plausible dans la liste déroulante après coup au lieu de capturer la véritable cause. Combiné aux arrêts courts non enregistrés, cela corrompt à la fois les données de cause et le nombre de défaillances, ce qui explique pourquoi la plupart des installations CMMS ne réalisent jamais avec succès une analyse de défaillance basique.
Connexion
Blog