Une GMAO organise l’information et les travaux; elle ne rend pas automatiquement cette information fiable. Si une pompe apparaît sous trois noms, que les réparations sont enregistrées sur une ligne entière et que le texte de clôture dit seulement « fait », les analyses auront peu de valeur. Le problème peut venir du logiciel, mais aussi des règles de saisie, de la structure des actifs ou du processus de travail. Il faut tester ces hypothèses avant d’acheter une autre plateforme.
Choisir une question opérationnelle concrète
Commencez par une question telle que : quels actifs de cette ligne provoquent le plus d’arrêts répétitifs? Vérifiez si les données permettent réellement de répondre. Il faut relier l’événement au bon actif, distinguer arrêt et réparation, enregistrer les heures pertinentes et préciser le défaut. Si ces champs ne sont pas disponibles ou cohérents, construisez une amélioration ciblée au lieu de nettoyer indistinctement toute la base.
| Champ | Avant | Après |
|---|---|---|
| Actif | Pompe atelier / P12 / ligne 2 | Identifiant unique P-012; parent ligne 2; même identifiant au terrain. |
| Défaillance | Bris | Perte de débit; fuite constatée à la garniture; cause à confirmer. |
| Travail effectué | Réparé | Garniture remplacée, référence de pièce, temps et essai de remise en service consignés. |
| Temps | Une durée non définie | Temps d’arrêt et heures de main-d’œuvre distincts. |
Une liste de vérification des données maîtres
- Un identifiant stable par actif, avec une hiérarchie compréhensible et une règle pour les doublons.
- Des nomenclatures de pièces reliées au bon équipement et vérifiées selon la configuration installée.
- Des codes de défaillance assez simples pour être utilisés, mais séparant symptôme, mode et cause confirmée.
- Des champs de clôture définis, une distinction entre zéro, inconnu et non applicable, et une vérification par échantillon.
- Un responsable de chaque règle et un processus pour modifier les fiches sans créer une nouvelle version concurrente.
Ne pas transformer une hypothèse en cause racine
« Roulement défectueux » peut décrire une pièce, pas la raison de sa dégradation. Laissez une cause inconnue comme inconnue jusqu’à validation. Un dictionnaire de codes et des exemples de saisie réduisent les interprétations différentes entre équipes. ISO 14224 fournit un cadre pour les données de fiabilité dans des secteurs précis; son utilisation doit respecter ce périmètre, et non être présentée comme une exigence générale pour toute usine.
Ce qu’il faut corriger avant de déployer de l’IA
Une IA peut regrouper des textes ou détecter des tendances, mais elle ne rend pas exact un historique incohérent. Avant le pilote, définissez la question, un échantillon de référence validé par un spécialiste et les erreurs inacceptables. Contrôlez les droits d’accès et la confidentialité des données. Comparez le résultat à une analyse simple, puis faites vérifier les recommandations; aucune suggestion automatisée ne doit modifier seule une règle de sécurité ou un plan critique.
Pour commencer, retenez une famille d’actifs et examinez un échantillon d’ordres de travail avec les utilisateurs. Corrigez les règles qui empêchent la décision, formez l’équipe et contrôlez de nouveau le même type de dossier. Le succès se mesure à la qualité des décisions et à l’utilisation réelle des données, pas au nombre de champs obligatoires ajoutés.