Efficacité des Modules Maintenance dans les ERP. Les progiciels ERP (Entreprise Ressource Planning) proposent l ensemble des modules permettant de gérer une entreprise. Mais le module Maintenance est souvent assez mal traité voire mal paramétré ce qui le résume à une utilisation de Gérer les activités de la Maintenance, mais est inutile pour Gérer l amélioration et la Fiabilistion des équipements. La très grande majorité des modules Maintenance des ERP sont mal paramétrés, voir pas utilisés, par manque de volonté Managériale de travailler sur l analyse des causes de pannes. 1. Les constats : Le processus de traitement des Avis, les Demandes d Interventions sont souvent peu maîtrisés pour plusieurs raisons : Le vocabulaire de définition des symptômes est laissé à la libre apréciation des déclarants, ce qui entraîne des risques d interprétation et donc de fausses orientations sur des actions de Fiabilisation La codification des actions est souvent farfelue, et ne respecte pas la Normalisation Européenne de Maintenance Certains outrepassent leurs fonctions en orientant ce qu il faut faire et non se contenter de décrire le symptôme (tout simplement un Objet qui a un Défaut) Il n y a pas de filtrage dans la rédaction des Avis (Le Gate Keeper) pour fiabiliser le début du processus et donc entraîner des OT sans grande utilité, car non filtrés par une matrice de risque. Les comptes-rendus des interventions ne respectent pas les principes de la chaîne causale de l AMDEC. Par exemeple dans SAP, on parle de Profil de panne, ce qui ne veut rien dire et entraîne une confusion dans la tête de ceux qui rédigent les comptes-rendus. Voila le CR des Avis dans SAP : Les tables (Profils de Pannes et Codes Causes) sont élaborés par des intégrateurs de solutions informatiques, au mieux par des groupes de travail de techniciens maintenance, mais malheureusement qui n ont pas de culture Fiabiliste (Peu d entre eux connaisent les définitions précises des Modes de Page 1 sur 5
Défaillances et des Causes du vocabulaire de l AMDEC (Et dans l AMDEC, ou il n y a qu une colonne Cause, on met laquelle, la cause de la panne ou la cause première?) En finalité, il y a peu de processus de validation par l encadrement et dans la base est fréquemment inexploitable Le Management exige peu d analyses Fiabilistes et est très centré sur le Top Ten de ce qui coûte le plus cher, mais sans savoir réellement pourquoi!! De plus, il n y a pas la possibilité de déclarer dans tous les registres des modules Maintenance des ERP, le moyen de la détection (Qui existe cependant dans la Feuille d étude AMDEC). 2. Les conséquences Cette situation fréquemment rencontrée n entraîne pas les techniciens à correctement documenter les Comptes-Rendus des travaux, car ils ne savent pas souvent à quoi ça sert et à qui ça rend service (Analyse Fonctionnelle oblige). Il est vrai que depuis l apparition des nouvelles applications ou le paramétrage par l utilisateur permet une personnalisation importante, cette remarque est de moins en moins vraie à condition que le paramétrage respecte le vocabulaire de la Fiabilité. Heureusement que l activité des groupes de travail amène des propositions de modifications fonctionnelles basées sur les préoccupations, mais malheureusement basées sur l expérience passée sans grandes propositions prospectives. Le contenu des Compte-rendus d intervention : Dans une grande majorité des cas, les techniciens sont conduits à remplir des comptes-rendus d intervention sans qu ils aient participé directement aux modalités de rédaction des «symptômes», «causes», «remèdes», etc, encore moins à ce que l on va faire de leurs enregistrements si par bonheur une synthèse leur ait retournée. Il est fréquent de rencontrer de plus en plus, avec les ERP possédant des modules maintenance, que le paramétrage des menus déroulants est réalisé par des «experts» situés dans des bureaux et non confrontés au vocabulaire du terrain. Certains n y retrouvent pas leurs petits entre les codes/causes et les codes/pannes. La culture maintenance : L analyse de la typologie des formations dispensées en maintenance montre la situation suivante : La majorité des formations dispensées est axée sur les métiers professionnels (mécaniciens, hydrauliciens, pneumaticiens, électromécaniciens,..) certes nécesaires, mais pas suffisantes. Elles n intègrent pas toujours les concepts de maintenance et de résolution de problèmes. La formation d un électromécanicien peut lui permettre de câbler une armoire électrique, mais lui permet-elle de savoir la dépanner? La première action est d envoyer des techniciens chez les constructeurs pour se faire démontrer comment la machine fonctionne (avez-vous vu un constructeur qui montre à son client toutes les défaillances potentielles de son équipement?). En fait il n en sait rien, car une fois vendu, son équipement ne lui appartient plus et qu en conséquence, ne connaissant pas les conditions d exploitation, il est incompétent pour proposer un plan de maintenance crédible. L analyse des AMDEC Moyens fait par les constructeurs et souvent réalisés sans analyse fonctionnelle préalable (qui est une démarche couramment rencontrée dans d autres situations), conduit les constructeurs à repousser la responsabilité sur l exploitant en lui indiquant que si il souhaite que son équipement fonctionne, il n a qu à faire le préventif proposé. C est facile, car il reporte la responsabilité et les dépenses sur le client et évite de remettre pas en cause sa conception. Page 2 sur 5
Quelles formations «maintenance» sont négligées? : Les analyses fonctionnelles Les concepts de maintenance et les indicateurs de Fiabilité (MTBF/MTTR) La recherche des défaillances fonctionnelles à partir des IND 1 Les données de fiabilisation (FMDS 2 ) Les méthodes de résolutions de problèmes eficaces (Maxer,..) Les systèmes Experts de Diagnostic. NB : En 1990, un projet avait été fait qui consistait à créer un Atelier Logiciel Maintenance qui partait du principe suivant de transfert des données entre les différentes étapes suivantes : L AMDEC d un moyen de production doit permettre d identifier tous les Modes de Défaillance qui risque d arriver dans sa vie, (Inductif) La GMAO doit permettre d enregistrer ce qui arrive et de pouvoir le comparer à ce qui avait été prévu et de mettre à jour l AMDEC (Déductif) Le Système Expert qui a pour objectif de faire un retour d expérience en cumulant les infos pour aider à traiter les autres problèmes (Prospectif) Le concept avait fait l objet d une maquette opérationnelle sans intérêt des industriels et donc sans suite commerciale 3. Les incohérences : Il n y a très peu de liens entre la culture Fiabiliste et la culture Maintenance. Certains utilisent L AMDEC en conception (car il ne faut pas oublier que c est une démarche inductive qui a pour but de prévoir ce qui risque d arriver) D autres utilisent des démarches déductives (ce qui est réellement arrivé) Qui fait le lien entre ce qui risque d arriver et ce qu on vit tous les jours? Personne parce que les vocabulaires utilisés dans les différentes phases ne sont pas les mêmes. Le vocabulaire : La grande majorité des logiciels de GMAO demandent que lors d un compte rendu d intervention, le technicien rédige les informations du type «Symptômes», «Causes», «Remède». Les deux premiers mots sont constituants de l explication de la défaillance, le troisième est d une autre nature qui est l activité de la maintenance. Analysons la différence entre le vocabulaire de l AMDEC et celui généralement rencontré dans certaines GMAO : AMDEC Effet constaté Mode de défaillance Causes Détection Actions correctives ou préventives GMAO Symptômes???? (Profil de Panne dans SAP) Causes de panne??? (N existe pas) Remèdes 1 Investigations Non Destructives 2 Fiabilité, Maintenabilité, Disponibilité, Sécurité Page 3 sur 5
Le constat de cette situation est le suivant : Si le mode de défaillance n est pas rédigé dans un compte-rendu, il est impossible de faire de la fiabilisation d équipement, car l explication de la manière dont l équipement n a pas assuré sa fonction n est pas enregistrée. On est réduit à faire des statistiques de ce qu on a fait et non pourquoi on l a fait! Les actions correctives ou préventives sont rarement rédigées par les intervenants et la fonction méthode à peu de possibilités de la faire à postériorité par manque du mode de défaillance déclaré En fait pour intégrer la culture fiabilité, il faut se référer aux définitions suivantes : MODE DE DEFAILLANCE : Un mode de défaillance est la manière dont le dispositif ou le système peut s arrêter de fonctionner ou fonctionner anormalement Le mode de défaillance est relatif à chaque fonction de chaque élément Il s exprime en termes physiques (rupture, desserrage, grippage, fuite, court-circuit) CAUSE DE DEFAILLANCE : Une cause de défaillance est l anomalie initiale susceptible de conduire au mode de défaillance Elle s exprime en termes d écart par rapport à la norme (sous-dimensionnement, absence de frein d écrou, manque de lubrifiant, joint mutilé, connecteur mal encliqueté) À un mode de défaillance peut correspondre plusieurs causes et inversement On la trouve essentiellement dans les 7 M : Matériel : Equipement / Fonction / Sous-fonction Matière : Matière première/ Consommables / Pièces de rechange Mesure : Fiabilité du processus de mesure Main d œuvre : Compétences / Formation / Quantité Milieu : Salle blanche / Température / Equipement de sécurité Méthodes : Conception des équipements/doc. technique / Procédures / Formation Management : Décisions de la hiérarchie EFFET DE LA DEFAILLANCE : Un effet est la concrétisation de la conséquence subie par l utilisateur. PROBABILITE DE DETECTION : Une cause (et/ou un mode) de défaillance étant supposée apparue, on analyse et on dresse la liste de tout ce qui empêche cette cause et/ou ce mode de défaillance d arriver jusqu à l utilisateur On peut identifier : manque de capteurs et de détecteurs, contrôles impossibles 4. Les propositions Quatre d actions pourraient améliorer la situation : 1. La prise en compte par les éditeurs de GMAO des concepts fondamentaux de la Fiabilité pour éviter de provoquer un trouble dans les déclarations de codes causes et codes pannes (c est quoi un profil de panne?) en appliquant le vocabulaire de la Normalisation 2. La participation effective des acteurs chargés de faire les comptes-rendus dans les GMAO du vocabulaire de terrain à employer en respectant les définitions préalables. Cela éviterait de Page 4 sur 5
trouver des modes de défaillances du type Fuite d Huile dans la famille «Automate Programmable» 3. La validation du vocabulaire des Modes et des Causes par des Responsables Maintenance qui ont une culture de la Fiabilité et la formation des techniciens au vocabulaire de la Fiabilité (APR 3, AMDEC) 4. Mettre en place en Management de la Fiabilité. Jusqu à présent la GMAO a trouvé sa rentabilité sur l amélioration de la gestion des Pièces de Rechange, l optimisation et la planification des travaux, la meilleure répartition des activités entre les actions, correctives, préventives, réparations, améliorations, sans toutefois en faire des corrélations directes. On ne peut pas se réfugier derrière le manque affirmé de complexité et de convivialité des ERP par rapport aux GMAO sous Windows pour ne pas documenter les registres nécessaires, car des solutions existent d interfaces conviviales. Il reste un champ important à développer qui est sur le point «G» de gestion de l amélioration de la Fiabilité des équipements et du TRS 4 à condition de s intéresser plus à ce qui sort du processus de rédaction des Avis et en déduire ce qui doit y rentrer, cela permettrait déjà de faire le point sur les informations qui sont inutiles! Il reste de la responsabilité du Management d exiger une très grande précision dans la rédaction des comptes-rendus dans le but de lancer des recherches de causes premières, car si on ne demande rien on a rien Ce qui est valable pour les ERP, est également valable sur ce point précis de la Qualité des Comptes- Rendus pour tous les logiciels de GMAO. Jean-Paul Souris S.CONSULTANTS 3 Anlayse Préliminaire des Risques 4 Taux de Rendement Synthétique Page 5 sur 5