Amélioration du
retour d'expérience.
Méthodes de
recueil de données de fiabilité:
Nous avons vu que l'un des outils nécessaires à
la mise en place de la TPM reposait sur un recueil des informations de
maintenances et leur analyse en vue d'effectuer des actions correctives (de
type FRACAS). La version actuelle de Maximo telle que nous l'utilisons
gère les historiques de maintenance, mais ne permet pas d'analyse facile
ni de comparaison des données qui permettraient de cerner les
problèmes qu'ils soient techniques ou économiques. L'un des
moteurs de la TPM consiste à créer un système permettant
en plus des commentaires libres de pouvoir catégoriser les sources de
coûts, de pannes, les types de pannes et leurs conséquences. On
veut aussi pouvoir comparer les niveaux de fiabilité entre
équipements identiques fonctionnant sur des chantiers différents.
Ce type d'information impose une standardisation de la saisie d'un certain
nombre de données obligatoires qu'il faudra ajouter à Maximo.
Nous pourrions créer notre propre standard, mais le mieux serait de
s'inspirer de l'expérience déjà acquise par d'autres.
Il existe une norme internationale nommée:
ISO-14224:1999 "Industries du pétrole et du
gaz naturel"
"Recueil et échange de données de
fiabilité et de maintenance des équipements"
Cette norme offre des spécifications de recueil
d'information, d'échange et de contrôle de la qualité des
données de fiabilité dans le domaine des industries du forage,
production, raffinage, et distribution de produits gaziers ou
pétroliers.
Par contre, elle ne définit pas la façon dont
seront utilisées les données par la suite ni les moyens de les
analyser.
Elle est issue de l'expérience d'un projet nommé
OREDA (Offshore REliability
DAta) mené depuis les années 80 par le SINTEF et
DNV Norway avec initialement huit des plus grandes compagnies
pétrolières mondiales: BP, ENI, ExxonMobil, Hydro ASA, Conoco
Phillips, Shell, Statoil, TOTAL. Chevron Texaco a rejoint ce groupe depuis
2001.
Ce recueil d'information avait pour objectif principal
d'obtenir des données de fiabilité et de maintenabilité
afin de définir des niveaux de risques pour les personnes, les
équipements ou écologiques. Les données de OREDA ont
été publiées dans les "OREDA Offshore Reliability Data
Handbook" dont la dernière version est sortie en 2002. Une nouvelle
révision du standard devrait sortir vers 2005 (Phase VII).
Certaines études prouvent qu'une maintenance efficace
ne peut se faire sans une collecte et une analyse des données de
défaillance, de modes de défaillances et des activités de
maintenance [MOUB]. D'ou l'intérêt de disposer d'une normalisation
de collecte, d'échange d'information de maintenance. L'analyse des
données ne fait pas partie de la norme.
La spécification des données collectées
permettra d'effectuer les analyses suivantes:
- Sécurité, fiabilité,
disponibilité et maintenabilité des systèmes.
- Planification, optimisation et réalisation des
tâches de maintenance.
- Lors de la conception d'équipements industriels
nouveaux ou pour remplacer des équipements existants et les
configurer.
- Analyse du coût de cycle de vie.
Le format normalisé des données permettra les
échanges, les comparaisons entre différents interlocuteurs ainsi
que le contrôle de la qualité des informations
enregistrées.
Le texte suivant reprendra l'essentiel de la norme et donnera
chaque fois les indications relatives à notre application. On tentera de
faire ressortir ce qui est utilisable en tant que tel et de définir ce
qui devrait être ajouté ou amélioré sans toutefois
entrer dans l'étude complète de la migration qui demandera un
travail plus approfondi.
Certains éléments de la norme seront
notés en référence et ne seront pas reproduits dans ce
document. Les annexes fournies dans la norme sont données à titre
informatif et ne constituent pas un cadre rigide même si elles
correspondent à des implantations existantes. Nous trouverons plus
d'informations applicatives dans les documents publiés par le projet
OREDA, mais la norme reste la référence pour la mise en
oeuvre.
Guide pour l'obtention
de données de qualité:
La mise en place de cette norme repose sur un certain nombre
de mesures à prendre afin de garantir une saisie de données de
qualité. Elle recommande de se poser un certain nombre de questions
auxquelles nous allons répondre:
- Examen des sources de données:
Les sources de données de défaillances et de
maintenance proviendront des rapports de maintenance et de "Downtime" du module
"Work Order Tracking" de Maximo. Toutes ces informations sont saisies par les
opérateurs des chantiers. Il n'existe aucune saisie automatique dans
Maximo. Les écrans de Maximo devront être adaptés pour
inclure les informations obligatoires préconisées par la
norme.
Les informations d'équipement proviendront du module
équipement après modification des écrans. Cela consistera
principalement en l'addition de catégories d'équipement et des
données spécifiques qui leur sont propres. Les données
spécifiques d'équipement existent pour une grande partie, mais
devront être transcrites de la "Long Description" vers le format
imposé par la catégorie d'équipement.
- Objectif de la collecte:
Les données de fiabilité et de maintenance
peuvent servir à cinq types d'applications décrites dans l'annexe
D de la norme. Chacune d'elles nécessitera un certain nombre
d'informations dont la saisie sera obligatoire ou non suivant les cas. Il nous
faudra choisir le ou les types d'applications adaptés à nos
besoins.
1) Augmenter les objectifs en terme de sécurité
de fonctionnement et diminuer les risques (EQR).
2) Optimiser l'utilisation des équipements au travers
d'une maintenance appropriée (FMD). Les coûts de maintenance plus
élevés doivent être compensés par une meilleure
performance de l'installation.
3) Maintenance basée sur la fiabilité (MBF): Il
s'agit d'un type de maintenance ou les mesures sur les équipements
permettent d'obtenir des informations de fiabilité qui font partie des
historiques au même titre que les informations manuelles.
4) Permettre de comparer les performances de fiabilité
de différents équipements (EVP).
5) Analyse du Coût de Cycle de Vie (CCV) et
possibilité d'effectuer des comparaisons entre équipements.
L'objectif premier est d'obtenir des données de
Fiabilité, de Maintenabilité et
de Disponibilité (FMD)
destinées aux services de maintenance du siège social et aux
superviseurs de maintenance.
Il existe aussi un besoin concernant le calcul du
Coût de Cycle de Vie
(aussi nommé LCC), mais il s'agit d'une utilisation annexe qui ne fait
pas directement partie du projet même si l'analyse des coûts ne
peut être dissociée de la maintenance. Le produit Maximo ne
dispose pas de toutes les informations pour fournir la totalité des
coûts associés à un équipement (coûts de
stock, du personnel, de la logistique, d'arrêts...). Les données
de Maximo devront être associées à d'autres pour fournir
ces informations.
Il n'existe pas de saisie automatique de données de
maintenances dans Maximo (compteurs horaires ou donnés de Maintenance
Basée sur la Fiabilité ou MBF). Ce n'est pas encore une pratique
courante. Les données MBF actuelles sont issues des mesures d'huile,
isolement et thermographie. Nous n'en tiendrons pas compte dans cette
étude. Ces informations lorsqu'elles existent sont traitées dans
le cadre des maintenances préventives. Il n'est pas encore
envisagé de monter une maintenance de type MBF. Nous ne pensons pas en
utilisant cette norme migrer vers une maintenance de type MBF (ou RCM) qui
nécessiterait une trop grande rigueur pour notre type
d'environnement.
La sécurité peut dans un premier temps
être considérée comme une conséquence d'une bonne
maintenance même si elle nécessitait un traitement à part
pour certains équipements. En offshore, elle sera traitée au
travers des indicateurs "ISM" qui servent à spécifier une
certification couvrant tous les équipements de sécurité du
navire. Les données FMD incluent l'ensemble des données de
sécurité.
Le fait de choisir les données FMD donne une des
contraintes de saisie les plus fortes. Cela veut dire que si toutes les
données FMD sont disponibles, nous pourrons obtenir les données
des autres applications hors MBF qui requièrent en plus la notion
"Activité de maintenance" (Tableau Annexe B4).
La sélection des données obligatoire par type
d'application décrite dans l'annexe D n'est qu'une recommandation et
nous pourrons y ajouter toute donnée complémentaire.
- S'assurer de la qualité des données de
défaillances:
La saisie des données de maintenance se fait dans le
module "Work Order" où l'on peut mettre un équipement en
arrêt (Downtime) et où sont saisis les rapports des maintenances
préventives et correctives.
Lors de la saisie des "Work Order" correctifs, nous disposons
des informations décrites dans le tableau suivant, certaines sont
obligatoires (colonne OB) d'autres non. Nous allons détailler pour
chaque champ, les valeurs qu'ils peuvent prendre et les commentaires subjectifs
sur leur validité (Table 17). Notre jugement est issu de l'examen des
données de deux chantiers offshore représentatifs. Ces chantiers
sont ceux sur lesquels ont été testés les prototypes des
autres chapitres. Il est volontairement sévère. Nous donnerons
une note sur 5 pour chaque champ afin de juger de la qualité des
informations entrées.
WORKORDER
|
Valeur saisie
|
OB
|
Commentaire
|
Note
|
N° d'équipement
|
O
|
L'équipement peut être choisi à plusieurs
niveaux de l'arbre suivant l'utilisateur. Il n'existe pas de consigne
particulière. Seul le bon sens prévaut.
|
4
|
Work Type
|
O
|
Les valeurs possibles sont:
ALT Alerte. SM Safety
maintenance.
CM Maintenances correctives.
PM Maintenances préventives.
RKS Remarques. RM Routine
maintenance.
RPT RMS report (offshore only).
Les maintenances de type SM ont été
abandonnées.
La sélection PM est indiquée automatiquement
lors de la génération des PWO dans le module PM tous les 15
jours.
Les sélections autres que CM sont très peu
utilisées. Autre que pour PM & CM, il n'existe pas de règle
d'usage. Certains ajustements de stock ou remarques sont mis dans des CM sans
différenciation utilisable. De nouvelles consignent indiquent d'utiliser
RM à la place.
|
4
|
Sub Work Type
|
N
|
Il peut prendre les valeurs suivantes:
NDT Non destructive test.
CAL Calibration.
INS Insulation. CMS
Continuous Machinery Survey.
ANA Analysis. MPI Magnetic
Particle Test.
DRN Drainage. SJ Survey jobs
(Lloyds, ABS, BV, DNV).
OTHER
Ce champ n'est pratiquement pas utilisé en CM sauf
parfois pour les valeurs CAL et INS.
|
3
|
Priority
|
N
|
Optionnel, valeurs "Normal" ou "High level". Très peu
utilisé.
|
1
|
Failure code
|
N
|
Non utilisé.
|
0
|
Problem code
|
N
|
Non utilisé.
|
0
|
Start Date
|
N
|
Contiens la date de début des opérations de
maintenance. Son remplissage n'est pas formalisé.
|
4
|
Finish date
|
N
|
Par défaut, il s'agit de la date ou le WO est
passé en statut COMP. Il devrait contenir la date de finition des
travaux. Elle doit être obligatoirement après la date de
début. Son remplissage n'est pas très formalisé, mais il
semble correct sur quelques chantiers.
|
4
|
Duration
|
N
|
Durée des travaux en heure-homme. Elle devrait inclure
les temps de préparation, rangement et d'écriture des rapports
ainsi que ceux liés à cette maintenance. Ce n'est pas souvent le
cas. Il semble toutefois y avoir une certaine cohérence entre deux
travaux identiques. De nouvelles consignes ont été données
pour le remplissage de ce champ avec des données valides.
|
4
|
Meter reading
|
N
|
Ce champ texte optionnel devrait contenir la valeur du
compteur de l'équipement lorsque la panne s'est produite. Il s'agit
d'une simple information et ne peut être utilisé d'une
façon sure. Il est très rarement utilisé.
|
1
|
%Completion
|
N
|
Ce champ optionnel contient le % de réalisations des
travaux. Il n'est pas systématiquement mis à jour
régulièrement. Le plus souvent, il n'est mis à jour que
lors d'un changement de statut.
|
2
|
Reported by
|
N
|
Il s'agit d'un champ texte libre. Pas de contrôle de la
saisie, car les personnes physiques ne sont pas répertoriées.
|
1
|
Lead Craft
|
O
|
Le "Lead Craft" contient la liste des différents
départements du chantier. Il s'agit du département pour lequel on
travaille et responsable de l'appareil ou se passe l'intervention. Il peut
être différent du "Crew" pour lequel travaille l'intervenant.
|
4
|
Crew
|
N
|
L'équipe d'intervention. La différence avec
"Lead Craft" n'est pas claire.
|
3
|
Supervisor
|
N
|
Optionnel, contient la liste des titres des superviseurs. La
dénomination n'est pas claire par rapport aux "Lead Craft" et "Crew".
|
3
|
Modified by
|
N
|
Saisie automatique du nom de Login de l'utilisateur. Il s'agit
d'un texte libre.
|
3
|
Modified date
|
N
|
Date à laquelle les modifications ont été
faites sans lien avec le statut du WO.
|
3
|
Status Date
|
X
|
Ce champ contient la date de dernière modification du
statut du WO. Elle correspond assez bien à la date à laquelle
s'est passé l'événement qui a fait changer le statut.
|
3
|
Reported date
|
X
|
La date de création du "Work Order". Elle n'a pas de
lien avec la date ou s'est produit le problème. Il s'agit de la date du
premier état WAPPR pour les CM, celle de la génération des
maintenances pour les PM.
|
5
|
Report downtime
|
X
|
Ce menu permet d'entrer des arrêts après coup
alors que l'équipement est déjà retourné en
service. On doit entrer les dates de début et de fin de l'arrêt
ainsi que le "Downtime code". Les historiques enregistrent un état UP et
un état DOWN aux dates entrées.
Ce menu est peut utilisé et les "Downtime code" ne sont
pas toujours entrés. Lorsqu'il est utilisé, les dates sont
justes. Les raisons qui font que ce menu est peu utilisé sont purement
politiques, car certains arrêts ne sont pas comptabilisés ou
l'objet de négociations et ne doivent pas apparaître en tant que
tels.
|
4
|
Change Eqpt statut UP/Down
|
X
|
Permet de mettre un équipement dans un états
opérationnel ou non en entrant une date et un "Downtime code".
Même statut que le précédent.
|
4
|
Failure Report Date
|
N
|
N'est jamais utilisé (onglet "Failure report").
|
0
|
Failure Classe
|
N
|
N'est jamais utilisé (onglet "Failure report").
|
0
|
|
|
|
|
Table 18 Estimation de la
qualité de saisie dans Maximo.
Le tableau qui précède (Table 17) nous permet de
dire que la qualité de saisie des données de Maximo peut
être grandement améliorée. La compétence des
utilisateurs ne peut être remise en cause la plupart du temps. Il s'agit
plutôt d'un manque de formaliste, il est vrai assez difficile à
mettre au point dans notre type d'environnement. Nous travaillons dans un
milieu dispersé ou l'information a parfois du mal à circuler.
Un certain nombre d'informations devront être rendues
obligatoires et d'autres redéfinies pour en expliciter le contenu aux
utilisateurs de façon plus formelle. La dernière partie du projet
donnera des indications pour améliorer les saisies des données
existantes. Les données de défaillances additionnelles
nécessaires à l'implantation de la norme seront définies
dans la suite du document.
- Identification des sources de données et des
périodes:
La période d'exploitation des données
démarre avec l'implantation de Maximo sur l'appareil. Certains appareils
qui ont été rachetés d'autres sociétés
possédaient des historiques de maintenances, mais peu d'entre eux ont
été repris dans Maximo. Le plus souvent, l'ancien outil de
gestion de la maintenance est gardé comme outil indépendant, mais
uniquement pour la consultation des historiques. Il n'existe pas de liens
immédiats entre les produits anciens et Maximo.
Il se posera toutefois le problème des données
historiques des maintenances existantes qui ne possèdent pas de notions
de défaillances.
Nous ne prendrons donc en compte les données
présentes dans Maximo qu'à partir du moment ou seront
implantés les codes de défaillances et les nouvelles
spécifications d'équipements.
Il serait possible de reprendre les historiques et de leur
attribuer des codes de défaillances. Mais l'étendue du travail
pour chaque chantier ne permettra certainement pas d'effectuer cette
opération. Tout au plus pourrions-nous le faire sur des
sélections d'équipements principaux dont le suivi présente
un fort intérêt économique.
- Vérification des méthodes de collecte de
données:
Il n'existe pas de méthode automatique de saisie des
données dans Maximo. L'ensemble est manuel et très
dépendant de la formation de l'utilisateur. Ces derniers devront
être formés aux standards de saisie que nous allons définir
à l'aide de cette norme. Les saisies sont effectuées pour une
part par les opérateurs de maintenance, contrôlées par les
HOD et en final par les TC. Ce ne sont pas les utilisateurs finaux de ces
données.
Les données de fiabilité des équipements
seront principalement utilisées a posteriori par les personnels
superviseurs ou par les responsables de la maintenance du siège de
Houston. Toutefois, la qualité de saisie ne pourra être atteinte
que si les utilisateurs n'appartenant pas à ce groupe voient les
résultats de leurs saisies. De fortes contraintes de saisie sans
résultats visibles par les opérateurs de maintenance pourraient
entraîner des dérives. Si la norme est mise en place, il faudra
tenir compte de ces contraintes et remonter certaines informations au niveau
des chantiers. Garder l'information uniquement dans des sphères
élevées serait une grave erreur.
- Plan du processus de collecte:
Il existe deux types principaux de rapports de maintenance:
Les maintenances correctives et les maintenances correctives. Le processus de
collecte des informations est déjà formalisé et ne
nécessite pas de restructuration profonde. Il a déjà
été décrit dans l'analyse de l'existant (voir Fig.11).
Seules des données complémentaires devront être saisies
lors des rapports de maintenance. Cela ne concernera pas nécessairement
la totalité des équipements du chantier, mais les plus
significatifs pour le fonctionnement opérationnel de l'unité.
Cela inclura ceux de la norme plus une liste additionnelle à
définir.
- Plan de formation du personnel à la saisie des
données:
Les nouvelles normes de saisie seront intégrées
aux formations Maximo et diffusées sous forme d'additifs à la
partie PMS des manuels de référence normalisés de la
société (Q-SMS).
Ils feront l'objet de documents de référence
additionnels. Seuls ces additifs seront distribués localement aux
différents départements jusqu'à mise à jour du
Q-SMS.
Il existe déjà un plan de formation du personnel
impliqué dans la maintenance et utilisant Maximo. Les supports de
formation devront inclure ces nouvelles normes de saisie et faire l'objet d'une
description spécifique durant le cours. On pourra prévoir des
supports plus spécifiques pour les personnes chargées du
contrôle de la qualité des données saisies (superviseurs,
HOD, TC).
- Assurance qualité de la collecte de
données: Annexe C de la norme.
La qualité des saisies des "Work Order" est
déjà contrôlée à deux niveaux avant qu'ils
soient fermés: Par le HOD lorsque le "% completion" est à 100%.
Le HOD ne le passe dans l'état COMP que si la saisie est correcte et les
champs renseignés. Il est ensuite vérifié par le TC avant
sa fermeture (CLOSE).
L'assurance qualité des données se fera par
l'intermédiaire des superviseurs des différents domaines et lors
du passage de ceux du siège social de Houston. Ceux-ci ont
déjà pour rôle de contrôler le contenu
(cohérence, complétude, périodicité...) des champs
et des commentaires libres inscrits dans les maintenances de Maximo. Leur
rôle sera ainsi amplifié pour inclure la qualité des
données faisant partie de la norme. Cela inclura les données
spécifiques d'équipement et le contrôle du contenu des
WO.
Il nous faudra créer des outils d'audit de la
qualité des données sur des échantillons de données
d'équipement et de WO préventifs et correctifs. Cela devra
inclure des informations concernant les causes d'écarts et de mauvaise
interprétation.
Formats des
données d'équipements, de défaillances et de
maintenance:
Les trois chapitres qui suivent donnent la liste des
informations nécessaires faisant partie de la norme et les mettent en
correspondance avec les informations disponibles dans Maximo.
La norme décrit trois formats de données
nécessaires pour s'assurer que les données sont
réutilisables. Il s'agit des données d'équipement, de
défaillances et de maintenance.
Les équipements:
La normalisation des catégories d'équipements
est essentielle pour pouvoir comparer les données entre elles d'un
chantier à l'autre, mais aussi avec des données externes
provenant d'autres sources ("OREDA handbook", constructeurs...). Elle sera
construite sous forme d'arbre dont le niveau dépendra de la
complexité de l'équipement et du niveau de détails requis.
L'arbre dont le niveau le plus haut est la catégorie d'équipement
doit indiquer les sous-équipements ainsi que les interfaces avec
l'environnement. La norme définit quatre niveaux:
- La catégorie d'équipement,
- le type,
- le sous-ensemble,
- l'entité maintenable (EM).
Les données de fiabilité devront être
rattachées à un niveau de l'arbre en fonction de leur usage.
La norme définit un certain nombre de données
nécessaires et optionnelles à la description d'un
équipement. Nous allons reprendre celles du module EQUIPMENT qui nous
paraissent les plus réalistes par rapport à notre application.
Catégorie
|
Ss-Catégorie
|
Données
|
Données de Maximo
|
Identification
|
Emplacement
|
Numéro d'identification
|
EQNUM et DESCRIPTION. C'est l'arbre existant dans Maximo.
|
Classification
|
Catégorie d'unité d'équipement. (a)
Type d'équipement. (a)
Application. (a)
|
"Catégories" et "Type" peuvent être entrés
dans l'onglet "Specifications" sous forme de "Classification" et
"ss-classifications". (Specs)
N'est pas utilisé dans notre version.
"Application" n'a pas d'équivalent, mais peut être
inclus dans les caractéristiques de conception.
|
Données d'installation
|
Nom de l'installation ou code. (a)
Type d'installation. (a)
Type d'opérations. (a)
Zone géographique.
|
Ce type d'information est enregistré dans la "Longue
description" (LD) de l'équipement à la racine de
l'arbre ou dans les "Specs" (à définir).
On y trouve les spécifications complètes de
l'appareil.
|
Données d'unité d'équipement
|
Description de l'unité d'équipement.
Numéro unique (N°série ou autre).
|
Dans la LD ou "Linked documents" (format PDF
préféré).
Champ SERNUM.
|
Conception
|
Données du fabricant
|
Désignation du fabricant.
Modèle.
|
Champ VENDOR.
Champ MANUFACTURER.
Champ ASSETNUM.
|
Caractéristiques de
conception
|
Suivant la catégorie d'équipement:
Puissance, vitesse, pression... (a)
|
Contenu dans la LD.
Maximo inclut ce type de renseignement dans un onglet
"Specifications". Les spécifications entrées sont
dépendantes des sous classifications sélectionnées.
N'est pas utilisé dans notre version.
|
Application
|
Exploitation en condition normale
|
Type de redondance.
Mode de fonctionnement.
Date d'installation.
Périodes de surveillance
calendaire.
Durée de
fonctionnement/période.
Nombre de sollicitations/période.
Paramètres de fonctionnement. (a)
|
Pas d'équivalent. Dans "Specs".
Pas d'équivalent. Dans "Specs".
Champ INSTALDATE.
Pas d'équivalent.
Compteurs horaires.
Pas d'équivalent.
Pas d'équivalent. Dans "Specs".
|
Facteurs d'environnement
|
Extérieur (b) et intérieur (c).
(extrême, modérée, favorable)
|
Pas d'équivalents.
Peut-être inclus dans "Specifications".
|
Commentaires
|
Compléments
|
Fiches techniques.
|
Peut être inclus en texte libre dans la LD ou encore comme
document attaché pour les documents autres que du texte simple (format
PDF de préférence).
|
|
|
|
|
Note: Les caractères en
gras indiquent les éléments nécessaires
à la norme pour une application FMD.
Note: Les caractères en italique
indiquent le minimum requis pour la norme.
|
a) Voir l'annexe A de la norme pour consulter les listes
proposées.
b) Paramètres à prendre en compte: Protection de
l'enceinte, vibrations, humidité, corrosion...
c) L'environnement interne de l'équipement.
Acidité, pressions chaleur...
|
|
Table 19 Données
d'équipement ISO-14224.

L'annexe A définit (à titre indicatif) les
caractéristiques des équipements à partir des informations
suivantes:
Figure 39 Hiérarchie
des équipements ISO-14224.
- Catégorie d'équipement: P.ex, "Moteur
électrique".
Directement applicable en tant que "Classification" dans le
module équipement. Chaque équipement ne peut appartenir
qu'à une catégorie. Le lien entre catégorie et
désignation de l'équipement dans Maximo doit être univoque.
Dans le cas contraire, la classification n'est pas applicable. Il faudra soit
la modifier ou descendre à un niveau inférieur de l'arbre.
P.ex: "053101001 Diesel Engine #1 (Eng+Alt)" contient deux
catégories, "Engine" et "Alternator". La classification n'est pas
applicable.
- Type d'équipement: P.ex, Continu ou
Alternatif.
Directement applicable en tant que "SubClassification" dans le
module équipement. Chaque équipement ne peut appartenir
qu'à un type qui lui-même est lié à une seule
catégorie. Dans le cas contraire, descendre dans l'arbre pour assigner
les classifications.
P.ex: "053101002 Diesel Engine #1 Wartsila" appartient
à la catégorie "Combustion engine". Le titre indique aussi le
type de l'équipement qui est "Diesel".
- L'application: P.ex, Energie de secours, Energie
principale, Secours incendie.
N'a pas d'équivalent dans les écrans Maximo.
Elle pourra être incluse dans les spécifications.
- Les notions de sous-ensemble et d'entités
maintenables (EM):
P.ex, pour les "Sous-ensemble": Moteur, Circuit de commande,
Lubrification.
P.ex, pour les EM du système de lubrification:
Réservoir, filtre.
Ces deux valeurs sont communes à tous les types d'une
catégorie. Chaque sous-ensemble contient un certain nombre
d'entités maintenables.
Cela nécessitera la création de deux niveaux de
classification supplémentaires dans le module "Inventory", "Asset
Catalog setup". Actuellement, l'application ne propose que deux niveaux, mais
cinq sont possibles. Il faudra faire apparaître les champs dans le module
équipement et "Asset Catalog setup" à l'aide du "Centura Object
Nationalizer" qui permet de paramétrer les écrans de Maximo.
- Les données spécifiques à la
catégorie: P.ex, Puissance, vitesse.
Directement applicable dans l'onglet "Specifications" du
module équipement. Il faudra créer les listes dans le module
"Inventory", "Asset Catalog setup".
Ces données ne seront rattachées qu'aux niveaux
des "catégories" ou "catégorie+type" et non aux niveaux
inférieurs. Le choix de l'un ou l'autre dépendra de la
façon dont a été conçu l'arbre des
équipements dans Maximo. Toutefois, rien n'empêche d'ajouter
celles qui nous paraîtrait nécessaire à d'autres niveaux ou
d'inclure des informations non présentes dans la norme.
- Lorsque c'est applicable, les données
environnementales:
P.ex, Présence de gaz, pression, débit.
Elles pourront apparaître dans la liste des
données spécifiques à la catégorie.
- A chaque catégorie d'équipement sont
associées des listes de "Modes de défaillances". Il faudra faire
apparaître le champ FAILURECODE dans le module équipement à
l'aide du "Centura Object Nationalizer" et créer ces valeurs dans le
module "Failure codes".
Note: Le "Failure Code" est aussi appelé "Failure
Class" dans Maximo.
Les catégories d'équipements traités sont
les suivants dans le domaine "Equipement de procédés":
- Moteurs à combustion.
- Compresseurs.
- Unités logiques de commande.
- Générateurs et moteurs électriques.
- Systèmes incendie et gaz.
- Turbine à gaz.
- Echangeurs thermiques.
- Capteurs et procédés.
- Pompes.
- Turbines de détente.
- Soupapes et robinets.
- Capacités et procédés de stockage.
Les parties "Equipement sous-marins" et de "Complétion
de puits" ne sont pas applicables telles qu'elles. Elles sont très
adaptées à la production et non à la partie forage.
La partie "Equipement de Forage" est réduite à
sa plus simple expression, car elle ne concerne que les équipements
"Tête d'injection motorisée" qui ne sont en général
utilisés que lors des forages déviés.
La majorité des catégories équipements
sont décrits dans les annexes, mais il nous faudra créer nos
propres caractéristiques pour celles qu'il manque. On peut citer dans un
premier temps, les plus importantes:
- "Equipement sous-marin": BOP, acoustique.
- "Equipement de forage": Tiges, risers.
- "Equipement marine ou positionnement": DGPS, gyroscopes,
radio/navigation, télécoms.
La majorité de nos chantiers sont déjà
équipés de Maximo et les arbres d'équipements existent
déjà. Les trois premiers niveaux de l'arbre sont trop
génériques pour correspondre à la classification de la
norme. Ils correspondent respectivement au chantier (racine de l'arbre), aux
grandes familles d'équipements et aux sous ensembles ou systèmes.
Les équipements ne sont décrits qu'à partir du
quatrième ou cinquième niveau. C'est à partir de ces
niveaux que l'on pourra appliquer les classifications et/ou de "Failure code"
à chaque branche des équipements.
Exemple d'arbre d'équipement:
Equipement
|
Catégorie
|
Type
|
Sous-ensemble
|
Entité maintenable (EM)
|
053 Drill Ship Pride Angola
|
Drill Ship (catégorie à créer pour chaque
type de chantier)
|
0531 Power & Associated
|
Regroupement générique.
|
053101 Main Generators
|
Regroupement générique.
|
053101001 Diesel Engine #1 (Eng+Alt)
|
Pas de catégorie applicable, car cela regroupe moteur et
générateur.
|
053101002 Diesel Engine #1 Wartsila
|
Moteur à Combustion (CE)
|
Moteur Diesel (DE)
|
Pas de Sous-ensemble ni EM.
Données spécifiques entrées à ce
niveau.
|
...
|
|
|
|
|
053101011 Fuel feed pump
|
CE
|
DE
|
Unité du moteur à combustion
|
Pompe à carburant
|
053101015 Starting Equipement
|
CE
|
DE
|
Système de démarrage
|
Unité de démarrage
|
...
|
|
|
|
|
053101003 Alternator/Diesel Eng #1
|
Générateur Electrique (EG)
|
Entraîné par moteur (MD)
|
Pas de SS-Ensemble ni EM.
Données spécifiques entrées à ce
niveau.
|
|
|
|
|
|
Il ne sera pas toujours facile de faire correspondre la
hiérarchie de la norme avec celle des équipements, car les arbres
ne sont pas superposables. Il conviendra de vérifier si la
hiérarchie existante peut être changée ou
re-découpée sans remettre en cause les historiques de maintenance
ni les maintenances préventives qui leurs sont associées.
Les données spécifiques ne seront
définies qu'aux niveaux des "catégories" ou
"catégorie+type". Il est toutefois difficile de donner des règles
précises, car tous les arbres ne sont pas identiques entre chantiers.
La norme spécifie d'indiquer les sous-ensembles et
"Entités Maintenables" (EM) dans les saisies des données de
défaillances. Dans notre cas, ils seront implicites et contenus dans le
numéro de l'équipement, car ces champs n'existent pas dans
Maximo. Le numéro d'équipement est entré dans le "Work
Order" avec les autres informations de défaillance.
La majorité des informations requises par la norme
existent déjà dans les saisies actuelles.
Les données spécifiques sont renseignées
la majorité du temps dans la "Long Description" (LD). L'onglet
"Specification" commence à être utilisé depuis peu et les
données de la LD y sont transférées progressivement. Les
données spécifiques à chaque catégorie
d'équipement n'ont pas été créées à
partir des données de cette norme.
La conversion des données spécifiques entre les
LD et le nouveau format devront être faite manuellement et cela
représentera un gros travail de saisie.
La conversion des spécifications existantes (hors LD)
vers le nouveau format pourra être faite automatiquement. Cela
nécessitera une comparaison entre ce qui est proposé par la norme
et les 21 catégories existantes.
Il est prématuré de juger de la
faisabilité. Il nous faudra examiner les possibilités
d'adaptation et juger de l'intérêt de le faire. On notera que cela
ne concernera que les équipements décrits dans la norme ainsi que
ceux que l'on aura souhaité y ajouter et non l'ensemble.
Les données de défaillances:
Cette partie concerne principalement les données de
maintenances correctives. L'ensemble des défaillances doit être
consigné dans Maximo avec un minimum d'informations nécessaires
à leur exploitation. Ce tableau résume les informations
recommandées par la norme et celles qui sont le minimum
nécessaire.
La majorité de ces informations sont déjà
présentes dans notre version et sont contenues dans les "Work Order"
correctifs. La différenciation entre une donnée de maintenance
(préventive) et un rapport de défaillance (corrective)
étant faite par le "Work Type".
Maximo dispose d'un module permettant de créer une
hiérarchie de "Failure Class" et "Problems,
Causes, Remedies". Ce module n'est pas utilisé dans notre configuration
actuelle. Il devra être renseigné pour être utilisé
dans les rapports de maintenance.
Catégorie
|
Donnée
|
Description
|
Données de Maximo
|
Identification
|
Enregistrement de la défaillance
|
Numéro unique
|
Numéro "Work order" corrective: WONUM.
|
Emplacement de l'équipement
|
Numéro d'identification de l'équipement
|
Numéro d'équipement: EQNUM.
|
Données de défaillances
|
Date de défaillance
|
Date de détection
|
Pas d'équivalent. Correspond à "Failure Date"
(FAILDATE) onglet "Failure reporting" module WO.
Non utilisé dans notre version.
|
Mode de défaillance
|
Voir (a).
|
"Failure Class" (FAILURECODE) dans le module WO.
Spécifique à un équipement.
Peut être lié à l'équipement.
Non utilisé dans notre version.
|
Conséquences sur la production ou la
sécurité
|
Echelle d'impact.
|
Le "Downtime" de l'équipement dans le module "Work Order"
contient aussi un "Downtime code" qui permet de caractériser le
problème, mais pas forcement l'impact.
|
Classe de sévérité
|
Effet critique ou non sur l'unité.
|
Il existait une notion de "Downtime" opérationnel ou non
dans les précédentes versions. Il faudrait la réactiver.
Le champ "WO priority" pourrait aussi être utilisé.
|
Indicateur de la défaillance
|
Voir (b).
|
Champ PROBLEM du "Work Order" et compléments dans
la "Long Description" (LD).
Non utilisé dans notre version.
|
Cause de défaillance
|
Voir (c).
|
Champ CAUSE du "Work Order" et compléments dans
la LD.
Non utilisé dans notre version.
|
Sous-Ensemble défectueux
|
Sous-ensemble défaillant.
Voie (a)
|
Implicite dans le numéro d'équipement lorsque
applicable.
|
Entités maintenables défaillantes
|
Détail des unités défaillantes. Voir (a).
|
Implicite dans le numéro d'équipement lorsque
applicable.
|
Méthode d'observation
|
Méthode de détection de la défaillance. Voir
(d)
|
Dans la "Long Description" du "Work Order". Peut faire l'objet de
l'ajout de DETECTION dans les PROBLEM/CAUSES/REMEDIES.
|
Commentaires
|
Informations complémentaires
|
Informations complémentaires sur les conditions et cause
de défaillances, diagnostic et méthodes de réparation.
|
Dans la "Long Description" du "Work Order".
|
|
|
|
|
Note: Les caractères en
gras indiquent les éléments nécessaires
à la norme pour une application FMD.
Note: Les caractères en italique
indiquent le minimum requis pour la norme.
|
a) Voir l'annexe A de la norme pour consulter les listes
proposées.
b) Tableau B1 de la norme "Indicateurs de
défaillance".
c) Tableau B2 de la norme "Causes de défaillances.
d) Tableau B3 de la norme "Méthodes de
détection".
|
|
Table 20 Données de
défaillances ISO-14224.
L'annexe A donne une liste des "Modes de défaillances"
par catégories d'équipements. Cette liste qui est assez similaire
aux indicateurs de défaillances de la liste B1 doit correspondre
à la description de la défaillance observée
reportée au niveau du type d'équipement de la
catégorie.
Le titre correspondrait aux "Failure Class" de Maximo. Le
"Failure Class" d'un équipement peut être défini dans le
module équipement ou par défaut dans le "Work Order", onglet
"Failure Reporting". Il apparaîtra dans "Failure Class" lorsqu'un "Work
Order" sera généré pour cet équipement. Ce champ
n'est pas apparent dans la version actuelle du module équipement.
Les annexes B donnent à titre indicatif les listes
générales des informations suivantes:
- B1: Les indicateurs généraux de
défaillances (fuite, court circuit...) avec une répartition par
catégorie (mécanique, électrique...). Il doit indiquer la
cause de la défaillance au niveau le plus base de la hiérarchie
de l'équipement (sous-ensemble ou entité maintenable). Cette
distinction n'existe pas dans Maximo. Nous ferons correspondre les titres des
"Modes de défaillances" avec "Failure Class". A chaque "Failure Class"
correspondra une liste de PROBLEM correspondants à la liste des "Modes
de défaillances" de l'annexe A.
- B2: Une liste commune de causes de
défaillances: P.Ex, erreur humaine, mauvaise conception. On l'associera
au champ CAUSE des "Failure Class" de Maximo.
- B3: Une liste commune de modes de détection:
P.ex, observation, contrôle.
- B4: Une liste commune d'activités de
maintenance: P.ex, PM, CM, réglage, remplacement.
Les listes B2, B3 et B4 seront communes à toutes les
classes de défaillances.
Ces listes ne sont pas complètes et devront être
revues avec le concours des personnels qualifiés de chaque discipline.
Elles pourront servir de base solide pour de futures améliorations.
Chaque élément de ces listes fera l'objet d'une codification
adaptée à Maximo. On utilisera la codification de la norme si
elle existe. Il faudra veiller à ne pas entrer dans une trop grande
complexité afin de ne pas rebuter les personnes et de ne pas engendrer
des temps de recherche trop longs de la bonne information dans des listes
interminables.
Les données de maintenance:
Ce module est complémentaire du
précédent. Dans Maximo, la différenciation entre rapports
de défaillance et rapport de maintenance n'existe pas sous cette forme.
Les rapports sont faits dans le module "Work Order" quel qu'en soit le type. La
différentiation provient du champ "Work Type" qui définit si l'on
a affaire à une maintenance préventive ou corrective. Les
données de défaillances sont incluses dans les rapports dans le
cas des maintenances correctives.
Catégorie
|
Donnée
|
Description
|
Données de Maximo
|
Identification
|
Enregistrement de maintenance.
|
Identifiant unique de la maintenance.
|
Numéro de "Work order" préventif: WONUM.
|
Emplacement de l'équipement.
|
Identification de l'équipement.
|
Numéro d'équipement: EQNUM.
|
Enregistrement de défaillance.
|
Pour les maintenances correctives uniquement.
|
N'est pas applicable.
Les maintenances préventives et correctives sont
enregistrées dans le même module "Work Order".
|
Données de maintenance
|
Date de maintenance.
|
Date à laquelle s'est effectuée la maintenance.
|
ACTSTART & ACTFINISH module "Work Order".
|
Catégorie de maintenance.
|
Préventive ou corrective.
|
WORKTYPE du module "Work Order", inclut entre autres les PM et
CM.
|
Opération de maintenance
|
Voir (b).
|
Pas d'équivalent. Pourrait correspondre à une liste
modifiée des "Sub Work Type".
|
Conséquence sur la production.
|
Echelle d'impact.
|
Le "Downtime" de l'équipement dans le module "Work Order"
contient aussi un "Downtime code" qui permet de caractériser le
problème.
|
Sous ensemble soumis à la maintenance.
|
Sous ensemble concerné par la maintenance. Voir (a).
|
Pas d'équivalent. Implicite dans
le numéro d'équipement.
|
Entité maintenable soumise à la maintenance.
|
Spécifier l'entité concernée. Voir (a).
|
Pas d'équivalent. Implicite dans le numéro
d'équipement.
|
Moyens de maintenance
|
Maintenance en homme-heures par discipline.
|
Voir (c).
|
Les heures sont entrées dans le champ DURATION du module
"Work Order". Chaque discipline devrait faire un "Work Order" différent.
Ce n'est pas toujours le cas.
|
Durée totale de la maintenance en homme-heure.
|
|
Pas d'équivalent. Sauf à cumuler les heures des
différentes disciplines. Toutefois, il ne sera pas possible de
déterminer facilement s'il s'agit de la même intervention.
|
Temps de maintenance
|
Temps de maintenance active.
|
Temps de maintenance active par rapport au temps
d'indisponibilité.
|
Peut être déduit à partir de ACTSTART,
ACTFINISH et DURATION module "Work Order".
|
Temps d'indisponibilité.
|
Temps d'indisponibilité de l'équipement
concerné.
|
FAILDATE, ACTSTART & ACTFINISH module "Work Order".
|
Commentaires
|
Informations complémentaires.
|
Indiquer toute information utile à cet emplacement.
|
Dans la "Long Description" du "Work Order".
|
|
|
|
|
Note: Les caractères en
gras indiquent les éléments nécessaires
à la norme pour une application FMD.
Note: Les caractères en italique
indiquent le minimum requis pour la norme.
|
a) Voir l'annexe A de la norme pour consulter les listes
proposées.
b) Tableau B4 de la norme "Méthodes de
détection".
c) Pour les équipements sous-marins, préciser la
logistique et les ressources externes.
|
|
Table 21 Données de
maintenance ISO-14224.
Le développement en
interne:
Nous avons vu que l'implantation de la norme était
possible, mais qu'elle demandait un certain nombre de modifications de Maximo
et de gros efforts de saisie si elle devait être
implémentée complètement. Nous ne prétendons dans
ce qui suit, donner une liste exhaustive, mais plutôt un ordre
d'idée des opérations à effectuer. Le but étant
principalement de faire une première évaluation des travaux afin
de faciliter la prise de décision.
Avant de commencer l'étude, il conviendra de
répondre aux questions suivantes:
- Quel effort de normalisation sommes-nous prêts
à assumer et en voyons-nous les avantages?
Les plus gros travaux de normalisation concernent la
classification des équipements dont il faudra évaluer la
faisabilité.
La situation actuelle convient pour planifier les maintenances
et pour une exploration manuelle des historiques uniquement.
- Voulons-nous une normalisation pour un usage interne
uniquement et à quelle échelle?
Il est toujours possible de s'inspirer de la norme sans
l'implémenter complètement. Dans ce cas, les données
risquent de n'être utilisables qu'en interne et difficile à
comparer aux données OREDA. Il est aussi possible de ne l'implanter que
sur certains équipements sélectionnés. Nous pourrions
limiter l'implantation à certains secteurs à forte valeur
ajoutée comme le offshore qui seraient probablement plus demandeurs que
d'autres.
- Quels sont les bénéfices espérés
et comment présenter le projet aux directions?
Il s'agit d'un projet d'envergure et cela demandera
l'implication des directions du groupe. Il ne s'agit pas d'un projet à
court terme, car les données de maintenances et les résultats ne
se feront sentir qu'au delà de deux ans dans le meilleur des cas. Nous
comptons un an de mise en place et un an d'historiques minimum. La reprise des
anciens historiques ne parait pas réalisable et n'est pas souhaitable
car les règles utilisées n'auront pas été les
mêmes.
- Vérifier que des solutions commerciales n'existent
pas ou que nous ne pouvons pas bénéficier de l'expérience
d'autres implémentations de la norme dans Maximo. MRO propose un
élément de solution qu'il faudra explorer.
- Il serait aussi souhaitable d'entrer en contact avec les
membres du projet OREDA pour en discuter les différents aspects et voir
l'intérêt d'y participer. La normalisation et l'appartenance
à ce projet sont dissociés.
On donnera dans ce qui suit, une liste préliminaire des
opérations à effectuer pour mettre en place cette norme au sein
de nos chantiers. Celle-ci peut servir de point de départ pour
démarrer l'étude, mais devra être revue en détail
pour s'assurer de la faisabilité de certains points. Il se peut que la
situation soit différente sur d'autres installations, car nous n'avons
exploré que les chantiers d'Angola et notre vision n'est pas celle de la
situation du groupe.
Afin de compléter cette étude, nous devrons
disposer du "OREDA Offshore Reliability Data Handbook" qui nous permettra
d'avoir une idée d'implémentation de la norme.
En ce qui concerne le module équipement, la norme donne
des indications qui pourraient nous permettre de créer une taxinomie
ainsi que les listes de spécifications de chaque classification
d'équipements. L'application de ces catégories à l'arbre
des équipements existant pourra s'avérer difficile sur les
chantiers ou il n'aura pas été conçu à partir de
cette norme. Il conviendra de faire une étude de faisabilité
avant d'entreprendre ces opérations. Les modifications ne devraient pas
concerner tous les équipements, mais seulement ceux décrits par
la norme et ceux que nous aurons voulus y ajouter.
- Afin de faciliter les futures saisies. Remettre en forme les
formats proposés par la norme pour les faire correspondre à ceux
de Maximo. Codifier les quatre niveaux de la hiérarchie des
équipements. Les Catégories et Types ont déjà un
code attribué dans la norme, nous pourrons le conserver (P.ex: CE pour
la catégorie "Combustible Engine" et DE pour le type "Diesel
Engine").
- Faire apparaître quatre niveaux de classifications
dans le module "Asset Catalog Setup" du menu "Inventory" et dans l'onglet
"Specification" du module équipement à l'aide du "Centura Object
Nationalizer". Les nommer: Category, Type, Sub-assembly et Maintenable
Entity.
- Faire apparaître le champ "Failure Code" dans l'onglet
principal du module équipement. Associer les équipements
sélectionnés avec une "Failure Code".
- Faire disparaître le champ "Classification" de
l'onglet principal du module équipement. Il sera remplacé par les
données de l'onglet "Specifications".
- Créer les "Classifications", "Sous Classifications",
"sous-ensembles", "Entités maintenables" ainsi que les "Données
spécifiques" décrites par la norme dans le module "Asset
Catalogue Setup" du menu "Inventory".
- Etendre les classifications aux équipements manquants
dans la norme. Cela demandera l'expérience des personnes expertes du
domaine.
- Assigner une classification à chaque niveau de
l'arbre des équipements ou c'est applicable. Cela revient à
assigner dans l'ordre un ou plusieurs des niveaux suivant de la
hiérarchie: Catégorie, Type, sous-ensemble et Entité
maintenable. Pour les équipements qui poseraient des problèmes,
vérifier s'il est possible de modifier l'arbre ou la
dénomination.
- Pour les équipements où c'est applicable.
Reporter toutes les données d'équipement se trouvant dans les
"Long Descriptions" dans le format proposé dans l'onglet
"Classifications". Vu l'étendue de ce travail, celui-ci ne pourra pas
être réalisé par les personnes du bord, mais par les
superviseurs de Maximo lors de leur passage.
Les données de défaillance ne peuvent être
définies que si les équipements le sont aussi. A chaque type
d'équipement correspondra une "Failure Class".
- Afin de faciliter les futures saisies. Remettre en forme les
formats proposés par la norme dans les annexes A & B pour les faire
correspondre à ceux de Maximo.
- Créer la hiérarchie des "Failure class",
"Problems", "Causes" et "Remedies" dans le module "Failure codes" de Maximo.
- Ajouter le niveau de hiérarchie DETECTION dans le
module "Failure codes". Il est nécessaire pour les rapports de
défaillances
- Etendre cette hiérarchie aux cas non décrits
par la norme. Cela demandera l'expérience des personnes expertes du
domaine.
- Assigner une "Failure Class" aux équipements. On
préférera les niveaux ou seuls "Catégory+Type" sont
définis. A défaut on l'indiquera au niveau "Category". Il s'agit
de la valeur qui apparaîtra dans le "Work Order" lors de sa
génération. A défaut, l'utilisateur devra choir dans les
listes.
- Explorer les solutions pour créer les champs
obligatoires manquant dans les écrans et dans la base de données.
On vérifiera que ces champs ne sont pas inclus dans une partie de Maximo
non encore utilisée. Cela concerne les champs suivants: Classe de
sévérité, Echelle d'impact, les temps de maintenance.
Tâches additionnelles:
- Ecrire les scripts SQL d'installation.
- Choisir un site pilote et définir la façon de
mettre à jour les données d'équipements.
- Créer et diffuser la documentation additionnelle
décrivant les normes de création de la hiérarchie
d'équipements et de remplissage des rapports de maintenance.
- Définir des critères de qualité des
données enregistrées et se donner les moyens pour les
évaluer.
- Créer les outils d'analyse des données de
maintenance à partir des nouvelles informations. Les tests que nous
avons faits dans la partie qualitative devront pouvoir être
réutilisés pour définir les meilleurs outils.
- Pour le siège social: Créer les outils de
regroupement et d'analyse d'informations de maintenance à partir des
données des différents chantiers. Il existe un projet
nommé MIMOSA qui pourrait répondre à ce type de
problème.
|