12. Recommandations d'usage.
A la suite de l'étude de l'existant et de l'exploration
des données de Maximo sur plusieurs chantiers, nous sommes à
même de donner quelques indications pour corriger certains défauts
ou améliorer la saisie des informations d'équipement et de
maintenance.
Module EQUIPMENT:
- A l'examen des données d'historiques, on
s'aperçoit que tous les arrêts ("Downtime") ne sont pas
reportés dans le module équipement. Il semble que le principal
frein vient du fait que l'équipement n'est pas remis en service
automatiquement (statut UP) lors de la fermeture du "Work Order" qui a permis
de le mettre en arrêt (statut DOWN).
Actuellement, la notion de "Downtime" est faite sur des
formulaires standards à part de Maximo par les opérationnels des
chantiers.
Il existe une forte opposition des chantiers et de la base
pour inclure les "Downtime" dans Maximo. Certains font l'objet de
négociations avec le client et ne peuvent être inclus dans le
rapport final même s'ils ont généré des pertes
opérationnelles. Il existe aussi une notion de tarif client en fonction
du type de problème rencontré. L'aspect financier domine par
rapport aux aspects techniques même s'ils s'influencent mutuellement. Il
faudra que les directions statuent sur ce sujet.
- Rétablir la notion d'arrêt opérationnel
ou non. Cette différenciation existait dans la version
précédente de Maximo. Elle permettrait de pouvoir traiter le
point précédent sans pour autant générer des
alertes inutiles dans les rapports. On garderait dans ce cas un historique des
arrêts opérationnels ou non séparément.
- Utiliser l'onglet classification du module EQUIPMENT pour
entrer les caractéristiques d'équipements choisis dans la norme
ISO-14224 et ajouter ceux qui ne s'y trouvent pas en respectant la taxinomie.
Le champ "Classification" de la page principale devra disparaître au
profit de celle de la norme. On disposera toujours de la "Long Description"
pour donner les spécifications d'éléments non
classifiables.
- Etendre la classification à tous les
équipements du bord de façon à améliorer les
diagrammes de Pareto qui pourraient être utilisés. La
catégorie "Other" pourra être utilisée le cas
échéant pour inclure les éléments non classifiables
dont la description se trouve dans la "Long Description".
- Faire apparaître le champ "Failure Class" dans
l'écran principal des équipements. Attribuer une "Failure Class"
aux équipements suivant leur classification.
Module "Work Order":
- Améliorer les rapports dans les "Work Order"
correctifs en imposant la saisie des informations suivantes dans les "Long
description" qui contiennent le rapport de maintenance sous forme de texte non
formaté:
· Description détaillée du
problème.
· La cause du problème.
· Les actions entreprises pour le corriger.
· Le détail de ce qui permettrait d'éviter
le problème à nouveau.
Si la hiérarchie des "Problems, Causes & Remedies"
est mise en place ainsi que la mise en place de la norme ISO-14224, ces
informations seront complémentaires de celles données dans le
format imposé. Elles donneront des détails sur les
opérations exécutées alors que les codes permettront de
faire des statistiques plus générales.
- La phrase habituelle "job done as per job plan nothing
abnormal to report" se trouvant dans les "Long Description des "Work
Order" préventifs devra être remplacée par une autre
donnant des conseils de remplissage d'informations utiles du type:
Mesures, consommations, remarque sur l'état, statut des
pièces changées...
On peut proposer la phrase suivante:
"Enter any information regarding the result of the PM:
Measurement, consumptions, remarks about the status of the equipment and the
spare parts replaced".
- Ne pas hésiter à ajouter des
documents attachés dans l'onglet "Linked documents" aux informations du
rapport. Toutes les photos ou compléments techniques (tableaux,
graphiques, rapport de visite de fournisseurs...) sont à prendre en
compte pour valoriser l'expérience acquise. On préférera
le format Acrobat .PDF à tout autre.
- Le champ "Duration" du "Work Order" doit
devenir obligatoire et contenir la totalité des heures-homme
effectuées et non le temps de réparation. Dans la mesure
où chaque service doit faire son propre "Work Order", cela permettra de
faire une répartition entre services.
- Les champs "Start Date" et "Finish
Date" doivent devenir obligatoires et contenir des informations
valables sur le temps passé sur un problème.
- Le champ "Failure report date" de l'onglet
"Failure reporting" des "Work Order" doit devenir obligatoire et contenir la
date de la panne. Cette date pourra être utilisée pour les calculs
des statistiques de fiabilité comme le MTBF à la place du
début des opérations de maintenance.
- Il faut définir des règles pour
sélectionner la partie de l'arbre des équipements auxquels
rattacher le "Work Order" . Actuellement, les avis divergent et il est
difficile d'édicter une règle stricte tant le découpage
est varié. On peut cependant donner les règles de bon sens
suivantes:
4 Lorsque le défaut peut être
généralisé aux autres branches, remonter à la
racine des branches. Préciser toutefois dans le titre, à quel
élément on se réfère pour continuer à
pouvoir identifier une panne propre à un des équipements.
P.ex: Panne d'un automate généralisable aux
autres automates d'un système en contenant plusieurs du même
type.
4 Rester au niveau spécifique lorsque l'on veut donner
une information de l'ordre du sous-ensemble ou de l'entité
maintenable.
P.ex: S'il existe des parties électriques et
hydrauliques, classer les pannes dans la bonne catégorie et non dans la
racine de l'équipement.
4 Ne descendre au fond de l'arbre que pour des
éléments bien identifiés du sous-ensemble. Dans le cas
contraire, rester au niveau de la racine des branches de l'équipement
considéré et non au sommet d'un arbre général.
4 Garder une même profondeur d'arbre pour des
problèmes similaires. Regarder
l'historique existant des
problèmes similaires et garder la même logique de rapport.
4 Ne pas créer de maintenance dans les trois premiers
niveaux de l'arbre qui ne contiennent pas d'informations d'équipement,
mais plutôt un découpage. On pourra faire exception à cette
règle pour les parties certifications propres au chantier qui pourront
être placées au sommet de l'arbre.
- Les utilisateurs doivent générer un "Work
Order" correctif s'ils découvrent un défaut ne faisant pas parti
du processus de maintenance préventive normal.
On rappelle que la maintenance préventive ne doit
comprendre que: les opérations normales de maintenance (graissage,
serrage, mesures...) et changement de pièces d'usures (charbons,
lampes...) ou de consommables (huile, graisse...). Lorsqu'il y a recherche de
panne, il s'agit le plus souvent de maintenances correctives.
Par contre, les éléments de diagnostics comme
les échantillons d'huile ou la thermographie sont des maintenances
préventives. Ils devraient faire parties de maintenances
conditionnelles, mais cette pratique ne fait pas partie de notre organisation
de la maintenance (MBF).
- Faire un "Work Order" par service et non global.
Actuellement, sur certaines opérations de grosses maintenances, des WO
génériques sont créés en début
d'opération afin de regrouper les coûts. D'une part, les
coûts peuvent être facilement calculés par
équipement
avec récursivité sur les sous
équipements en sortant le rapport CO-BY-EQ du module équipement.
D'autre part, cela fausse les historiques, car ceux-ci ne sont pas
attachés aux bons équipements ni aux bons services.
- Ne pas enregistrer les mouvements de stock dans un "Work
Order" correctif, mais sous le type RM (pour routine maintenance). Cela
évitera de les inclure dans les décomptes des maintenances. On
fera de même pour les sorties de matériel consommable qui n'en
sont pas non plus. Les remarques ou alertes ne sont pas non plus à
mettre en CWO.
| 
