CONSERVATOIRE NATIONAL DES ARTS ET METIERS
PARIS
MEMOIRE
Présenté en vue d'obtenir
LE TITRE D'INGENIEUR DIPLOME PAR L'ETAT
en
INFORMATIQUE INDUSTRIELLE
Par
Philippe JUNG
Etude de méthodes d'analyse des historiques de
maintenance dans un environnement de forage pétrolier
offshore
Soutenu le:
9 Novembre 2004
JURY:
Président:
Monsieur
le professeur Pierre Paradinas
Membres:
Monsieur le professeur Jacques Jouhaneau
Monsieur François-Yves Villemin
Monsieur Daniel Hajage
Monsieur Olivier Beaujard
RESUME EN FRANÇAIS
En 1992, le groupe "Pride International" décide
d'implanter la méthode TPM pour améliorer la gestion de sa
maintenance. Il sélectionne le produit Maximo de MRO qui est un leader
mondial de ce type de logiciels. Depuis sa première implantation avec
succès sur le chantier Nymphéa en 1994, tous les chantiers
terrestres et maritimes en ont été équipés.
Depuis la première installation, le produit a
été adapté à nos besoins par la personnalisation
des écrans et la création de nombreux rapports. Il existe trois
rapports de synthèse répondant aux besoins des
opérationnels, d'analyse des coûts et de la
sécurité, mais rien concernant la maintenance.
Après avoir construit quelques prototypes, nous avons
créé et implanté un rapport quantitatif mensuel de
l'état de la maintenance nommé MMR et répondant aux
besoins des utilisateurs.
Après de nombreuses années de fonctionnement,
nous disposons de nombreux historiques de maintenance. Nos différents
tests sur les données existantes ont montré que les
méthodes usuelles d'analyse qualitative des données de
maintenance (MTBF, Pareto, Weibull) ne pouvaient être utilisées
avec succès sans l'addition d'informations complémentaires et une
amélioration de la qualité de la saisie.
A la suite de cet état de fait, nous avons
examiné les possibilités d'implantation de la norme
ISO-14224:1999 qui permettrait d'améliorer le retour d'expérience
et les possibilités d'analyse des données de fiabilité de
notre groupe.
Nous préconisons aussi des améliorations
générales du produit ainsi que l'utilisation d'un produit OLAP
tel que Powerplay pour effectuer des analyses multidimensionnelles de
données.
SUMMARY IN ENGLISH
In 1992, the group "Pride International" decides to implant
the TPM method to improve the management of its maintenance. It selects the
Maximo product of MRO that is a world leader of this type of software. Since
its first implantation with success on the rig Nymphéa in 1994, all
onshore and offshore rigs have been equipped some.
Since the first installation, the product has been adapted to
our needs by the personalization of the screens and the creation of many
reports. Three reports of synthesis answering the needs of the operational, of
analysis of the costs and the security, exist but nothing concerning the
maintenance. After having constructed some prototypes, we created and implanted
a monthly quantitative report of the state of the maintenance named MMR and
corresponding to the needs of the users.
After numerous years of working, we have many historic of
maintenance. Our different tests on the existing data showed that the usual
methods of qualitative analysis of the maintenance data (MTBF, Pareto, Weibull)
could not be used with success without the addition of complementary
information and an improvement of the quality of the inputs.
Taking this fact into account, we examined the possibilities
of implantation of the ISO-14224:1999 standard that would permit to improve the
return of experience and the possibilities of analysis of the reliability data
of our group.
We also recommend the general improvements of the product as
well as the use of an OLAP product as Powerplay to do multi-dimensional
analysis of data.
MOTS CLEF
En Français:
MAXIMO, CMMS, PARETO, WEIBULL, IS0-14224:1999, OREDA, MTBF.
In English:
MAXIMO, CMMS, PARETO, WEIBULL, IS0-14224:1999, OREDA, MTBF.
Remerciements:
A M. Christian Girard directeur de la base Luanda pour avoir
accepté ce projet.
Tout particulièrement à M. Gilles Bocabarteille
(Ing Arts et Métiers) directeur des opérations de la base Luanda
qui est à l'origine de ce projet, de sa présentation aux
directions et qui l'a soutenu tout au long de sa réalisation en
mobilisant les équipes lors des réunions d'expression des
besoins.
A M. Jean Pierre Chaix responsable de la maintenance au
siège de Houston et qui a accepté que ce projet se fasse
localement sur le site d'Angola.
Au service maintenance de la base de Luanda, M. Thierry
Manescau et M. Johann Glot qui m'ont donné de précieuses
indications concernant la maintenance.
Aux superviseurs de forages des différents appareils,
M. Patrick Arberet, M. Jean Lemoal, M. Meno Bosma et M. Raphaël Siri.
Aux différents intervenants des chantiers qui m'ont
fourni une critique constructive des différents prototypes et des
informations de valeur sur la maintenance dans tous ses aspects.
Et en particulier M. Yves Nerisson, M. Didier Sautron pour
leurs conseils avisés.
Sommaire.
Table des matières:
Sommaire.
1
Table des matières:
1
Index des figures
2
Index des tableaux.
3
Présentation de la TPM (Total
Productive Maintenance).
6
Introduction:
6
La définition de la TPM tient en cinq
points:
6
Afin d'arriver à ses fins, la TPM repose sur
la mise en place de cinq piliers:
6
L'ensemble des règles de la TPM amène
à édicter les règles suivantes:
8
L'objectif principal étant le "Zéro
défauts":
9
Les indicateurs de performance:
9
Mise en place de la TPM:
10
Description du projet:
11
Répertoire des intervenants:
14
Contexte et contraintes:
16
Analyse de l'existant.
18
Organisation générale de
l'application Maximo:
18
Module "Equipment" (EQPT):
18
Module "Preventive Maintenance" (PM):
22
Module "Job plan" (JP):
25
Module "Work Order Tracking" (WO):
26
Schéma relationnel des tables
principales:
33
Détails de quelques tables près
définies:
33
Schéma d'interconnexion entre modules:
34
Rapports existants:
35
Droits d'accès aux modules et rapports:
37
Aspects financiers:
37
Architecture et ressources
informatiques.
38
Description de la configuration type:
38
Environnement d'installation:
39
Ressources informatiques:
39
Ressources documentaires de base:
40
Les outils de développement:
40
Formation:
41
Réunion initiale d'expression des
besoins.
42
Minutes of meeting "Expression des besoins
initiale"
42
Revue critique des différents points:
45
Les différents aspects du rapport
initial:
47
Format final du prototype papier n°1:
53
Etapes de construction du prototype
quantitatif.
54
Les choix de réalisation des prototypes:
54
Installation de Maximo sur le poste de
développement:
54
Analyse des données et des
écrans:
57
Le prototype n°2 MS-Access:
58
Prototype n°2 chiffré sous
MS-Access:
59
Minutes of meeting "Expression des besoins
prototype N°2"
60
Construction du prototype n°3 sous SQR:
62
Prototype n°3 sous SQR:
64
Minutes of meeting "Expression des besoins
prototype N°3"
65
Prototype n°4 sous SQR:
66
Minutes of meeting "Expression des besoins
prototype N°4"
70
Intégration du rapport n°4 dans
Maximo:
71
Tests en réel sur les serveurs des
chantiers:
73
Minutes of meeting prototype n°4 par les
utilisateurs des chantiers:
74
Prototype n° 5:
75
Minutes of meeting "Expression des besoins
prototype n°5":
77
Conclusion de la partie quantitative:
78
Etude de la partie qualitative.
79
Qualité de la maintenance et TPM:
79
Marqueurs de base de la fiabilité:
81
Méthodes graphiques de base:
87
Analyse de données statistiques
associées aux défaillances.
92
Amélioration du retour
d'expérience.
95
Méthodes de recueil de données de
fiabilité:
95
Guide pour l'obtention de données de
qualité:
96
Formats des données d'équipements, de
défaillances et de maintenance:
100
Le développement en interne:
106
Solutions commerciales:
109
Publications de OREDA:
109
Conclusions concernant l'implantation de la norme
ISO-14224:1999:
110
Autre piste à explorer:
111
Recommandations d'usage.
112
Module EQUIPMENT:
112
Module "Work Order":
112
Conclusions générales.
115
Partie quantitative:
115
Partie qualitative:
115
Amélioration du retour
d'expérience:
115
Annexe A.
117
Littérature:
117
Sites internet:
117
Lexique et acronymes:
117
Annexe B: Exemple de rapport qualitatif
final.
119
Annexe C: Résultats des tests
Weibull++.
122
Index des figures
Figure 1 Taux de Rendement Synthétique.
9
Figure 2 Prototypage [VONK].
12
Figure 3 Organisation générale de
Maximo.
18
Figure 4 Fenêtre principale du module
EQUIPMENT
20
Figure 5 Onglet "Meters" du module EQUIPMENT
21
Figure 6. Ecran "Specification" du module
EQUIPMENT.
21
Figure 7 Ecran principal du module PM
23
Figure 8 Onglet "Frequency" du module Preventive
Maintenance.
23
Figure 9 Ecran principale du module Work Order.
28
Figure 10 Work Order statut.
31
Figure 11 Diagramme "Work Order tracking".
32
Figure 12 Schéma relationnel des principales
tables.
33
Figure 13 Diagramme de retour d'expérience
dans Maximo.
35
Figure 14 Installation matérielle et
logicielle de Maximo.
38
Figure 15 Entête des rapports Maximo.
47
Figure 16 "SQR4" configuration ODBC.
55
Figure 17 "SQLedit" Ecran principal.
55
Figure 18 "SQLedit" détails de la
configuration.
56
Figure 19 Fenêtre principale de SQRWT
62
Figure 20 "SQR viewer" fenêtre d'exemple.
63
Figure 21 Graphique "Time-bases" & Meter-based"
overdue.
66
Figure 22 Graphique "PM & CM WO counts".
67
Figure 23 PM & CM other status counts.
67
Figure 24 Graphique "PM ratio & overdue".
68
Figure 25 Module "Reports and other Apps" de
Maximo.
72
Figure 26 Prompts des rapports Maximo.
73
Figure 27 Coûts des Work Order CLOSE par
département.
76
Figure 28 TOP5 PM & CM stock consumption.
76
Figure 29 Work Order costs.
76
Figure 30 Major WO PM overdue.
77
Figure 31 Marqueurs de base de la
fiabilité.
81
Figure 32 Graphique P-F.
82
Figure 33 Exemple de tableau de
fiabilité.
85
Figure 34 Diagramme de distribution et de
répartition.
87
Figure 35 Diagramme de défaillance.
88
Figure 36 Analyse Pareto descendante.
88
Figure 37 Diagrammes de Pareto, chantier "Pride
Angola" toutes périodes.
91
Figure 38 Formes de loi de probabilité en
maintenance.
92
Figure 39 Hiérarchie des équipements
ISO-14224.
101
Index des tableaux.
Table 1 Principales causes de pertes en TPM
[JACQ].
7
Table 2 Planning prévisionnel.
13
Table 3 Répertoire des intervenants.
15
Table 4 Tables du module EQUIPMENT.
20
Table 5 Tables du module PM.
22
Table 6 Table de calcul pour les maintenances
basées sur le temps.
24
Table 7 Table de calcul pour les maintenances
basées sur les compteurs.
24
Table 8 Tables du module "Work Order".
27
Table 9 Tables des états d'un "Work
Order".
30
Table 10 Contenu des tables
prédéfinies LeadCraft & CrewID.
33
Table 11 Valeurs prédéfinies du champ
"Classification".
34
Table 12 Downtime codes.
34
Table 13 Liste des rapports existants.
36
Table 14 Exemple de tailles de table Maximo.
41
Table 15 Paramètres de la ligne de commande
Maximo.
72
Table 16 VALUELIST classification.
89
Table 17 Comptage des Sub-work type.
89
Table 18 Estimation de la qualité de saisie
dans Maximo.
98
Table 19 Données d'équipement
ISO-14224.
101
Table 20 Données de défaillances
ISO-14224.
105
Table 21 Données de maintenance
ISO-14224.
106
Introduction.
Le groupe "Pride Internationnal" dont le siège est
à Houston est l'un des leader mondiaux dans les domaines du forage et la
maintenance de puits pétroliers ou gaziers. Il fournit ses prestations
dans des environnements terrestres ou maritimes dont beaucoup se trouvent dans
les endroits les plus difficiles de la planète. Il possède plus
de 290 chantiers dans le monde et emploie plus de 10000 employés.
Sa filiale "Pride Foramer" qui a été un
précurseur dans le monde du forage en grande profondeur dans les
années 70 possède un siège social en France. Elle est
représentée en Angola par "Pride Foramer Angola". L'ensemble des
appareils fonctionnant en Angola est géré par une "Joint Venture"
entre Sonangol, la compagnie pétrolière angolaise à raison
de 49% et "Pride Foramer Angola" pour 51%. Ce groupe possède 2
unités à positionnement dynamique, 2 semi-submersibles, 2 tenders
et s'occupe de la gestion de deux plateformes TLP (Tension Leg Platform). Ses
principaux clients dans cette région sont Total, Exxon et Chevron. C'est
au sein de cette entité qu'aura lieu ce projet.
Après avoir utilisé pendant longtemps des
méthodes manuelles, faute à l'époque d'informatique et de
produits performants, le groupe "Pride International" a décidé en
1992, d'améliorer la gestion de la maintenance en implantant la
méthode TPM (Total
Productive Maintenance). Cette implantation
implique des changements importants dans l'organisation et de choisir un
logiciel de suivi de la maintenance ou CMMS (Computerized
Maintenance Management System).
Le progiciel Maximo de la compagnie MRO a
été sélectionné parmi huit autres produits. Les
principaux critères ont été les suivants:
- Facilité d'utilisation et conviviale.
- Facilité de paramétrage et
disponibilité de modules complémentaires.
- Il permet de gérer la maintenance, mais aussi les
stocks et les achats.
- Il doit permettre de réduire les coûts de
maintenance.
- MRO est un leader mondial dans le domaine de la
maintenance.
La première implantation se fera sur la plateforme
semi-submersible Nymphea en 1994. Après quelques années,
les gains sur les coûts de maintenance, du stock mort et la
réduction des arrêts de l'appareil ont été
significatifs. Ce bénéfice s'est fait sentir non seulement au
sein de la compagnie, mais aussi chez le client qui est aussi très
concerné par tous les aspects de la maintenance. Depuis, tous les
chantiers de "Pride International" ont été équipés
avec Maximo, même ceux dont les revenus journaliers sont faible comme les
appareils terrestres. Ce que personne n'aurait cru possible à
l'origine.
Plus que jamais, les performances économiques d'une
entreprise sont le garant de sa longévité. Toutefois, dans un
environnement aussi technique que celui des forages pétroliers,
l'économie n'est pas le seul critère qu'il faille prendre en
compte. Les équipements doivent être maintenu opérationnels
pour assurer les revenus de l'entreprise, mais aussi pour d'autres raisons plus
prosaïques qui en sont la corollaire:
- Satisfaire les exigences contractuelles des clients.
- Se conformer aux nombreuses réglementations et normes
nationales ou internationales telles que:
ISM, IMO, DNV, OSHA, EPA, ISPS, API...
- Assurer la sécurité des biens, des personnes
et de l'environnement.
- Améliorer les performances opérationnelles des
unités afin d'accroître leur compétitivité
internationale et l'image de marque de l'entreprise.
- Améliorer la durée de vie des
équipements.
- Favoriser de meilleurs choix d'équipements.
La maintenance est un des outils importants pour arriver
à satisfaire toutes ces exigences. Elle ne doit plus être
considérée uniquement comme un poste de coût, mais comme un
facteur de pérennité des investissements de la
société. Toutefois, quel que soit l'outil informatique
sélectionné, celui-ci ne fait pas tout. Encore faut-il pouvoir en
tirer des informations utiles afin d'améliorer le retour
d'expérience. Il ne s'agit pas d'emmagasiner des données, encore
faut-il qu'elles soient exploitables et qu'elles contiennent des informations
à valeur ajoutée.
Depuis son implantation, Maximo a été grandement
adapté pour correspondre à nos besoins. Cela concerne plus
particulièrement le format des écrans, mais aussi de nombreux
rapports additionnels par rapport au produit de base. Nous disposons maintenant
d'outils d'analyse et de suivi des aspects sécurité,
économiques et opérationnels de la maintenance. Il nous reste
à compléter ce panel par de nouveaux produits d'analyse des
résultats et de suivi de la maintenance.
Il existe plusieurs catégories de personnes
intéressées par les résultats de la maintenance:
- Les experts qui rechercheront à détecter les
principaux équipements à problèmes et les modes de
défaillances afin d'en tirer des règles de maintenance.
- Les responsables techniques ou d'exploitation qui
rechercheront les performances et des critères de qualité.
- Les gestionnaires qui voudront évaluer
l'efficacité globale de la maintenance au travers des coûts.
- Les commerciaux qui voudront pouvoir présenter des
résultats synthétiques aux clients et présenter les
méthodes de gestion utilisées.
C'est pourquoi il est nécessaire de créer des
d'outils permettant d'offrir une vue synthétique de l'état de la
maintenance et de ses performances, utilisables par différents publics
au sein de l'entreprise.
Il existe de nombreuses façons de représenter
les données extraites d'une base de données de maintenance. Il
nous faudra rechercher les plus pertinentes pour notre métier avec
l'aide des différentes personnes impliquées dans le projet. Seuls
des tests en réel nous permettrons de déterminer la
qualité des données existantes et dans quelle mesure ces
informations sont utilisables pour obtenir des informations pertinentes. A
l'issue de ce projet, nous donnerons, le cas échéant des
recommandations pour améliorer l'existant dans les limites du produit
Maximo.
Présentation de la TPM (Total Productive
Maintenance).
Introduction:
Avant de poursuivre cette étude, il convient de
définir succinctement ce qu'est la TPM afin de mieux délimiter
notre champ d'action. Nous limiterons cette présentation aux aspects les
plus importants, car tous les domaines qu'elle englobe ne nous concernent
pas.
Le concept de la TPM a été mis au point au Japon
en 1970 à partir des techniques de maintenance préventive mises
au point aux Etats-Unis dans les années 1950. Les premières
implémentations s'effectueront vers 1960 par le groupe Nippondenso. Le
JIPM (Japan Institute of Plant Maintenance) détient les brevets de la
méthode et propose des prestations pour la mettre en place et la
promouvoir.
Alors que la maintenance préventive concerne un nombre
de plus en plus important d'agents de maintenance spécialisés, la
TPM inclut aussi les opérateurs formés à la
réalisation des maintenances de base. C'est ce que l'on nomme
"Maintenance Autonome".
Les opérations essentielles de maintenance sont
toujours effectuées par du personnel spécialisé. Ces
derniers participent aussi lors de la conception pour améliorer la
fiabilité des équipements dés l'origine. Ce que l'on nomme
"Prévention de la maintenance".
La TPM était à l'origine plutôt un produit
destiné à la production de produits à cycle de vie court,
sur un marché très concurrentiel nécessitant une forte
adaptabilité. Toutefois, une grande partie des règles qui la
gouvernent peuvent être appliquées sur nos unités. La
documentation dans ce domaine est importante, mais les interprétations
sont nombreuses. Ce qui suit est une tentative de synthèse
adaptée à notre cas.
La TPM est avant tout une philosophie d'entreprise devant
concerner l'ensemble des acteurs de la société plutôt
qu'une méthode au sens strict. Cela implique que les méthodes
permettant d'atteindre les objectifs peuvent être différentes
suivant les applications.
La définition de
la TPM tient en cinq points:
1) Aider à créer une culture de
société centrée sur l'amélioration de la
productivité générale de l'outil de travail. Voir plus
loin la définition de l'indicateur de performance nommé TRS. Il
est aussi appelé OEE (Overall Equipment Efficiency) dans la
littérature anglo-saxonne.
2) Etablissement d'un système de maintenance pour
atteindre les "zéro défauts, zéro pannes, zéro
accidents" durant tout le cycle de vie des équipements.
Cela inclut entre autres de mettre en place:
ü Une maintenance préventive.
ü Une maintenance d'amélioration.
ü Une meilleure conception en amont, amenant à une
maintenance réduite appelée "prévention de la
maintenance".
3) Participation du concepteur, des opérateurs et des
services de maintenance, mais aussi les services développement,
marketing et administratifs.
4) Implication complète de tous les niveaux de la
hiérarchie jusqu'au sommet de la pyramide.
5) Mise en place de la maintenance préventive autonome
et des cercles TPM de petits groupes autonomes.
Afin d'arriver à
ses fins, la TPM repose sur la mise en place de cinq piliers:
1) Programme d'amélioration
générale:
Cette partie qui concerne tous les niveaux de l'entreprise
implique la détection et l'enregistrement de tous les petits
détails de fonctionnement qui pourraient faire perdre une partie de la
productivité à l'entreprise. On procède par
l'enregistrement de l'ensemble des problèmes puis par analyse des
pannes, de leur cause et leurs effets. Cela revient à:
- Enregistrer chaque défaut.
- Déterminer la proportion de chacune des sources de
pertes.
- Juger des obstacles aux pertes de rendement.
- Déterminer les effets des pertes.
- Déterminer des solutions.
Elimination des sources de pertes:
L'objectif est d'éliminer les grandes causes de pertes.
Il existe 6 sources de pertes:
- Pannes des équipements.
- Changements de fabrications ou réglage.
- Marche à vide ou petits arrêts.
- Vitesse réduite.
- Défauts de qualité ou retouches.
- Rendement au démarrage inférieur à la
vitesse de croisière de la production.
Les pertes peuvent aussi être réparties en 3
familles et 17 causes comme suit:
|
Fiabilité des équipements
|
Organisation
|
méthodes et procédés
|
Pannes
Réglages
Pertes au démarrage
Micro arrêts
Marche à vide
Sous vitesse
Rebuts et retouches
Arrêts programmés
|
Temps de changement de fabrication
Activité opérateur
Déplacements et manutention
Organisation du poste
Défauts de logistique
Excès de mesures
|
Rendement des matériaux
Rendement énergétique
Sur consommation:
- d'outillage,
- d'accessoires
- de consommables
|
Table 1 Principales causes
de pertes en TPM [JACQ].
Amélioration des performances des services
administratifs:
Les améliorations ne concernent pas que la partie
production, mais aussi les services administratifs qui doivent aussi
améliorer leur efficacité en identifiant les sources de moindre
performance dans la circulation d'information.
Sécurité, santé et
environnement:
Le but est d'atteindre les "zéro problèmes" dans
chacun des domaines. Cette partie concerne aussi les parties
réglementations et certifications.
2) Mise en place de la "Maintenance Autonome":
Prise en charge d'une partie de la maintenance des
équipements par les opérateurs formés pour cet objectif
afin de libérer les opérateurs spécialisés pour
d'autres tâches à valeur ajoutée. L'opérateur est
aussi encouragé à participer à la détection des
pannes en amont en utilisant ses connaissances pratiques de
l'équipement. Tout défaut doit être considéré
comme une honte par l'employé.
Mise en place de la méthode des
5S:
Les 5S proviennent des verbes Japonais
(Seiri, Seiton, Seiso,
Seiketsu, Shitsuke) que l'on peut traduire en
français par: Débarrasser, Ranger, Nettoyer, Standardiser, self
discipline.
Ce sont des opérations qui concernent principalement
les opérateurs de la production, ceux qui effectuent la maintenance
autonome.
3) Mise en place de la maintenance
programmée:
On y définira programmes des différents types de
maintenance:
- Préventive,
- Corrective,
- Prévisionnelle et d'amélioration,
- Les vérifications routinières incluses dans la
maintenance autonome.
Il s'agit de toutes les actions qui permettent de passer de la
maintenance réactive à la maintenance
proactive. On parle aussi du passage du "Contrôle de la
qualité" à "l'Assurance Qualité". On doit pour cela
créer des marqueurs qui permettront de détecter les transitions
par rapport à l'état normal de fonctionnement et de prendre des
décisions.
La détection doit pouvoir être faite en ligne et
permettre de catégoriser les défaillances, l'analyse des
phénomènes et des causes.
Cette étape ne peut se faire sans avoir recueilli des
informations cohérentes et à valeur ajoutée de la part des
personnels de maintenance et des utilisateurs.
Cette étape comprend aussi la gestion des
améliorations, la gestion des stocks et l'analyse et prévision
des pannes.
4) Mise en place d'un programme de formation:
Le but est d'accroître les connaissances des
opérateurs et du personnel de maintenance afin de mieux assurer la
maintenance autonome pour les premiers et d'améliorer
l'efficacité de la maintenance pour les seconds.
5) Prévention de la maintenance:
On y inclut aussi l'amélioration des équipements
à la conception de façon à limiter la maintenance à
posteriori. Il s'agit d'un système nommé "Prévention de la
Maintenance" permettant d'agir en amont lors de la conception des
équipements. Elle inclut les notions de maintenabilité, de
coût de cycle de vie (LCC Live Cycle Cost) et de fiabilité.
C'est à ce niveau que devront être définis
les documents de maintenance utilisables par les opérateurs et les
services de maintenance: Les "Job Plans" qui décrivent les
opérations de maintenance programmée et la maintenance autonome,
les conditions optimales de fonctionnement et des informations de
fiabilité en amont.
L'ensemble des
règles de la TPM amène à édicter les règles
suivantes:
|
1
|
Améliorer l'efficacité des équipements.
|
- Respect des conditions d'utilisation.
- Maintenance préventive.
- Amélioration des équipements.
- Formation des opérateurs.
|
|
2
|
Démarrage rapide des nouveaux produits ou
équipements.
|
- Maîtrise de la conception.
|
|
3
|
Améliorer l'efficacité des services
fonctionnels.
|
Les services administratifs sont engagé à:
- Simplifier leurs procédures et a diminuer le nombre
de tâches.
- Fournir les moyens aux opérationnels de fournir les
ressources de l'entreprise.
|
|
4
|
Stabiliser les 5S
|
- Maîtrise de la qualité.
|
|
5
|
Maîtriser la sécurité, les conditions de
travail et l'environnement.
|
- Assurer les différentes certifications et
réglementations.
|
L'objectif principal
étant le "Zéro défauts":
Pour atteindre cet objectif qui peut se traduire par les deux
points suivants:
1) Maintenir l'état optimal des systèmes homme
machine.
2) Améliorer la qualité globale de
l'unité de travail.
On peut appliquer trois principes permettant d'arriver au
niveau de qualité "Zéro défauts":
1) Maintiens de l'état normal de fonctionnement des
systèmes par les opérateurs. Ils doivent effectuer les
opérations et vérifications routinières qui leur incombent
ainsi qu'appliquer les trois premières règles des 5S
(Débarrasser, Ranger, Nettoyer).
2) Découverte très tôt des
problèmes de fonctionnement par les opérateurs. Ils doivent pour
cela utiliser leurs connaissances des équipements et effectuer les
vérifications nécessaires en utilisant les moyens de mesures
adéquats.
3) Action rapide de la maintenance.
On peut encore le formuler de la façon suivante:
1) Empêcher la détérioration
accélérée en maintenant l'équipement dans un
état normal.
2) Maintenir l'installation en bon état.
3) Maintenir des conditions de fonctionnement correctes.
4) Améliorer la qualité de la maintenance.
5) Effectuer des réparations définitives.
6) Eliminer les faiblesses de conception.
7) Utiliser l'expérience de pannes pour
améliorer l'existant.
Les indicateurs de
performance:
L'outil de mesure des performances de la TPM est nommé
TRS ou "Taux Rendement
Synthétique" (ou encore OEE Overall Equipment Efficiency).
En production, l'unité de référence est le nombre
d'unités fabriquées dans un temps donné. Pour notre
application, le temps semble beaucoup plus significatif, car nous faisons
principalement du service. Le temps des opérations de forage ou de
maintenance des puits est planifié, mais la durée réelle
n'est pas uniquement fonction de la qualité de la maintenance. Il
dépend aussi des problèmes rencontrés dans le puits et
d'autres impondérables. Nous verrons si ce type de métrique est
utilisable dans notre cas.
Le TRS est le produit de trois taux: La Disponibilité,
la Performance et la Quantité. Ces taux sont tous liés à
diverses pertes de temps non utilisables pour la fabrication proprement dite et
non à des notions directes de coûts.
Les facteurs du TRS sont calculés comme suit
(Fig.1):
Figure 1 Taux de Rendement
Synthétique.
Il nous faudra déterminer si cet indicateur est
utilisable dans notre domaine, car au premier abord, les paramètres sont
différents de ceux de notre application.
Le calcul de ce taux repose en grande partie sur la mise en
place d'indicateurs qui permettent de caractériser les pertes de la
façon suivante:
- Par leur nature: "Problems".
- Par origine: "Causes".
- Par solution: "Remedies".
- Par département ou activité.
- Par classification d'équipement.
Mise en place de la
TPM:
La mise en place de la TPM requiert l'implication à des
degrés divers de tous les niveaux de la hiérarchie d'une
entreprise.
- La direction:
Elle doit définir les objectifs et la politique de
l'entreprise.
- La direction technique responsable de la maintenance:
Elle assure le contenu du programme et des moyens
nécessaires pour atteindre les objectifs.
- Les cadres intermédiaires:
Ils assurent la mise en place des procédures au niveau
opérationnel et effectuent les modifications nécessaires pour
atteindre les objectifs.
- Les opérateurs:
Ils assurent le suivi des maintenances à leur
portée technique et proposent des améliorations au cours de
réunions de petits groupes de travail.
Initialisation du
projet.
Description du projet:
L'outil Maximo est maintenant généralisé
sur tous les chantiers de la compagnie même ceux à revenu faible.
Il a prouvé son efficacité dans le domaine de la maintenance
préventive. Maintenant que nous disposons d'un volume d'historiques de
maintenance important, la société souhaiterait disposer d'outils
d'analyse lui permettant d'avoir des marqueurs de la qualité de la
maintenance effectuée. Elle souhaite aussi disposer de moyens pour
détecter des problèmes et les prévenir en changeant au
besoin les programmes de maintenance ou le contenu des listes
d'opérations à effectuer. Rien ne permet de dire que les
données actuelles permettent d'obtenir ces informations. Certaines
propositions pourront être faites pour améliorer la qualité
de l'information enregistrée et y ajouter le contenu nécessaire
à une analyse autre que par l'examen manuel des historiques.
Objectifs:
L'objet de cette étude est de fournir les moyens
d'analyse des historiques de maintenance du produit Maximo en vue
d'améliorer les performances et d'optimiser la maintenance des appareils
de forage de notre compagnie.
Pour cela, on se fixera plusieurs objectifs qui seront
étudiés séparément:
1) Fournir des outils d'analyse quantitatifs de la maintenance
au niveau opérationnel. Ce rapport aura pour nom MMR
(Monthly Maintenance Report).
2) Proposer des outils d'analyse qualitatifs au niveau des
équipements et définir les moyens de les mettre en place.
3) Proposer le cas échéant d'autres
méthodes ou outils permettant d'ajouter de la valeur aux rapports des
utilisateurs.
4) Diagnostiquer les dysfonctionnements de l'outil de
maintenance et le moyen de l'améliorer.
Limites:
- On utilisera les données et de
préférence les outils de Maximo pour obtenir les
résultats.
- On essaiera dans la mesure du possible de se limiter aux
améliorations de l'usage du produit existant.
- Il ne s'agit pas de proposer de nouvelles méthodes de
maintenances, mais d'améliorer l'existant en proposant des outils de
diagnostic et de nouvelles méthodes de valorisations des
données.
- Dans certains cas, si les contraintes techniques sont trop
grandes par rapport au temps imparti, on ne produira pas une solution finale,
mais plutôt des résultats chiffrés de façon à
juger de la pertinence des données et de leur intérêt. Dans
ce cas, on ne préjugera pas des méthodes employées pour
les obtenir.
Buts:
- Diminuer les coûts des stocks.
- Diminuer les coûts de maintenance.
- Augmenter la fiabilité et la disponibilité des
équipements.
- Assurer une traçabilité de la maintenance.
- Optimiser la gestion des maintenances préventives.
- Augmenter la qualité du service.
- Améliorer les performances de sécurité
et les interactions avec l'environnement lorsqu'ils sont liés avec les
aspects de la maintenance.
Stratégie:
En regard du contexte de développement, nous ne
pourrons pas utiliser une méthode standard (voir le chapitre des
contraintes). Toutefois, nous nous inspirerons pour partie de méthodes
récentes en utilisant la partie prototypage comme moteur d'avancement de
certaines parties du projet.
Dans la mesure ou nous partons déjà d'une base
existante et que nous ne ferons qu'utiliser des données supposées
cohérentes, nous n'effectuerons qu'une phase de conception rapide issue
de l'expression des besoins pour passer rapidement aux prototypes.
L'utilisation des données de Maximo s'apparente plus à du
"Reverse Engineering" qu'à de la conception pure.
Le prototypage offre les avantages suivants:
- Pas apprentissage de méthodes lourdes et peu
adaptées à l'environnement.
- Facilite la communication avec l'utilisateur, car il
décrit la future interface.
- Retour d'information plus rapide.
- On pourra utiliser le cas échéant d'autres
outils que ceux fournis par Maximo.
- Cela ne préjuge pas des méthodes
utilisées en interne par les développeurs.
Figure 2 Prototypage
[VONK].
Les réunions d'expression des besoins ne pouvant
s'organiser facilement dans un contexte dispersé comme le notre, nous
procéderons par courrier électronique ou par des réunions
informelles lors du passage du CPI sur les différents sites. Un compte
rendu de chaque visite sera envoyé à tous les intervenants
concernés pour obtenir leur analyse critique.
Seules les réunions de la base seront
consignées. Pour des raisons pratiques, les idées en provenance
des différents interlocuteurs des chantiers seront
intégrées au niveau de ces réunions ou dans le texte de
commentaire des propositions effectuées. Elles ne présenteront
pas un aspect aussi formel que celles de la bases et ne pourront être
consignées comme telles sans retranscription.
Faisabilité:
Le contexte de travail qui sera décrit dans un chapitre
à suivre n'étant pas des plus favorables, il est possible que les
délais d'obtention du produit final sortent des contraintes de temps
imposé par la présentation du dossier. Le projet devra au moins
pouvoir fournir des prototypes aboutis des futurs produits en particulier pour
la partie quantitative. Ceux-ci seront le cas échéant transmis
à des développeurs dédiés à cette fonction
pour les mettre définitivement aux normes de développement de la
société.
Les prototypes seront dans tous les cas suffisamment
documentés pour être réutilisables. Tous les documents
ayant servi au développement devront être consignés et
transmirent aux services responsables de la maintenance.
Il en sera de même de toutes les branches
explorées qui seront documentées même si elles
n'aboutissent pas toujours à des prototypes ou à des usages
immédiats.
Budget estimé:
- Les ressources matérielles existent
déjà et ne nécessitent pas d'investissements
complémentaires. Cela inclut les ressources en équipement
informatiques, les frais de déplacement et tous frais annexes.
- Les formations seront incluses dans le budget global de
formation 2004 en Angola.
On s'en tiendra à deux semaines de cours d'une valeur
de: 3000usd.
- Les ressources documentaires et informatiques seront
réparties sur les budgets de fonctionnement des différents
chantiers. Ceci s'explique par le simple fait que la supervision ne dispose pas
de budget propre.
On peut l'estimer à une licence "Maximo 4.0.3 single
user", quelques ouvrages de référence et textes de normes. Le
tout ne devant pas dépasser: 10000usd.
- Frais annexes non encore définis: 2000usd.
Le proposition de budget est de l'ordre de:
15000usd.
Planning prévisionnel du projet:
La durée du projet ne devra pas excéder 8 mois
dans sa première étape.
|
Mars
|
Avril
|
Mai
|
Juin
|
Juillet
|
Août
|
Septembre
|
Octobre
|
|
12
|
24
|
19
|
19
|
14
|
14
|
9
|
8
|
1
|
|
Angola
|
Congés
|
Angola
|
Congés
|
Angola
|
|
(1)
|
|
|
|
|
|
|
|
|
|
(2)
|
|
|
|
|
|
|
|
|
|
(3)
|
|
|
|
|
|
|
|
|
|
(4)
|
|
|
|
|
|
|
|
|
|
(5)
|
|
|
|
|
|
|
|
|
|
(6)
|
|
|
|
|
|
|
|
|
|
(7)
|
|
|
|
|
|
|
|
|
|
(8)
|
|
Table 2 Planning
prévisionnel.
1) 12 Mars réception du courrier d'acceptation du
dossier par le CNAM Paris.
12 Mars au 24 Mars: Acquisition des ressources. Durée
d'apprentissage du produit Maximo et des outils associés.
Démarrage de l'étude de l'existant.
2) 24 Mars, réunion d'expression des besoins avec les
personnes de la base Luanda.
24 Mars au 19 Avril: Développement d'un "prototype
n°1" de la partie quantitative sous MS-Access afin de faciliter la
visualisation des données. Validation du prototype par la base.
Présentation des résultats sur certains chantiers.
3) 19 Avril, réunion d'expression des besoins avec les
personnes de la base Luanda.
19 Avril, 19 Mai: Développement sous SQR "prototype
n°2" de la version MS-Access. Addition des modules manquants et correction
à partir des informations obtenues grâce au premier prototype.
4) 19 Mai, présentation du produit au personnel de la
base Luanda. Nouvelle expression des besoins et validation de la solution.
19 Mai,14 Juin développement du "prototype n°3"
à partir de l'expression des besoins.
5) 14 Juin, réunion d'expression des besoins avec les
personnes de la base Luanda.
6) 14 Juin,14 Juillet développement du "prototype
n°4" à partir de l'expression des besoins. Intégration dans
Maximo et test en réel sur plusieurs sites. Présentation au
personnel des chantiers.
7) 14 Juillet début de l'étude et
développement d'éventuels prototypes concernant la partie
qualitative.
8) 1 Octobre, envoi du dossier au CNAM.
Octobre 2004, présentation des résultats aux
responsables de la maintenance LDA. Prises de décisions concernant
l'avenir du projet et sa future implantation dans les standards du groupe.
Note: Les réunions d'expressions des besoins au niveau
des chantiers ne sont pas planifiables. Elles se feront lors des passages du
CPI et suivant la disponibilité des personnes.
- Le projet a été approuvé par la
direction de "Pride Foramer Angola" et par le département maintenance du
siège Houston en Février 2004.
- Il devra se faire en parallèle avec les autres
activités de supervision de la maintenance du CPI.
- Il se fera en collaboration avec le développeur de
siège social de Houston.
Engagements et lancement du projet:
Répertoire des intervenants:
La table 3 contient la liste des intervenants dans le projet.
Aucun nom n'est cité volontairement dans ce qui suit, car le rythme des
rotations implique une personne différente tous les mois.
Les identifiant des fonctions ne sont pas tous usuels au sein
de notre compagnie. Elles ont été créées pour des
raisons pratiques et seront utilisées dans le reste du document lorsque
leur répétition imposerait un texte trop lourd.
Le contexte de travail des chantiers de forage
pétrolier et l'aspect dispersé des différentes
compétences feront qu'il ne sera pas possible de réunir ces
personnes en même temps dans une salle.
- Le CPI sera le seul à pouvoir rencontrer tous les
intervenants.
- La communication s'effectuera principalement par courrier
électronique.
- Des réunions informelles se feront avec les chefs de
services lors du passage du CPI sur les différents appareils.
- Les réunions sur la base de LDA (LUANDA) se feront
lors des débuts et fins des séjours du CPI.
- La planification des réunions sera très
dépendante des conditions opérationnelles.
|
"ID"
|
Fonction
|
Responsabilité dans le projet
|
|
HHOM
|
Service maintenance siège social Houston:
Ce service est responsable de la mise en place de Maximo sur les
différents appareils de Pride. Elle centralise toutes les informations
de maintenance et tente de généraliser les procédures.
|
Il validera la solution finale et suivant l'état du
développement la mettra en oeuvre ou confiera la réalisation par
des intervenants internes ou externes. Il pourra être consultée
dans les phases intermédiaires du projet.
|
|
LDAD
|
Direction base Luanda:
|
Elle soutiendra le projet dans ses aspects financiers. Elle
approuvera l'initiative et les moyens associés.
|
|
LDAO
|
Direction des opérations base LDA:
Elle est responsable de la partie opérationnelle des
chantiers et de l'infrastructure. Il en existe une par client.
|
Elle proposera des solutions et validera la partie
opérationnelle du projet aux différentes
étapes du prototype.
|
|
LDADS
|
Drilling Supervisors base LDA:
Ils sont responsables de la gestion d'un chantier de forage.
|
Ils proposeront des solutions et valideront la partie
opérationnelle du projet aux différentes étapes du
prototype.
|
|
LDAM
|
Service Maintenance base LDA:
Il gère l'ensemble des opérations de maintenance
des appareils d'Angola ainsi que les superviseurs des différentes
spécialités.
|
Ils proposeront des solutions et valideront la partie maintenance
du projet aux différentes étapes du prototype.
|
|
SM
|
"Site Manager":
Ils sont responsables de la gestion des opérations au
niveau des chantiers pendant les opérations de forage.
|
Ils proposeront des solutions. Ils n'auront qu'un rôle
consultatif.
|
|
TC
|
"Technical Coordinator":
Il coordonne les opérations de maintenance de tous les
services sur les chantiers. C'est l'interlocuteur des chantiers en ce qui
concerne tous les problèmes liés à l'usage de Maximo.
|
Ils proposeront des solutions et valideront le prototype pour les
aspects liés à son usage au sein du chantier.
|
|
HOD
|
Head Of Department:
Ce sont les responsables du personnel de maintenance dans leur
domaine (électricité, mécanique, hydraulique...).
|
Ils auront un rôle consultatif en ce qui concerne les
éventuelles contraintes de saisie additionnelles. Ils ne sont pas
concernés directement par le projet.
|
|
MCREW
|
Maintenance CREW:
Ce sont les équipes qui effectuent les maintenances
correctives ou préventives sur les équipements. Ils sont pour
certains d'eux amenés à faire la saisie des rapports dans
Maximo.
|
On tiendra compte de leur avis pour toute modification
liée à la saisie des rapports. Ils sont à même de
signaler les imperfections d'un JP à leur chef de service. Ils
permettront de définir les limites des écrans de saisie. Ils
n'interviendront pas directement dans le projet.
|
|
MSUP
|
Maintenance SUPervisors:
Ce sont les personnes qui supervisent la maintenance sur les
différents chantiers. Ce sont les experts dans les domaines qui les
concernent.
|
Ils proposeront des solutions et valideront les prototypes
à ses différentes étapes en particulier pour la partie
qualitative.
|
|
CPI
|
Chef de Projet Informatique:
L'auteur de ce document.
|
Il effectuera:
- La conception
- L'animation des réunions d'expression des besoins.
- Le développement des prototypes.
|
|
|
|
Table 3 Répertoire
des intervenants.
Contexte et contraintes:
Environnement:
Dans le titre de ce mémoire, nous avons pris soin de
préciser dans quel contexte se ferait l'étude. En effet, il
s'agit d'un milieu particulier qui engendre des contraintes
spécifiques.
Tout d'abord le milieu. Il s'agit de forage pétrolier
en mer sur des unités flottantes à positionnement dynamique. Ces
appareils sont le plus souvent situés dans des pays en voie de
développement ou la logistique est particulièrement difficile. En
l'occurrence pour notre cas, en Angola qui sort d'une guerre qui a duré
une vingtaine d'années. L'éloignement des côtes ne fait que
compliquer les problèmes d'approvisionnement même pour les choses
les plus élémentaires.
Pourtant, il règne au sein de ces unités une
organisation et une rigueur importante qui seule permet de maintenir les
appareils en état de fonctionnement. Cela nécessite des
capacités de prévision importantes et une très bonne
connaissance des équipements.
Le personnel encadrant de ces unités est de
qualité, mais il doit disposer d'outils adéquats pour pouvoir
faire face à tous les évènements auxquels il est
confronté sans faire appel le plus souvent à des ressources
extérieures. C'est là qu'intervient la gestion de la maintenance
par le produit Maximo.
Cependant, pour ces personnes, l'informatique n'est pas une
fin en soi. Pour eux, le travail se situe aussi bien dans les bureaux que sur
les équipements. Les deux aspects étant complémentaires et
ne pouvant pas fonctionner sans l'autre.
Saisir des données informatiques ne leur pose aucun
problème, mais ils veulent en savoir la raison et surtout quel en sera
le bénéfice direct sur leur activité. Il est parfois
souhaitable d'avoir des contraintes fortes pour pouvoir imposer des projets,
car la résistance est grande lorsque les objectifs ne sont pas
visibles.
Dans certains cas, les données de maintenance ne sont
que validées par les responsables et sont saisies par des subalternes.
Les propositions d'amélioration de la saisie devront tenir compte de cet
état de fait afin de ne pas imposer des travaux de relecture importants
aux chefs de service.
Il conviendra de tenir compte des différents
interlocuteurs intéressés par les rapports de maintenance.
Suivant le point de vue où l'on se trouve, on souhaitera obtenir des
informations différentes:
- Les personnes des chantiers ont une vision plutôt
locale de la maintenance.
- Les superviseurs ont une vision globale, mais cherchent des
outils leurs permettant de cibler leurs recherches des équipements
à problèmes ou encore des améliorations à apporter
à la maintenance. Ils cherchent à étendre leurs
diagnostics à plusieurs unités.
- Les responsables de la base veulent se faire une opinion
globale sur la qualité et l'efficacité de la maintenance. Ils
veulent à partir de ces informations de synthèse pouvoir trouver
des arguments pour débloquer des budgets ou des ressources.
- Les responsables de la maintenance du siège social de
Houston (HHOM) cherchent à généraliser les maintenances en
comparant les éléments des différents chantiers au sein du
groupe.
Contexte:
Le rôle de l'auteur au sein de l'organisation lui permet
de connaître toutes les unités et les responsables locaux
impliquées dans les choix de maintenance ainsi que les cadres à
terre. Il lui faudra synthétiser les réflexions de ces personnes
chacune d'elles ayant des domaines de prédilection particuliers. Sauf
avec les cadres de la base, il sera physiquement impossible de réunir
les personnes concernées en même temps dans un même bureau.
C'est pourquoi la communication s'effectuera principalement par courrier
électronique sauf les réunions de la base LDA qui s'effectueront
à chacun de ses passages à terre.
Techniques:
Il nous faudra tenir compte aussi des contraintes liées
au produit Maximo. Celui-ci est très configurable, mais il nous a
été demandé expressément de n'utiliser que les
outils fournis par le produit Maximo. Si des modules externes devaient
être ajoutés, ils devraient pouvoir être implanté
dans l'environnement réseau existant et pourvoir migrer avec les
versions supérieures du produit.
Dans l'immédiat, la connaissance du produit par le CPI
est celle d'un utilisateur averti. Il devra se former à Maximo, son
administration ainsi qu'aux outils de développement qui lui son
propre.
Temps:
Il se pose aussi une contrainte de temps. En effet, sur les
chantiers, nous travaillons 28 jours d'affilés suivis d'une
période de congés de même durée. Ce projet n'est pas
la seule activité de l'auteur. Il devra l'exécuter en
parallèle avec ses autres responsabilités. Ce qui imposera des
arbitrages en fonction des conditions opérationnelles.
Autres:
Il faut aussi signaler l'emploi de beaucoup de termes anglais.
Cet usage est volontaire et correspond à celui de notre
société. Etant une compagnie internationale, la langue
parlée principale et celle des rapports sont l'Anglaise. Ce rapport sera
traduit en Anglais par la suite. L'auteur n'a pas essayé de traduire
tous les termes en usage en Anglais pour de simples facilités de
compréhension ce qui explique une certaine pratique du Franglais qui
pourrait choquer les puristes.
En résumé, l'auteur devra:
- Améliorer ses connaissances des circuits de
données.
- Prendre en compte les contraintes liées aux personnes
et à l'environnement.
- Se former à Maximo et à ses outils.
- Se former aux techniques de la maintenance.
- Organiser son temps de travail et arbitrer.
Analyse de l'existant.
Organisation générale de l'application
Maximo:
L'application Maximo est découpée en
différents modules décrits dans le schéma suivant (Fig.3).
Seule la partie "Preventive Maintenance System" (PMS) fera partie de cette
étude même si par la suite, les autres modules pourront en
être influencés indirectement.
Dans la partie PMS, les trois modules qui nous concernent et
les liens qui les unissent sont décrits par la suite en ne
détaillant que les parties qui apparaissent dans un premier temps
nécessaires à l'étude.
Vu la complexité de chaque module et des liens entre
eux, certains points seront approfondis au fur et à mesure des
étapes du prototypage et aux différentes périodes de la
conception.
De même, on ne s'attardera pas à faire le reverse
engineering sur la base de donnée dans la mesure ou celle-ci prés
existe. On ne donnera que les détails pragmatiques nécessaires
à la conception et le plus directement possible à la
création du prototype.
Les écrans de Maximo sont paramétrables et
adaptés à notre application. Dans ce qui suit, les copies
d'écrans sont celles de ceux utilisés actuellement et non les
écrans d'origine de l'application.
Figure 3 Organisation
générale de Maximo.
Module "Equipment" (EQPT):
Il contient l'arborescence des équipements d'un
chantier. Les équipements des chantiers ont été
structurés sous forme d'arbre en partant du général vers
le détail. Chaque équipement est identifié par un
numéro de 9 caractères.
Les deux premiers niveaux de l'arbre sont définis une
fois pour toutes par les administrateurs Maximo du siège social de
Houston. Les autres niveaux peuvent être adaptés par les "Super
Users" ou les "Technical Coordinator" (TC) au niveau des chantiers. Les
utilisateurs normaux n'ont qu'un accès en consultation et ne peuvent en
modifier la structure ni les dénominations.
Il faut noter la taille variable des différentes zones
du code qui pourra complexifier toute analyse liée à cet arbre en
utilisant les différentes subdivisions. Il existe aussi de nombreux
exemples où cette hiérarchie n'est pas respectée et
où le repérage d'un équipement dans l'arbre ne peut pas
être déduit de l'organisation des chiffres qui le compose. On
préférera reconstruire l'arbre à partir des données
de chaque chantier en utilisant les champs EQNUM & PARENT.
Sur les appareils tels que les bateaux à positionnement
dynamique, le nombre d'équipements peut aller jusqu'à
5000. Par contre, il n'est que de l'ordre du millier sur un
chantier terrestre.
L'arbre des équipements est organisé comme
suit:
Rig code (2 ou 3 caractères) qui correspond au code
comptable du chantier.
Family (1 ou 2 caractères) 9 familles de base.
Subfamily (2 caractères) sous ensembles,
Systèmes, Etc.
Equipment
(3 caractères incluant les sous équipements)
équipements individuels
Equipment
Sub-Equipment
Equipment
- C'est dans ce module que sont entrées les valeurs des
compteurs permettant de déclencher les maintenances préventives
(PM) programmées (Meter-Based PM).
- Il maintient un historique du statut des équipements
(équipement up/down). Il existe une notion d'équipement
opérationnel ou non (downtime), mais le statut ne peut être
modifié que dans un "Work Order" (WO).
- Il contient des informations propres à cet
équipement dont certaines peuvent être utilisées pour les
PM.
Structure des différentes tables associées au
module EQUIPMENT:
|
Table: EQUIPMENT main table for the
EQUIPMENT module
|
|
FIELDS
|
TYPE
|
SIZE
|
Name on screen
|
Value list/table
|
Comment
|
|
EQNUM
|
UPPER
|
10
|
Equipment
|
NA
|
|
|
DESCRIPTION
|
ALN
|
50
|
NA
|
NA
|
|
|
PARENT
|
UPPER
|
10
|
Belongs To
|
Drill Down
|
|
|
PARENTDESC
|
ALN
|
50
|
NA
|
NA
|
|
|
LOCATION
|
UPPER
|
8
|
JDE Class / Sub-Class
|
Location
|
|
|
LOC_DESCRIPTION
|
ALN
|
50
|
NA
|
NA
|
|
|
VENDOR
|
UPPER
|
8
|
Vendor
|
Company
|
|
|
VENDORDESC
|
ALN
|
50
|
NA
|
NA
|
|
|
MANUFACTURER
|
UPPER
|
8
|
Manufacturer
|
Company
|
|
|
MANUFACDESC
|
ALN
|
50
|
NA
|
NA
|
|
|
EQ15
|
ALN
|
16
|
Meter reading ?
|
PRUSER
|
|
|
EQ3
|
ALN
|
1
|
Critical Level
|
CRITIC
|
1, 2 or 3 not used
|
|
ISRUNNING
|
YORN
|
1
|
Up?
|
NA
|
|
|
ASSETNUM
|
ALN
|
30
|
Asset
|
NA
|
|
|
EQ9
|
YORN
|
1
|
ISM
|
NA
|
ISM flag (Y or N) , update WOEQ9 & PMEQ1 by a script if
modified
|
|
STATUSDATE
|
DATETIME
|
10
|
Date
|
NA
|
|
|
SERIALNUM
|
ALN
|
15
|
Serial #
|
NA
|
|
|
CLASSIFICATION
|
UPPER
|
50
|
Classification
|
EQCLASS
|
|
|
TOTDOWNTIME
|
DURATION
|
8
|
Total Downtime
|
NA
|
|
|
TOTALCOST
|
AMOUNT
|
10
|
Total
|
NA
|
|
|
INSTALLDATE
|
DATE
|
4
|
Installation Date
|
NA
|
|
|
CHANGEBY
|
ALN
|
20
|
Modified By
|
NA
|
|
|
YTDCOST
|
AMOUNT
|
10
|
YTD
|
NA
|
|
|
PURCHASEPRICE
|
AMOUNT
|
10
|
Purchase Price
|
NA
|
|
|
CHANGEDATE
|
DATETIME
|
10
|
Date
|
NA
|
|
|
EQ16
|
ALN
|
40
|
Certifying Authority #
|
NA
|
|
|
EQ17
|
ALN
|
40
|
Certifying Authority
|
NA
|
|
|
EQ18
|
DATE
|
4
|
Date
|
NA
|
|
|
METERREADING
|
DECIMAL
|
15
|
Last reading
|
NA
|
In the Meters tab
|
|
READINGDATE
|
DATETIME
|
10
|
Last reading date
|
NA
|
In the Meters tab
|
|
AVGMETERUNIT
|
DECIMAL
|
15
|
Avg. Unit/day
|
NA
|
In the Meters tab
|
|
METERUNIT1
|
ALN
|
10
|
Meter Units
|
NA
|
In the PM module only
|
|
CLASSSTRUCTUREID
|
UPPER
|
8
|
Classification
|
CLASSSTRUCTURE
|
Tab "Specification"
|
|
|
|
|
|
|
|
Table: EQSTATUS history of the
equipment status
|
|
FIELDS
|
TYPE
|
SIZE
|
Name on screen
|
Value list/table
|
Comment
|
|
EQNUM
|
UPPER
|
10
|
NA
|
NA
|
|
WONUM
|
UPPER
|
10
|
NA
|
NA
|
|
|
ISRUNNING
|
YORN
|
1
|
NA
|
NA
|
Y or N
|
|
CHANGEDATE
|
DATETIME
|
10
|
NA
|
NA
|
|
|
CHANGEBY
|
ALN
|
20
|
NA
|
NA
|
Login user name
|
|
DOWNTIME
|
DURATION
|
8
|
NA
|
NA
|
|
|
CALNUM
|
UPPER
|
8
|
NA
|
NA
|
|
|
LDKEY
|
INTEGER
|
4
|
NA
|
NA
|
Link to long description
|
|
CODE
|
UPPER
|
8
|
NA
|
NA
|
|
|
OPERATIONAL
|
YORN
|
1
|
NA
|
NA
|
Y or N no more used
|
|
LOCATION
|
UPPER
|
8
|
NA
|
NA
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 4 Tables du module
EQUIPMENT.
Ecran principal du module EQUIPMENT:
Cet écran contient les informations
générales concernant un équipement (Fig.4). Il contient
aussi un certain nombre d'informations propres à certaines
certifications.
Figure 4 Fenêtre
principale du module EQUIPMENT
Les champs qui pourraient être utiles pour
l'étude sont les suivants:
- Le champ ISM: Ce champ à Y
spécifie un équipement de sécurité critique pour la
certification ISM du navire. Cette certification est nécessaire pour
l'obtention du certificat de navigabilité du navire. Ce champ n'est
accessible à aucun des utilisateurs des chantiers. Il est
renseigné par les administrateurs du siège de Houston.
- Le champ "Critical Level": Ce champ n'est pas
utilisé, mais possède trois niveaux de criticité. Il
n'existe pas de règle d'usage.
- Le champ "Classification": Ce champ qui devrait
contenir la classification de type d'équipement n'est pas utilisé
la majorité du temps (80% ne sont pas renseignés). La table
prédéfinie contient 23 valeurs qui seront décrites plus
loin.
- Le champ "Up ?": Qui spécifie
si l'équipement est fonctionnel ou non. Il ne peut être mis
à jour que par l'intermédiaire d'un "Work Order" (WO). Chaque
changement de statut est enregistré dans la table EQSTATUS. Les champs
"Date" et "Total Downtime" sont des champs
calculés à partir des informations de changement d'état du
WO.
Les champs "Certifying Authority" de la zone
"Certification" ne sont que des zones de texte. Il n'existe pas de
règles de remplissage. Ce sont des informations qui concernent les
certificats spécifiques à un équipement et les dates de
renouvellement au format date.
Onglet "Meters" du module EQUIPMENT:
Figure 5 Onglet "Meters" du
module EQUIPMENT
C'est dans cet écran (Fig.5) que sont entrées
les valeurs de compteurs permettant de déclencher les Maintenances
Préventives (PM) basées sur les compteurs se trouvant sur les
équipements. On entre la valeur du compteur directement dans le champ
"New reading" ou le delta par rapport à la
dernière mesure dans "Reading Delta". La date du jour
de la saisie est automatiquement entrée dans "New reading date".
Les champs "Last reading", "Last
reading date" et "Avg. Units/Day" sont mis à
jour à partir des valeurs entrées dés que l'on sauvegarde
les données. Après la sauvegarde, les champs "New reading",
"Reading Delat" et "New reading date" sont mis à blanc.
Si une maintenance préventive (PM) est utilisée
pour cet équipement, les champs "Meter Readings"
associés du module PM sont mis à jour.
Onglet "Specification" du module EQUIPMENT:
Figure 6. Ecran
"Specification" du module EQUIPMENT.
L'écran (Fig.6) de cet onglet n'est pas utilisé
dans notre version actuelle, mais il contient les "Classification" et
"Subclassification" des équipements. Les éléments
caractéristiques de l'équipement sont définis pour chacune
de ces classes et sous classes. La table contenant la description de la
hiérarchie est nommée CLASSSTRUCTURE. Actuellement, les
caractéristiques des équipements sont entrées dans la
"Long description" en texte libre ce qui limite les comparaisons entre
chantiers.
Le champ classification des équipements se trouvant
dans l'écran principal du module équipement n'a pas de lien avec
celui-ci et les données ne sont pas extraites de la même table,
mais de la table VALUELIST décrite plus loin.
Module "Preventive Maintenance" (PM):
Ce module contient les informations permettant de
générer les "Work Order" (WO) des maintenances programmées
par le temps ou par les compteurs. Les PM sont créées sur les
chantiers par un "Super User" en l'occurrence le TC sur les chantiers. La
génération devrait se faire tous les 15 jours. En pratique, elle
est effectuée toutes les semaines.
Chaque PM est associée à un ou plusieurs Job
Plan (JP) et à un seul équipement (EQPT).
Structure des différentes tables associées au
module PM:
|
Table: PM main table of the preventive
maintenance module
|
|
FIELDS
|
TYPE
|
SIZE
|
Name on screen
|
Value list/table
|
|
|
PMNUM
|
UPPER
|
8
|
PM
|
NA
|
|
|
DESCRIPTION
|
ALN
|
50
|
NA
|
NA
|
|
|
EQNUM
|
UPPER
|
10
|
Equipment
|
Drill Down
|
|
|
EQDESCRIPTION
|
ALN
|
50
|
NA
|
NA
|
|
|
ROUTE
|
UPPER
|
8
|
Route
|
NA
|
|
|
ROUTEDESCR
|
ALN
|
50
|
NA
|
NA
|
|
|
JPNUM
|
UPPER
|
10
|
Job Plan
|
NA
|
Only if no JP sequence
|
|
JPDESCRIPTION
|
ALN
|
50
|
NA
|
NA
|
|
|
PMJP1
|
UPPER
|
8
|
Lead Craft
|
NA
|
|
|
WORKTYPE
|
UPPER
|
50
|
Work Type
|
Work Type Option
|
|
|
STORELOC
|
UPPER
|
8
|
Storeroom
|
Select Storeroom
|
|
|
CREWID
|
ALN
|
8
|
Crew
|
CREWID
|
|
|
PMJP4
|
ALN
|
20
|
Sub Work
|
NA
|
|
|
PMEQ1
|
YORN
|
1
|
ISM
|
NA
|
EQ9 in PM, WOEQ9 in WO
|
|
FREQUENCY
|
INTEGER
|
10
|
Frequency
|
|
Time based
|
|
FREQUNIT
|
UPPER
|
8
|
Frequency Units
|
|
|
|
METERFREQUENCY1
|
DECIMAL
|
11
|
Frequency
|
|
Meter based
|
|
LASTMETERREADING1
|
DECIMAL
|
8
|
Reading at last WO
|
|
|
|
LASTMETERDATE1
|
DATETIME
|
10
|
Date of last WO
|
|
|
|
FIRSTDATE
|
DATE
|
4
|
First Start Date
|
|
|
|
LASTSTARTDATE
|
DATE
|
4
|
Last Target Start Date
|
|
|
|
LASTCOMPDATE
|
DATE
|
4
|
Last Completion Date
|
|
|
|
USETARGETDATE
|
YORN
|
1
|
Use Target Date
|
|
|
|
EXTDATE
|
DATE
|
4
|
Extended Date
|
|
|
|
ADJNEXTDUE
|
YORN
|
1
|
Adjust Next Due Date
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 5 Tables du module
PM.
Ecran principal des PM: (Fig.7)
- Le champ "Lead Craft" provient du "Job
Plan" (JP). Il est copié dans le champ correspondant du WO
généré. Ce champ est obligatoire. Il est issu d'une liste
de valeurs prédéfinie.
- Le champ "ISM" provient du module EQPT. Il
est Y ou vide (= N).
- Le champ "CMS" (Continuous Machinery
Survey) indique un équipement pouvant être certifié par
l'intermédiaire d'un processus dit de maintenance continue de
l'équipement qui permet d'éviter des tests complets lors des
inspections de certifications par DNV. Il sera mis en service dans une
prochaine version à paraître en fin 2004 et sera positionné
sous le champ ISM.
- Le champ "Worktype" contient l'état
initial des PM générées. Il est toujours positionné
à WSCH.
- Le champ "Crew" contient l'équipe
qui sera copiée dans le WO généré. Ce champ n'est
pas obligatoire. Il est sélectionné dans une liste de valeurs
prédéfinie.
Figure 7 Ecran principal du
module PM
Ecran "Frequency" des PM: (Fig.8)
Cet écran contient toutes les informations
nécessaires pour la planification des maintenances
préventives.
Figure 8 Onglet "Frequency"
du module Preventive Maintenance.
Il existe deux types de méthodes de planification des
maintenances situées dans les deux zones correspondantes de
l'écran:
- Time-Based: Est la
planification par le temps.
Les champs "Frequency" et "Frequency
Unit" permettent de définir la périodicité de la
maintenance. Le premier est un nombre entier représentant le nombre
d'unité de temps. Lorsqu'il est à 0, la PM n'est pas
planifiée par le temps. Le second qui correspond à l'unité
de temps peut prendre les valeurs: YEARS (365 jours), MONTHS (30 jours) , WEEKS
ou DAYS.
La valeur "Next Due Date" est un champ
calculé à partir des valeurs de dates contenues dans la zone
"Work Order Generation Information". Il est calculé comme suit (Table
6):
|
Use Target Date
|
Adjust Next Due Date
|
Extended Date Exists
|
Next Due Date
|
|
Y
|
Y
|
Y
|
Extended Date + Frequency
|
|
Y
|
N
|
Y
|
Last Target Start Date + Frequency
|
|
N
|
Y or N
|
Y
|
Last Completion Date + Fequency
|
|
Y
|
N/A
|
N
|
Last Target Start Date + Frequency
|
|
N
|
N/A
|
N
|
Last Completion Date + Fequency
|
Table 6 Table de calcul pour
les maintenances basées sur le temps.
Note: Si le champ "Use Target Date" est à N, cela
indique que la prochaine maintenance sera effectuée à partir du
moment de fermeture du "Work Order" qui la concerne. Dans ce cas, le champ
"Next Due Date" ne peut être calculé et reste à blanc tant
que le "Work Order" n'est pas fermé.
- Meter-Based: Est la
planification par les compteurs se trouvant sur les équipements.
Ces compteurs peuvent avoir différentes significations
suivant le type d'équipement. Toutefois, dans notre application, cela ne
représente que des heures de fonctionnement. Ce type de maintenance est
lié au module EQUIPEMENT ou sont entrées les valeurs des
compteurs des équipements concernés par ce type de PM.
Le champ "Frequency" est le nombre
d'unités de comptage entre deux générations de PM. Les
unités de comptage sont celles que mesurent les compteurs des
équipements. Sur nos unités, il s'agit d'heures. S'il est blanc
ou 0, il n'y a pas de planification par le temps.
Le champ "Avg.Meter Unit/Day" provient de la
table équipement. Il s'agit de la valeur moyenne des comptages
effectués par jour. Elle est mise à jour au fur et à
mesure que l'on entre les valeurs des compteurs dans le module
équipement.
Le champ "Reading at last WO" est
copié de la table EQUIPEMENT chaque fois qu'un WO est
généré.
Le champ "Date of Last WO" est copié
de la table EQUIPEMENT chaque fois qu'un WO est généré. Il
correspond à la date de la lecture de la dernière mesure.
Les champs "Estimate next reading" et
"Estimate Next Due Date" sont des champs calculés. Ils
correspondent respectivement à l'estimation de la valeur de la mesure
à la date estimée de la génération de la prochaine
PM. Ces deux champs sont mis à jour au fur et à mesure que l'on
entre des valeurs de compteurs dans le module équipement.
Les champs "Estimate next reading" et
"Estimate Next Due Date" sont calculés comme suit
(Table 7):
|
S'il y a eu un enregistrement de compteur dans le
module EQPT depuis que le WO a été généré
par la PM:
|
|
|
Equipment Meter 1 Last Reading Date +
PM Meter 1 Freq - (Equipment Meter 1 New Reading - PM Meter
1 Reading at Last WO)
PM Meter 1 Average Units per Day
|
|
S'il n'y a pas eu d'enregistrement de compteur dans
le module EQPT depuis que le WO a été généré
par la PM:
|
|
|
Si Use Target Start = Y
|
|
PM Last Target Start Date + (PM Meter 1 Frequency / PM Meter 1
Avg. Units per Day)
|
|
|
Si Use Target Start = N
|
|
PM Last Completion Date + ( PM Meter 1 Frequency / PM Meter 1
Avg. Units per Day)
|
Table 7 Table de calcul pour
les maintenances basées sur les compteurs.
La zone "Work Order Generation Information" contient
les informations de planification des PM des deux types.
- Le champ "First Start Date". Date de
démarrage de la planification de cette PM par le temps. La planification
par le temps ne démarre que si une valeur existe dans ce champ.
- Le champ "Last Target Start Date" date
à laquelle le WO généré par la PM était
prévu de démarrer.
- Le champ "Last Completion Date" contient la
date de fermeture du dernier WO créé par cette PM.
- Le champ "Use Target Start" lorsqu'il est
à N indique que la planification ne se fera qu'à
partir de la date de clôture du WO (Last Completion Date) et non à
la date prévue par le système. Dans ce cas, toute la
planification est décalée dans le temps. Lorsqu'il est à
Y, il impose une planification stricte dans le temps et peut
dans une certaine mesure accroître le nombre de maintenance en retard
(overdue).
- Le champ "Sequenced" indique si la PM utilise une
séquence dans le JP qui lui est associé. Le "JP sequence" est une
technique permettant de séquencer plusieurs JP au fur et à mesure
de leur planification. Cette option n'est pas encore implémentée
et l'on considérera que l'on n'a qu'un et un seul JP par PM.
- Le champ "Counter" indique le nombre de PM
effectuées depuis "First Start Date".
- Le champ "Use Frequency for Scheduling"
indique si le système de hiérarchie des PM sera utilisé ou
non lorsque les critères de déclenchement de la PM seront
atteints. Cette option n'est pas encore implémentée.
Note: Les notions de JP séquence et de PM
hiérarchie serons implémentés dans la nouvelle
révision à paraître en fin 2004.
La zone "Override Due Date" contient les informations
permettant de décaler une PM dans le temps.
- Le champ "Extended Date" contient la date
à laquelle la PM aura lieu. Il ne s'applique qu'à la PM courante
et non plus à sa hiérarchie. Il est remis à blanc
dés que la PM a été générée. Ce champ
est en lecture seule si "First Date" ou "Next Due Date" est
vide. Il remplace la valeur de "Next Due Date" par celle de "Adjust Next Due
Date" lorsque les conditions sont remplies.
- Le champ "Adjust Next Due Date" n'est
accessible que si une valeur est entrée dans "Extend Date". Il doit
être à Y pour que cette date soit prise en compte. Il est mis
à blanc dés que la PM a été
générée.
Module "Job plan" (JP):
Un JP est une liste d'instructions qui décrivent les
opérations à effectuer lors des opérations de maintenance
préventive. Dans certains cas, ils peuvent aussi s'appliquer aux
maintenances correctives.
- Les JP sont majoritairement créés par les
superviseurs ou par les HOD des chantiers.
- Les JP sont idéalement communs à l'ensemble
des chantiers de la compagnie même si dans la pratique, la plupart sont
spécifiques à un chantier.
- Toute création d'un JP doit être faite par
l'intermédiaire d'un formulaire spécifique. Les JP sont ensuite
validés par les TC ou HOD des autres chantiers de la région
possédant le même équipement s'il en existe. La version
définitive est transmise au service maintenance de la base LDA qui le
transmet au service maintenance de Houston pour approbation.
- Les mises à jour des JP ne peuvent être
effectuées que par l'intermédiaire d'un programme de mise
à jour en provenance des administrateurs de Maximo au siège
social de Houston.
- La majorité des JP sont proposés par les
chantiers et adaptés à leurs équipements sauf s'il s'agit
d'équipements génériques pour lesquels il existe
déjà des JP au niveau du groupe.
Module "Work Order Tracking" (WO):
Ce module permet le suivi des WO des maintenances
préventives (PWO) générées par le module PM ou
encore les WO de maintenances correctives (CWO) créées par
l'utilisateur. Il maintient un historique de l'état des WO pendant leur
cycle de vie.
C'est dans les menus des WO que l'on peut définir si un
équipement est opérationnel ou non (downtime). Le statut de
l'équipement est reporté dans la table EQSTATUS des historiques
du module équipement.
Définition des différents types de
maintenances:
Même si d'autres types de maintenances existent dans
Maximo, seuls deux types de maintenances sont utilisés dans notre
application.
- Maintenance Préventive (PM):
Il s'agit d'une maintenance planifiée dans le temps ou
par l'intermédiaire de compteurs se trouvant sur les équipements.
Elle a pour objectif de réduire la fréquence des
dysfonctionnements d'un équipement. A chaque maintenance sont
associés des "Job Plan" qui correspondent à une liste
d'opérations à effectuer. La maintenance préventive permet
de faire des visites de routines, des mesures ou de remplacer des pièces
d'usure ou des consommables. Lorsqu'une panne est détectée
pendant ces opérations, elle doit faire l'objet d'une maintenance
corrective. Une pièce est remplacée au cours de la PM lorsque la
probabilité qu'elle soit dégradée avant la prochaine
maintenance programmée est trop grande.
Le fait que ces maintenances soient programmées doit
permettre de faire les approvisionnements à temps avant qu'elles ne
soient déclenchées.
- Maintenance Corrective (CM):
Il s'agit de toutes les maintenances non programmées
déclenchées par la défaillance d'un équipement.
Elle comprend le diagnostic, la réparation et les tests de remise en
service. Dans la mesure où par nature elles ne sont pas
prévisibles, les pièces nécessaires à la
réparation peuvent ne pas être disponibles (WMATL) ou les
conditions opérationnelles adéquates pour pouvoir les
réaliser (WOPCOND).
Toutes les activités correctives devraient être
enregistrées dans le système afin d'en conserver un historique
nécessaire pour améliorer les maintenances.
Structure des différentes tables associées au
module WO:
|
Table: WORKORDER main table of the
Work Order module.
|
|
FIELD
|
TYPE
|
SIZE
|
Name on screen
|
Value list/Table
|
|
|
WONUM
|
UPPER
|
10
|
Work Order
|
NA
|
|
|
DESCRIPTION
|
ALN
|
50
|
NA
|
NA
|
Free for
the CWO, from PM for PWO
|
|
WOPRIORITY
|
INTEGER
|
4
|
WO Priority
|
WOPRIOR
|
|
|
EQNUM
|
UPPER
|
10
|
Equipment
|
Drill Down
|
|
|
EQDESCRIPTION
|
ALN
|
50
|
NA
|
NA
|
Linked to EQNUM
|
|
ISRUNNING
|
YORN
|
1
|
Equipment Up?
|
NA
|
|
|
STATUS
|
UPPER
|
50
|
Status
|
WOSTATUS
|
|
|
REPORTDATE
|
DATETIME
|
10
|
Reported Date
|
NA
|
|
|
WOEQ9
|
YORN
|
1
|
ISM
|
NA
|
Necessary for ISM certification
EQ9 in EQPT, PMEQ1 in PM
|
|
WO1
|
ALN
|
20
|
MR N°
|
NA
|
Material request(s) number, free text
|
|
STATUSDATE
|
DATETIME
|
10
|
Status Date
|
NA
|
|
|
WORKTYPE
|
UPPER
|
50
|
Work Type
|
Work Type Opt
|
|
|
WOJP3
|
ALN
|
1
|
API RP 8B
|
NA
|
|
|
WO3
|
YORN
|
1
|
Print this WO in the end of Trip report
|
NA
|
|
|
WOJP4
|
ALN
|
20
|
Sub-Work Type
|
NA
|
|
|
JPNUM
|
UPPER
|
10
|
Job Plan
|
Select Job Plan by Work Asset
|
|
|
SAFETYPLAN
|
UPPER
|
8
|
Safety Plan
|
NA
|
|
|
FAILURECODE
|
UPPER
|
20
|
Failure Class
|
NA
|
Not used
|
|
ORIGINWO
|
|
|
Originating WO
|
NA
|
|
|
PMNUM
|
UPPER
|
8
|
PM
|
NA
|
|
|
PROBLEMCODE
|
UPPER
|
20
|
Problem Code
|
NA
|
Not used
|
|
HASFOLLOWUPWORK
|
YORN
|
1
|
Has Follow-up Work?
|
NA
|
|
|
ACTSTART
|
DATETIME
|
10
|
Start Date
|
NA
|
|
|
ACTFINISH
|
DATETIME
|
10
|
Finish Date
|
NA
|
|
|
WO7
|
ALN
|
18
|
Reported By
|
NA
|
|
|
WO2
|
DURATION
|
8
|
Meter reading
|
NA
|
|
|
REMDUR
|
DURATION
|
8
|
Duration
|
NA
|
|
|
WOJP1
|
UPPER
|
8
|
Lead Craft
|
Leadcraft
|
In fact department
|
|
WO6
|
ALN
|
4
|
% Completion
|
PERCOMP
|
|
|
CREWID
|
ALN
|
8
|
Crew
|
CREWID
|
|
|
SUPERVISOR
|
UPPER
|
8
|
Supervisor
|
LABOR
|
|
|
CHANGEBY
|
ALN
|
20
|
By
|
NA
|
Login username
|
|
CHANGEDATE
|
DATETIME
|
10
|
Date
|
NA
|
|
|
WOJP1
|
UPPER
|
8
|
Lead Craft
|
LEADCRAFT
|
|
|
|
|
|
|
|
|
Table: WOSTATUS status history of the
WO (can be seen in "Action", "View WO status")
|
|
FIELD
|
TYPE
|
SIZE
|
Name on screen
|
Value list/Table
|
|
|
WONUM
|
UPPER
|
10
|
Work Order
|
N/A
|
|
|
STATUS
|
UPPER
|
8
|
Status
|
WOSTATUS
|
|
|
CHANGEDATE
|
DATETIME
|
10
|
|
N/A
|
|
|
CHANGEBY
|
UPPER
|
18
|
By
|
NA
|
Login user name
|
|
MEMO
|
ALN
|
50
|
|
NA
|
|
|
GLACCOUNT
|
ALN
|
20
|
|
NA
|
|
|
|
|
|
|
|
|
Table: MATUSETRANS History of the
stock consumptions of the WO.
|
|
FIELD
|
TYPE
|
SIZE
|
Name on screen
|
Value list/Table
|
|
|
WONUM
|
UPPER
|
10
|
Work Order
|
NA
|
|
|
EQNUM
|
UPPER
|
10
|
Equipement
|
Drill Down
|
|
|
LINECOST
|
AMOUNT
|
10
|
Line Cost
|
NA
|
|
|
|
|
|
|
|
Table 8 Tables du module
"Work Order".
Ecran principal du module "Work Order": (Fig.9)
- Le champ "Work order" contient un
numéro en 10 chiffres uniques. Il est automatiquement
généré soit lors de la génération des
maintenances préventives dans le module PM ou encore lorsque
l'utilisateur crée une maintenance corrective dans le module WO. Le
texte sur la droite du numéro de MR est celui du module PM pour les
maintenances préventives. Il est entré par l'utilisateur pour les
correctives. Dans le même champ, en cliquant sur un onglet, on peut
entrer ce qui est nommé une "Longue description". Cette description doit
contenir les informations détaillant les opérations
effectuées lors de la maintenance. Elle contient le texte "job done
as per job plan nothing abnormal to report" lorsque la PM vient juste
d'être générée et se trouve dans l'état
WSCH.
- Le champ "Equipment" provient de la PM qui
a généré le "Work Order" pour les maintenances
préventives. Il est entré par l'utilisateur pour les correctives.
Dans ce cas, il est de l'initiative de l'utilisateur de sélectionner ou
non une branche détail ou non de l'arbre des équipements. Cela
implique que les historiques des maintenances correctives peuvent se trouver
à différents niveaux de l'arbre pour une même maintenance
faite par un utilisateur différent.
- Le champ "Status" sera explicité
plus loin. Le champ "Status date" est renseigné lorsque
l'on change le statut d'un WO. Le champ "Reported date" est la
date de création du WO.
- Le champ "MR N°" est un champ texte
libre, mais il devrait contenir des informations relatives aux requêtes
de matériel (MR) faites lorsque le statut du WO est en WMATL.
- Le champ "Work type" ne devrait être
que PM ou CM pour maintenances préventives et correctives. Il existe
d'autres états disponibles, mais qui ne devraient pas être
utilisés dans notre application. Ils seront ignorés par la
suite.
- Le champ "Equipement Up?" est à Y
lorsque l'équipement est opérationnel, il est à N dans le
cas contraire. Il est issu du module PM. Par contre, son statut ne peut
être changé que dans un WO à l'aide des menus: "Action",
"Report downtime" pour un passage de Y à N ou réciproquement ou
encore dans "Action", "Equipement eqpt Up/Down status" après coup
lorsque l'action est passée. Dans le premier cas, on ne devra pas
oublier de passer l'équipement "Up" avant de fermer le WO. Dans le
second, on indique le début de l'état "Down" et la date de retour
à l'état "Up". Dans les deux cas, le statut de
l'équipement est enregistré dans l'historique des
équipements.
Ce champ devrait être utilisé à chaque
fois qu'un équipement n'est plus opérationnel.
- Le champ "ISM" principalement utilisé pour les PM
signifie que la maintenance est nécessaire à la certification
ISM. Il est lié à l'équipement choisi dans le WO.
Figure 9 Ecran principale du
module Work Order.
La zone "Job details" indique les numéros de
PM et de "Job Plan" utilisés lorsqu'il s'agit d'une PM uniquement.
Toutefois, rien n'interdit d'utiliser le champ JP pour une CM.
La zone "Problem" n'est pas utilisée et aucune
valeur n'est proposée. L'arborescence des "Problems/Causes/Remedies"
devrait être entrée dans le module "Failure code" pour
apparaître à cet endroit.
La zone "Scheduling information" contient des
informations relatives aux travaux exécutés:
- "Start date" et "Finish
date" correspondent aux dates de début et de fin des travaux.
Cela peut représenter la période d'indisponibilité des
équipements, mais pas la durée des travaux surtout lorsque les
travaux sont effectués en plusieurs fois.
- Le champ "Duration" doit indiquer la
durée effective des travaux (man-hours). En pratique, il indique le plus
souvent la durée des travaux par manque d'information. La tendance va
vers un remplissage correct.
- Le champ "% completion" indique le
pourcentage de travaux effectué. En pratique, il ne sert que lorsqu'il
est à 100% pour indiquer au chef de service qu'il peut passer
l'état à COMP après vérification du contenu du WO.
Il n'est pas souvent mis à jour sauf parfois lors des changements
d'état des WO. Toutefois, la tendance récente est à la
mise à jour.
- "Meter reading" et "Estimated
duration" ne sont que des indications concernant les compteurs lorsque
l'appareil en dispose et du temps estimé pour les travaux.
La zone "Responsability" permet d'indiquer les
personnes responsables des travaux:
- "Reported by" contient le nom de la
personne ayant fait les travaux. Il s'agit d'un texte libre.
- "Lead craft" est issu de la table
prédéfinie "LEADCRAFT". Il désigne le responsable du site
ou s'effectuent les travaux.
- "Crew" est issu de la table
prédéfinie "CREWID". Il indique l'équipe effectuant les
travaux.
- "Supervisor" est issu de la table
prédéfinie "LABOR". Il indique la personne qui supervise les
travaux.
Ces trois derniers champs seront décrits plus loin dans
le chapitre relatif aux tables prédéfinies.
La zone "Modified" indique par qui a
été modifié le WO la dernière fois ainsi que la
date de la dernière modification. Le champ "By" est issu du "Username"
lors du "Login" sur la base. Il peut toutefois être changé sans
contrôle de la valeur. Les WO CLOSE devraient tous l'être pas le
TC, les COMP par les chefs de service.
Ecran de l'onglet "Actual" du module "Work Order":
Cet écran est utilisé pour entrer les
pièces du stock consommées durant les opérations de
maintenance préventive ou corrective. Les informations sont ensuite
stockées dans la table MATUSETRANS. L'information qui nous concerne est
le champ "Line Cost" qui contient le coût total en USD de chaque ligne de
chaque élément consommé dans le WO. Il pourra nous servir
à calculer la partie financière des rapports.
La signification de chaque état d'un "Work Order"
est la suivante: (Table 9)
|
Signification
|
Abréviation
|
Détail
|
|
Wait for APPRoval
|
WAPPR
|
Il s'agit de l'état initial d'un "Work Order" de
maintenance corrective (CWO). Sa date de création n'a pas toujours de
lien avec la date réelle de découverte d'un problème
même si l'on tend à la faire correspondre.
|
|
Wait on SCHedule
|
WSCH
|
Il s'agit de l'état initial d'un "Work Order" de
maintenances préventives (PWO) après leur
génération par le "Technical Coordinator" (TC) dans le module PM.
Il s'agit de l'état initial indiqué dans le champ "Work Type" de
la PM correspondante. Ce champ est toujours à WSCH dans notre
application. Dans la mesure où les PWO sont
générées de 1 semaine à 15 jours avant leur
échéance, la date de création peut être
antérieure à la date de déclenchement.
|
|
APPRoved
|
APPR
|
Cet état n'est pas utilisé dans notre application.
S'il était utilisé, il servirait à mobiliser les
ressources de stock de pièces, de personnel et d'outils.
|
|
IN PRoGess
|
INPRG
|
Il indique que les travaux correspondants au WO sont
lancés. Il est le résultat de l'action INITIATE dans les menus.
Il devrait correspondre à la date de départ des travaux.
|
|
Waiting for OPerating CONDitions
|
WOPCOND
|
Cet état indique que le WO ne peut être
exécuté faute de conditions opérationnelles
adéquates.
|
|
Wait for MATeriaL
|
WMATL
|
Cet état indique que l'on ne dispose pas des pièces
de rechange nécessaires pour effectuer la réparation. On y
associe le plus souvent un numéro de requête de matériel
dans le champ "MR N°" (Material Request Number).
|
|
COMPlete
|
COMP
|
Il devrait suivre le passage du champ "% Completion" à
100%. Indiquant au chef de service (HOD) que les travaux ont été
terminés par les équipes de maintenance. Le WO doit dans ce cas
être complètement rempli et vérifié par le HOD. Les
champs commentaire, "Duration" et les dates de début et de fin
renseignées.
|
|
CLOSE
|
CLOSE
|
C'est l'état qui suit COMP. Le "Technical Coordinator"
(TC) passe le WO dans cet état après vérification de son
contenu et que tous les champs soient correctement renseignés. Il est le
seul à pouvoir passer le WO dans cet état. Lorsque des
informations manquent, le HOD devra reprendre le WO et le corriger.
|
|
Cancel
|
CAN
|
Work Order annulé par l'utilisateur.
Les cas d'annulation de PM doivent être rares et
justifiés surtout s'il s'agit d'équipements de type ISM.
|
|
HISToric EDIT
|
HISTEDIT
|
Ce champ n'apparaît pas directement dans la liste des
états disponibles aux utilisateurs. Il est toutefois noté dans le
fichier historique des statuts des WO. Il indique qu'un WO a été
modifié après sa fermeture par le TC. Celui-ci est le seul
à pouvoir le faire.
|
|
|
|
Table 9 Tables des
états d'un "Work Order".
Le schéma de passage entre les différents
états d'un WO: (Fig.10)
Figure 10 Work Order
statut.
Chaque type de WO suivant qu'il soit correctif ou
préventif peut prendre différents états. Le schéma
de passage d'un état à l'autre est défini non seulement
par le progiciel, mais aussi par des règles organisationnelles.
Les règles de passage entre états
imposées par le progiciel sont décrites dans le schéma
précédent (Fig.10).
Les états intermédiaires WAPPR et WSCH sont les
états de départ respectifs des maintenances correctives et
préventives. Les états intermédiaires APPR et INPRG sont
des états dont la fonction n'est pas claire et reste à
définir dans notre organisation. La logique voudrait que les
états WSCH et WAPPR aboutissent à INPRG sans passer par APPR qui
n'a pas d'application dans notre organisation.
Il faut noter qu'il n'existe pas toujours de lien temporel
entre la date de passage dans un état particulier et sa
réalisation pratique sur le terrain. Cela pourrait compliquer
singulièrement l'utilisation des dates pour faire des calculs
qualitatifs sur les équipements.
Les règles de passage d'un état à l'autre
sont figées par le système, mais elles correspondent au
schéma suivant en terme d'organisation: (Fig.11)
Figure 11 Diagramme "Work
Order tracking".
Schéma
relationnel des tables principales:
Figure 12 Schéma
relationnel des principales tables.
Détails de quelques tables près
définies:
Maximo contient un certain nombre de tables
prédéfinies servant à contrôler les entrées
de certains champs.
Ces deux tables montrent l'ambiguïté de certaines
d'entre elles. La première LEADCRAFT représente la personne
responsable du site et l'autre, CREWID indique quel département effectue
le travail. La nuance est parfois subtile et peu utilisée sur les
chantiers sinon incomprise la majorité du temps.
LEADCRAFT
|
|
CREWID
|
CE
|
Chief Electrician
|
|
BOP
|
Sub Sea Department
|
RM
|
Rig Mechanic
|
|
DRILL
|
Drilling Department
|
HYD
|
Hydraulic Man
|
|
ELE
|
Electric Department
|
BOP
|
Sub Sea Engineer
|
|
MAR
|
Marine Department
|
ENG
|
Chief Engineer
|
|
MEC
|
Mechanical Department
|
STP
|
Senor Tool Pusher
|
|
SAF
|
Safety Department
|
MAR
|
Barge Master
|
|
HYD
|
Hydraulic Department
|
CM
|
Chief mechanic
|
|
ENG
|
Engine department
|
SAF
|
Safety Officer
|
|
MAT
|
Material Man Department
|
|
|
|
|
|
Table 10 Contenu des tables
prédéfinies LeadCraft & CrewID.
Il faut aussi noter que les valeurs RM, MEC et CM
représentent la même personne. Il en est de même entre HYD
et BOP ainsi que CE et ELE. Ces listes seront simplifiées dans une
prochaine version.
Certaines valeurs prés définies des
écrans Maximo se trouvent dans la table VALUELIST.
C'est le cas pour le champ "Classification" du module
équipement. On les retrouve en sélectionnant le champ
LISTNAME=EQCLASS. Cette liste pourra nous être utile pour classer les
taux de défaillance par type d'équipement.
|
VALUE
|
VALDESC
|
|
VALUE
|
VALDESC
|
|
ACMOTORS
|
AC Motors
|
|
HYDMISC
|
Hydraulic Miscellaneous
|
|
AIRDRYER
|
Air Dryer
|
|
MARMISC
|
Marine Miscellaneous
|
|
AIRRCVR
|
Air Receiver
|
|
MECMISC
|
Mechanic Miscellaneous
|
|
ALTERNAT
|
Alternator
|
|
MOTORS
|
Motors
|
|
COMPRESS
|
Compressors
|
|
MUDTREAT
|
Mud Treatment
|
|
COOLING
|
Cooling System
|
|
PUMPS
|
Pumps
|
|
DCMOTORS
|
DC Motors
|
|
SAFETY
|
Safety
|
|
DRILLEQT
|
Drilling Equipment
|
|
SUBSEAEQT
|
Sub Sea Equipment
|
|
DRILLINST
|
Drilling Instrumentation
|
|
TANK
|
Tank
|
|
ELEMISC
|
Electrical Miscellaneous
|
|
VALVES
|
Valves
|
|
HOISTEQT
|
Hoisting Equipment
|
|
WINCHES
|
Winches
|
|
HVAC
|
Heating/Ventilation/Air Cond
|
|
|
|
Table 11 Valeurs
prédéfinies du champ "Classification".
Lorsque l'on rapporte un "Down
time", il est possible d'indiquer un "Down time code ". Ce code permet de
caractériser l'opération ayant occasionné l'arrêt.
Les codes se trouvent dans la table VALUELIST en sélectionnant le champ
LISTNAME= DOWNCODE.
|
VALUE
|
VALDESC
|
|
VALUE
|
VALDESC
|
|
01
|
Fishing operations
|
|
07
|
Marine repair
|
|
02
|
Downtime operator
|
|
08
|
Subsea repair
|
|
03
|
Waiting on weather
|
|
09
|
Engine repair
|
|
04
|
Drilling repair
|
|
10
|
Preventive maintenance
|
|
05
|
Mechanical repair
|
|
11
|
Other
|
|
06
|
Electrical repair
|
|
|
|
Table 12 Downtime
codes.
Schéma
d'interconnexion entre modules:
Les informations des différents modules sont
entrées suivant une certaine organisation. Sans entrer dans les
détails opérationnels qui parfois différent
singulièrement de la logique dans laquelle cela devrait fait, nous
détaillerons les différents modules et leurs interconnexions dans
la (Fig.13). Nous ne rentrerons pas à nouveau dans la description de
chaque module, car ils ont été décrits plus haut dans les
chapitres précédents.
- L'arborescence des équipements est
créée lors de l'implantation de Maximo sur un chantier à
partir des listes des matériels installés. Elle peut ensuite
être adaptée au sein du chantier par le "Technical Coordinator"
(TC) en fonction du remplacement d'un équipement ou de sa
disparition.
- Chaque équipement possède un certain nombre de
documentations qui permettent de définir les "Job Plans" (JP) des
maintenances de base. Il existe des JP types définis au sein du groupe
pour des mêmes types d'équipements, les autres seront
créés la plupart du temps par les superviseurs de chaque
spécialité ou à défaut par les personnes du bord,
en général les chefs de services (HOD).
Dans tous les cas, toute création ou modification d'un
JP passe par une phase d'approbation par les gestionnaires de la maintenance
à Houston. Les JP ne peuvent être implantés que par
l'exécution d'un programme utilisant des données en provenance du
service maintenance de Houston.
- Un JP doit être associé à une
maintenance préventive (PM) pour être visible au niveau des
opérateurs de maintenance. Chaque PM est associée à un
unique équipement et à un JP (parfois plusieurs dans le cas de JP
séquences, cette partie n'étant pas utilisée dans
l'immédiat, elle ne sera pas traitée). Les experts
définiront les fréquences et le type de planification des
maintenances dans un premier temps à partir des informations des
constructeurs et pourront les adapter suivant les informations
complémentaires dont ils disposent.
Figure 13 Diagramme de
retour d'expérience dans Maximo.
Le retour d'expérience agit
principalement sur le contenu des opérations de maintenance
préventive à exécuter décrites dans les JP ou
encore, sur la fréquence des PM.
Il peut s'effectuer par différents moyens:
è Adaptation afin de les faire correspondre aux
réalités du chantier ainsi qu'en fonction des expériences
acquises sur l'équipement.
è Examen des historiques des maintenances correctives
et des anomalies apportées.
è Examen de l'historique des maintenances
préventives et des paramètres qui s'y trouvent lorsqu'il s'agit
de mesure, de notion d'usure ou de toute autre information pertinente.
è Apport extérieur de l'avis des superviseurs
avec une vision plus large du même équipement sur d'autres
chantiers.
è Apports des constructeurs sous forme de modifications
d'améliorations ou de nouvelles recommandations.
Rapports existants:
Chacun des modules décrits précédemment
est associé à des rapports permettant leur suivi. Même si
chacun de ces rapports présente un intérêt dans son
domaine, aucun de ces rapports ne contient d'informations permettant de faire
une analyse quantitative ni qualitative de la maintenance effectuée.
|
Rapport
|
Module
|
Description
|
Commentaire
|
|
END-TRIP
|
EQPT
|
Rapport de fin de séjour émis une fois par
mois.
|
Liste tous les WO avec détails émis avec le
statut"Print in end of trip report".
|
|
AUDIT
|
WO
|
Liste le statut des WO dans une période et par
département.
|
Donne une somme des WO, mais ne donne pas le détail par
type de WO.
|
|
DELIN-WO
|
WO
|
Liste les PWO ouverts ayant dépassé leur temps
d'ouverture.
|
Fonctionne partiellement, pas de règles
décrites.
|
|
WO-CLOSED
|
WO
|
Liste les WO Closed dans une période.
|
|
|
WORKPROG
|
WO
|
Ne fonctionnait pas.
|
?
|
|
WO-PREV
|
WO
|
Liste des WO Not Closed avec détails.
|
Pas de récapitulatif par Département ou
Statut.
|
|
PM-PREVI
|
PM
|
Prévision des PM à sortir dans une
période.
|
Nous n'avons pas d'idée sur la façon qui permet
de sortir ce rapport.
|
|
EQFAIL1
|
EQPT
|
Donne le Nombre de CWO, MTBF et "Downtime" moyen d'un
équipement.
|
Pas utilisé dans notre application.
Existe dans la version de base de Maximo, mais utilise le
champ FAILDATE non présent dans nos écrans.
|
|
EQFAIL2
|
EQPT
|
Idem, mais réparti par "Failure Code".
|
Pas utilisé dans notre application.
Nous n'utilisons pas les "Failure Code".
|
|
EQFAIL3
|
EQPT
|
Donne la liste détaillée des CWO pour un
équipement avec "Downtime", "Failure Code", cause, Remède et
dates.
|
Pas utilisé dans notre application.
Utilise les mêmes informations que
précédemment.
|
|
LOCFAILx
|
EQPT
|
Idem que les trois précédents, mais pour une
location particulière.
|
Nous n'utilisons pas la notion de location.
|
|
EQHSTGRA
|
EQPT
|
Donne les informations suivantes pour un équipement:
Total labor hours, ?mean response time for emergency work
orders, ?total downtime hours, ?mean time to repair, ?mean time between
failures.
Nécessite la présence des informations suivantes
dans les CWO:
Labor hours, response time, downtime, mean time to repair, and
mean time between failures
|
Pas utilisé dans notre application.
Ne donne les informations que pour un équipement. Les
informations ne sont pas présentes dans nos écrans. Rien ne
permet de les obtenir.
|
|
FAILGRPH
|
EQPT
|
Donne les informations suivantes pour un équipement:
Répartition des "Failure Type" en quantité et
%.
Utilise Excel pour afficher les données à partir
d'un fichier .CSV.
|
Pas utilisé dans notre application.
Listé dans Maximo, mais exécutable non
disponible.
Nous n'utilisons pas les "Failure Code".
|
|
RNRBYLOC
|
WO
|
Calcule les valeur suivantes pour une location:
- Mean time to respond =
AVG(ActStart - ReportDate)
- Mean time to repair (MTTR) =
AVG(ActFinish - ActStart)
|
Pas utilisé dans notre application. Listé dans
Maximo, mais exécutable non disponible.
Le calcul pour une location ne présente pas
d'intérêt dans notre application.
|
|
|
|
|
Table 13 Liste des rapports
existants.
En dehors des rapports standards de Maximo, il n'existe qu'une
initiative locale qui présente un intérêt. Il s'agit d'un
fichier MS-Access appelé CGOEQPT conçu par le
département maintenance. Il semble que les données y soient
entrées à la main et non automatiquement. Ce fichier trace
différentes courbes pour un même chantier.
La liste des courbes est la suivante:
- Nombre d'équipement hors service (ou Down) par
mois.
- Total des maintenances préventives en retard depuis
plus de 1 an et 6 mois.
- Total des maintenances préventives en attente par
mois.
- Total des maintenances préventives en attente par
mois et par département.
- Total des maintenances préventives ISM en attente par
mois.
- Total des maintenances préventives CLOSE par mois et
par département.
- Total des maintenances correctives CLOSE par mois et par
département.
- Total général des maintenances
préventives CLOSE par mois.
- Total général des maintenances correctives
CLOSE par mois.
- Total des maintenances préventives APPR par mois.
- Total des maintenances préventives WMATL par mois.
- Total des maintenances préventives WOPCOND par
mois.
Certaines idées de ce rapport pourront être
réutilisées dans le rapport final.
Droits d'accès aux modules et
rapports:
Maximo permet de contrôler l'accès à un
certain nombre d'objets de l'application. Il s'agit des Modules, les champs et
menus dans les différents écrans de chaque module ainsi que la
possibilité de lancer un rapport.
Il nous faudra définir qui aura le droit de lancer ce
rapport.
Aspects
financiers:
Les notions de coûts peuvent se retrouver à
plusieurs niveaux de Maximo.
- Dans le module inventaire qui contient l'ensemble des
pièces détachées associées à leur
coût.
- Au niveau des tables de taux de change. Ces taux doivent
normalement être changés une fois par mois à partir
d'informations comptables du siège.
- Dans le module "Work Order" ou chaque pièce est
sortis avec un coût converti en monnaie de référence (USD).
Tout cela dans la table MATUSETRANS aux valeurs du moment ou les pièces
ont été sorties.
- Dans le module EQUIPMENT qui contient le coût total de
l'installation ainsi que la date de mise en service (zone "Purchase
information"). Il contient aussi la totalité des coûts
associés à cet équipement depuis sa mise en service et
depuis la dernière remise à zéro (zone "Costs").
Ces champs sont mis à jour en lançant le rapport "Equipment cost
rollup" et "Zero equipment cost" du menu "Action".
Si des rapports financiers devaient être
réalisés, il faudra prendre les précautions d'usage et ne
pas confondre Maximo avec une comptabilité. Il est souvent difficile de
comparer les résultats comptables avec ceux d'une gestion de stock, car
ils n'utilisent pas les mêmes règles de gestion ni parfois les
mêmes informations pendant les mêmes périodes.
Nous pouvons aussi garder à l'esprit qu'en terme de
maintenance, nous cherchons des ordres d'idée plutôt que des
valeurs exactes aux centimes prêts. Cela dit, rien n'empêche de
tenter de faire correspondre les deux.
Architecture et ressources informatiques.
Description de la configuration type:
- Serveur dédié "MS-W2K Advanced server"
fonctionnant en RAID1 (mirroring) + Hot swap.
- Extension "MS-Windows Terminal Serveur".
- Moteur de base de données People Soft Centura "SQL
base 6.1.2".
- Application MRO "Maximo 4i v4.0.3" avec correctifs.
- Générateur de rapport BRIO (HYPERION/SCRIBE)
SQR4 viewer, Execute, print.
- Paramétrages d'écrans Maximo et rapports SQR
spécifiques de notre groupe.
- MS-Office 2K SP3 installé avec l'extension "Microsoft
Office Ressource Kit" pour assurer la compatibilité avec "Windows
Terminal Serveur" sur les postes clients.
- Les clients sont des PC installés avec W2K SP3 ou XP
et "Windows Terminal Server client".
- Le réseau est de l'Ethernet 10 ou 100baseT utilisant
le protocole TCP/IP.
- L'outil de développement des rapports BRIO
(HYPERION/SCRIBE) "SQR Workbench" livré avec Maximo n'est pas
installé sur les serveurs opérationnels.
Figure 14 Installation
matérielle et logicielle de Maximo.
L'application Maximo utilise une connexion Client/Server
(locale ou distante) à "SQL base" ou une connexion via ODBC pour
l'édition des rapports SQR.
Il peut coexister plusieurs bases de données en
même temps sur le serveur. Sur certains chantiers, on dispose des bases
de données d'autres chantiers similaires pour référence.
On pourra utiliser cette possibilité pour tester les rapports
définitifs sur des bases de test.
Toutes les adaptations du produit comme les écrans ou
les rapports sont installées sur le serveur et non sur les
différents clients. Elles sont communes à toutes les bases de
données.
Certaines applications liées à Maximo utilisent
la base de donnée Microsoft Access liée à "SQL base" par
ODBC. Office doit être installé avec les extensions "Terminal
Serveur" disponibles dans le "Microsoft Office
Ressource Kit" pour fonctionner dans cet environnement. Les informations
d'installation sont disponibles dans le document Q224313 de Microsoft.
Les clients utilisent Maximo par l'intermédiaire d'une
fenêtre de "Windows Terminal Server". Aucune application liée
à Maximo n'est installée sur le client. Toute modification de la
configuration de Maximo ou de ses rapports est donc appliquée
implicitement sur tous les postes qui se connectent au serveur. Cela facilite
grandement la maintenance.
L'utilisation de "Terminal Server" permet d'accéder aux
bases de données des différents chantiers à distance via
le réseau satellitaire global du groupe, pourvu que l'on ait un compte
sur le serveur concerné et que l'on ne recherche pas la
rapidité.
La gestion des licences "Windows Terminal Server" est
gérée globalement sur les serveurs du siège par
l'intermédiaire du réseau global.
Environnement d'installation:
Il existe des installations types de serveurs Maximo au sein
de notre groupe. Les répertoires sont définis dans ce qui
suit:
- D:\MAX403: Il contient les programmes de Maximo. On y trouve
entre autres les programmes des différents écrans dont certains
ont été adaptés à nos besoins par notre compagnie
à l'aide de l'outil "Centura Object
Nationalizer". Il s'agit de:
Equipment.exe, inventory.exe, pm.exe, po.exe, pr.exe,
jobplan.exe et wotrack.exe.
Ce répertoire contient aussi le fichier MAXIMO.INI et
SQL.INI. Le premier contient les paramètres de Maximo, le second ceux de
la connexion avec "SQL base".
- D:\SQR4: Il contient les programmes de
génération des rapports SQR (sqrwt.exe) et ceux
nécessaires à leur visualisation (sqrwv.exe).
- D:\SQR4\REPORTS\PRIDE: Contient les versions
compilées .SQT des rapports spécifiques à notre
compagnie.
- D:\CENTURA: Contient le moteur de la base de donnée
"SQL base", le fichier SQL.INI qui définit les connexions avec les bases
de données.
- D:\CENTURA\<database name>: Ce
ou ces répertoires contiennent les fichiers <database name>.DBS
des bases de données. Ils peuvent aussi contenir d'autres fichiers dont
ceux de transaction de "SQL base" (.LOG). Ce sont ces fichiers qui sont
sauvegardés quotidiennement et archivés après être
sorti du moteur de la base de données. Il n'existe pas de
procédé pour sauvegarder une base en fonctionnement.
Note: Il peut dans certains cas exister des variations suivant
l'ancienneté des installations. Dans ce cas, les répertoires ne
se trouvent pas aux emplacements décrits précédemment.
Note: L'installation locale utilisée pour les tests se
fera sur un portable ne possédant qu'un disque. Les tests se feront donc
dans le disque C: et non sur D:.
Note: Les adaptations des écrans Maximo ont fait
disparaître un certain nombre de champs qui ne sont pas
documentés.
Ressources informatiques:
Dans la mesure où l'auteur est amené à se
déplacer sur de nombreux chantiers, il lui faudra disposer d'une
configuration locale installée sur un portable.
Les travaux de prototypage des rapports devront se faire sur
cette plateforme et seront ensuite adaptés pour fonctionner sur un
serveur opérationnel.
- PC portable Pentium III avec 1024Mo RAM, disque 40Go, W2K
SP3, Office 2K SP3.
- CD d'installation "Maximo 4.0.3 for SQLbase 6.1.2" avec les
droits de licence et derniers service packs.
- Paramètres de l'application et derniers rapports avec
procédures d'installation.
- Mots de passe administrateur de Maximo
- CD installation "SQR Workbench".
- "Windows Terminal Server client".
- Dans la mesure du possible, les sources de certains rapports
SQR à titre de référence.
Ressources documentaires de base:
- Maximo User's manual.
- Maximo Admin. manual.
- SQL base Admin. manual.
- SQR user's manual, programmer's manual.
- SQR workbench user's manual.
- MS-Access programmer's manual et user's manual.
- Différents documents cités en
bibliographie.
Beaucoup de ces documents sont fournis avec Maximo sous forme
de fichiers .PDF. D'autres sources nous ont permis d'obtenir des
compléments de documentation.
Les outils de développement:
Les rapports Maximo sont exécutés
majoritairement sous SQR4 en utilisant une version pré compilée
(.SQT) du langage de développement SQR (.SQR). Les rapports sont ensuite
générés en format texte non formaté (.LIS) et en
format portable (.SPF) visualisable à l'aide du "SQR viewer". Le .SPF
est dit portable car il peut être interprété sur plusieurs
plateformes comme Unix, VMS, MVS et VM ou le "Viewer" est disponible.
Le format .LIS permet dans certains cas permettre d'extraire
des données des rapports, mais il nécessite des traitements pour
être utilisable en tant que tel.
Il faudra à terme arriver à une version SQT du
rapport pour l'intégrer dans l'application Maximo. Toutefois, les outils
de développement et d'examen des données ne sont pas très
puissants et pourraient dans une certaine mesure ralentir le
développement. C'est pourquoi nous avons proposé dans un premier
temps d'utiliser un outil intermédiaire pour effectuer le prototype de
l'application et proposer des données initiales mises en forme pour les
utilisateurs.
Certains rapports natifs de Maximo existent sous "Cristal
report", mais les développeurs du siège ne l'utilisent pas et
aucun de ceux utilisés par notre groupe n'utilisent cet outil. Nous
conserverons cette optique. Il s'agit plus d'un outil pour utilisateur final
qu'un outil de développement.
Dans l'installation de Maximo se trouve un outil de base
"SQLtalk" permettant d'effectuer des requêtes SQL sur
les bases de données. Cet outil est une implémentation
complète de SQL, mais n'est pas un outil de création de rapport
proprement dit.
Il possède les fonctionnalités suivantes:
- Définir la structure de la base.
- Ajouter, effacer ou changer des données dans une base
de données.
- Exécuter des requêtes sur une base de
données.
- Contrôler les accès et la
sécurité d'une base de donnée.
- Tester des requêtes SQL avant de les implanter dans
une application.
- Générer des rapports sous forme de texte non
formaté.
- Créer, sauver et rejouer des scripts utilisant des
commandes "SQLtalk".
L'exportation des données extraites par les
requêtes dans d'autres applications n'est pas aisée et rien n'est
prévu en ce sens. Nous l'utiliserons uniquement pour tester des
requêtes.
En addition à Maximo, nous disposons aussi d'un
générateur de rapport "VisualSCRIBE 5.0" qui
permet de définir des requêtes et de créer des rapports en
utilisant le langage SQR. Il pourra dans une certaine mesure nous permettre de
créer le corps de l'application, mais le contenu devra être
entièrement programmé pour les requêtes complexes.
Il inclut aussi un éditeur SQR qui permet de coloriser
les mots clefs et les commentaires. Cela pourrait nous faciliter le
développement par rapport à un éditeur de texte simple.
Aucun de ces outils ne permet d'examiner les données et
les résultats sous un format simple permettant de contrôler les
résultats. Notre application ne se contentera pas de simples
requêtes, mais nécessitera la compilation de nombreux
enregistrement afin d'effectuer un travail de synthèse. Les ordres de
grandeur hauts pour un navire à positionnement dynamique sont les
suivants:
|
Tables
|
WORKORDER
|
WOSTATUS
|
PM
|
EQUIPMENT
|
EQSTATUS
|
|
Enregistrements
|
40000
|
130000
|
3000
|
5000
|
300
|
Table 14 Exemple de tailles
de table Maximo.
Au regard des informations précédentes, nous
avons préconisé d'utiliser MS-Access pour effectuer les premiers
prototypes de l'application. L'objectif étant d'extraire des
données, de les mettre en forme et de vérifier les
résultats le plus rapidement possible afin de les présenter aux
futurs utilisateurs.
Un objectif secondaire, mais non négligeable est
l'examen des données se trouvant dans la base. En effet, Maximo
étant un progiciel, nous ne disposons pas toujours d'informations
précises sur la façon dont sont stockées les
données ni sur le contenu des différents champs. Seul MS-Access
permet un examen rapide et sans programmation des données d'une table
ainsi que l'export vers d'autres applications pour les retraiter.
Toutefois, MS-Access possède aussi un certain nombre
d'inconvénients:
- L'interface ODBC n'est pas très stable dans la
configuration que nous avons testée avec les versions de "SQLbase 6.1.2"
et ODBC sous W2K ou XP. C'est un problème connu par l'éditeur
"People Soft", mais qui nécessite de passer à une nouvelle
version de "SQLbase" incompatible avec notre version de Maximo. Nous avons
tenté le passage à une version 8.01 du driver ODBC, mais cela n'a
pas changé les problèmes.
- Le SQL généré par les rapports de
MS-Access n'est pas toujours utilisable pour extraire des données de
"SQLbase" via ODBC. C'est pourquoi les données seront dans un premier
temps importées avant d'être traitées.
- Les détails de la programmation "Access VB" peuvent
s'avérer complexes et souvent pas très bien documentés.
Une formation au "VB access" pourrait nous faire gagner du temps.
L'application définitive devra se faire par la suite
avec le langage SQR dont l'auteur fera l'apprentissage en parallèle avec
le développement du premier prototype.
La tentative de trouver des librairies de programmes SQR
adaptées à nos besoins n'a pas été très
concluante. La plupart d'entre elles donnent de bons exemples de programmation
SQR, mais ne peuvent pas s'adapter à nos besoins sans un grand travail
de reconstruction. La consultation du "Users-group" de Maximo a donné
quelques pistes pour la partie qualitative mais pas pour la partie
quantitative. Il nous faudra nous créer nos propres outils.
Le langage SQR permet de s'adapter à des bases de
données comme Oracle, Sybase, DB2, Informix, SQLBase... Notre
développement ne sera adapté qu'à SQLBase, car il n'est
pas à l'ordre du jour de changer de base de donnée. Des essais
sur SQLserver ont été faits, mais n'ont pas
présenté d'intérêt par rapport à
l'existant.
Formation:
Dans le temps imparti pour l'étude, il sera difficile
de faire tenir beaucoup de formation et de prendre le temps d'apprendre
complètement un langage. Toutefois, on peut préconiser:
- "Microsoft Acces VB", une semaine.
- "People Soft" SQR, une semaine.
La familiarisation avec Maximo et ses outils se fera pendant
la phase d'analyse des données. Elle devrait pourvoir tenir en trois
semaines.
Réunion initiale d'expression des
besoins.
Après avoir défini les grandes lignes du projet
avec les initiateurs du projet dans la partie initialisation, nous avons
organisé une réunion avec les autres décideurs afin de
cadrer les objectifs, redéfinir le problème et obtenir une base
stable pour le reste du projet. Le but est d'obtenir à la fin de cette
réunion une image assez claire des besoins des différents
intervenants permettant de définir les spécifications
fonctionnelles initiales.
Cette réunion servira de document de base pour la
réalisation des différents objectifs du projet.
On y examinera aussi les initiatives locales connues et
pouvant répondre à une partit du problème.
|
Minutes of meeting "Expression des besoins
initiale"
|
|
|
Situation:
|
|
Base "Pride Foramer" Luanda le 24 Mars 2004.
|
|
|
Participants: 7 personnes.
Durée 2 heures.
|
|
- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.
- LDAO: Directeur des opérations client TOTAL.
Initiateur du projet.
- 2*LDAM: Directeur de la maintenance LDA et son assistant.
- 2*LDARM: Rig Manager chantiers Pride Africa (PAN) et Pride
Angola (PAN).
- 1*TC: Technical Coordinator chantier Pride Africa.
|
|
|
Rappel sur les conditions de réalisation du
projet:
|
|
- Le projet est effectué par Ph JUNG en vue de
l'obtention du diplôme d'ingénieur DPE attribué par le CNAM
Paris. Ce projet s'effectuera en parallèle avec ses activités de
supervision.
- Le projet a été approuvé formellement
par le directeur de la base LDA en Février 2004.
- Il se fera en collaboration avec les développeurs du
service maintenance de Houston. Cette situation a été
officialisée par le courrier électronique du directeur de la
maintenance du siège social de Houston en février 2004.
- La durée du projet est de 8 mois à partir de
la date de cette réunion. Il devra donc se terminer en fin septembre
2004.
- Les personnes responsables des chantiers et de la base ont
été informées de cette situation et de la collaboration
qu'ils devront assurer au cours du développement de ce projet.
- Les personnes sont aussi informées que le projet se
fera sous forme de prototypes et que l'évolution du produit final sera
liée pour une grande part au retour d'informations qu'ils fourniront,
mais aussi de l'intérêt des participants à le faire
vivre.
- Les chantiers d'expérimentation seront les deux
navires à positionnement dynamique PAN et PAF.
|
|
|
Rappel des faits:
|
|
Il existe sur chaque chantier de forage un certain nombre de
rapports de synthèse permettant dans différents domaines de se
faire une idée de la qualité des prestations dans le domaine
concerné:
- MOCA (Monthly Operational Cost Analysis): Analyse des
coûts de la maintenance et des achats d'un chantier.
- MOR (Monthly Operational Report): Etat d'un chantier au
niveau opérationnel.
- MSR (Monthly Safety Report): Statistiques de
sécurité d'un chantier.
Chacun d'eux permet non seulement de suivre les
évolutions des marqueurs spécifiques à chaque
métier, mais aussi de comparer les chantiers.
Par contre, il n'existe aucun outil permettant de se faire une
idée de l'état de la maintenance ni de faire de comparaison entre
chantiers.
|
|
|
Rappel sur les objectifs du projet:
|
|
L'objet de cette étude est de fournir les moyens
d'analyse des historiques de maintenance du produit Maximo en vue
d'amélioration les performances et optimiser la maintenance des
appareils de forage de notre compagnie.
Pour cela, on se fixera plusieurs objectifs qui seront
étudiés séparément:
1) Fournir des outils d'analyse quantitatifs de la maintenance
au niveau opérationnel. Ce rapport aura pour nom MMR
(Monthly Maintenance Report).
2) Proposer des outils d'analyse qualitatifs au niveau des
équipements et définir les moyens de les mettre en place.
3) Proposer le cas échéant d'autres
méthodes ou outils permettant d'ajouter de la valeur aux rapports des
utilisateurs.
4) Diagnostiquer les dysfonctionnements de l'outil de
maintenance et le moyen de l'améliorer.
|
|
|
Limites de l'étude:
|
|
- On utilisera les données et de
préférence les outils de Maximo pour obtenir les
résultats.
- On essaiera dans la mesure du possible de se limiter aux
améliorations de l'usage du produit existant.
- Il ne s'agit pas de proposer de nouvelles méthodes de
maintenances, mais d'améliorer l'existant en proposant des outils de
diagnostic et de nouvelles méthodes de valorisations des
données.
- Dans certains cas, si les contraintes techniques sont trop
grandes par rapport au temps imparti, on ne produira pas une solution finale,
mais plutôt des résultats chiffrés de façon à
juger de la pertinence des données et de leur intérêt. Dans
ce cas, on ne préjugera pas des méthodes employées pour
les obtenir.
|
|
|
Synthèse des propositions des
participants:
|
|
Après présentation des objectifs, il a
été demandé aux différents intervenants de proposer
des éléments pouvant être intégrés dans le
futur rapport. Le compte rendu qui suit ne préjuge pas de la
faisabilité ni du bien fondé des informations demandées.
Il est reproduit d'une façon brute et les propositions seront
examinées plus loin.
a) Comptage des maintenances préventives et correctives
par département sur une période
b) Comparer les nombres de maintenances préventives
relativement aux correctives:
Les utilisateurs veulent voir l'évolution dans le temps
afin de déterminer la performance de la maintenance.
c) Comparer les temps de réalisation des
maintenances.
d) Comptage des "Work Order" avec détails par statut et
par département.
Lister au besoin les demandes de matériel
associées à l'état WMATL (Wait for Material).
e) Evolution des maintenances correctives sur une
période et par équipement:
Le but serait de pouvoir cibler un équipement à
problème.
f) Liste des maintenances préventives retardées
et raisons:
Afin de déterminer les principales causes faisant que
les maintenances préventives ne peuvent être
exécutées.
g) Liste des arrêts par équipements et
durée sur une période:
Le but est le repérage des équipements source de
problèmes.
h) Liste des équipements générant des
arrêts et causes sur une période.
i) Graphique des arrêts par équipement sur un an
glissant:
Evolution des arrêts sur un type d'équipement
pour voir les effets de la maintenance.
j) Liste des équipements en arrêt sans que le
chantier soit en arrêt.
k) Coûts des compagnies de service par type de travaux
et par équipement.
l) Faire un lien entre les maintenances et les types de
défaillances ISM. Proposer une méthode pour remplir les rapports
en utilisant ces notations.
Les rapports de maintenance, qu'ils soient correctif ou
préventif ne consistent qu'en un texte non structuré. Ce texte ne
permet pas de caractériser les types de pannes et donc de faire des
statistiques. Seule une reprise manuelle des commentaires permettrait de le
faire.
m) Associer les rapports aux certifications ISM:
Les travaux associés aux certifications ne peuvent
supporter de délais. Ils sont nécessaires aux certificats de
navigabilité des unités.
n) Notions de MTBF/MTTR par équipements:
Il s'agit de mesurer le taux de pannes dans un
équipement ainsi que les temps moyens de réparation. Cela devrait
permettre de juger de l'efficacité de la maintenance, mais aussi
à pouvoir redéfinir les périodicités des
maintenances.
o) Liste des maintenances préventives majeures (>1an
ou 1000heures) à effectuer dans le mois suivant:
Ce rapport permettrait de pouvoir préparer les achats
et les ressources de personnel ou en équipements.
p) Il a été demandé de proposer tout
moyen supplémentaire permettant de donner du contenu aux rapports de
maintenance.
q) Il est aussi fait mention de graphiques
récapitulatifs sur un an, mais sans vraiment préciser quoi.
En ce qui concerne les améliorations du produit Maximo,
il a été demandé d'observer en annexe les points
suivants:
r) Faire fonctionner les attachements de fichiers externes
à Maximo dans les "Work Order" afin de compléter les rapports
avec des informations plus pertinentes que le texte simple des commentaires.
s) Revisiter le rapport de fin de mois qui ne donne pas les
informations escomptées.
t) Lister les fichiers externes qui permettraient de
compléter les rapports de maintenance.
u) Vérifier la faisabilité d'un "Down time
report" à partir de Maximo.
v) Il a aussi été émis l'idée que
ce rapport puisse être sorti en milieu de mois pour voir
l'évolution des chiffres dans le mois. Nous déciderons de
l'intérêt de la chose plus tard.
|
|
|
Initiatives locales reconnues:
|
|
Il existe un certain nombre de rapports existants dans Maximo,
mais qui ne présentent pas selon les utilisateurs, le caractère
de synthèse que nous recherchons. Chacun donne des informations
partielles et parfois difficiles à interpréter. Certaines
personnes ont essayé de les utiliser pour faire des graphiques Excel
avec plus ou moins de bonheur.
Il existe aussi certaines tentatives de comptage, mais elles
non pu être faites que manuellement dans la mesure ou aucun des outils de
développement n'est disponible à l'utilisateur et qu'il n'existe
pas non plus de moyen simple de faire des exports de données. La
tentative de rapport sous MS-Access par le service maintenance pourrait
être une bonne base de départ pour la création des
graphiques.
Certaines personnes ont réussi sans grand succès
à extraire des données de la base à partir de SQLtalk. Les
problèmes d'import des données dans un tableur qu'ils ont
rencontré n'ont pas permis de continuer ces tests. En effet, SQLtalk ne
fournit pas de moyen de mise en forme des données de sortie.
Le rapport CGOEQPT est une initiative du service maintenance.
Elle contient un certain nombre de courbes décrites dans l'analyse de
l'existant. La saisie des informations est manuelle, mais la procédure
d'obtention des données est inconnue. Il pourrait malgré tout
servir de base pour les graphiques que nous proposerons.
|
|
|
Conclusions:
|
|
En fonction de ce qui précède, il a
été décidé les points suivants:
- Mr JUNG continue l'apprentissage du produit et devra
présenter un premier prototype chiffré dans un mois à
dater de cette réunion.
- Les résultats intermédiaires seront
envoyés pour critique aux intéressés par courrier
électronique avant son retour en Angola.
- Il présentera la première version du prototype
au personnel de la base le 19 Mai 2004.
|
Revue critique des
différents points:
a) Ne pose pas de problème, il s'agit d'un simple
comptage.
b) Suggère un pourcentage entre PM et CM. Il
suggère aussi la visualisation de ce rapport sur une longue
période. Admettons dans un premier temps une période de 1 an
glissant à partir de la date du rapport.
c) On veut comparer des temps de maintenance, mais entre quoi
et quoi ? On peut suggérer plusieurs solutions:
Comparer les temps des correctives et en sortir celles qui ont
mobilisé le plus de temps sur un équipement donné.
Lister les temps cumulés en heures et coûts de
maintenance pour chaque département.
d) Reviens à a). Le listage des MR (Material Request)
en attente permettrait à la base de juger de ceux qui bloquent un "Work
Order". Ce pourrait être une partie séparée du report pour
ne pas alourdir le format. Aucun rapport existant ne donne ces valeurs.
e) Ce point paraît difficile à réaliser
tel quel. En effet sur les navires, il existe environ 5000 équipements.
Cette demande pourrait faire partie de la partie qualitative et être
associée avec les MTBF ou MTTR. Il restera à déterminer
comment filtrer les équipements que l'on voudra voir apparaître ou
non.
f) Les seules causes de délais peuvent être les
états WOPCOND et WMATL. Les comptages des cas a) pourraient
répondre à cette demande.
g) Tous les "Downtime" ne sont pas reportés dans
Maximo. L'exploration des fichiers n'a pas montre l'intérêt de
cette information. Un changement de la procédure de déclaration
des arrêts pourrait rendre cette information plus pertinente.
h) Même problème que g).
i) De même que pour e), vu la quantité
d'équipement en jeu, il faudra trouver une représentation ou une
méthode pour représenter ce type d'information.
j) Cette notion n'existe plus dans cette version de Maximo.
k) Recherche où trouver l'information ?
l) ISM ne propose aucun classement des défaillances.
Par contre, il existe bien deux champs "Failure Class" et "Problem Code" dans
les "Work Order" qui permettraient de caractériser les défauts.
Cela fait partie de la partie qualitative. Il existe une norme de ce type qui
pourrait convenir pour notre environnements.
m) Il faudra extraire des informations relatives aux
équipements certifiés ISM et surtout au retard de maintenances
préventives de cette catégorie.
n) Il faudra vérifier que les données existantes
permettent d'effectuer ces calculs d'une façon fiable.
o) Ne pose pas de problème.
p) Nous tenterons de noter toute information nécessaire
à l'amélioration des rapports.
q) Cela reste à définir.
En ce qui concerne les propositions annexes et
améliorations possibles de Maximo:
r) Hors sujet. La procédure a déjà
été faite par le CPI. Elle doit être formalisée par
le siège de Houston dans les standards.
s) Hors sujet. Nous ne disposons pas des sources du
programme.
t) Il existe déjà un certain nombre de fichiers
externes permettant de compléter ceux de Maximo. Nous interrogerons les
utilisateurs à ce sujet. Un certain nombre de ces modules pourraient
faire partie des "Custom Applications" de Maximo.
u) Ce sujet doit être discuté avec les divers
responsables opérationnels, car c'est un point très sensible. Le
consensus à ce sujet est de garder Maximo hors de ce type de rapport. Il
s'agit d'un point très politique que seules les directions pourront
trancher.
v) Il faudra attendre les premiers prototypes pour juger de
l'intérêt des données. Il ne semble pas dans un premier
temps utile de suivre l'évolution des données à
très court terme sous peine de mauvaises interprétations.
Conception initiale partie
quantitative.
Au cours de ce chapitre, nous reprendrons les idées
fournies lors de l'expression des besoins. Nous tenterons de voir comment les
utiliser ou les écarter en fonction de leur faisabilité ou de
leur distance par rapport au contexte.
Les indices correspondent aux références de
l'expression des besoins.
Nous allons construire le format du premier prototype à
partir des demandes des utilisateurs sous forme d'une proposition non
fonctionnelle.
Les différents aspects du rapport
initial:
Paramètres d'entrée du
rapport:
Comme son nom l'indique, le MMR (Monthly
Maintenance Report) est un rapport mensuel que l'on devrait pouvoir sortir en
fin de chaque mois avec les autres rapports de synthèse existants.
Dans un premier temps, nous n'entrerons qu'un seul
paramètre qui sera la date de fin de période de l'exercice. Le
format sera celui généralement utilisé dans Maximo
à savoir: DD/MMM/YYYY.
Par exemple: 01/JUL/2003 pour obtenir les résultats
antérieurs à cette date non compris. Soit le mois de juin et les
précédents pour les graphiques sur un an.
On ne peut préjuger à ce niveau du
résultat si une personne entre une date quelconque. Dans tous les cas,
les chiffres du rapport seront calculés un mois en arrière
à partir de cette date. Cette situation imposera probablement d'utiliser
les historiques.
Il est fort probable que dans le futur produit fini, nous ne
rentrerons que le mois et l'année. Ce n'est pas encore le choix des
utilisateurs.
Entête et pieds de page du
rapport:
L'entête du rapport sera une copie de celui
utilisé dans les rapports Maximo existants. Il sera présent sur
toutes les pages du rapport. Il n'y aura pas de pied de page.
Figure 15 Entête des rapports Maximo.
- Le logo en haut à gauche.
- La pagination en haut à droite comprenant le
numéro de page courant ainsi que le nombre total de pages.
- Au centre, en texte intermédiaire le nom du rapport
suivit en dessous des dates de début et de fin du rapport pour les
parties mensuelles.
- En bas à gauche, la date d'impression du rapport
suivie du nom du chantier.
- En bas à droite, le nom du rapport dans Maximo suivit
du numéro de version du rapport afin de permettre un suivi des
versions.
- En bas d'entête une barre horizontale séparant
les résultats de l'entête.
Les cotes et tailles des différents
éléments ainsi que les marges seront reprises d'un rapport
existant.
Zone 1 du rapport:
Des points a), b) et c) on peut déduire qu'il existe
une demande de comptage des maintenances avec une répartition par
département, type de maintenance et statut.
- Les différents "Types" de maintenance d'un "Work
Order" (WO) sont: PM, CM, SM, RKS, ALT, RM, RPT. Seuls les deux types de
maintenances PM (Preventive Maintenance) et
CM (Corrective Maintenance) seront pris en compte dans notre
étude. Les autres types n'étant considérés que
comme des indications. L'état SM (Safety Maintenance) que nous avions
pris en considération au début semble avoir été
abandonné dans la nouvelle version à venir.
- Les différents "Status" d'un "Work Order" sont au
nombre de neuf:
|
WAPPR
|
APPR
|
WOPCOND
|
WMATL
|
INPRG
|
COMP
|
CLOSE
|
CAN
|
HISTEDIT
|
De ces huit états nous ne garderons que six:
|
WOPCOND
|
WMATL
|
INPRG
|
COMP
|
CLOSE
|
CAN
|
En effet, les états intermédiaires WAPPR, APPR
et INPRG pourront être regroupés dans un seul et même groupe
des "Work Order" en progrès. En pratique, on s'aperçoit que ces
états sont confondus par les utilisateurs et ne correspondent à
rien de précis en terme de travaux effectués. Ils ne font
qu'indiquer qu'un WO est ouvert et le travail en cours ou en phase de
l'être.
Le regroupement des valeurs sera nommé improprement
INPRG, qu'il faudra ne pas confondre avec le même état
spécifique à Maximo.
L'état HISTEDIT n'a pas de signification
opérationnelle et ne sera pas comptabilisé.
- La répartition par département pose un
problème, car il existe différents champs pouvant correspondre
à cette définition. Toutefois, dans l'écran des WO, seul
le champ "Lead Craft" est obligatoire les autres sont optionnels. Le champ
"Crew" a pratiquement la même signification que celle du "Lead Craft". Le
champ "Supervisor" ne présente pas d'intérêt. Nous
décidons donc de choisir le champ "Lead Craft" pour effectuer nos
sélections.
Dans la liste des "Lead Craft", se trouvent différents
champs signifiant la même chose: CM/RM ainsi que BOP/HYD sont les
mêmes personnes. On les regroupera respectivement sous les noms: CM et
HYD.
Ce qui représente au final sept valeurs:
|
HYD
|
CE
|
CM
|
ENG
|
MAR
|
STP
|
SAF
|
- A la suite de discussion avec différents
interlocuteurs lors de la création de cette partie, on ajoutera
plusieurs colonnes:
· Une colonne de total de chaque ligne "Total M".
· Une ligne correspondant au même total, mais pour
le mois précédent notée "M-1".
· Une colonne "Delta" qui correspond à la
différence entre le total du mois courant avec celui du mois
précédent afin de visualiser l'évolution.
· Enfin une colonne "%" qui indiquera le pourcentage de
chaque état d'un WO par rapport au total des WO cités dans le
tableau.
Les idées précédentes peuvent nous amener
à proposer deux tableaux. L'un pour les PM et l'autre pour les CM
regroupant les totaux demandés:
|
HYD
|
CE
|
CM
|
ENG
|
MAR
|
STP
|
SAF
|
Total M
|
M-1
|
Delta
|
%
|
WOPCOND
|
|
|
|
|
|
|
|
|
|
|
|
|
WMATL
|
|
|
|
|
|
|
|
|
|
|
|
|
INPRG
|
|
|
|
|
|
|
|
|
|
|
|
|
COMP
|
|
|
|
|
|
|
|
|
|
|
|
|
CLOSE
|
|
|
|
|
|
|
|
|
|
|
|
|
CAN
|
|
|
|
|
|
|
|
|
|
|
|
Zone 2 du rapport:
Dans l'expression des besoins c), se trouve aussi une
idée d'heures de travail fournies par les équipes. Il ne semble
pas très intéressant de calculer les heures avant que le "Work
Order" soit dans l'état CLOSE. En effet, les états
intermédiaires d'avancement des travaux ne sont que rarement remplis au
fur et à mesure des travaux.
Le calcul des heures peut s'effectuer de plusieurs
façons:
- En calculant la différence entre les dates de
début et fin des travaux. Cela ne peut tenir compte du nombre de
personnes ayant fait le travail ni des périodes d'interruption des
activités.
- En calculant la différence entre les dates
d'ouverture du "Work Order" et celui ou il est CLOSE. Cette solution ne peut
être retenue, car elle inclut aussi les états d'attente de
matériel ou pour opérations. Les états d'un WO ne
permettent pas de connaître la durée des travaux.
- En utilisant le champ REMDUR qui contient la durée
des travaux. Pourvu qu'il soit rempli correctement, ce champ est celui qui doit
contenir la durée exacte d'heures passées en
"man-hours". Ce champ n'est pas obligatoire dans notre
version.
Il faut toutefois remarque que la signification des ces heures
doit être prise avec circonspection. Elle devrait inclure la somme des
travaux effectués par chaque personne d'un même "Lead Craft" (ce
qui interdirait les regroupements entre services). Cela inclut:
- Le nombre d'heures pour la réalisation de la
tache.
- Les travaux de préparation et de fermeture du
chantier.
- Le temps d'écriture des rapports.
- Tout délai additionnel pendant lequel les personnes
mobilisées le sont restées sans pouvoir exécuter d'autres
taches.
On reprendra le format d'entête du tableau
précédent.
|
HYD
|
CE
|
CM
|
ENG
|
MAR
|
STP
|
SAF
|
Total M
|
M-1
|
Delta
|
CLOSE man hrs
|
|
|
|
|
|
|
|
|
|
|
Zone 3 du rapport:
Le rapport entre le nombre de maintenances préventives
par rapport à celui des correctives est un bon indicateur de la
qualité de la maintenance exécutée. En effet, un fort taux
de maintenances correctives peut indiquer plusieurs choses:
- Les maintenances préventives
sont inadaptées.
- Les maintenances préventives ne sont pas
planifiées correctement.
- Les maintenances préventives n'existent pas.
- Un problème sur un ou plusieurs
équipements.
On admet en général qu'un taux de maintenances
préventives de 80% relativement à toutes les maintenances
effectuées est correct. Le pourcentage sera comparé uniquement
sur les maintenances fermées (CLOSE) dans le mois du rapport.
Il est possible que ce taux soit différent dans le cas
d'équipements redondants. En effet, lorsqu'il y a redondance, il est
admis que l'on répare la partie redondante pendant que l'autre partie
fonctionne. Certains équipements sont conçus redondants lorsque
la fiabilité ne peut être garantie et que les conséquences
peuvent être importantes sur la sécurité et les
opérations.
C'est pourquoi cette comparaison devra toujours être
faite sur des unités similaires.
Le titre sera: "%PM/All WO CLOSE".
Zone 4 du rapport:
Il est fait mention d'une notion de retard
(overdue) dans la réalisation des maintenances
préventives. En pratique, les maintenances préventives sont
émises toutes les semaines (au lieu des 15 jours préconisé
dans les manuels). Cela fait que la majorité des maintenances sont
déjà en retard sauf celles qui ont une périodicité
inférieure à une semaine.
Il a été considéré qu'une
maintenance était en retard si sa réalisation excédait 25%
de sa période.
Nous donnerons donc un pourcentage des maintenances en retard
relativement à toutes les maintenances effectuées dans le
mois.
Il existe aussi une notion de maintenances effectuées
sur des équipements spécifiques dits ISM. Ces équipements
sont ceux liés à la sécurité et aux certificats de
navigabilité du navire. On en donnera donc aussi le pourcentage par
rapport au nombre total de maintenances effectuées dans le mois.
L'indicateur ISM se trouve dans les différentes tables: EQ9 dans la
table EQPT, PMEQ1 dans PM, WOEQ9 dans WO. Le champ ISM est très
important pour les unités maritimes uniquement, mais il fait partie des
requêtes des inspecteurs du DNV à chaque inspection de
certification.
Il s'agit de champs libres des tables Maximo et
utilisés dans l'adaptation faite par notre société.
Le calcul des champs "Next Due Date" nécessaire
à la détermination des "Overdue" a été
décrit dans la présentation de l'existant.
Les titres seront respectivement: "% overdue
ALL" et "% overdue ISM".
La proposition suivante a été
éliminée au profit des pourcentages en bout de chaque ligne de
statut. Les pourcentages de PM et "overdue" seront indiqués
séparément. Le zone ISPS a été
éliminée, car elle fait partie des certifications ISM.
|
% overdue
|
ISM overdue
|
ISPS ovr
|
%WSCH
|
%WMATL
|
%WOPCOND
|
MR Pending
|
|
|
|
|
|
|
|
Zone 5 du rapport:
Afin de répondre au point h) et partiellement à
g), nous pouvons proposer de donner une liste d'équipement ayant
occasionné le plus d'heures de travail dans le mois
considéré pour les PM et les CM. Il a été
considéré après consultation que les 5 premières
valeurs suffiraient. Nous nommerons ces listes "TOP5 list of man hours
consumption".
Les heures sont celles du champ DURATION dans les "Work
Order". Il avait été proposé initialement de mettre de
% d'heures par rapport au total des heures travaillées.
Les résultats calculés n'ont pas été très
significatifs.
Sur un seul mois, ces informations ne pourront pas donner une
information très utile. Par contre, la comparaison sur plusieurs mois
permettrait probablement de détecter des équipements à
problèmes. Cette partie ne saurait être suffisante pour la
détection de ce type d'équipements et devra être
complétée par d'autres informations de fiabilité.
Le terme "man-hours" indique la somme des
heures de travail cumulées de toutes les personnes ayant effectué
le travail. Voir l'explication dans le zone 2.
Nous proposons le format suivant pour les maintenances
préventives:
TOP5 list of PM man hours
consumption:
|
Hours
|
Equipment
|
Designation
|
|
96
|
053206603
|
Bridge crane fwd
|
Nous aurons une deuxième colonne du même format,
mais pour les maintenances correctives:
TOP5 list of CM man hours
consumption:
|
Hours
|
Equipment
|
Designation
|
|
120
|
053209401
|
Mud pump set #3
|
Zone 6 du rapport:
Afin de répondre à g), nous proposons une liste
des équipements en arrêt ou ayant été
arrêtés pendant la période du rapport. Nous l'appellerons
"Equipement down".
Le tableau devra comprendre la date de départ de
l'arrêt. Elle sera issue des historiques des équipements. Le
nombre de jours écoulés de la date du début de
l'arrêt jusqu'à la date de fin du rapport ou de celle de
l'arrêt si l'équipement est retourné en service entre
temps.
On y ajoutera le numéro du "Work Order" concerné
ainsi que l'état du WO. L'état du WO permettra de
déterminer s'il s'agit de causes opérationnelles (WOPCOND) ou
pour attente de matériel (WMATL). Dans ce dernier cas, on
précisera le numéro de requête de matériel (MR#) se
trouvant dans le champ "MR N°" du WO. Une case vide indiquerait que le WO
a été mal rempli et qu'il manque cette information importante
pour le compléter.
Nous avons aussi proposé une deuxième solution
qui comprend uniquement un décompte des équipements en
arrêt dans les six derniers mois. Nous verrons l'intérêt de
chacun au cours de la réalisation du prototype. La première
solution donne des détails sur les équipements en arrêt. La
seconde solution pourrait faire l'objet d'un graphique sur une année
plutôt qu'une solution tabulaire.
Nous proposons les deux formats suivants. Il faudra
décider du choix de l'un ou de l'autre lors des réunions
d'expression des besoins. La proposition 2 pourrait avantageusement être
remplacée par un graphique.
Equipement down: proposition 1
|
Since
|
Days
|
Equipment
|
Designation
|
WO#
|
Status
|
MR#
|
|
11/04/2004
|
30
|
053206603
|
Bridge crane fwd
|
530029241
|
WMATL
|
53006302
|
|
02/04/2004
|
12
|
053209401
|
Mud pump set #3
|
530026084
|
WOPCOND
|
|
Equipment down: proposition 2
|
P-5 and +
|
P-4
|
P-3
|
P-2
|
P-1 month
|
Period
|
|
|
|
|
|
|
Zone 7 du rapport:
Dans le point d), il est fait mention d'une liste de
requêtes d'équipement (MR) associée aux "Work Order"
préventifs ou correctifs se trouvant dans l'état WMATL. Cette
liste permettrait aux gestionnaires de suivre précisément les
achats d'équipements liés à des arrêts
d'appareils.
Dans le "Work Order", existe un champ nommé "MR
N°" qui permet d'entrer un ou plusieurs numéros de MR dans un champ
texte. Ce champ n'est pas contrôlé.
On peut proposer le tableau simple qui suit. Le format en est
assez compact pour éviter les listes extensives, mais il répond
au problème.
WMATL PM and associated MR:
WO#
|
530029241
|
530036103
|
530026084
|
|
|
|
|
MR#
|
53006302
|
|
53005422; 53005162
|
|
|
|
|
WO#
|
|
|
|
|
|
|
|
MR#
|
|
|
|
|
|
|
|
Zone 8 du rapport:
Au final dans le point o), il est demandé de lister une
prévision des maintenances majeures à venir dans le mois suivant.
L'objectif de cette information est de pouvoir préparer les
approvisionnements ainsi que les éventuelles ressources en personnel.
Après discussion avec le personnel du bord, cette période sera
étendue à 6 mois et non à un mois. En effet, les
délais moyens d'achat sont de l'ordre de six mois pour la
majorité des pièces.
Par majeures, on entendra les grosses maintenances de
périodicité supérieure à 1 an ou à 10000
heures. Il se posera un problème si ces maintenances sont en cours et
non exécutés. Dans ce cas, le champ "Next Due Date" n'est pas
renseigné. Il faudra donc donner une estimation des dates à
partir des informations disponibles dans la PM ou les compteurs des
équipements.
Nous proposons le format suivant:
Major PM prevision: Over 2 Years, or
10000h for the next month.
|
PM#
|
Due Date
|
Designation
|
Equipement
|
Designation
|
|
3867
|
31-Jul-2004
|
5 years - obtention MODU safe
|
053
|
DRILLSHIP PRIDE ANGOLA
|
Rapport final:
La proposition de format du premier prototype se trouve sur la
page suivante.
Il a simplement été créé dans un
document MS-Word afin de donner un format initial. Il n'a rien de
fonctionnel.
Format final du prototype papier
n°1:
Maintenance Management Report
Pride
Drill Ship
Period from xxxx to yyyyy
Preventive Maintenance:
MMR v0.1b
|
CE
|
ENG
|
HYD
|
MAR
|
RM
|
STP
|
Total
|
Reference
|
Delta
|
|
INPRG
|
|
|
|
|
|
|
|
|
|
|
WMATL
|
|
|
|
|
|
|
|
|
|
|
WSCH
|
|
|
|
|
|
|
|
|
|
|
WOPCOND
|
|
|
|
|
|
|
|
|
|
|
CLOSE
|
|
|
|
|
|
|
|
|
|
|
CAN
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CLOSE man hrs
|
|
|
|
|
|
|
|
|
|
|
% overdue
|
ISM overdue
|
ISPS overdue
|
%WSCH
|
%WMATL
|
%WOPCOND
|
MR Pending
|
|
|
|
|
|
|
|
Note: Overdue is after 25% of the period of the PM.
Corrective Maintenance:
|
CE
|
ENG
|
HYD
|
MAR
|
RM
|
STP
|
Total
|
Reference
|
Delta
|
|
INPRG
|
|
|
|
|
|
|
|
|
|
|
WMATL
|
|
|
|
|
|
|
|
|
|
|
WSCH
|
|
|
|
|
|
|
|
|
|
|
WOPCOND
|
|
|
|
|
|
|
|
|
|
|
CLOSE
|
|
|
|
|
|
|
|
|
|
|
CAN
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CLOSE man hrs
|
|
|
|
|
|
|
|
|
|
|
%PM/CM close
|
ISM overdue
|
ISPS overdue
|
% WSCH
|
%WMATL
|
%WOPCOND
|
MR Pending
|
|
|
|
|
|
|
|
|
Total (h):
|
|
Top 10 list of the CM man hours
consumption:
|
Hours
|
Equipment#
|
Designation
|
|
Hours
|
Equipment#
|
Designation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Equipment down:
|
P-5 and +
|
P-4
|
P-3
|
P-2
|
P-1 month
|
Period
|
|
|
|
|
|
|
Major PM prevision: Over 2 Years, or
10000h for the next month.
|
PM#
|
Due Date
|
Designation
|
Equipment#
|
Equipment designation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Etapes de construction du prototype
quantitatif.
Les choix de réalisation des
prototypes:
Afin de nous permettre de visualiser et d'extraire les
données se trouvant dans les tables, nous avons choisi d'utiliser la
base de donnée MS-Access comme une sorte d'AGL de départ. En
effet, comme nous l'avons vu dans la présentation des ressources
informatiques, les outils fournis avec Maximo ne présentent pas l'aspect
pratique de MS-Access pour effectuer des requêtes ni pour
représenter les données simplement sans programmation
complexe.
MS-Access peut se lier à des tables ou importer les
données de "SQL base" par l'intermédiaire d'ODBC. Nous
importerons les données, car certaines requêtes MS-Access ne sont
pas acceptées par ODBC.
Le premier prototype se fera dans un premier temps sous
MS-Access avec les outils graphiques de base et des extensions "VB Access". Il
permettra d'obtenir les premières informations utilisables pour donner
du contenu au format proposé pour le "Prototype n°1" dans le
chapitre précédent.
Le prototype MS-Access sera ensuite transcrit après
validation du format dans le langage de programmation SQR utilisé pour
la génération de rapport dans Maximo. Nous aurions pu utiliser
Cristal Report, mais nous n'en disposons pas de licence et les
développeurs du siège social ne l'utilisent pas.
Afin de pouvoir vérifier les chiffres plus facilement
et pour faciliter la mise en page de tableaux sans avoir à tout
construire, nous avons pris pour option d'utiliser les données de
MS-Access, mais de faire le rapport dans Excel en utilisant les commandes de
"VB-Access". Le format tabulaire d'Excel permet une mise en forme tabulaire
plus pratique que MS-Access.
Installation de Maximo sur le poste de
développement:
La machine de développement est un portable Dell
Latitude C510, 40Go disque dur, 1Go ram.
L'installation se fera en locale et nous n'utiliserons pas les
possibilités "Windows Terminal Server" des serveurs pour effectuer les
développements. Cela permettra de rester indépendant des sites ou
l'auteur se trouvera.
Les serveurs ne seront utilisés que lors de la
finalisation du projet juste avant le déploiement de la première
version jugée opérationnelle.
Etapes de l'installation:
- Installation standard de "Maximo SQLserver 4.0.3i". Nous ne
disposons pas de la version "SQL base" sur la base LDA.
- Installation de Centura "SQL base 6.1.2"
séparément.
- Installation des outils de développement "Visual
Scribe".
- Installation des patches 1 & 2 de Maximo.
- Installation d'ODBC pour "SQL base", "Centura SQLbase
32-bits driver NT&95". La tentative de mise à jour vers la version
"Gupta SQLbase 8.01" n'a pas donné de résultats probants avec
MS-Access.
- Chargement des fichiers .DBS des bases de test en provenance
de plusieurs chantiers:
Le nom des répertoires sera au format
C:\Centura\<nom chantier>.
Le nom du fichier de la base de donnée doit avoir le
même nom que celui du répertoire
C:\Centura\<chantier1>\<chantier1>.DBS.
- Déclaration des bases de données dans ODBC:
Le DSN se nommera du nom de la base suivie du suffixe -O.
Par exemple: PANGOLA-O pour le "Database Name" PANGOLA.
Le nom du serveur est "server1".
Les bases devront être définies dans le fichier
MAXIMO.INI. Voir dans les lignes suivantes.
Figure 16 "SQR4"
configuration ODBC.
- Configuration des fichiers .INI des répertoires
C:\max403 et C:\Centura et C:\WINNT. A noter que ces répertoires seront
à un emplacement différent sur les futurs serveurs.
è MAXIMO.INI:
Vérifier les chemins des différents
répertoires qui doivent pointer sur C:.
Les connexions ODBC doivent être déclarées
dans ce fichier sous la forme
SQR4_SQLBASE_ODBC:{Database Name}={Data source name}
Exemple: SQR4_SQLBASE_ODBC:PANGOLA=PANGOLA-O pour la base
PANGOLA.
è SQL.INI:
Il existe un fichier SQL.INI dans les répertoires
C:\MAX403 et C:\CENTURA. Les deux doivent être modifié pour
pointer sur les bases de données déclarées dans le
répertoire C:\CENTURA.
Pour configurer ces fichiers, on utilise le programme
SQLEDIT.EXE se trouvant dans chacun
des répertoires.
Figure 17 "SQLedit" Ecran
principal.
On effectuera deux configurations: Une pour le "Serveur" et
l'autre pour le "Client" sur le même poste.
Etant en local nous utiliserons une connexion par "Anonymous
pipe" dans l'environnement "Windows NT single User".
Les installations des serveurs opérationnels sont aussi
locales mais "Multi Users". En effet, la connexion par "Windows Terminal
Server" n'implique aucune connexion client-serveur distante pour l'utilisation
de Maximo. Certains sites sont encore installés avec une version
client-serveur, mais ils devraient être migré dans le courant de
l'année 2004.
Les figures suivantes décrivent les détails de
chaque écran de configuration:
Figure 18 "SQLedit"
détails de la configuration.
Le contenu du fichier SQL.INI doit ressembler à ce qui
suit:
[dbnt1sv] ! Déclaration pour le serveur
! Déclaration de quatre bases de données.
dbname=PAFRICA,SQLAPIPE
dbname=PANGOLA,SQLAPIPE
dbname=PNA,SQLAPIPE
dbname=PSP,SQLAPIPE
servername=server1,sqlapipe ! Le nom du pipe
centurydefaultmode=0
! Les répertoires d'installation, ils seront sur D:
dans les serveurs
dbdir=C:\Centura
logdir=C:\spl
tempdir=C:\temp
[win32client] ! Déclarations du nom client
clientname=PJUNG
[win32client.dll]
comdll=sqlapipe
è SQR.INI:
Il se trouve dans c:\winnt. Il contient les
spécificités propres à SQR en particulier les
configurations régionales.
Il nous permettra d'obtenir le cas échéant les
chemins de certains éléments de SQR.
Analyse des données et des
écrans:
Une partie de l'analyse des tables de Maximo ainsi que la
correspondance avec les champs des écrans ont déjà
été faits dans le chapitre d'analyse de l'existant. Toutefois,
certaines tables ne sont pas visualisables facilement dans Maximo et le
fonctionnement de certains écrans devra être analysé dans
les détails. L'exploration des tables nous a aussi permis
d'éliminer celles qui n'étaient pas utilisées.
Après examen d'une part des écrans, mais aussi
par exploration des données des différentes tables, on peut
donner la liste des tables qui nous concernent pour la création du
prototype:
- EQUIPMENT: Qui est la table des équipements.
- EQSTATUS: Qui contient l'historique des statuts Up/Down des
équipements (opérationnel ou pas).
- EQHISTORY: Contiens l'historique des compteurs ou
"Meter-Readings" d'un équipement.
- PM: Contiens la liste des PM du chantier.
- WORKORDER: Est la table des "Work Order".
- WOSTATUS: Contiens l'historique du statut des "Work
Order".
- MATUSETRANS: Contiens les transactions des pièces de
rechange. Elle nous servira pour déterminer les coûts des
pièces consommées dans un WO.
- VALUELIST: Contiens un certain nombre de valeurs
prédéfinies. Les valeurs d'une liste sont obtenues en fonction du
champ LISTNAME. Les listes sont configurables dans le menu "Application
setup".
Nous avons rencontré certaines anomalies dans les
tables. En voici la liste:
WOSTATUS:
|
WONUM
|
STATUS
|
CHANGEDATE
|
CHANGEBY
|
MEMO
|
GLACCOUNT
|
|
0000001028
|
HISTEDIT
|
10/12/2000 14:57
|
CE
|
|
|
|
0000001028
|
HISTEDIT
|
20/11/2000 00:35
|
CE
|
|
|
|
0000001028
|
HISTEDIT
|
03/09/2000 14:50
|
SYSADM
|
|
|
|
0000001028
|
HISTEDIT
|
03/09/2000 14:49
|
SYSADM
|
|
|
|
0000001028
|
COMP
|
17/09/1999 14:56
|
SEC
|
|
|
|
0000001028
|
CLOSE
|
17/09/1999 14:56
|
SEC
|
|
|
|
0000001028
|
INPRG
|
17/09/1999 14:47
|
SEC
|
|
|
- Les dates de chaque statut peuvent être identiques
pour des statuts différents. Cela ne permet pas toujours de les remettre
en ordre chronologique. C'est ce que représente l'exemple suivant. Il
nous faudra trouver des artifices pour remettre les historiques dans un ordre
cohérent.
EQSTATUS:
- Si l'on suit la chronologie des équipements Up/Down,
certains équipements sont restés Down dans les historiques, mais
sont marqués Up dans la table EQUIPEMENT. Il nous faudra toujours
comparer l'état actuel de l'équipement avec celui des
historiques.
WORKORDER:
- Les champs obligatoires WOJP1 qui contiennent le
département contiennent d'anciennes valeurs non
référencées dans la liste proposée par les
utilisateurs. On considérera l'équivalence suivante pour les cas
identifiés:
'ELE'=CE, 'MEC'=CM, 'STS'=STP, 'MEC/MOT'=CM, 'JRTP'=STP,
'RIGENG'=STP.
Tous les autres cas seront indiqués dans une colonne
"Other" que nous rajouterons le cas échéant dans la liste des
départements.
- Les statuts WAPPR, APPR et INPRG sont utilisés de
façon peu orthodoxe. Il existe des allers et retours entre les
différentes valeurs qui sont inexplicables par rapport aux
procédures d'usage. Cela tend à démontrer que ces notions
ne sont pas claires pour les utilisateurs.
Le prototype n°2 MS-Access:
Il est nécessaire de donner quelques détails sur
la réalisation du prototype, ses limitations et les problèmes
rencontrés:
- Les paramètres d'entrée sont le mois et
l'année.
- La possibilité de formater les données dans un
tableau MS-Excel nous a permis de vérifier les chiffres et de faciliter
la mise en page qui est un peu plus complexe sous MS-Access.
- L'ensemble des comptages des statuts a été
détaillé pour mieux pourvoir vérifier les comptes lors du
regroupement des états: WSCH, WAPPR, APPP et INPRG sous le nom INPRG.
- Le format ne respecte pas tout à fait celui
proposé pour le prototype initial, mais il permet de montrer des
résultats chiffrés aux utilisateurs. Ce qui était le
premier objectif.
- Les SM ou "Safety Maintenance" ont été
imprimées pour informations, car certaines personnes voulaient les voir
apparaître. Elles devraient être éliminées des
prochains prototypes, car elles ne devraient plus être utilisées
dans les prochaines versions de Maximo.
- Les zones "Downtime", "WMATL MR
list" et "PM previsions" n'ont pas encore été
implémentées.
- Les données de Maximo ont dû être
importées dans MS-Access, car les requêtes trop complexes
n'étaient pas supportées par ODBC sur des tables liées. La
mise à jour d'ODBC vers la version 8.01 n'a pas changé la
situation. Elle a créé d'autres problèmes, car la
chaîne de connexion n'est pas stockée dans la configuration. Nous
sommes donc restés sur l'ancienne version.
Ce prototype sous MS-Access nous aura permis d'explorer les
tables et leur contenu, de préparer les futures requêtes qui
seront utilisées dans le futur produit SQR. Il ne sera plus
utilisé par la suite et nous passerons directement à la
programmation sous SQR afin de préparer l'intégration dans
Maximo.
Prototype n°2 chiffré sous
MS-Access:
|
|
|
|
|
Maintenance Management Report
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DRILLSHIP PRIDE ANGOLA
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Period : May 2003
|
|
|
|
|
Preventive maintenance:
|
|
|
|
|
|
|
|
|
MMR
|
V0.1b
|
|
|
BOP
|
CE
|
CM
|
ENG
|
HYD
|
MAR
|
RM
|
SAF
|
STP
|
Total M
|
M-1
|
Delta
|
|
INPRG
|
0
|
0
|
0
|
0
|
2
|
0
|
2
|
0
|
0
|
4
|
2
|
2
|
|
WMATL
|
0
|
0
|
0
|
3
|
0
|
2
|
0
|
0
|
0
|
5
|
2
|
3
|
|
WSCH
|
0
|
55
|
0
|
24
|
24
|
19
|
33
|
0
|
6
|
161
|
257
|
-96
|
|
WOPCOND
|
0
|
18
|
0
|
1
|
0
|
0
|
3
|
0
|
1
|
23
|
32
|
-9
|
|
CLOSE
|
0
|
166
|
0
|
107
|
36
|
37
|
125
|
0
|
32
|
503
|
570
|
-67
|
|
CAN
|
0
|
0
|
0
|
11
|
0
|
1
|
0
|
0
|
0
|
12
|
4
|
8
|
|
APPR
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
WAPPR
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
COMP
|
0
|
22
|
0
|
19
|
0
|
0
|
1
|
0
|
11
|
53
|
0
|
53
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CLOSE man/hrs
|
0,0
|
616,2
|
0,0
|
158,0
|
66,5
|
42,7
|
142,0
|
0,0
|
33,5
|
1058,9
|
1170,1
|
-111,2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Overdue All
|
29,0
|
|
|
|
%WSCH
|
%WMATL
|
%WOPCOND
|
|
|
|
Overdue ISM
|
0,7
|
|
|
|
21,2
|
|
0,7
|
|
3,0
|
|
|
|
|
Corrective maintenance:
|
|
|
|
|
|
|
|
|
|
|
|
|
BOP
|
CE
|
CM
|
ENG
|
HYD
|
MAR
|
RM
|
SAF
|
STP
|
Total M
|
M-1
|
Delta
|
|
INPRG
|
0
|
0
|
0
|
0
|
5
|
14
|
1
|
0
|
2
|
22
|
26
|
-4
|
|
WMATL
|
0
|
29
|
0
|
1
|
0
|
1
|
0
|
0
|
0
|
31
|
37
|
-6
|
|
WSCH
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
WOPCOND
|
0
|
6
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
6
|
3
|
3
|
|
CLOSE
|
2
|
45
|
0
|
44
|
11
|
5
|
8
|
0
|
26
|
141
|
167
|
-26
|
|
CAN
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
APPR
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
5
|
-5
|
|
WAPPR
|
0
|
4
|
0
|
0
|
0
|
1
|
0
|
0
|
0
|
5
|
1
|
4
|
|
COMP
|
0
|
7
|
0
|
7
|
1
|
3
|
0
|
0
|
11
|
29
|
5
|
24
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CLOSE man/hrs
|
42,0
|
163,5
|
0,0
|
83,0
|
18,0
|
116,0
|
11,0
|
0,0
|
26,0
|
459,5
|
807,8
|
-348,3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% PM/All Close
|
72,8
|
|
|
|
%WSCH
|
%WMATL
|
%WOPCOND
|
|
|
|
|
|
|
|
0,0
|
|
13,2
|
|
2,6
|
|
|
|
|
Safety maintenance:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BOP
|
CE
|
CM
|
ENG
|
HYD
|
MAR
|
RM
|
SAF
|
STP
|
Total M
|
M-1
|
Delta
|
|
INPRG
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
WMATL
|
0
|
0
|
0
|
0
|
0
|
2
|
0
|
0
|
0
|
2
|
2
|
0
|
|
WSCH
|
0
|
5
|
0
|
5
|
0
|
10
|
0
|
0
|
0
|
20
|
36
|
-16
|
|
WOPCOND
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
CLOSE
|
0
|
5
|
0
|
18
|
0
|
24
|
0
|
0
|
0
|
47
|
40
|
7
|
|
CAN
|
0
|
0
|
0
|
0
|
0
|
1
|
0
|
0
|
0
|
1
|
2
|
-1
|
|
APPR
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
WAPPR
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
COMP
|
0
|
0
|
0
|
2
|
0
|
0
|
0
|
0
|
0
|
2
|
1
|
1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CLOSE man/hrs
|
0,0
|
10,0
|
0,0
|
9,8
|
0,0
|
76,5
|
0,0
|
0,0
|
0,0
|
96,3
|
99,5
|
-3,3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
%WSCH
|
%WMATL
|
%WOPCOND
|
|
|
|
|
|
|
|
27,8
|
|
2,8
|
|
0,0
|
|
|
|
|
Top 5 list of man hours
consumption:
|
|
|
|
|
|
|
|
|
|
|
Hrs
|
Equipment#
|
Designation
|
|
|
PM
|
36
|
53319
|
VENT FANS
|
|
|
27
|
53101102
|
DIESEL ENGINE N°2
|
|
|
20
|
53317801
|
AIR FANS / HVAC SERVICES
|
|
|
14
|
53103202
|
MDO PURIFIER SET N°1
|
|
|
13,5
|
53209004
|
MUD PUMP N°1
|
|
|
CM
|
60
|
53808101
|
LIFE BOATS
|
|
|
31
|
53319
|
VENT FANS
|
|
|
30
|
53603008
|
MINI CONNECTOR F/ CAMERON K & C LINES number 3
|
|
|
30
|
53802
|
GENERAL ALARM
|
|
|
24
|
53319501
|
SILO ROOM FANS
|
|
|
15
|
53208230
|
TALK BACK SYSTEM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Equipment down:
|
|
|
|
|
|
|
|
|
|
|
|
|
Since
|
Days
|
Equipment#
|
Designation
|
|
|
12/09/2000
|
883
|
53317501
|
HVAC / MUD LABORATORY
|
|
|
Minutes of meeting "Expression des besoins prototype
N°2"
|
|
|
Situation:
|
|
Base "Pride Foramer" Luanda le 19 Avril 2004.
|
|
|
Participants: 6 personnes.
Durée 1h30.
|
|
- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.
- LDAO: Directeur des opérations client TOTAL.
Initiateur du projet.
- 2*LDAM: Directeur de la maintenance LDA et son assistant.
- 2*LDARM: Rig Manager chantiers Pride Africa et Pride
Angola.
|
|
|
Rappel sur l'objectif de la
réunion:
|
|
- Examen critique du prototype n°2. Nous rappelons que ce
prototype n'est pas intégré à Maximo et qu'il s'agit avant
tout de donner des valeurs chiffrées au tableau papier du prototype
n°1. Il s'agit aussi d'explorer le produit Maximo et ses outils afin d'en
apprendre le fonctionnement.
- Visualisation des données produites et justification
de leur intérêt.
- Revisiter le format initial du rapport et faire
éventuellement de nouvelles positions de modifications.
- Nous rappelons que le prototype est un produit vivant et
qu'il ne pourra vivre que par les remarques et propositions des utilisateurs.
Il ne s'agit pas encore du produit final, mais une construction
intermédiaire.
|
|
|
Propositions et remarques des
participants:
|
|
- Les pourcentages de chaque statut devront être mis en
fin de chaque ligne, après la colonne "Delta".
- Les champs BOP&HYD, CM&RM seront regroupés
sous les dénominations HYD et CM. Les deux colonnes
libérées seront laissées en place.
- Nous mettrons l'entête définitif avec les dates
de début et de fin de la période à la place du mois
uniquement.
- La partie SM "Safety Maintenance" est définitivement
abandonnée, mais les comptages seront inclus dans les maintenances
correctives.
- Dans les TOP5 nous conservons les heures à la place
des % initialement proposés.
- Le comptage des heures de travail semble
singulièrement faible au regard des équipes en présence
sur les navires. On peut justifier cette faiblesse par le fait que les
données entrées ne sont le plus souvent pas des heures-homme
("man-hours"), mais des heures d'équipes. Toutefois,
les valeurs semblent cohérentes entre chantiers. De même, elles
n'incluent pas les travaux de préparation et clôture du chantier
ni les temps d'attente ou d'écriture des rapports.
- Nous confirmons le regroupement des états
intermédiaires: APPR, WAPPR, WSCH, INPRG sous le dénominatif
INPRG qu'il ne faudra pas confondre avec l'état correspondant de
Maximo.
- Le principe des "Overdue" n'est pas clair. Certains pensent
que les maintenances devraient être faites dés leur
génération, d'autres considèrent qu'il faut inclure un
délai. Le CPI propose un délai variable fonction de certains
critères: 50% de la période pour les périodes
inférieures à 2 mois, 25% pour le reste.
Nous nous entendons sur 25% de la période de
maintenance pour les maintenances planifiées par le temps.
- Il est question de CMS (Continuous
Machinery Survey) nécessaire aux certifications
DNV. Toutefois, ce concept n'existe pas encore dans Maximo.
Cette notion ne sera pas traitée tant qu'elle ne sera pas
utilisée et que nous n'aurons pas d'information sur son
implémentation et ce qu'elle recouvre exactement.
- Il est question de "Critical Equipement". Il s'agit
bien d'un champ utilisé dans le module équipement. Il en existe
trois niveaux: 1=Not essential, 2=Can run Without for a short period et
3=Essential. Toutefois, lorsque l'on explore les fichiers, aucun
chantier ne l'utilise. Il ne faut pas le confondre avec le statut ISM qui
concerne une certification liée aux équipements de
sécurité du navire et nécessaire à son certificat
de navigabilité. Cette notion ne sera pas traitée.
- Il faudra ajouter la zone "WMATL MR list". Cette liste
donnera le détail des demandes de matériels associé
à l'état WMATL.
- En ce qui concerne les droits d'accès du rapport et
sa situation dans Maximo. Le rapport sera inclus dans le module "PM" sans
restriction d'accès. Tous les utilisateurs pourront donc le lancer.
|
|
|
Conclusions:
|
|
- Constituer une liste des améliorations concernant la
saisie des rapports dans les "Work Order".
- Application des différentes remarques dans le
"Prototype N°3".
- La prochaine étape est de créer le prototype
SQR du rapport. Il inclura les prévisions de PM, les "Major PM overdue"
et les "WMATL MR list". Cela imposera de posséder l'outil et pourra
représenter un travail important d'auto formation ainsi que de
fabrication d'outils.
|
Construction du prototype n°3 sous
SQR:
Nous utiliserons "VisualSCRIBE 5.0" comme
éditeur des fichiers source SQR. Cet éditeur ne possède
pas de fonctions particulières sauf la colorisation des mots clefs du
langage et des commentaires. Il permet aussi une visualisation directe des
résultats au format .SPF.
Cet outil est d'origine un outil d'assistance à la
génération de rapport. Quelques tests ne nous ont pas
prouvé l'efficacité de cet outil pour la création des
rapports complexes qui nous intéressent. Tout au plus pourrions-nous
l'essayer pour tester quelques requêtes SQL ou profiter de la
génération automatique de programme pour nous aider lorsque la
syntaxe des instructions ne nous sera pas familière. L'ouvrage SQR
cité en référence devrait fournir la majorité des
solutions à nos problèmes.
Le SQR n'est certainement pas un langage de dernière
génération. La structuration du programme est laissée aux
soins de l'utilisateur. Il existe toutefois des notions de procédures
Locales et Globales ainsi que la possibilité d'inclure des modules
externes par la directive #include. Toutefois, ces notions sont
spécifiques à ce langage (par exemple dans une procédure
locale, les variables locales gardent leur valeur entre deux lancements).
Pour les besoins du prototype, la programmation ne sera pas
adaptée à différents environnements, mais seulement au
SQBD "SQL base", dans un contexte uniquement US-English et dans un OS Windows.
Il n'est pas à l'ordre du jour ni de changer d'environnement ni de base
de donnée.
Nous tenterons toutefois de programmer en vue de la
réutilisation des modules même si le prototype n'aboutit pas
à la version définitive du produit.
On respectera les règles simples suivantes pour la
documentation des programmes:
- En entête de module:
File Name, Author, Creation Date, Description, Parameters.
Une liste des révisions comprenant: Date, Programmer,
version, list and details of modifications.
- En tête de chaque procédure:
Description, Input parameters, Output parameters, liste des
révisions pour les plus importantes.
- Commenter les programmes de façon à ce qu'il
soit réutilisable par un autre programmeur.
Les versions suivies d'un indice "b" seront
les versions de travail pendant la phase de prototypage. La version 1.0 sera la
première version opérationnelle, elle apparaîtra dans
l'entête du rapport. Cette version ne sera officialisée
qu'après plusieurs mois de résultats et la vérification
des chiffres obtenus.
L'outil que nous utiliserons pour exécuter nos
programmes source .SQR est SQRWT.EXE qui se
trouve dans le répertoire C:\SQR4.
Il n'existe pas d'outil de "debuggage" proprement dit. Seules
quelques fonctionnalités du langage permettent de tracer
l'exécution:
- Le langage intègre cependant des
fonctionnalités permettant d'imprimer des résultats dans une
fenêtre pendant l'exécution à l'aide des commandes SQR
show ou display. La
commande show est plus puissante que display, car elle permet
d'afficher plusieurs variables ou textes dans la même commande.
Figure 19 Fenêtre
principale de SQRWT
- Il existe aussi des possibilités de compilation
conditionnelle. La compilation de la ligne est déclenchée lorsque
l'option -DEBUG est entré dans la ligne de commande.
Dans ce cas, les lignes du source
précédées de la directive #debug sont
compilées. En fait, l'option -debug peut aussi être
suffixée par un certain nombre de chiffres ou lettres et testée
de la même façon dans le programme.
La syntaxe de la ligne de commande devient alors:
-debug<string> et le test dans le programme
#debug<string> <command line>.
- Certaines variables explicites du programme ou celles des
options -debug peuvent aussi être testées à l'aide des
directives #ifdef, #ifndef, #else et #end-if. Cela permet de créer des
portions de programme à compilation conditionnelle.
- Dans la ligne de commande, on peut aussi préciser les
directives suivantes:
-E[file name] qui permet de
générer un fichier .ERR contenant tous les messages d'erreur de
SQR. Le fichier par défaut est le <nom du program>.ERR.
-CB fait apparaître une fenêtre
d'exécution qui permet de visualiser les messages de SQR, ceux du
programme (display & show) ainsi que de saisir les
entrées du programme.
-S permet d'afficher les commandes SQL, le
nombre de fois ou elles sont exécutées, le nombre de lignes
sélectionnées.
Le programme source .SQR est directement exécutable par
le programme SQRWT. Par contre dans Maximo il est d'usage de
le compiler au format .SQT pour qu'il soit exécuté et que le code
ne soit pas visible par l'utilisateur.
La compilation s'effectue en utilisant
l'option -RS de la ligne de commande.
Le programme "SQR viewer" SQRWV.EXE dans
C:\SQR4 permet de visualiser les fichiers de sortie portable d'extension
.SPF. C'est l'outil d'édition des rapports
utilisé par Maximo.
Il existe aussi par défaut un format .LIS qui est du
texte simple sans grande utilité dans notre cas. Il est
généré en même temps que le format .SPF sauf option
contraire de la ligne de commande.
Figure 20 "SQR viewer" fenêtre
d'exemple.
Prototype n°3 sous SQR:
|
Minutes of meeting "Expression des besoins prototype
N°3"
|
|
|
Situation:
|
|
Base "Pride Foramer" Luanda le 19 Mai 2004.
|
|
|
Participants: 7 personnes.
Durée 1 heure.
|
|
- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.
- LDAO: Directeur des opérations client TOTAL.
Initiateur du projet.
- 2*LDAM: Directeur de la maintenance LDA et son assistant.
- 3*LDARM: Rig Manager chantiers Pride Africa, Pride Angola et
Barracuda.
|
|
|
Rappel sur l'objectif de la
réunion:
|
|
- Valider le format du prototype N°3.
- Faire de nouvelles propositions ou corrections du rapport
existant.
|
|
|
Propositions et remarques des
participants:
|
|
- Le format est assez bien accepté par l'ensemble des
participants.
- Les listes WMATL sont jugées compactes, mais
conformes à la demande. Dans la mesure ou le champ est un texte libre,
il est difficile de donner d'autres informations complémentaires. Dans
tous les cas, le numéro de "Material Request" (MR) permet de trouver
tous les autres éléments d'une commande ("Purchase Order").
- Dans les "major PM prévisions", remplacer "Days" par
le nom du département trié. Les intervalles sont passés
à 1 an et 1000h à la demande des utilisateurs des chantiers. Cela
afin de pouvoir effectuer les achats nécessaires à ces
maintenances en avance. Cela inclut la moyenne des temps d'approvisionnement
normaux.
- Ajouter des graphiques donnant les répartitions des
"PM overdue" dans le temps et en pourcentage.
- Ajouter des graphiques de répartition sur une
année glissante des: Etats des PM et CM, des overdue et du % de PM/all
maintenances.
- CPI précise aux utilisateurs qu'il n'a pu tester les
données que sur quelques mois et qu'il existe peut être des
lacunes dans ces rapports. Cela ne semble pas les frapper... Il indique qu'il
faudra à l'issue du prototype lancer des tests plus complets faits par
les administrateurs Maximo de Houston.
|
|
|
Conclusions:
|
|
- Remplacement des "Days" par le département et trier
par cette valeur.
- Nous avons décidé d'ajouter les graphiques
récapitulatifs suivants:
§ Pourcentages de "PM overdue" dans le temps.
§ Répartition des différents états
des maintenances préventives et correctives sur une année
glissante.
§ Répartition des %PM sur un an glissant.
§ Répartition des % d'overdue ISM ou non sur un
an.
- Préparation de l'intégration du produit
à Maximo.
|
Prototype n°4 sous SQR:
Les principales modifications proposées par les
utilisateurs lors de la dernière réunion d'expression des besoins
consistent en l'addition de graphiques. Les fonctions graphiques de SQR ne sont
pas très évoluées et rentrent dans un cadre rigide auquel
il faudra s'adapter. La documentation SQR en ce domaine est faible et il faudra
tester les fonctions dont on ne connaît que les syntaxes et non la
représentation graphique des résultats après
exécution.
L'usage des tableaux pourrait poser quelques problèmes,
car ceux-ci ne sont pas dynamiques dans SQR. L'usage de tables
intermédiaire ne nous semble pas souhaitable pour effectuer ce type de
travail sur les données. Elles poseraient des problèmes de droits
lors de leur création.
Les graphiques suivants ont été ajoutés.
Pour chacun d'eux, nous donnerons un descriptif ainsi que des informations
concernant leur usage par les services de maintenance.
Les maintenances en retard (Overdue):
Titres: "Time based overdue" et
"Meter based overdue".
Dans Maximo, il est possible de planifier les maintenances
suivant deux façons:
- Dans le temps pour les maintenances dites "Time-based".
P.ex: 1 mois, 6 mois, 1 an etc...
- Par les compteurs des équipements pour les
maintenances dites "Meter-readings". P.ex: 250heures, 1000h etc...
Les graphiques proposés proposent de donner deux
valeurs calculées sur 1 an précédant la date de fin du
rapport:
- Le pourcentage de chaque maintenance d'une
périodicité donnée par rapport à l'ensemble du
même type. Cette partie devrait plus ou moins rester figée avec le
temps sauf addition ou élimination de certaines maintenances.
P.exemple: S'il y a 1000 maintenances préventives et 35
de 360 jours, on aura le chiffre de 35% (partie rouge ou gauche autour de
chaque périodicité).
- Le pourcentage des maintenances en retard pour les
maintenances de cette périodicité s'étant produite dans
l'année précédant la date de fin du rapport.
P.exemple: Si l'on a eu 100 maintenances de 2000 heures dans
l'année et 12 en retard, on aura le chiffre de 12% (partie verte ou
gauche autour de chaque périodicité).
Figure 21 Graphique
"Time-bases" & Meter-based" overdue.
Ce graphique peut donner quelques indications que nous
expliciterons sur quelques exemples:
- Les maintenances 7 jours représentent un faible
pourcentage des maintenances préventives. Toutefois, 10% d'entre elles
sont faites en retard.
- Un pourcentage de 20% des maintenances 250 heures sont
faites en retard.
Note: Le graphique tel qu'il est fait pose un problème
pour les maintenances supérieures à 1 an (la
périodicité du rapport) ou encore pour les équipements
tournant peu. Cela ne renseigne pas correctement sur les maintenances longues,
mais en retard.
Totaux des maintenances CLOSE ou INPRG:
Titre: "PM & CM WO counts"
Ce graphique est un récapitulatif sur un an glissant
des totaux de maintenances préventives (PM) et correctives (CM) pour les
statut CLOSE et INPRG.
Il recouvre l'année précédant la date de
fin du rapport.
On rappelle que INPRG regroupe les états WSCH, APPR,
WAPPR et INPRG.
Ce graphique donne une idée des volumes de maintenances
effectuées. Il est un résumé sur un an des tableaux de
chiffres de la première page du rapport.
Figure 22 Graphique "PM
& CM WO counts".
Totaux des autres status:
Titres: "PM counts other status" &
"PM counts other status".
Ce graphique est un récapitulatif sur un an glissant
des totaux de maintenances préventives (PM) et correctives (CM) pour les
statuts autres que CLOSE et INPRG.
Il recouvre l'année précédant la date de
fin du rapport.
Figure 23 PM & CM other
status counts.
Il s'agit comme le précédent d'un
récapitulatif sur un an des informations du tableau se trouvant dans la
première page du rapport.
Suivant que l'on s'intéresse aux PM ou au CM, il ne
présente pas le même intérêt.
Pour les PM, on observera en premier les états WMATL et
WOPCOND. L'état de WMATL permet de détecter des problèmes
d'approvisionnements ou de prévision des maintenances. Trop nombreux,
les états WOPCOND indiquent que les opérations empêchent
les maintenances de s'effectuer. Cela peut amener à des discussions avec
le client pour laisser des fenêtres de travail plus importantes ou encore
de tolérer des arrêts programmés.
Le statut CAN qui indique une annulation. Lorsqu'il s'agit de
maintenances préventives, il peut signifier deux choses: Soit des
maintenances surnuméraires par exemple, une maintenance d'un sous
équipement faite dans une autre PM. Ou encore des problèmes de
planifications des maintenances.
Pour les CM, un fort taux de WMATL est assez normal même
s'il est tentant d'essayer de le réduire. Un fort taux de WOPCOND
indiquerait que certains équipements ou parties d'équipements ne
peuvent être réparés faute de fenêtres
opérationnelles.
Pourcentages des overdue et des PM:
Titre: "PM percents".
Ce graphique regroupe plusieurs informations. Le taux de
maintenances préventives relativement à toutes les maintenances
effectuées. Le taux global de maintenances exécutées en
retard ainsi que les retards des maintenances spécifiques à la
certification ISM.
Un taux de maintenances préventives au-dessus de 75%
est jugé acceptable dans la littérature de la maintenance, 80%
étant une valeur très correcte. Toutefois, ces taux sont à
relativiser si les maintenances correctives ne sont pas toutes
enregistrées.
Les taux de maintenances en retard doivent être les plus
faibles possible surtout en ce qui concerne les maintenances ISM. Toutefois, il
faut prendre en compte le mode de comptabilisation qui considère une
maintenance "overdue" si la date de sa réalisation a
dépassé 25% de la période. Il faudra juger sur exemple du
bien fondé de cette technique.
Figure 24 Graphique "PM
ratio & overdue".
Critique de ces graphiques:
La plupart de ces graphiques ne sont que des regroupements des
chiffres, mais ils ne donnent pas une vision synthétique de la
situation. Cela est-il d'ailleurs possible ?
On souhaiterait pouvoir trouver des indicateurs nous indiquant
simplement:
- Trop de délais dans les achats.
- Achats mal planifiés.
- Pas assez de fenêtres opérationnelles...
Des valeurs plus directives quant aux points où
concentrer notre action.
Il est clair que ces graphiques ne représentent que des
synthèses de chiffres et ne pourront se substituer à des analyses
plus approfondies au niveau des catégories, équipements ou tout
autre critère de regroupement.
|
Minutes of meeting "Expression des besoins prototype
N°4"
|
|
|
Situation:
|
|
Base "Pride Foramer" Luanda le 20 Août 2004.
|
|
|
Participants: 7 personnes.
Durée 1 heure.
|
|
- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.
- LDAO: Directeur des opérations client TOTAL.
Initiateur du projet.
- 2*LDAM: Directeur de la maintenance LDA et son assistant.
- 3*LDARM: Rig Manager chantiers Pride Africa, Pride Angola et
Barracuda.
|
|
|
Rappel sur l'objectif de la
réunion:
|
|
- Valider le format du prototype N°4 et les nouveaux
graphiques.
- Faire de nouvelles propositions ou corrections du rapport
existant.
|
|
|
Propositions et remarques des
participants:
|
|
- Il est demandé un document permettant de donner des
explications sur le rapport MMR. Les utilisateurs veulent savoir d'où
viennent les données et ce qu'elles expriment.
- Les utilisateurs sont majoritairement satisfaits du rapport
et demandent son implantation sur les chantiers. L'objectif étant de
sortir le rapport sur plusieurs mois afin de juger de l'intérêt
des données qui s'y trouvent.
- Il est demandé de rajouter une liste des maintenances
préventives en retard pour les maintenances majeures. Par maintenances
majeures, on entend: au-dessus de 1 an, 1000h ou ISM.
- Les graphiques correspondent bien aux demandes des
utilisateurs, mais d'aucun se demandent comment les interpréter. Nous ne
pourrons juger que sur des exemples et après analyse d'une situation
réelle.
- Une partie financière ne serait-elle pas
nécessaire pour compléter ces informations ?
Il s'agit d'un sujet délicat pour des raisons plus
politiques que techniques. Maximo n'est pas un logiciel de comptabilité.
Dés que l'on sort des montants, certains se voient dans l'obligation de
les comparer à d'autres et cherchent des interprétations
là ou les calculs sont faits différemment (taux de change,
période, coût de la facture ou moyenne des coûts de
stock...)
- Le CPI informe que les résultats n'ont pas encore
été validés complètement et que cela
représente un gros travaille. Cela ne semble pas inquiéter les
utilisateurs.
|
|
|
Conclusions:
|
|
- Rédaction d'un document descriptif du rapport et
donnant des détails et explications sur la provenance des données
et la signification des graphiques.
- Demande l'implantation du rapport dans le Maximo des cinq
chantiers accessibles par le réseau commun de la compagnie. La version
restera 0.4b jusqu'à nouvel ordre.
- Nous allons chercher dans la littérature s'il existe
des méthodes plus synthétiques pour analyser une situation de
maintenance.
- Nous allons chercher à créer une partie
financière du rapport sans toutefois essayer de la faire coller au
niveau comptable.
- On note un certain essoufflement des utilisateurs en ce qui
concerne les idées de modifications du rapport. Ils veulent obtenir des
résultats chiffrés rapidement et juger sur pièce de
l'intérêt de chaque modèle du rapport.
|
Intégration du rapport n°4 dans
Maximo:
L'ensemble du développement du rapport a
été exécuté sur un ordinateur portable ne
possèdent qu'un disque C:. Toutes les installations des serveurs se
trouvent en D:. Il conviendra donc de changer cette valeur dans les programmes
et de les recompiler avant la mise en production.
Le logo de notre société se trouve en
général dans le répertoire "SQR4" des postes. Toutefois
après observation sur différents serveurs, il peut aussi se
trouver ailleurs. A défaut d'avoir pu obtenir d'informations
complémentaires, nous ajouterons donc quelques lignes de code pour
rechercher ce logo dans différents endroits.
Jusqu'à maintenant, le passage des paramètres
entre l'utilisateur et le programme se produisait soit dans la fenêtre
d'exécution soit dans une fenêtre de saisie
générée par "SQRWT". Dans Maximo, les paramètres
sont transmis d'une façon différente. Seuls quatre
paramètres textes peuvent être transmis aux programmes par une
entrée manuelle de l'utilisateur. Dans ce cas, la fenêtre de
saisie est générée par Maximo et non par le programme
lui-même. En addition, il existe deux autres paramètres transmis
par Maximo sans saisie directe de l'utilisateur, mais issus des
sélections d'éléments dans les écrans Maximo.
|
Format des paramètres passés à SQR
par Maximo
|
|
Variable
|
Contenu
|
|
$where
|
Contiens l'éventuelle sélection du WHERE de la
clause SELECT. La liste est créée à partir des
éléments suivants:
- Les champs peuvent être représentés sous
deux formes:
<fieldname>. P.ex: EQNUM= '0533'.
<table>.<fieldname>. P.ex: EQUIPMENT.EQNUM LIKE
'0536021%'.
La première est utilisée lorsque l'on ne
sélectionne qu'une valeur. La seconde dans les autres cas.
- Sélection dans une suite de valeur limitée:
<table>.<fieldname> IN (<value list comma
separated>).
P.ex: EQUIPMENT.EQNUM in ('053901005', '053607910').
- Sélection de plusieurs champs:
<expression list>=<expression [AND <expression
list> ]
P.ex: @upper(EQUIPMENT.CLASSIFICATION) = 'ACMOTORS' AND
EQUIPMENT.VENDOR = 'GE'.
|
|
Note1:
|
Les valeurs passées dans $where dépendent de la
sélection effectuée lors du lancement du rapport. Dans la
fenêtre de lancement, le champ "Range" permet de sélectionner:
- "No input": Lorsque le champs $where n'est pas
utilisé. Dans ce cas, il contient 1=1.
- "Current record": Sélectionne le champ courant. P.ex:
EQNUM= '0533'.
- "Current selection": Toutes les autres
possibilités.
|
|
Note2:
|
L'utilisation du paramètre $where nécessitera de
construire les requêtes SQL en fonction des paramètres
passés. Il faudra enlever l'ambiguïté lorsque l'alias ne
sera pas passé par Maximo. Les paramètres passés ne
correspondent qu'à ceux de la table principale du module
concerné. Il n'existe pas de possibilité de requêtes sur
plusieurs tables même si l'écran affiche des valeurs d'autres
tables.
|
|
|
|
$p1
|
1er paramètre saisi par l'utilisateur. Vide
si rien de saisi.
|
|
$p2
|
2ième paramètre saisi par l'utilisateur. Vide si
rien de saisi.
|
|
$p3
|
3iéme paramètre saisi par l'utilisateur. Vide si
rien de saisi.
|
|
$p4
|
4iéme paramètre saisi par l'utilisateur. Vide si
rien de saisi.
|
|
$schema
|
Apparemment toujours égal à Maximo.
|
|
|
|
Note3:
|
Tous les paramètres sont au format Texte et sont
simplement récupérés par une fonction "input" du langage
SQR. P.ex INPUT $P1.
|
Table 15 Paramètres
de la ligne de commande Maximo.
Dans notre cas, seul le paramètre $p1 sera
utilisé. Il contiendra une date dont le format reste encore à
définir. Dans l'immédiat, on y entrera le jour suivant de la date
de fin du rapport au format DD/MMM/YYYY.
Par exemple: 01/FEB/2004 pour un rapport couvrant le mois de
janvier et précédents pour les graphiques.
Le rapport MMR sera disponible dans la liste des rapports
liés au module "PM" uniquement. On ne lui appliquera aucune restriction
d'accès et tous les utilisateurs pourront l'exécuter.
Le paramétrage d'un rapport dans Maximo se fait comme
suit:
- Se logger en Administrateur Maximo.
- Aller dans les menus "Setup", "Reports and other Apps".
- Aller dans le menu "View", "Application list" et
sélectionner "SQRW", "SQR report writer".
- Aller dans le menu "Insert", "New row" et remplir les
valeurs des colonnes du tableau comme suit.
- Dans "Filename", entrer "MMR".
- Dans "Maximo application", sélectionner "PM" dans la
liste proposée. On suppose dans ce cas que ce rapport ne sera visible
que du module "Preventive Maintenance".
- Dans "Description", entrer "Monthly Maintenace Report".
- Dans "Command line", enter "SQRWV {SPOOL}MMR.SPF".
- Sauver les modifications, "File", "Save Application".
Figure 25 Module "Reports
and other Apps" de Maximo.
Ensuite, il faut paramétrer les prompts de Maximo pour
cette application:
- Sélectionner la ligne du rapport concerné. En
l'occurrence, "MMR".
- Aller dans le menu "Action", "Specify Users prompts".
- Saisir le texte du prompt:
"Before date (DD/MMM/YYY):"
dans la fenêtre suivante.
- Sauver l'application, "File", "Save Application"..
Figure 26 Prompts des
rapports Maximo.
Dans la mesure où l'auteur ne peut aller sur tous les
chantiers dans une période courte, il lui faudra effectuer les
opérations à partir du chantier ou il se trouve.
L'installation sur les différents chantiers se fera
à distance à l'aide de "Windows Terminal Server". Il nous faudra
dans un premier temps, transférer la version compilée .SQT du
programme sur un répertoire partagé des serveurs et les copier
dans le répertoire D:\SQR4\REPORTS\PRIDE\ qui contient l'ensemble des
rapports spécifiques à notre société.
Cela nécessite de disposer des droits d'accès au
serveur lui-même ou encore à un répertoire partagé
d'un PC du domaine ou se trouve le serveur. Le CPI dispose de tous les droits
Administrateur sur tous les postes des réseaux d'Angola. Par contre, il
n'existe pas de standard concernant les répertoires partagés.
Ensuite, les opérations de configuration de Maximo se
feront comme décrit dans les lignes qui précèdent.
Tests en réel sur les serveurs des
chantiers:
- L'installation du rapport proprement dit et la configuration
de Maximo n'ont posé aucun problème sur aucun des sites. Seule la
lenteur de "Windows Terminal Server" lors des opérations à
distance a imposé des temps de mise à jour non
négligeables avec parfois des coupures de communications
intempestives.
- Le rapport a été implanté sur 5 sites:
PAN, PAF, PNA, PSP, BDA.
- Sur PNA, il a fallu réorganiser la base pour pouvoir
sortir le rapport. Le CPI se trouvait sur le site à ce moment ce qui n'a
pas posé de problème. Cette opération est possible
à distance, mais pose des problèmes en cas de reprise. On
évitera de procéder à distance.
- Sur PSP, le rapport ne fonctionnait pas, car certains
départements n'existaient pas dans le programme. Nous avons
traité le cas avec une colonne supplémentaire comptant les cas
non répertoriés. Cette colonne pourra être utilisée
par les administrateurs de Maximo pour corriger ces valeurs. Dans la mesure ou
nous explorons la totalité des fichiers historiques, il ne nous est pas
possible de ne pas les prendre en considération.
La base de PSP a aussi nécessité une
réorganisation pour fonctionner.
La réorganisation de la base se passe en plusieurs
étapes:
Voir "SQL base, database Administrator's guide" et "SQL base,
SQL language reference".
On évite de faire cette opération à
distance pour des problèmes de récupération s'il se
produit un problème lors du processus. Seuls les opérateurs avec
droits que sont les administrateurs de Maximo peuvent exécuter ces
opérations.
Les opérations à effectuer sont les
suivantes:
- S'assurer qu'aucun utilisateur n'est connecté
à la base de donnée.
- Sortir du moteur de la base de donnée.
- Faire une sauvegarde du fichier .DBS de la base de
données. La base de donnée peut être perdue si une erreur
se produit durant la réorganisation.
- Relancer le moteur de la base.
- Lancer SQLTalk.
- Se connecter à la base de données en tant
qu'Administrateur.
- Lancer les commandes SQL suivantes après s'être
assuré qu'aucun utilisateur n'est connecté à la base de
données:
set recovery off; Principalement pour des
problèmes de performances.
check database; effectue un test
d'intégrité complet de la base donnée (données et
index).
reorganize; Défragmentation de la base de
donnée (Unload to a file, initialize, Reload from Unload file).
set recovery on;
update statistics on database; Remets à jour
les statistiques de la base de données.
exit; Sortie de SQLTalk.
|
Minutes of meeting prototype n°4 par les
utilisateurs des chantiers:
|
|
|
Situation:
|
|
Le prototype n°4 a été installé sur
5 chantiers. Les résultats du mois de juin 2004 ont été
diffusés aux utilisateurs avec un explicatif sur les différentes
informations fournies par le rapport ainsi qu'un mode d'emploi.
Ce document contient le résumé des remarques des
personnels de chantier après installation du prototype sur les chantiers
et après visualisation des résultats du mois de juin 2004. Les
personnes rencontrées ont été variées à tous
les niveaux de la hiérarchie.
|
|
|
Participants: 7 personnes.
Durée1 heure.
|
|
- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.
- TC chantiers: PAN, PAF.
- SM chantier: BDA.
- MSUP Maximo Houston.
|
|
|
Rappel sur l'objectif de la
réunion:
|
|
- L'objectif de ces réunions est d'obtenir les avis des
différentes personnes concernées par le projet à propos du
format du rapport ainsi que l'intérêt de son contenu.
- Le but est de créer un prototype n°5 avec les
nouvelles informations à partir de ces remarques.
|
|
|
Propositions et remarques des
participants:
|
|
- La partie liste des "Material Request" associée aux
"Work Order" dans l'état WMATL est appréciée.
- Les parties "Major PM previsions" et "Equipement down" sont
jugées intéressantes. La période de 6 mois pour la partie
prévision des PM est jugée acceptable, car elle correspond au
temps moyen d'approvisionnement du matériel.
- La partie TOP5 est jugée intéressante, mais
n'indique qu'une situation passée. Elle pourrait être
intéressante sur plusieurs mois si le même équipement
revient dans la liste. Il semble clair que d'autres rapports devront
étayer ces informations.
- Les TC confirment ne pas utiliser les "Downtime" par peur
d'oublier de remettre les équipements Up avant de fermer le "Work
Order".
- Les utilisateurs ont une peur concernant ce rapport:
· Ils pensent que ce rapport servira à la
direction de LDA et de Houston de comparaison entre chantiers afin d'entretenir
une compétition.
· Les différents services s'inquiètent de
voir apparaître les heures cumulées par service. Il leur semble
que ces heures sont faibles par rapport aux équipes et au travail
effectué dans la réalité.
· Les pourcentages d'overdue sont aussi
une source d'inquiétude, car le pourcentage moyen autour de 35%
paraît important. Ils demandent une liste des "Overdue" principaux. On
confirme que les "Major Overdue" sont les PM >1 an et 1000h ayant
dépassé 25% de la période de la maintenance.
- Les TC demandent l'ajout d'une partie financière au
rapport. Pas d'idée précise sur le format. On nous demande de
faire des propositions.
- Tenter d'améliorer la lisibilité du rapport et
corriger certaines erreurs d'affichage.
- Le CPI rappelle que les résultats n'ont toujours pas
été vérifiés complètement et que cette
opération devra être faite un jour ou l'autre avant une
utilisation en réelle des données.
|
|
|
Conclusions:
|
|
- Nous allons ajouter une partie financière au rapport.
Reste à en définir le contenu.
- Nous allons créer une liste des "Major PM
overdue".
|
Prototype n° 5:
Corrections d'erreurs de programmation:
- Problèmes de tailles de certaines colonnes par
rapport aux champs affiché.
- Changement de taille de police et mise en gras de certains
titres.
- Correction du rapport de prévision. Certains
équipements étaient détectés par erreur à
cause d'un problème d'initialisation de variable.
- Les listes de détails suivantes seront
imprimées à partir de la deuxième page: "WMATL WO and
associated MR", "PM previsions" et la liste additionnelle à ce rapport
"Major PM overdue".
Rapport financier:
A défaut d'avoir plus d'informations de la part des
utilisateurs, nous proposons d'ajouter trois types d'informations au rapport
existant. Dans la mesure ou il s'agit d'un rapport de synthèse, nous ne
donnerons pas d'information détaillée pour tous les
équipements.
Ce type de rapport sera à prendre avec
précautions, car les "Work Order" correctifs n'incluent pas seulement
les maintenances, mais aussi des ajustements de stock.
Les calculs seront directement issus des lignes de
consommation des "Work Order" CLOSE et pourront être différents
des chiffres du rapport financier MOCA qui est en cours de mise au point et
pour lequel nous n'avons pas d'information sur les moyens utilisés pour
le créer.
Nous avons délibérément choisi de ne pas
inclure les consommations de stock des "Work Order" ouverts ceux-ci se
retrouvant dans les mois suivants dés leur fermeture.
L'objectif étant d'avoir une idée des
consommations plutôt qu'un rapport comptable, nous pensons que cela ne
posera pas de problème. Ce qui n'empêche pas d'essayer d'avoir un
rapport juste par ailleurs...
Proposition 1:
De même que nous avions donné le détail
des heures consommées par chaque service et pour chaque
département, nous proposons d'ajouter une ligne détaillant la
répartition des coûts par département avec les totaux du
mois courant, du mois précédent et la différence entre les
deux. Les calculs seront faits pour les maintenances préventives et
correctives et uniquement sur les "Work Order" CLOSE dans le mois.
Ils pourront être comparés aux budgets mensuels
attribués à chaque département.
Figure 27 Coûts des
Work Order CLOSE par département.
Proposition 2:
De même que nous avions fait une liste des 5 premiers
équipements consommateurs de temps, nous proposons une liste des 5
premiers équipements consommateurs de budget. Les calculs seront faits
pour les maintenances préventives et correctives pour les "Work Order"
CLOSE dans le mois uniquement.
L'objectif de ce type de liste est d'essayer de repérer
les équipements les plus consommateurs de budget. Ces listes devront
être examinées au cours de mois pour être utiles.
Figure 28 TOP5 PM & CM
stock consumption.
Proposition 3:
Nous proposons aussi un graphique récapitulatif des
coûts engendrés par les maintenances préventives et
correctives sur un an glissant à partir de la date du rapport.
Ces chiffres seront à comparer aux budgets mensuels du
chantier et pourraient servir à préparer les budgets à
venir.
Figure 29 Work Order
costs.
Liste des principales maintenances préventives en
retard:
Les utilisateurs veulent pourvoir obtenir un
récapitulatif des principales maintenances en retard. Par principales,
on entend de période supérieure à 1 an, au-dessus de 1000h
ou encore celles liées aux équipements de catégorie
ISM.
Il faut noter que si le rapport est imprimé
après coup, les "Work Order" seront indiqués majoritairement
CLOSE. En effet, nous avons décidé d'imprimer le statut du "Work
Order" au moment de l'impression. Par contre, la liste provient des historiques
et correspond bien aux "Overdue" de l'époque concernée. Ce
rapport ne sera utilisé que de mois en mois pour le suivi courant, il
n'aura plus d'intérêt après coup.
Figure 30 Major WO PM
overdue.
|
Minutes of meeting
"Expression des besoins prototype n°5":
|
|
|
Situation:
|
|
Base "Pride Foramer" Luanda le 10 Août 2004.
|
|
|
Participants: 3 personnes. Par
courrier électronique.
|
|
- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.
- LDAO: Directeur des opérations client TOTAL.
Initiateur du projet.
- LDAM: Assistant au directeur de la maintenance LDA.
|
|
|
Rappel sur l'objectif de la
réunion:
|
|
- Statuer sur l'état d'avancement du prototype.
- Critique du prototype n°5 et propositions
d'améliorations.
- Statuer sur les résultats obtenus des chantiers
après l'installation du rapport n°5 sur les chantiers.
|
|
|
Propositions et remarques des
participants:
|
|
- Les utilisateurs sont majoritairement satisfaits des
corrections apportées.
- Demande est faite d'ajouter une ligne concernant les
certifications expirant dans les trois mois. L'information est maintenant
disponible dans le module équipement. Nous statuons que ces informations
devront faire l'objet d'un rapport spécifique additionnel, car il ne
s'agit pas de maintenance proprement dite.
- Décision est prise de transmettre le prototype au
siège de Houston afin de l'inclure dans les standards de rapport de la
société. Nous précisons qu'il ne s'agit que d'un prototype
et que les phases suivantes seront:
§ Test complet des résultats du rapport sur
plusieurs mois. Actuellement, les tests non été fait que par
échantillonnage.
§ Amélioration de la documentation du
programme.
§ Documenter les résultats du rapport de
façon plus complète en créant un manuel utilisateur.
§ Adaptation du programme aux différentes
configurations de Maximo dont nous n'avons pas connaissance.
§ Vérifier la finitude du programme et ajouter des
contrôles d'erreurs plus efficaces.
Il restera toutefois à convaincre le siège de
Houston que ce rapport doit être implanté sur nos unités
avec le nouveau standard de rapports qui est en cours d'installation. Notre
implantation actuelle n'a pas eu l'aval officiel d'une façon très
explicite et l'on sent que nous marchons sur des oeufs même si l'accord
initial de développement a été obtenu.
|
|
|
Conclusions:
|
|
- Décision est prise d'installer cette nouvelle version
v0.5b sur l'ensemble des six chantiers d'Angola sans attendre
l'accord explicite du département maintenance de Houston.
- Communication du rapport au département de
maintenance de Houston pour approbation de l'installation sur l'ensemble des
chantiers d'Angola. L'envoi comprendra les sources de prototype ainsi que les
documentations créées pendant le projet.
|
Conclusion de la partie quantitative:
Conclusions:
- Nous avons réalisé un prototype qui correspond
aux requêtes des utilisateurs.
- Il a été implanté sur cinq sites
pilotes pour des tests en réel.
- Malgré le bon accueil des utilisateurs, il est encore
difficile de savoir de quelle façon il sera utilisé ni quelle
sera son influence sur la gestion de la maintenance. Rien n'indique que les
souhaits des utilisateurs correspondent à des informations utiles
mêmes si elles ont été choisies à priori à
bon escient.
- Il reste encore à valider les données obtenues
d'une façon définitive. Dans l'immédiat, seuls des
échantillons nous ont permis de tester les résultats obtenus.
- Nous avons découvert un certain nombre de
disfonctionnement ou d'améliorations à apporter. Ils seront
regroupés dans un chapitre spécial.
Note: Un exemple du format définitif de cette partie
est donné en Annexe B.
Etude de la partie qualitative.
Dans les chapitres précédents, nous avons
extrait et mis en forme des informations de Maximo, mais sans pour autant leur
donner un sens précis. Il s'agit d'informations factuelles dont le sens
ne peut être extrait qu'après analyse des chiffres ou du contenu.
Elles peuvent donner une information sur le passé, mais rien de
précis en ce qui concerne les actions à entreprendre sur les
maintenances. L'objectif n'était pas d'obtenir des informations
détaillées mais une synthèse permettant d'avoir des
tendances.
Ce chapitre tente de répondre au problème qui
consiste à détecter les défaillances
potentielles à partir des historiques de maintenance de
façon à d'éviter les défaillances fonctionnelles
futures.
Il existe de nombreuses méthodes plus ou moins
élaborées pour obtenir des informations qualitatives à
partir des données d'historiques de maintenance. Nous allons examiner
les plus répandues et juger de leur intérêt et de la
fiabilité des données de Maximo nécessaires pour les
obtenir. Certaines parties feront l'objet d'un prototype de rapport. Les
prototypes prendront en compte les remarques faites lors de l'expression des
besoins initiale. Nous resterons dans la phase d'exploration des solutions et
ferons des propositions sur les solutions qu'il faudrait explorer plus
avant.
Cette partie devrait plus intéresser les TC ou MSUP que
les gestionnaires. En effet, ceux-ci sont plus au fait des problèmes de
terrain et plus à même de juger de la valeur des résultats
et de leurs implications en terme de maintenance.
A chaque fois, il conviendra de considérer les risques
que l'on peut prendre en changeant un plan de maintenance à partie de
données statistiques. Plusieurs critères doivent être pris
en compte:
- Le calcul des avantages / risques. En clair, quels sont les
gains en coûts de maintenance par rapport au risque d'avoir mal
interprété les données. Il faut pouvoir évaluer la
qualité des données enregistrées au moins sur un lot
d'équipements sensibles.
- Il faut aussi savoir si contractuellement on peut
outrepasser les préconisations des constructeurs par le simple fait de
statistiques internes.
- Pour les équipements engageant la
sécurité des installations ou des personnes ou encore
l'environnement, ces décisions ne pourront pas être prises au
niveau du chantier, mais seulement après discussion avec des experts du
domaine et les responsables opérationnels. Cela peut aussi impliquer
d'autres interlocuteurs auxquels nous devrons fournir des justificatifs en cas
de défaillances liées à des défauts de
maintenance.
Qualité de la maintenance et
TPM:
Nous avons vu dans la présentation de la TPM que la
métrique utilisée pour juger de la qualité de la
maintenance était nommée TRS (Taux de Rendement
Synthétique).
Cette valeur est le produit de trois résultats
appelés respectivement:
- Taux brut de disponibilité: B/A.
- Taux de performance: C/B.
- Taux de qualité: D/C.
Chaque valeur peut être exprimée comme suit:
- A "Temps d'ouverture": Est la durée de travail
potentiel de la période de calcul. Dans notre cas, nous travaillons
24h/24h tous les jours de l'année.
- B "Temps brut de fonctionnement" = A - Temps d'arrêts
planifiés:
Cela pourrait concerner seulement les maintenances, mais en
TPM cela concerne aussi tous les autres arrêts normaux pendant lesquels
l'outil de production n'est pas actif (programme de production,
réunions, maintenance préventive). Toutefois, en pratique
même si les maintenances préventives sont planifiées
à intervalles réguliers, elles ne sont faites le plus souvent que
pendant des fenêtres opérationnelles n'engageant pas
d'arrêt. Dans le cas où elles occasionnent des arrêts
ceux-ci ne sont pas distinguables des maintenances préventives
normales.
- C "Temps net de fonctionnement" = B - pannes ou moindres
performances:
Les pannes peuvent être caractérisées par
un rapport de "Downtime" dans le module équipement. On pourrait aussi
prendre en compte les temps globaux de pannes calculés à partir
des maintenances correctives pour caractériser la moindre
performance.
- D "Temps utile de fonctionnement" = C - Non
qualité:
Dans la TPM, la non qualité concerne les pièces
mises au rebut ou qu'il faut retoucher. Cela inclut aussi le temps perdu lors
du démarrage de la production et la mise au point des outils. Il
n'existe pas de telles notions dans notre environnement. Il existe bien une
notion de tarif journalier réduit à la suite de litiges
contractuels (équipement non opérationnel ou manquant, vitesse
réduite), mais les chiffres ne peuvent être obtenus de Maximo.
Il faut noter aussi que les heures cumulées des
maintenances correspondent au travail de plusieurs équipes, mais pas
d'un équipement seul.
Exemple de calcul:
Sur le chantier PAN, entre le 01 mars 2004 et le 31 mars 2004
= 744 heures. Nous avons eu 1324h de maintenances préventives, 922
heures de maintenances correctives. Nous considérons que la non
qualité n'existe pas ou n'est pas calculable.
TRS =
(B/A)*(C/B)*(D/C)=(1324/744)*(922/1324)*(922/922)=1.24.
Ce résultat n'a pas un sens précis, car les
calculs de temps des maintenances sont calculés sur l'ensemble du
personnel de maintenance et non sur des calculs de taux liés à
des quantités de fabrication sur une chaîne de production. Il nous
faudrait trouver d'autres informations non disponibles dans Maximo ou une autre
méthode pour calculer ce rendement.
Conclusions:
- Nous ne pensons pas qu'il soit possible d'utiliser le taux de
rendement synthétique (TRS) comme marqueur de qualité de le TPM
en tant que tel dans notre contexte.
- Ce type de marqueur est trop global pour pouvoir donner des
informations utiles sur la qualité de la maintenance et les actions
à entreprendre.
- Le pourcentage de maintenances préventives par
rapport à l'ensemble des maintenances effectuées paraît
être un marqueurs plus significatif si il s'agit de n'avoir qu'un chiffre
de synthèse. Ce marqueur a déjà été
calculé dans le prototype quantitatif.
Nous pourrions remplacer les paramètres temps par des
paramètres économiques, mais nous ne disposons pas de ces
informations dans Maximo (coût horaire des employés, coûts
de l'arrêt ou de moindres performances, coûts du stock...)
Marqueurs de base de la
fiabilité:
Nous avons vu que l'un des objectifs de l'analyse des
historiques de maintenance était d'optimiser les maintenances
préventives. L'une des méthodes pour le faire est l'analyse de la
fiabilité des équipements au cours du temps. Ce type
d'informations pourrait nous aider à préciser les points
suivants:
- Changer la périodicité des maintenances
préventives pour les faire correspondre au taux de panne.
- Détecter les équipements à
problèmes en examinant les taux de pannes.
- Changer les "Job Plan" afin de les faire correspondre aux
problèmes le plus fréquemment détectés.
Il existe un certain nombre de marqueurs de base de la
fiabilité que nous allons examiner dans ce chapitre (Fig.31). Ces
marqueurs sont tous basés sur des moyennes d'évènements et
doivent être utilisés avec circonspection. Bien entendu, ces
marqueurs sont tous basés sur l'analyse des maintenances correctives et
non des maintenances préventives. On peut citer:
- MTTF (Mean Time To Failure): Il s'agit de
la moyenne du temps de vie de l'équipement avant la première
panne. Il nécessite de définir correctement l'état initial
t=0.
- MTTR (Mean Time To Repair): C'est le temps
moyen de réparation d'un équipement. Lorsque l'équipement
possède plusieurs modes de défaillance, on devra définir
un taux pour chacun d'eux.
- MDT (Mean Down Time): Est le temps moyen
entre un défaut et la remise en service de l'équipement.
- MUT (Mean Up Time): Est le temps moyen de
fonctionnement entre la dernière remise en service après
réparation et le prochain défaut.
- MTBF (Mean Time Between Failure): C'est le
temps moyen de fonctionnement entre deux défaillances de
l'équipement. MTBF=MDT+MUT.
- Taux de défaillance : Est l'inverse
du MTBF. =1/MTBF.
- Taux de réparation : Est l'inverse
du MTTR. =1/MTTR.
- Disponibilité: Elle est égale
au rapport MTBF/(MTBF+MTTR).
Figure 31 Marqueurs de base
de la fiabilité.
Chacun de ces marqueurs est utilisé principalement pour
juger de la qualité de la maintenance dans les domaines suivants:
- Fiabilité: L'aptitude d'un équipement
à fonctionner dans des conditions données d'utilisation est
caractérisée par le MTBF et le MTTR.
- Disponibilité: L'aptitude d'un
équipement à fonctionner quand on le sollicite est
caractérisée par le MUT et le MDT.
- Maintenabilité: L'aptitude à être
entretenu et remis en fonctionnement est caractérisée par le MTBF
et MTTR.
- Sûreté: L'aptitude à fonctionner
tout en respectant les individus et l'environnement. Elle n'est pas
caractérisée par un de ces paramètres, mais est souvent
liée à une situation dépendante de l'état des
paramètres précédents.
Il convient aussi de se poser les questions et de
considérer les points suivants:
- Pour chacun de ces paramètres, il serait bon
d'introduire la valeur de l'écart type "" qui nous
indiquera la variabilité des valeurs autour de la moyenne. Les valeurs
pouvant varier de (Moyenne +- 2*). Un écart type faible indiquera une
faible variation autour de la moyenne.
- Il conviendra aussi de déterminer les conditions de
départ des calculs. Ferons-nous les calculs sur la totalité du
cycle de vie de l'équipement, entre les PM ou seulement sur une
année ? Un calcul sur plusieurs périodes permettrait de comparer
plusieurs périodes entre elles et de voir l'évolution.
- Au regard de l'organisation de l'arbre des
équipements, devrons-nous faire le calcul du MTBF et MTTR sur un
équipement seul ou sur l'ensemble des branches à partir de cet
équipement. La réponse est très dépendante de la
partie de l'arbre ou l'on se trouve. Un MTTR ou un MTBF sur l'ensemble du
chantier n'a pas de sens précis. Il n'a un intérêt que si
on l'associe à un sous équipement et surtout si l'on peut
catégoriser les types de défauts.
L'objectif principal de ce type d'information étant la
gestion des maintenances préventives (PM). On peut citer les
règles de base suivantes:
· Trop de maintenances correctives et pas de PM:
Création de PM adaptées aux problèmes
rencontrés.
· Trop de maintenances correctives malgré les PM
existantes: Changement des périodicités ou du contenu des "Job
Plan".
· MTBF inférieur à l'intervalle entre PM:
Changement du contenu des Job Plans ou de la périodicité.
· MTTR trop important: Analyse des rapports de
maintenance pouvant justifier les délais.
Il existe aussi dans la littérature une notion de
"Fault Finding Interval" ou FFI [MOUB]. Le
but de cette valeur est de déterminer l'intervalle entre les
interventions à partir des informations de fiabilité des
équipements et si des possibilités de détection de pannes
potentielle existent. On part du principe que les défauts peuvent
être détectés avant qu'il se produise dans la mesure ou les
informations statistiques sont disponibles. Même si beaucoup de
défauts ne sont pas directement liés au temps de service de
l'équipement, il est souvent possible de détecter des
défauts en analysant un certain nombre d'alertes données par le
matériel lui-même. C'est ce que tente d'exprimer le diagramme
suivant (Fig.32).
Figure 32 Graphique
P-F.
Entre le moment où commencent à se produire le
défaut et le point F ou il s'est produit, se trouve un ou plusieurs
points P permettant de détecter que le défaut va se produire. Il
peut exister plusieurs points P suivant la technique employée pour
détecter la faute. La zone P-F dite zone d'alerte est celle pendant
laquelle des maintenances peuvent se produire avant le défaut complet de
l'équipement. On peut l'exprimer en unités différentes du
temps si la pratique le justifie. Si les maintenances préventives sont
faites à des intervalles supérieurs à cet intervalle, il
est possible de rater la détection. Si elles sont faites à des
intervalles trop courts, il s'agit plutôt d'une mauvaise utilisation des
ressources de la maintenance entraînant des coûts
supplémentaires.
Nous effectuerons les calculs à partir des
éléments suivants:
- Le ou les équipements ont subi des maintenances
préventives à un intervalle donné FFI et les
défauts ont été enregistrés pendant une
période donnée.
Temps total de service = Nombre d'équipement *
période de mesure des défauts.
- Le MTBF a été calculé avec les
informations précédentes.
MTBF = Temps total de service / Nombres total de pannes
pendant la période.
Comme on ne sait pas si la panne se produira en début
ou en fin de période, on choisira le milieu de la période.
- Le taux de panne, %TDP doit être choisi par
l'utilisateur de l'équipement en fonction de critères qui lui
sont propres.
On calcule alors: FFI = 2 * %TDP * MTBF.
Ce type de calcul ne peut se faire en automatique que si l'on
connaît le %TDP désiré pour l'utilisateur. Ce
paramètre ne peut être défini facilement pour les 5000
équipements des chantiers. Il faudra utiliser le MTBF obtenu par le
prototype que nous allons créer ou par des données externes
fiables (constructeurs, bases de données de données de
fiabilité...) et choisir les équipements qui pourraient
être concernés par ce type de calcul. De la qualité des
données dépendra le résultat. Il faudrait aussi
considérer le cas des pannes multiples pour lesquelles ce type de calcul
n'est pas valable sauf si l'on calcule le MTBF des différents
éléments à considérer. Il faut savoir aussi que les
probabilités de pannes d'un équipement sont liées à
tous ses sous-équipements et non pas seulement aux branches de
l'arbre.
Il paraît donc difficile d'automatiser ce type de
calculs. Tout au plus pourrons-nous donner les informations de fiabilité
obtenues à l'aide des MTBF. Il restera à déterminer de
façon précise la fiabilité des données obtenues.
Données de Maximo:
Afin d'effectuer ces calculs, il nous faut disposer des
informations concernant l'état des équipements ainsi que le
détail des opérations concernant les interventions.
Dans Maximo, ces informations peuvent se trouver dans
plusieurs modules:
- Les historiques du statut des équipements pour les
arrêts (downtime). Cela ne concerne que les arrêts complets des
équipements et non les maintenances correctives. Donc, cette information
n'est pas utilisable telle qu'elle se présente.
- Un "Work Order" contient un certain nombre de champs qui
nous permettraient de retrouver ces informations.
· Le champ "Duration": Contient le temps
passé pour effectuer les opérations de maintenance, il est
facultatif et (rempli correctement 8 fois sur 10). Il devrait contenir le
nombre d'heures homme pour effectuer le travail. Toutefois, cette valeur pose
un problème, car rien n'indique le nombre de personnes ayant
effectué le travail. Nous pourrions calculer le MTTR à partir de
cette valeur, mais cette valeur sera à prendre avec précautions,
car elle correspondra à une moyenne d'un total d'heures et non à
une durée entre le démarrage des opérations et la fin des
opérations.
En pratique, à l'examen des données
entrées dans Maximo, on s'aperçoit que cette valeur correspond
plutôt au temps passé entre le début et la fin des
opérations de maintenance. Elle ne tient pas en compte le nombre de
personnes. Elle est évalué au jugé par les personnes
effectuant le travail ce qui le rend difficile à utiliser.
· Les champs "Start Date" et
"Finish Date": Doivent indiquer les dates de début et
de fin de la maintenance, mis à part la chronologie, ils ne sont pas
contrôlés et ne sont pas lié aux dates des statuts du WO.
Ce ne sont pas des champs obligatoires, mais ils sont remplis pratiquement
systématiquement. Cette valeur serait de meilleure qualité que le
champ "Duration" pour calculer le MTTR.
· Le champ "Status" associé aux
dates "Status date" ou "Reported date"
pourraient nous fournir des informations. Toutefois, il n'y a pas forcement de
lien temporel entre ces dates et celles des opérations sur le
terrain.
- Dans les historiques des "Work Order" se trouvent les dates
des différents états pris par un WO de maintenance corrective. Le
statut d'un WO ne préjuge pas des dates ni des durées de la
maintenance sur le terrain. Il n'y a pas forcement de lien temporel entre les
opérations de maintenance et les rapports effectués dans
Maximo.
- Dans notre version actuelle de Maximo, il n'existe pas de
méthode permettant de caractériser le mode de défaillance
de l'équipement. Tout calcul de MTTR se fera donc sur l'ensemble des
modes de défaillances.
- Un certain nombre de "Work Order" sont créés
pour sortir des consommables ou pour ajuster les stocks. Il ne s'agit pas de
travaux de maintenance sur les équipements. Il faudra trouver une
méthode pour les éliminer des moyennes. Il semble que le mot
REGULARIZATION soit toujours présent dans le texte de description de ce
type de WO. Toutefois, ce n'est pas une pratique formalisée et elle
pourrait être différente sur d'autres chantiers que ceux
examinés. Nous n'utiliserons pas cette méthode de filtrage.
En conclusion, seul le MTTR pourrait être calculé
d'une façon relativement précise, mais seulement sur l'ensemble
des modes de défaillances d'un équipement. Ce qui limitera
singulièrement son intérêt pour détecter les parties
des équipements générant le plus de
défaillances.
Il est difficile à partir des données de Maximo
de déterminer les dates exactes des évènements
étant intervenus sur un équipement. Ce qui rend difficile ou
approximatif le calcul des autres valeurs. Seule l'utilisation du champ
FAILDATE permettrait de palier au problème du MTBF.
Il nous faudra faire des essais d'extraction de données
avec les approximations suivantes pour pouvoir obtenir d'autres valeurs:
- Les dates les plus fiables sont les "Start
Date" et "Finish Date".
- Les temps t0, t1 et t2 seront confondus et correspondront
à "Start Date".
- Les temps t3 et t4 seront confondus et correspondront
à "Finish Date".
- Dans ce cas, le MDT=MTTR et MTBF=MDT+MUT=MTTR+MUT.
Le résultat des calculs dépendra grandement de
la fiabilité des données entrées dans Maximo. Les
écarts types calculés pour les MTBF et MTTR nous permettront de
juger de la variabilité des valeurs autour des moyennes, mais pas de la
qualité des données. Les maintenances correctives sont par nature
aléatoires. Une forte variabilité peut aussi signifier: Des
pannes aléatoires ou des durées de réparation
aléatoires.
Proposition de prototype de calcul des marqueurs de base de
la maintenance:
Nous choisirons dans un premier temps de ne mettre que les
valeurs suivantes pour chaque équipement et pour chaque "Work Order"
CLOSE sur une période:
- Le nom du rapport sera EQPTSTAT1. L'indice laisse supposer
que nous pourrons créer d'autres rapports de mêmes types, mais
avec des affichages un peu différents. Ceci, pour la simple raison que
les paramètres de Maximo sont imités à 4.
- Les paramètres d'entrée seront les dates de
début et de fin de la période du rapport.
- L'entête sera celui utilisé en standard pour
les rapports Maximo.
- Numéro de l'équipement. Le numéro
d'équipement sera décalé d'un nombre d'espaces égal
à sa profondeur dans l'arbre. On pourra au besoin choisir une autre
représentation du type "----->" pour signifier le niveau.
- Classement par équipement et sous équipements.
Ce qui impliquera de reconstituer une partie de l'arbre des équipements
à partir des données EQNUM et PARENT de la table EQUIPMENT.
Désignation de l'équipement limitée aux 50 premiers
caractères.
- Le nombre de maintenances correctives CLOSE pendant la
période concernée.
- Le nombre de maintenances préventives
associées à cet équipement.
- Si l'équipement est lié à la
certification ISM. Cela permettra de vérifier d'une part que ces
équipements possèdent des maintenances préventives et que
leur taux de panne est faible.
- MTTR et variance des moyennes
trouvées. La variance est nommée SD pour "Standard
Déviation".
- MTBF et variance à partir du
premier "Work Order" CLOSE de la période. On lui donnera le nom de
MTBW (Mean Time Between Work order) afin de limiter
l'ambiguïté avec la valeur vraie qui n'utilise pas exactement les
mêmes dates.
- Seuls les équipements ayant eu au moins une
maintenance corrective seront affichés.
- Nous avons choisi pour ce premier prototype de calculer le
MTBF à chaque niveau de l'arbre et non de descendre dans chaque branche.
Il reste que cette autre logique devra être explorée aussi dans
une autre version. Dans ce cas, il doit être clair que certaines valeurs
n'auront pas de sens au fur et à mesure que nous remonterons dans
l'arbre. Un MTBF sur un groupement d'équipement de différents
types n'a pas de sens.
Analyses des données du prototype:
Après examen des données d'un des chantiers les
plus significatifs sous MS-Access, il s'avère que sur 5000
équipements, prés de 2000 sont concernés par les
maintenances correctives sur toute la durée de vie du chantier.
D'où un problème important de représentation des
résultats. Il faut donc limiter les affichages aux valeurs les plus
significatives et déterminer s'il est nécessaire de cumuler les
résultats à tous les niveaux de l'arbre.
Nous avons donc créé un prototype sous SQR qui
permet de sortir le format suivant: (Fig.33)
Figure 33 Exemple de
tableau de fiabilité.
L'affichage de tous les équipements donne plus de 80
pages de rapport. Une taille rédhibitoire pour un utilisateur standard.
Si on se limite aux équipements ayant eu des WO pendant la
période entrée en paramètres, on devrait obtenir une
quinzaine de pages sur une période d'un an.
On remarque les points suivants:
- La position d'une maintenance dans l'arbre des
équipements n'est pas claire. Certains utilisateurs mettent les WO
à la racine et d'autres dans les détails. Nous avons
trouvé certaines maintenances correctives à des niveaux de
l'arbre où elles n'auraient pas dû être.
- On peut noter une forte variance du MTBF sur certains
équipements. Cela peut vouloir dire soit des pannes aléatoires
soit des données fantaisistes. Nous avons trouvé beaucoup de
valeur du champ DURATION à 0 et parfois plusieurs maintenances
correctives identiques à quelques minutes d'intervalles. Il ne s'agit
pas de généralités, mais de points à surveiller.
- A l'inverse, une faible variance pourrait indiquer des
pannes récurrentes à intervalles réguliers. Dans ce cas,
il faudrait déterminer s'il existe un lien entre les pannes
rencontrées afin de pouvoir éliminer le problème s'il en
est. On pourra aussi vérifier la périodicité des PM ainsi
que le contenu des JP pour les adapter au problème.
- Le programme ne traite que les données brutes et non
des données censurées. Cela veut dire que les "Work Order" qui ne
sont pas des maintenances sont aussi traités comme des
défaillances.
- Ce rapport permet d'identifier les équipements
suivants:
· Ceux qui ont des maintenances correctives et pas de
maintenance préventive. Pour ceux la, il faudra vérifier que des
PM n'existent pas à des niveaux supérieurs de l'arbre et qu'elles
traitent les cas trouvés dans les CM.
· Ceux dont le MTBF est inférieur au temps entre
maintenances préventives. Certains éléments pourraient ne
pas être traités dans les PM et devraient être
ajoutés au JP.
· Les équipements ISM à fort taux de
maintenances correctives ou sans maintenances préventives.
Présentation des résultats aux
utilisateurs:
Nous avons présenté le prototype à
certains utilisateurs (TC, MSUP). Ils jugent ce type des données
difficiles à interpréter. Ils ne voient pas toujours
l'intérêt de ces informations qu'ils trouvent trop
théoriques.
Conclusions:
- L'analyse des défaut à partir du MTBF et MTTR
doit être faite avec beaucoup de prudence surtout si les
échantillons ont une faible population.
- Il ne traite pas le cas des appareils travaillant par
intermittence.
- Les MTBF et MTTR doivent être calculé par
catégorie de panne et non sur la globalité d'un
équipement. Cela n'est pas possible dans notre version.
- Les résultats ne doivent être utilisés
que sur des équipements sensibles et bien identifiés pour
lesquels les données sont entrées avec soin. On pourra
procéder par expérimentation sur quelques équipements pour
valider la technique. Toutefois le programme ne traite que les données
brutes.
- On n'utilisera pas ce type de technique sur des
équipement à risque surtout si il s'agit d'aller à la
baisse en ce qui concerne la périodicité des maintenances. Dans
ce cas, seules les recommandations du constructeur peuvent faire foi en cas de
problème et lorsqu'il faudra justifier une défaillance au client
ou aux assurances. Par contre rien n'interdit de rajouter des points
additionnels ou d'éliminer les maintenances à risques dans les
"Job Plan" ou de réduire les fréquences.
- Il faudrait éliminer des calculs tous les "Work
Order" ne correspondant pas à de la maintenance proprement dite (sortie
de consommables, ajustement de stock...). Cela rends difficile l'automatisation
de la méthode car rien ne permet de les identifier.
Méthodes
graphiques de base:
Diagrammes de Pareto:
Le diagramme de Pareto permet d'avoir une
vision rapide de la contribution d'une catégorie
d'éléments par rapport à d'autres. En maintenance, on
pourrait par exemple l'utiliser pour visualiser l'importance relative des
éléments suivants:
- Nombre de défaillances par équipement.
- Nombre de types de défaillances par
équipement.
- Quantités cumulées d'indisponibilité
par équipement.
- Quantités cumulées d'indisponibilité
par type de défaillance.
Le "diagramme de distribution" contient les cumuls de
chaque élément de la catégorie classés par ordre
croissant.
Le "diagramme de répartition" ou cumulatif
s'obtient de la même façon, mais en traçant la courbe de la
somme des critères que l'on a choisi.
Ils s'obtiennent en appliquant la méthode suivante:
- Faire la somme des contributions de chaque
élément de la liste (nombre de pannes, cumul des temps, cumul des
coûts...)
- Classer les contributions par ordre croissant et leur donner
un rang dans la liste.
- Calculer pour chaque élément le pourcentage de
chaque ligne et le pourcentage cumulé.
Un exemple suivant permettra d'expliciter ce qui
précède à partir du tableau suivant:
Ce tableau donne une répartition des défauts par
type d'équipement. On a aussi calculé les pourcentages de chaque
ainsi que les pourcentages cumulés. Le tableau est classé par
ordre croissant du nombre de défauts.
|
Equipement
|
Classe
|
Défauts
|
%
|
% Cumulé
|
|
Pompes
|
1
|
40
|
57,1428571
|
57,1428571
|
|
Moteurs continus
|
2
|
15
|
21,4285714
|
78,5714286
|
|
Moteur Alternatifs
|
3
|
10
|
14,2857143
|
92,8571429
|
|
Compresseurs
|
4
|
5
|
7,14285714
|
100
|
On obtient le graphique suivant: (Fig.34)
Figure 34 Diagramme de
distribution et de répartition.
Le graphique en barres est le diagramme de distribution, celui
en courbe est celui de répartition. On a choisi de le tracer en % pour
des raisons pratiques de représentation.
Ce type de courbe de défaillance ne donne toutefois
qu'une information à la fois et ne tient pas compte d'autres
critères. Elle devrait être utilisée en parallèle
avec d'autres représentations détaillant par exemple: Les heures
d'indisponibilité cumulées, les coûts cumulés ou
tout autre paramètre présentant un intérêt pour ce
type d'équipement tel que la répartition par type de pannes ou
causes de pannes.
Méthode ABC:
La méthode ABC revient à construire le diagramme
de répartition de Pareto et de le séparer en trois zones A, B et
C. Les éléments de la zone A sont considérés comme
les plus importants, ceux de la zone B d'une moindre façon et ceux de la
zone C sont ceux qui peuvent faire l'objet d'une simple maintenance corrective
vu leur importance. On le nomme souvent 20-80 car il permet de
représenter les 20% des éléments qui représentent
80% du critère d'intérêt (P.ex: 20% des pièces
représentent 80% du coût).
Figure 35 Diagramme de
défaillance.
Sur le graphique précédent (Fig.35), la zone A
se trouve entre 0 et 73%, le zone B entre 73% et 97%. Ces zones peuvent
être définies autrement afin d'inclure plus ou moins de la
proportion du paramètre concerné dans chaque zone. On peut aussi
définir une quatrième zone au besoin.
Dans le graphique qui suit (Fig.36), on construit les
graphiques sur les catégories d'équipements puis sur les sous
catégories pour atteindre les "Failure codes".
Il est possible d'utiliser cette méthode pour effectuer
une analyse descendante en partant des catégories, en descendant aux
sous catégories pour atteindre le niveau des défauts d'un
équipement.
Figure 36 Analyse Pareto
descendante.
Utilisation à partir des données de
Maximo:
Dans notre version de Maximo, nous n'utilisons pas beaucoup de
catégories. Les seules qui soient utilisables sont les suivantes:
- Les "Départements" du module "Work Order". La courbe
de Pareto peut être obtenue en reprenant les chiffres du rapport MMR. Il
serait aisé de reprendre les chiffres par département pour en
sortir une courbe.
- Les "Classifications" et "Sub-classifications" du module
EQUIPMENT. Sur un chantier significatif, seuls 30% des équipements (sur
~4800) sont classés par catégories (Table 15). Il faudra donc se
méfier des informations non classées et voir si elles ne
représentent pas la majorité des totaux.
|
Table: VALUELIST champ
LISTNAME='EQCLASS' sur 4800 équipements
|
|
VALUE
|
VALDESC
|
Qté
|
|
VALUE
|
VALDESC
|
Qté
|
|
ACMOTORS
|
AC Motors
|
1148
|
|
ALTERNAT
|
Alternator
|
18
|
|
PUMPS
|
Pumps
|
532
|
|
DRILLEQT
|
Drilling Equipment
|
18
|
|
VALVES
|
Valves
|
430
|
|
Alternat
|
Alternators
|
9
|
|
TANK
|
Tank
|
306
|
|
MARMISC
|
Marine Miscellaneous
|
3
|
|
AIRRCVR
|
Air Receiver
|
276
|
|
ELEMISC
|
Electrical Miscellaneous
|
1
|
|
Valves
|
Valves, Fittings, Piping
|
215
|
|
HOISTEQT
|
Hoisting Equipment
|
1
|
|
Tank
|
Tanks,,Bulk System,Ballasts
|
153
|
|
MECMISC
|
Mechanic Miscellaneous
|
1
|
|
COMPRESS
|
Compressors
|
66
|
|
SAFETY
|
Safety
|
1
|
|
WINCHES
|
Winches
|
64
|
|
Safety
|
Safety
|
1
|
|
MOTORS
|
Motors
|
60
|
|
SUBSEAEQT
|
Sub Sea Equipment
|
1
|
|
Compress
|
Compressor: GD,Atlas...
|
33
|
|
HVAC
|
Heating/Ventilation/Air Cond
|
1
|
|
|
|
|
|
|
|
Table 16 VALUELIST
classification.
- Par EQUIPEMENT ou sous branches de l'arbre. Toutefois, cela
risque de poser un problème de représentation sauf si l'on
tolère de larges listes.
- La notion de "Failure class" et "Problem code" n'existe pas
encore même si les champs sont représentés dans les WO.
- Les "Sub-Work type" du module WO (champ WOJP4) nous offrent
une classification des WO par type de travaux. Ces types ne représentent
pas d'intérêt certain et nous n'en tiendrons pas compte. Sur
l'exemple suivant, nous obtenons le décompte dans le tableau suivant
(Table 16). Cela montre le peu d'intérêt de l'utilisation de cette
catégorie.
|
Sub-Work types utilisés dans la table:
WORKORDER, 37000 enregistrements.
|
|
Qté
|
WOJP4
|
Désignation
|
|
Qté
|
WOJP4
|
Désignation
|
|
0
|
|
|
|
104
|
NDT
|
Non destructive test
|
|
1
|
CAL
|
Calibration
|
|
107
|
INS
|
Insulation
|
|
7
|
CMS
|
Continuous Machinery Survey
|
|
128
|
OTHER
|
|
|
7
|
ANA
|
Analysis
|
|
220
|
MPI
|
Magnetic Particle Test
|
|
36
|
BOTH
|
????
|
|
768
|
DRN
|
Drainage
|
Table 17 Comptage des
Sub-work type.
Construction du prototype:
Les paramètres d'entrée du prototype seront les
dates de début et de fin du rapport.
Nous ne chercherons pas à effectuer une
représentation graphique des résultats dans SQR à cause
des limitations graphiques de l'outil. Nous représenterons les
données sous forme d'une table que nous pourrons reprendre sous MS-Excel
pour tracer les courbes de résultats. Les données seront
extraites d'une base de donnée MS-Access dans laquelle nous avons
importé les tables de Maximo lors de la construction du deuxième
prototype du rapport MMR.
Le prototype effectuera les calculs suivants pour les "Work
Order" CLOSE uniquement:
- Coûts cumulés des CM par classification sur la
période.
- Heures de maintenances cumulées CM par classification
sur la période.
- Quantités de CM associées à chaque
classification sur la période.
Exemples de résultats obtenus par
l'intermédiaire du prototype:
Les trois exemples de la figure ci-après (Fig.37) nous
indiquent que la loi de Pareto est respectée pour nos
échantillons. On s'aperçoit qu'une minorité
d'équipement consomme la majorité des ressources en temps et en
coût et qu'il y a adéquation entre les courbes de coût et de
temps passé. Ce type de courbe pourrait être utilisé pour
analyser les stocks associés à ces équipements de
façon à en prévoir les achats et éventuellement en
négocier les prix sur des quantités. On pourra aussi sortir un
autre rapport permettant de déterminer quelles sont les pièces
les plus coûteuses par département et revenir sur les WO pour en
examiner les raisons qui font que l'on consomme ces éléments.
Dans ce cas, nous ne pourrons pas utiliser de représentation graphique
vu la quantité de pièces concernées.
Dans notre cas, on s'aperçoit que quatre
équipements mobilisent plus de 80 des ressources: Les PUMPS, ACMOTOR,
VALVES et TANK dans tous les domaines de recherche. Il s'agit d'une piste pour
commencer une investigation, mais rien ne nous donne d'indication sur les
causes. Seule une répartition des modes de pannes et types de pannes
pour chaque classification nous permettrait de pourvoir approfondir
l'analyse.
La répartition aurait pu être différente:
Peu de ressources humaines, mais forts coûts liés dans ce cas aux
prix de pièces détachées ou encore l'inverse.
Ce qui veut dire qu'un graphique seul ne peut résumer
l'ensemble des informations. Plusieurs doivent être examinés de
concert puis associés à une recherche en détail dans les
"Work Order" pour pouvoir déterminer la source des problèmes ou
des coûts.
Commentaire des utilisateurs:
Nous avons présenté ces graphiques aux personnes
les plus concernées par ce type d'informations. En particulier, les TC
et les MSUP. Ils nous ont fait part des limites du système dans la
mesure ou les équipements ne sont pas tous classés dans des
catégories. Dans l'immédiat, ils ne voient pas
l'intérêt d'une telle représentation tant que la
classification n'est pas généralisée et qu'il n'existe pas
de notion de "Failure Code".
Conclusions des essais Pareto:
Conclusions:
- Ce type d'analyse représente bien d'une façon
synthétique les éléments les plus significatifs d'un lot
suivant les critères de regroupement choisis.
- Toutefois, dans la mesure ou il n'existe pas dans la version
actuelle de Maximo de classification fine des équipement pour une
analyse descendante dans les détails, nous arrivons aux limites du
système.
- Seule une comparaison de plusieurs graphiques suivant
différents critères permettrait de faire une analyse descendante
complète des données pour aboutir aux défauts de chaque
équipement sélectionné.
- Les rapports sous SQR sont trop rigide pour ce type
d'application. Il faudrait trouver un outil permettant de faire ce type de
rapport à la demande suivant les critères définis par
l'utilisateurs.
- Le produit "Powerplay" de la
société Cognos est une piste à explorer pour
générer ce type de rapport. Il sera examiné succinctement
plus loin.
Figure 37 Diagrammes de
Pareto, chantier "Pride Angola" toutes périodes.
Analyse de données statistiques
associées aux défaillances.
En supposant que les données de Maximo sont saisies
avec une suffisante fiabilité et que la qualité des informations
est satisfaisante, il devrait être possible de les utiliser pour calculer
un certain nombre d'informations utilisables pour déterminer:
- Des arbres de défaillance.
- Les intervalles des maintenances préventives.
- Des indicateurs de la fiabilité des
équipements.
- De fournir des indicateurs de la qualité de la
maintenance.
Il existe des méthodes statistiques permettant de
donner des informations sur la fiabilité du matériel. Ces
méthodes sont à utiliser avec beaucoup de précautions
surtout si elles sont utilisées par des personnes peu familières
avec les statistiques et les probabilités (une denrée rare).
Elles peuvent donner des résultats entachés d'erreurs importantes
si les échantillons ont une population faible.
L'utilisation de ces lois suppose les points suivants:
- D'avoir des échantillons de qualité suffisante
et censurés ou non suivant la méthode.
- De sélectionner la loi de probabilité parmi la
liste des cinq.
- Faire des calculs sur des échantillons, valider la
loi utilisée et définir des intervalles de confiance.
Les six loi de probabilité de
défaillances:
Il existe six formes de lois de probabilité de modes de
défaillance. Les six diagrammes qui suivent décrivent la
probabilité de défaut en fonction du temps en abscisse. Suivant
le type d'équipement auquel on a affaire, il entre dans l'une ou l'autre
de ces formes. En aviation, les pourcentages sont de A=4%, B=2%, C=5%, D=7%,
E=14% et F=68%. Toutefois, cela ne préjuge pas des pourcentages de nos
équipements. Les formes A, B et C sont liées directement à
l'âge de l'équipement alors que D, E et F ne le sont pas. Les
trois dernières formes sont celles pour lesquelles la maintenance
conditionnelle (MBF) est applicable et où la maintenance
préventive est difficile à appliquer.
Figure 38 Formes de loi de
probabilité en maintenance.
- Forme A (dite en baignoire): La zone IM (Infant
Mortality) indique les défaillances précoces. La zone WO (Wear
Out) indique une usure. La zone intermédiaire indique un taux de pannes
aléatoire. La période de vie de l'équipement se situe
entre ces deux zones. Ce type de courbe tendrait à indiquer des pannes
multiples à identifier.
- Forme B: Indique de l'usure. Dans ce cas, le MTBF
n'est pas directement applicable car le temps de vie de l'équipement se
trouve avant le MTBF. Le remplacement de l'équipement à l'issue
du temps de vie impliquerait des coûts de maintenance
élevés.
- Forme C: Avec un accroissement de la
probabilité de défaut avec le temps, cela peut indiquer une
fatigue, des problèmes d'isolation.
- Forme D: Est difficile à interpréter,
mais peut dans certains cas correspondre à de la fatigue.
- Forme E: Indique un équipement dont le taux de
pannes est aléatoire. C'est le cas ou le MTBF n'est pas très
utile sauf par comparaison entre deux équipements différents.
- Forme F: Indique un fort taux de défauts
précoces. Il s'agit dans ce cas plutôt de problèmes de
conception, d'installation, de méconnaissance de l'équipement...
Ce n'est pas un cas que peut traiter la maintenance préventive.
Il n'y a pas toujours consensus entre les auteurs quand
à l'interprétation de ces courbes. Il s'agit aussi pour certaines
d'elles de recherches de laboratoire et non d'essais en réel.
Les résultats expérimentaux montrent que ces
modes de défaillances des équipements peuvent être
décrites par cinq lois fondamentales de probabilité:
Exponentielles, normales, log-normales, Weibull et dite en
"Baignoire".
On choisit la loi la mieux adaptée en fonction du type
d'équipement et de ses courbes de défaillances.
L'exemple Weibull:
Nous allons tenter de donner une description succincte de
l'utilisation de la loi Weibull sans toutefois entrer dans les détails
précis de son interprétation.
La loi Weibull est une méthode graphique ou analytique
utilisée pour caractériser les modes de défaillances
d'éléments à partir de peu d'information. Elle permet de
représenter la majorité des formes de lois de probabilité
des modes de défaillance sauf la courbe en baignoire.
La distribution est décrite par une formule à
trois paramètres:  . Le plus souvent on considère que =0 (qui indique le temps entre
la mise en service et la première panne).
On cherche donc à déterminer ces
paramètres à partir des données de maintenance.
Dans le cas d'une méthode graphique sur du papier au
quadrillage Weibull. Si =0, on obtient la méthode suivante:
1) On ordonne les données par temps croissant de panne
à partir du point ou commence l'enregistrement des données.
2) A partir des données, on calcule les médianes
de chaque ligne:
3) On trace le graphique sur le papier Weibull.
4) On détermine le paramètre = X/Y soit la
pente de la droite sur le graphique. Il indique la tendance du mode de
défaillance. Lorsqu'il ne s'agit pas de droites, le mieux est d'utiliser
des méthodes analytiques (P.ex: Logiciel Weibull++).
5) On détermine le paramètre qui se trouve
à l'intersection de la droite avec Y=63,2%. Il indique le temps de vie
caractéristique ou moyen de survie (50% de survie).
Lorsque le paramètre est différent de 0, le cas
est plus complexe et ne peut être entièrement résolu
graphiquement.
A partir du paramètre , on peut déterminer
quelques caractéristiques du mode de panne de l'équipement:
- <1: Indique une mortalité précoce. Soit
encore probablement des problèmes de qualité, de montage,
d'installation...
- =1: Indique un taux de panne aléatoire
indépendant du temps (distribution exponentielle).
- =3: Usure prématurée.
- =6: Usure normale.
Il est aussi possible d'obtenir directement les valeurs
suivantes à partir du calcul des paramètres:
MTBF, écart type, taux de panne, moyennes,
médiane, .
Exemple extrait de Maximo:
Nous avons créé un programme sous SQR permettant
de récupérer les temps cumulés depuis le premier CWO de la
période concernée. Le tracé sur du papier Weibull n'a
jamais donné de droite. Ce qui nous a incités à utiliser
une méthode analytique plutôt qu'une méthode graphique.
Nous avons donc essayé ces données sur deux logiciels du
marché les plus répandus.
A partir des données issues du prototype, nous avons
entré les chiffres dans deux programmes différents: "Quart" et
"Weibull++". Ces programmes sont tous deux des versions de démonstration
avec des fonctionnalités limitées, nous nous contenterons de ces
résultats pour juger de l'intérêt de la méthode.
Le programme d'extraction n'est pas destiné à
une réutilisation future. Il s'agit d'une simple sortie au format CSV
(Coma Separated Values).
Pour des problèmes de place, les résultats de
nos essais sont regroupés dans l'Annexe C.
- Graphique A: Equipement 053106102, FRESH WATER
GENERATOR N°1 (PS).
Les coefficients =2,6 ; =5500 tendrait à indiquer des
usures prématurées de certains éléments de
l'équipement (forme A précoce). Ce qui est confirmé par
les opérateurs de maintenance.
- Graphique B: Equipement 053209204 MUD PUMP
N°2.
Les coefficients =1,5 ; =4379 tendrait à indiquer un
taux de pannes aléatoires difficile à traiter par la maintenance
préventive.
- Graphique C: Equipement 053211601 HIGH GRAVITY DRYER
SET.
Les coefficients =0,7 ; =3627 tendrait à indiquer une
forte mortalité précoce suivie d'un taux de panne
aléatoire (forme D). Les maintenances correctives en début de vie
de l'équipement ont corrigé les problèmes infantiles.
- Graphique D: Equipement 053401106 MIXER BEAR 30.
Les coefficients =1 ; =3134 tendrait à indiquer un taux
de pannes aléatoires indépendantes du temps (forme F). Les
maintenances préventives ne sont pas applicables.
Ces résultats présentés aux MSUP semblent
conforter les impressions qu'ils ont de ces équipements. La
confrontation avec les données de maintenance de Maximo donne les
mêmes résultats. Il reste que l'interprétation de telles
données nécessite une meilleure connaissance de ce type d'outils
et des statistiques pour pouvoir être utilisée avec
sécurité.
Les MSUP ne sont pas convaincus que de telles méthodes
sont utilisables dans notre contexte.
Conclusions de l'analyse des données
statistiques:
Conclusions:
- Ce type d'outil ne peut être utilisé que par
des utilisateurs avertis et féru de statistiques ou de fiabilité
des équipements.
- Il paraît illusoire de vouloir recréer nous
même ce type d'analyse avec les outils de Maximo.
- Il est préférable d'extraire les informations
de Maximo afin de les importer dans un logiciel spécialisé tel
que Weibull++.
- Il n'est pour l'instant pas possible de fournir des
données censurées automatiquement. Seule une validation manuelle
permettra d'extraire des information de valeur.
- Les saisies de Maximo devraient être
améliorées afin d'obtenir des données fiables et
utilisables par ce type de logiciel.
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.
Solutions
commerciales:
MRO, l'éditeur de Maximo propose deux solutions
permettant d'entrer des données conformes au standard ISO-14224.
- En ce qui concerne les d'équipement, il existe une
extension nommée "Maximo asset specifications" qui contiennent
à la fois les taxinomies des 17 catégories d'équipements
cités dans la norme avec les différents types,
sous-équipements, entités maintenables, et les tables de
données spécifiques qui leurs sont propres (onglet
"Specifications" du module EQUIPMENT). Un script SQL permet de mettre à
jour Maximo avec ces données.
- En ce qui concerne les tables des "Problems, Causes &
Remedies" pour chacun des équipements cités dans la norme, il
existe une extension à Maximo nommée "Maximo Failure code for
oil and gas"
Ce produit est livré avec des scripts SQL de chargement
et contient environ 500 "Failure Class" d'équipements associées
chacune aux "Problems", "Causes" et "Remedies".
Avantages:
- Il propose un cadre de normalisation pour les
catégories et données caractéristiques des
équipements décrits dans la norme.
- Il propose un cadre pour la saisie des rapports de
défaillance dans les "Work Order".
- Ces produits peuvent être utilisés sur de
nouvelles bases ou des bases existantes pour compléter les
données.
Inconvénients:
- Ces deux produits font l'objet d'une licence par site et
peuvent s'avérer un investissement lourd si on doit l'étendre
à l'ensemble des chantiers.
- Ils ne proposent apparemment pas de solution pour les champs
obligatoires ne se trouvant pas dans Maximo.
- Nous ne disposons toujours pas de moyen simple pour
convertir les formats existants des données caractéristiques des
équipements à partir de la "Long Description" ni à partir
des données déjà saisies dans les "Specifications". Ce
travail peut s'avérer important et ne pourra pas être fait par le
personnel des chantiers.
- Les outils d'analyse des données de maintenance ne
font pas partie de la proposition.
Note: Nous n'avons pas pu obtenir ni d'informations
complémentaires ni de cotation concernant ces deux modules (hors
documents commerciaux). Les achats étant regroupés au
siège de Houston, nos demandes n'ont pas encore obtenu de réponse
à la rédaction de ce document.
Note: Il pourrait s'avérer utile de disposer d'au moins
une licence du produit pour pouvoir étudier les détails de
l'implémentation proposée par MRO.
Publications de
OREDA:
La 4ième édition du "OREDA Offshore Reliability
Data Handbook" est sortie en 2002 (période 1997-2000, Phase IV & V)
et contient des données concernant les taux de pannes, les modes de
pannes et les temps moyens de réparation pour les équipements
utilisés principalement dans les installations offshore.
Il semble que OREDA collabore maintenant avec de nouveaux
fournisseurs en ce qui concerne les équipements sous-marins: ABB,
Cameron Controls, FMC, Kvaerner. Toutefois, il s'agit principalement de
données concernant les équipements de production.
Les équipements traités dans cet ouvrage sont
plus nombreux que ceux proposés par la norme:
|
Rotating machinery
|
Mechanical equipment
|
Control & Safety
|
Subsea equipment
|
|
Combustion engines
|
Cranes
|
Fire & Gas detectors
|
Control systems
|
|
Compressors
|
Heat exchangers
|
Control Logic Units
|
Pipelines
|
|
Electric generators
|
Heaters and Boilers
|
HVAC
|
Manifolds
|
|
Electric motors
|
Swivels
|
Nozzles
|
Risers
|
|
Gas turbines
|
Turrets
|
Process sensors
|
Running tools
|
|
Pumps
|
Vessels
|
UPS
|
Subsea pumps
|
|
Steam turbines
|
Winches
|
Valves
|
Templates
|
|
Turbo expanders
|
|
|
Wellhead & X-mas trees
|
|
|
|
|
Note: A cause des délais d'achats d'environ six mois,
il ne nous a pas été possible d'utiliser cet ouvrage comme
référence pour traiter complètement de l'implantation de
cette norme.
Conclusions:
Nous avons examiné les différents aspects de la
norme et revu les moyens de l'implanter dans Maximo. Ce ne sont que des
éléments de prise de décision que nous avons
observé de notre point de vue local. Il restera à effectuer une
analyse plus complète avant toute prise de décision au niveau du
groupe.
Avantages:
- La norme ISO-14224:1999 est le cadre idéal pour
normaliser à la fois la hiérarchie des équipements et des
données spécifiques les concernant mais aussi pour valoriser les
données de défaillances de nos historiques de maintenance.
- Elle impose peu de saisie complémentaires par rapport
à l'existant.
- Elle permettra de valoriser nos données de
maintenance et d'effectuer des comparaisons entre appareils.
- Les comparaisons pourront s'étendre aux mêmes
équipements dans d'autres sociétés. Pour cela il nous
faudra acquérir le:
"OREDA Offshore Reliability Data Handbook 4th
edition"
- Elle peut ne s'adapter qu'à certains
équipements spécifiques.
Inconvénients:
- Elle ne sera pas facile à mettre en place car les
structures existent déjà et cela pourrait engendrer des travaux
de saisie importants.
- Elle peut s'avérer chère si l'on utilise les
produits proposés par MRO sur tous les chantiers car elle fait l'objet
de deux licences par site.
- L'adaptation par nos services internes de cette norme
pourrait s'avérer longue si elle doit être étendue à
tous les chantiers.
- Il faudra attendra encore au moins un ou deux ans
d'historiques de maintenance pour pouvoir en tirer des résultats
tangibles. Les bénéfices ne pourraient se faire sentir
qu'après cette période.
Note:
Les conclusions sur cette partie ne peuvent être que
partielles pour plusieurs raisons:
- Nous n'avons pu disposer d'information concernant les
extensions de Maximo proposées par MRO.
- Nous n'avons pu obtenir l'ouvrage de référence
"OREDA handbook" afin d'en juger l'intérêt.
Conclusions concernant l'implantation de la norme
ISO-14224:1999:
Autre piste à
explorer:
Le produit Cognos Powerplay est un des outils que nous n'avons
pu explorer faute d'en disposer sur notre site. Il s'agit d'un outil qu'utilise
déjà MRO pour sortir certains rapports de maintenance ou
financiers à partir de Maximo.
Powerplay est un outil dit OLAP (On Line Analytical
Processing).
Il est conçu pour effectuer des analyses
multidimensionnelles de jeux de données. A partir d'une base de
données relationnelle ou non, on peut construire des diagrammes
variés dont le modèle est construit graphiquement à partir
des données croisées entre elles.
Ce type de rapport permet de faire des analyses
croisées avec le niveau de détail adapté aux analyses
demandées. Chaque dimension peut être scindée en ses sous
ensemble pour obtenir une analyse fine (Drilldown).
Ce type de produit repose sur trois concepts:
- Le premier est la dimension. Une dimension est une
entité de classification qui permet à l'organisation d'en mesurer
les performances. Dans notre cas, ce serait par exemple: Le temps, les
équipements, les services, les données de fiabilité, les
locations, les données de défaillances.
- Le second concept repose sur les membres des dimensions ou
catégories. Pour le temps, on pourrait citer l'année, le mois ou
une période. Certaines catégories peuvent être des
sous-ensembles d'autres catégories. Le mois est un sous-ensemble de
l'année.
- Le troisième concept est celui des mesures qui
représentent les rapports que l'on peut créer en croisant les
membres des dimensions en fonction de l'activité exercée
(maintenance, finance...).
Powerplay permet aussi de sortir des graphiques de type Pareto
type 80/20. Ces graphiques n'ont pu être sortis avec les outils de
Maximo, mais seulement après l'export des données vers d'autres
applications.
Ce type de produit ou tout autre produit concurrent
déjà interfacé avec Maximo pourraient être une
solution aux analyses multidimensionnelles que nous avons tentées
d'explorer au travers de nos différents prototypes SQR.
Il s'agit d'un produit que l'utilisateur final peut utiliser
sans recours au service informatique. On pourrait disposer de vues
spécifiques communes pour comparer les données des chantiers.
Les comparaisons entre vues ne pourront se faire que si les
données de Maximo sont comparables entre chantiers. Nous revenons au
problème de normalisation que nous avons déjà
exploré dans le chapitre précédent.
Les produits concurrents sont: Business Object, MicroStrategy,
SAP BW, Brio ou Oracle Discoverer. Nous n'avons pas exploré ces
solutions.
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:
è 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.
è 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.
è 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.
è 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.
è 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.
Conclusions
générales.
Partie
quantitative:
En terme de réalisation:
- Nous avons atteint l'objectif que nous nous étions
fixé.
- Les utilisateurs sont satisfaits et le prototype correspond
aux besoins exprimés.
- Le prototype a été implanté sur cinq
sites de test en Angola.
Toutefois, certains travaux restent à faire:
- Valider les données du prototype sur plusieurs
mois.
- Finaliser la version du programme afin de la faire
correspondre aux normes de développement et d'installation du groupe.
Compléter la documentation du programme. A l'issue de cette
étape, créer la version de production initiale 1.0.
- Créer les documentations pour inclure ce rapport dans
les manuels de Maximo.
- Même si les utilisateurs sont satisfaits, rien
n'indique pourtant que les données fournies puissent être
utilisées avec bénéfice pour le suivi de la maintenance.
Il nous faudra suivre les comptes rendus des utilisateurs dans les mois
à suivre pour avoir une idée plus précise de la
situation.
- Le fichier source du programme et sa documentation ont
été envoyées au siège de Houston, mais le produit
n'a pas encore eu d'approbation définitive à l'écriture de
ce document.
Ce produit reste une création locale et ne pourra
être utilisé officiellement qu'après réception de
l'accord officiel du siège social.
Partie
qualitative:
Nous avons examiné plusieurs méthodes d'analyse
qualitative des rapports de maintenance.
Aucune de ces méthodes n'a donné de
résultats utilisables d'une façon sure pour les raisons
suivantes:
- La saisie des données de maintenance n'est pas assez
contraignante pour donner des informations fiables.
- Il n'existe pas de catégorisation des
équipements.
- Il n'existe pas de catégorisation des
défaillances. Les données de défaillance sont
stockées sous forme de texte libre inutilisable pour une analyse
automatique.
Tant que ces problèmes ne seront pas résolus, il
serait illusoire de vouloir obtenir d'autres informations que quantitatives
à partir des données de Maximo sans retraitement manuel.
Les méthodes statistiques examinées ne sauraient
dans tous les cas être mises en place sans une formation adéquate
aux problèmes de la fiabilité des équipements. Leur
interprétation reste complexe et ne pourra être faite que par un
nombre restreint de personnes au siège social ou sur les bases
importantes. Les conséquences des décisions prises avec ce type
d'outils devront être examinées sur des sélections
d'équipements bien maîtrisés avant d'être
généralisées.
Dans notre environnement, il serait préférable
d'utiliser des outils de type Powerplay permettant aux utilisateurs d'extraire
des données sous différents formats sans recours au service
informatique du siège. Nous recommandons les analyses de type Pareto qui
paraissent les plus accessibles et les plus faciles à
interpréter.
Amélioration du
retour d'expérience:
Tout d'abord, une mise au point avant de commencer ce
chapitre. Il ne s'agit pas ici de remettre en cause les techniques de
maintenance telles qu'elles sont utilisées dans notre organisation. Les
maintenances préventives ont fait leurs preuves pour ce qui est
d'améliorer la fiabilité des équipements sur nos
chantiers. Toutefois, l'utilisation des historiques comme source d'information
pour le retour d'expérience pourrait être
améliorée.
Nous avons proposé un certain nombre de règles
d'usage destinées à améliorer la qualité de saisie
des rapports de Maximo. Il ne s'agit que des règles minimales qui
permettraient d'améliorer le produit existant, mais pas de le
transformer notablement.
Nous proposons en revanche l'implémentation de la norme
ISO-14224:1999 qui permettra d'améliorer le circuit de retour
d'expérience. Nous avons donné les éléments
nécessaires pour décider du bien fondé d'une telle
migration.
L'implantation de la norme nous permettrait de normaliser la
hiérarchie des équipements, mais aussi les rapports de
défaillances. Les objectifs de la collecte d'informations
normalisées seraient les suivants:
- Analyse des problèmes d'un chantier et
possibilité de comparaison avec d'autres.
- Optimisation des maintenances préventives:
Elimination des maintenances redondantes ou inutiles.
Ajout des maintenances manquantes.
Changement des "Job Plan" des maintenances
inadéquates, présentant des risques ou accroissant les risques de
pannes.
Adaptation de périodicités trop courtes ou trop
longues.
Utilisation de maintenances conditionnelles.
- Plus lointains, mais possibles: Construction des FMEA, des
arbres de causes, Ishikawa...
Aucun d'eux ne peut être atteint à partir des
informations extraites de la base actuelle autrement que par un retraitement
manuel important.
Malgré les avantages d'une telle normalisation,
l'implantation complète d'une telle norme ne sera pas simple et devra
dans un premier temps faire l'objet d'une étude de faisabilité et
d'opportunité. Elle ne constitue qu'une première étape
permettant de construire une base de donnée fiable et
réutilisable. Il restera à sélectionner les outils
d'analyse parmi ceux que nous avons explorés, mais aussi et surtout
à interpréter les résultats et à en tirer des
enseignements utiles pour la gestion de la maintenance.
Comme nous l'avons dit en introduction, quel que soit l'outil
informatique choisi, seule l'interprétation humaine des résultats
conduira à une prise de décision. C'est là ou se jouera
tout le talent des professionnels de nos chantiers.
Si nous avons atteint nos objectifs quand à la partie
quantitative, les autres domaines ne restent que dans le domaine de la
prospective. Ils ne dépendent que des améliorations de Maximo que
nous voudrons implémenter.
Nous avons exploré un certain nombres de domaines et
donné des solutions pour atteindre nos objectifs. Ce document devra
servir de base pour les prises de décisions qui s'imposent si nous
voulons améliorer le retour d'expérience de notre outil de
gestion de la maintenance.
Annexe A.
Littérature:
- [ZWINa] "La maintenance basée
sur la fiabilité guide pratique d'application de la RCM", Hermes,
ZWINGELSTEIN.
- [ZWINb] "Diagnostic des défaillances: Théorie
et pratique pour les systèmes industriels", Hermes, ZWINGELSTEIN.
- [FRAN] "La fonction maintenance", AFNOR, Jean Claude
Francastel.
- [HENG] "Pratique de la maintenance préventive",
Dunod, l'Usine Nouvelle, Jean Héng.
- [AFNO] "Comment réussir votre maintenance", AFNOR.
- [JACQ] Exposé "Maintenance Productive Totale",
Philippe Jacquemier.
- [SHIR] "Le guide TPM de l'unité de travail", Dunod,
Kunio Shirose.
- [MOUB] "Reliability-Centered Maintenance, 2nd ed",
Industrial Press, MOUBRAY John.
- [BLON] "Aide mémoire Gestion Industrielle", Dunod ,
François Blondel.
- [BENA] "La gestion des stocks", Hermes, Jean
Bénassy.
- [VONK] "Prototypage", Masson Printice Hall, R. VONK.
- [HUGU] "RAD, une méthode pour développer plus
vite", InterEditions, Jean Hugues/Bernard Leblanc/Chantal Morley.
- [UML3] "Visual Paradigm for UML Community Edition 3.0",
User's Manual.
- [VICK] "Systèmes d'information et processus agiles",
Hermes, Jean-Pierre Vickoff.
- [ORED] "OREDA Reliability Data Book" or ISO 14224:1999.
- [PSDI] PSDI "Maximo User's manual" & "Administrator's
manual".
- [CENT] Centura "SQLbase administrator & user's
manual".
- [GALI] "SQR in PeopleSoft and other applications", Manning,
Galina et Vlad Landres.
- [LEAR] "Programmation Microsoft Access", Learning Tree.
- [GETZ] "Access en action", O'Reilly, Ken Getz.
- [CLLH] "Access 2000 visual basic applications", Microsoft
Press, Evan Cllhan.
Sites internet:
- http://www.maximo-users.net.
MRO Maximo User's group.
- http://www.mro.com. Site de MRO.
- http://www.weibull.com.
- http://www.sintef.no. Projet
OREDA.
- http://www.rad.fr.
Développement RAD, processus agiles.
-
http://perso.wanadoo.fr/nathalie.diaz/index.htm. Normes de
qualité ISO.
-
http://www.jipm.or.jp/en/home/. Japan Institute of Plant Maintenance (
JIPM ).
- http://www.afim.asso.fr.
Association de maintenance.
- http://www.cnam.fr/. Site du
Conservatoire National des Arts et Métiers.
Lexique et acronymes:
- 5S: (Seiri, Seiton, Seiso, Seiketsu, Shitsuke) en
français (Débarrasser, Ranger, Nettoyer, Standardiser, self
discipline).
- CCV: Coût global du cycle de vie.
- CMMS: Computerized Maintenance Management System.
- CPI: Chef de projet informatique.
- CSV: Coma Separated Values.
- CWO: Corrective Work Order.
- EPE ou EVP: Évaluation de performances.
- EQR: Estimation Quantitative du Risque.
- EM: Entité Maintenable.
- FMD: Analyse de Fiabilité, Maintenabilité et
Disponibilité
- FM: Fiabilité et Maintenance
- FRACAS : Failure reporting and corrective action systems.
- FTA: Fault tree analysis.
- ISM: International Safety Management.
- JP: Job plan. Liste d'opérations à
réaliser pour effectuer une maintenance préventive.
- LCC: Live Cycle Cost.
- LDA: Luanda, capitale de l'Angola, par extension base
opérationnelle de Luanda.
- MBF: Maintenance Basée sur la Fiabilité.
- MCF: Maintenance centrée sur la fiabilité
- MMR: Monthly Maintenance Report.
- MR: Material Request. Requête pour l'achat
d'équipements, consommables ou service.
- MRO: Les fabricants du progiciel de la PMS Maximo.
- MTBF: Mean Time Between Failure.
- MTTR: Mean Time To Repair.
- OEE: Overall Equipment Efficiency = TRS.
- OLAP: On Line Analytical Analysis.
- OREDA: Projet de collecte de données de fiabilité
et de maintenance des équipements utilisés dans les industries du
pétrole et du gaz naturel.
- PM: Preventive Maintenance.
- PMS: Preventive Maintenance System.
- PO: Purchase Order. Commande d'équipement,
consommables ou de service.
- PWO: Preventive Work Order.
- TC: Technical Coordinator.
- TPM: Total Productive Maintenance.
- TRS: Taux de Rendement Synthétique en TPM.
- WO: Work Order.
Annexe B: Exemple de
rapport qualitatif final.
Exemple de résultats fourni par le prototype
quantitatif à l'issue de la version 0.5b.
Annexe C: Résultats
des tests Weibull++.
Résultats des tests obtenus à l'aide du logiciel
Weilbull++ 6.0.
| 