Etude de Méthodes D'analyse Des Historiques de Maintenance Dans Un Environnement de Forage Pétrolier Offshore - Philippe JUNG

14/12/2018 Memoire Online - Etude de méthodes d'analyse des historiques de maintenance dans un environnement de forage pétrolier offshor…
WOW !! MUCH LOVE ! SO

PEACE !
Rechercher sur le site: Fond bitcoin pour l'amélioration d
1memzGeKS7CB3ECNkzSn2qHwxU
Dogecoin (tips/pourboires)
DCLoo9Dd4qECqpMLurdgGnaoqbftj
Recherche
Home | Publier un mémoire | Une page au hasard
Memoire Online > Sciences

Etude de méthodes d'analyse des historiques de maintenance dans un
environnement de forage pétrolier offshore ( Télécharger le fichier original ) Disponible en
par Philippe JUNG mode multipage
CNAM Paris - Ingéieur DPE Informatique industrielle 2004
plaque polypropylene PP - croisillons,

Annonce fermée par
OUVRIR
conditionnementsBloquer l'annonce Pourquoi cette annonce ?
fabricants conteneurs emballages, intercallaires en polypropylene , alvéolaires kargil.com
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.
https://www.memoireonline.com/10/07/617/etude-methodes-analyse-historiques-maintenance-forage-petrolier-offshore.html 1/97
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
Prototype n°4 sous SQR: 66
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 Temps de changement de fabrication Rendement des matériaux
Réglages Activité opérateur Rendement énergétique
Pertes au démarrage
Déplacements et manutention Sur consommation:
Micro arrêts
Organisation du poste - d'outillage,
Marche à vide
Défauts de logistique - d'accessoires
Sous vitesse
Excès de mesures - de consommables
Rebuts et retouches
Arrêts programmés
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 - Maîtrise de la conception.
équipements.
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 - Assurer les différentes certifications et réglementations.
l'environnement.
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" Responsabilité dans le projet
Fonction
HHOM Service maintenance siège social Houston: Il validera la solution finale et suivant l'état du développement la
mettra en oeuvre ou confiera la réalisation par des intervenants
Ce service est responsable de la mise en internes ou externes. Il pourra être consultée dans les phases
place de Maximo sur les différents appareils intermédiaires du projet.
de Pride. Elle centralise toutes les
informations de maintenance et tente de
généraliser les procédures.
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 proposera des solutions et validera la partie opérationnelle
du projet aux différentes étapes du prototype.
Elle est responsable de la partie
opérationnelle des chantiers et de
l'infrastructure. Il en existe une par client.
LDADS Drilling Supervisors base LDA: Ils proposeront des solutions et valideront la partie opérationnelle
Ils sont responsables de la gestion d'un
chantier de forage.
LDAM Service Maintenance base LDA: Ils proposeront des solutions et valideront la partie maintenance
Il gère l'ensemble des opérations de
maintenance des appareils d'Angola ainsi que
les superviseurs des différentes spécialités.
SM "Site Manager": Ils proposeront des solutions. Ils n'auront qu'un rôle consultatif.
Ils sont responsables de la gestion des

opérations au niveau des chantiers pendant
les opérations de forage.
TC "Technical Coordinator": Ils proposeront des solutions et valideront le prototype pour les
aspects liés à son usage au sein du chantier.
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.
HOD Head Of Department: Ils auront un rôle consultatif en ce qui concerne les éventuelles
contraintes de saisie additionnelles. Ils ne sont pas concernés
Ce sont les responsables du personnel de directement par le projet.
maintenance dans leur domaine (électricité,
mécanique, hydraulique...).
MCREW Maintenance CREW: On tiendra compte de leur avis pour toute modification liée à la
saisie des rapports. Ils sont à même de signaler les
Ce sont les équipes qui effectuent les imperfections d'un JP à leur chef de service. Ils permettront de
maintenances correctives ou préventives sur définir les limites des écrans de saisie. Ils n'interviendront pas
les équipements. Ils sont pour certains d'eux directement dans le projet.
amenés à faire la saisie des rapports dans
Maximo.
MSUP Maintenance SUPervisors: Ils proposeront des solutions et valideront les prototypes à ses
différentes étapes en particulier pour la partie qualitative.
Ce sont les personnes qui supervisent la
maintenance sur les différents chantiers. Ce
sont les experts dans les domaines qui les
concernent.
CPI Chef de Projet Informatique: Il effectuera:
L'auteur de ce document. - 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 Value list/table Comment
screen
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 / Location
Sub-Class
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 NA
Date
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 NA
Authority #
EQ17 ALN 40 Certifying NA
Authority
EQ18 DATE 4 Date NA
METERREADING DECIMAL 15 Last reading NA In the Meters tab
READINGDATE DATETIME 10 Last reading NA In the Meters tab
date
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 Value list/table Comment
screen
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 NA
Trip report
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")
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.

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 WAPPR Il s'agit de l'état initial d'un "Work Order" de maintenance corrective (CWO). Sa date de
APPRoval 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 WSCH Il s'agit de l'état initial d'un "Work Order" de maintenances préventives (PWO) après leur
SCHedule 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 WOPCOND Cet état indique que le WO ne peut être exécuté faute de conditions opérationnelles
OPerating adéquates.
CONDitions
Wait for WMATL Cet état indique que l'on ne dispose pas des pièces de rechange nécessaires pour effectuer
MATeriaL 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 HISTEDIT Ce champ n'apparaît pas directement dans la liste des états disponibles aux utilisateurs. Il est
EDIT 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 Donne une somme des WO, mais ne donne pas
département. le détail par type de WO.
DELIN-WO WO Liste les PWO ouverts ayant dépassé leur temps Fonctionne partiellement, pas de règles
d'ouverture. décrites.
WO- WO Liste les WO Closed dans une période.
CLOSED
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 Pas utilisé dans notre application.
"Downtime" moyen d'un équipement.
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 Pas utilisé dans notre application.
équipement avec "Downtime", "Failure Code",
cause, Remède et dates. Utilise les mêmes informations que
précédemment.
LOCFAILx EQPT Idem que les trois précédents, mais pour une Nous n'utilisons pas la notion de location.
location particulière.
EQHSTGRA EQPT Donne les informations suivantes pour un Pas utilisé dans notre application.
équipement:
Ne donne les informations que pour un
Total labor hours, ?mean response time for équipement. Les informations ne sont pas
emergency work orders, ?total downtime hours, présentes dans nos écrans. Rien ne permet de
?mean time to repair, ?mean time between les obtenir.
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
FAILGRPH EQPT Donne les informations suivantes pour un Pas utilisé dans notre application.
équipement:
Listé dans Maximo, mais exécutable non
Répartition des "Failure Type" en quantité et %. disponible.
Utilise Excel pour afficher les données à partir Nous n'utilisons pas les "Failure Code".
d'un fichier .CSV.
RNRBYLOC WO Calcule les valeur suivantes pour une location: Pas utilisé dans notre application. Listé dans
Maximo, mais exécutable non disponible.
- Mean time to respond =
Le calcul pour une location ne présente pas
AVG(ActStart - ReportDate) d'intérêt dans notre application.
- Mean time to repair (MTTR) =
AVG(ActFinish - ActStart)
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 INPRG
CLOSE 17/09/1999 14:47
14:56 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:

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:
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.

- 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".
Construction du prototype n°3 sous SQR:
- Application des différentes remarques dans le "Prototype N°3".
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
- Larésultats
prochaine
au étape
formatest
.SPF.
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
Cet
queoutil est d'origine
de fabrication un outil d'assistance à la génération de rapport. Quelques tests ne nous ont pas prouvé l'efficacité de
d'outils.
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:

Situation:
Base "Pride Foramer" Luanda le 19 Mai 2004.
Participants: 7 personnes. Durée 1 heure.

- 3*LDARM: Rig Manager chantiers Pride Africa, Pride Angola et Barracuda.

- Valider le format du prototype N°3.
- Faire de nouvelles propositions ou corrections du rapport existant.

- 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.

Situation:
Base "Pride Foramer" Luanda le 20 Août 2004.
Participants: 7 personnes. Durée 1 heure.

- 3*LDARM: Rig Manager chantiers Pride Africa, Pride Angola et Barracuda.

- Valider le format du prototype N°4 et les nouveaux graphiques.
- Faire de nouvelles propositions ou corrections du rapport existant.

- 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.

- TC chantiers: PAN, PAF.
- SM chantier: BDA.
- MSUP Maximo Houston.

- 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.

- 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.

- LDAM: Assistant au directeur de la maintenance LDA.

- 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.

- 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 % % Cumulé

Défauts
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 Qté WOJP4 Désignation
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° O L'équipement peut être choisi à plusieurs niveaux de l'arbre suivant l'utilisateur. Il n'existe pas 4
d'équipement de consigne particulière. Seul le bon sens prévaut.
Work Type O Les valeurs possibles sont: 4
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.
Sub Work N Il peut prendre les valeurs suivantes: 3
Type
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.
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 4
formalisé.
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 4
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.
Duration N Durée des travaux en heure-homme. Elle devrait inclure les temps de préparation, rangement 4
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.
Meter reading N Ce champ texte optionnel devrait contenir la valeur du compteur de l'équipement lorsque la 1
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é.
%Completion N Ce champ optionnel contient le % de réalisations des travaux. Il n'est pas systématiquement 2
mis à jour régulièrement. Le plus souvent, il n'est mis à jour que lors d'un changement de statut.
Reported by N Il s'agit d'un champ texte libre. Pas de contrôle de la saisie, car les personnes physiques ne 1
sont pas répertoriées.
Lead Craft O Le "Lead Craft" contient la liste des différents départements du chantier. Il s'agit du département 4
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.
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 3
rapport aux "Lead Craft" et "Crew".
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 3
bien à la date à laquelle s'est passé l'événement qui a fait changer le statut.
Reported X La date de création du "Work Order". Elle n'a pas de lien avec la date ou s'est produit le 5
date 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.
Report X Ce menu permet d'entrer des arrêts après coup alors que l'équipement est déjà retourné en 4
downtime 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.
Change Eqpt X Permet de mettre un équipement dans un états opérationnel ou non en entrant une date et un 4
statut "Downtime code". Même statut que le précédent.
UP/Down
Failure Report N N'est jamais utilisé (onglet "Failure report"). 0
Date
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é "Catégories" et "Type" peuvent être entrés dans l'onglet
d'équipement. (a) "Specifications" sous forme de "Classification" et "ss-
classifications". (Specs)
Type d'équipement. (a)
N'est pas utilisé dans notre version.
Application. (a)
"Application" n'a pas d'équivalent, mais peut être inclus
dans les caractéristiques de conception.
Données Nom de l'installation ou Ce type d'information est enregistré dans la "Longue
d'installation code. (a) description" (LD) de l'équipement à la racine de l'arbre ou
dans les "Specs" (à définir).
Type d'installation. (a)
On y trouve les spécifications complètes de l'appareil.
Type d'opérations. (a)
Zone géographique.
Données d'unité Description de l'unité Dans la LD ou "Linked documents" (format PDF préféré).
d'équipement d'équipement.
Champ SERNUM.
Numéro unique (N°série
ou autre).
Conception Données du Désignation du fabricant. Champ VENDOR.
fabricant
Modèle. Champ MANUFACTURER.
Champ ASSETNUM.
Caractéristiques Suivant la catégorie Contenu dans la LD.
de conception d'équipement: Puissance,
vitesse, pression... (a) 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 Type de redondance. Pas d'équivalent. Dans "Specs".
condition
normale Mode de Pas d'équivalent. Dans "Specs".
fonctionnement.
Champ INSTALDATE.
Date d'installation.
Pas d'équivalent.
Périodes de
surveillance calendaire. Compteurs horaires.
Durée de Pas d'équivalent.

fonctionnement/période.
Pas d'équivalent. Dans "Specs".
Nombre de
sollicitations/période.
Paramètres de
fonctionnement. (a)
Facteurs Extérieur (b) et intérieur Pas d'équivalents.
d'environnement (c).
Peut-être inclus dans "Specifications".
(extrême, modérée,
favorable)
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 Pas de catégorie applicable, car cela regroupe moteur et générateur.
(Eng+Alt)
053101002 Diesel Engine #1 Moteur à Combustion Moteur Diesel (DE) Pas de Sous-ensemble ni EM.
Wartsila (CE)
Données spécifiques entrées à ce niveau.
...
053101011 Fuel feed pump CE DE Unité du moteur à Pompe à carburant
combustion
053101015 Starting CE DE Système de démarrage Unité de démarrage
Equipement
...
053101003 Alternator/Diesel Générateur Entraîné par moteur Pas de SS-Ensemble ni EM.
Eng #1 Electrique (EG) (MD)
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 Numéro unique Numéro "Work order" corrective: WONUM.
de la défaillance
Emplacement de Numéro d'identification de Numéro d'équipement: EQNUM.
l'équipement l'équipement
Données de Date de Date de détection Pas d'équivalent. Correspond à "Failure Date"
défaillances défaillance (FAILDATE) onglet "Failure reporting" module WO.
Non utilisé dans notre version.

Mode de Voir (a). "Failure Class" (FAILURECODE) dans le module
défaillance WO. Spécifique à un équipement.
Peut être lié à l'équipement.
Conséquences Echelle d'impact. Le "Downtime" de l'équipement dans le module
sur la production "Work Order" contient aussi un "Downtime code"
ou la sécurité qui permet de caractériser le problème, mais pas
forcement l'impact.
Classe de Effet critique ou non sur l'unité. Il existait une notion de "Downtime" opérationnel ou
sévérité non dans les précédentes versions. Il faudrait la
réactiver. Le champ "WO priority" pourrait aussi être
utilisé.
Indicateur de la Voir (b). Champ PROBLEM du "Work Order" et
défaillance compléments dans la "Long Description" (LD).

Cause de Voir (c). Champ CAUSE du "Work Order" et compléments
défaillance dans la LD.

Sous-Ensemble Sous-ensemble défaillant. Implicite dans le numéro d'équipement lorsque
défectueux applicable.
Voie (a)
Entités Détail des unités défaillantes. Voir Implicite dans le numéro d'équipement lorsque
maintenables (a). applicable.
défaillantes
Méthode Méthode de détection de la Dans la "Long Description" du "Work Order". Peut
d'observation défaillance. Voir (d) faire l'objet de l'ajout de DETECTION dans les
PROBLEM/CAUSES/REMEDIES.
Commentaires Informations Informations complémentaires sur Dans la "Long Description" du "Work Order".
complémentaires les conditions et cause de
défaillances, diagnostic et
méthodes de réparation.

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 Identifiant unique de la Numéro de "Work order" préventif: WONUM.
de maintenance. maintenance.
Emplacement de Identification de Numéro d'équipement: EQNUM.
l'équipement. l'équipement.
Enregistrement Pour les maintenances N'est pas applicable.
de défaillance. correctives uniquement.
Les maintenances préventives et correctives sont
enregistrées dans le même module "Work Order".
Données de Date de Date à laquelle s'est ACTSTART & ACTFINISH module "Work Order".
maintenance maintenance. effectuée la
maintenance.
Catégorie de Préventive ou WORKTYPE du module "Work Order", inclut entre autres
maintenance. corrective. les PM et CM.
Opération de Voir (b). Pas d'équivalent. Pourrait correspondre à une liste modifiée
maintenance des "Sub Work Type".
Conséquence sur Echelle d'impact. Le "Downtime" de l'équipement dans le module "Work
la production. Order" contient aussi un "Downtime code" qui permet de
caractériser le problème.
Sous ensemble Sous ensemble Pas d'équivalent. Implicite dans le numéro d'équipement.
soumis à la concerné par la
maintenance. maintenance. Voir (a).
Entité Spécifier l'entité Pas d'équivalent. Implicite dans le numéro d'équipement.
maintenable concernée. Voir (a).
soumise à la
maintenance.
Moyens de Maintenance en Voir (c). Les heures sont entrées dans le champ DURATION du
maintenance homme-heures module "Work Order". Chaque discipline devrait faire un
par discipline. "Work Order" différent. Ce n'est pas toujours le cas.
Durée totale de la Pas d'équivalent. Sauf à cumuler les heures des différentes
maintenance en disciplines. Toutefois, il ne sera pas possible de déterminer
homme-heure. facilement s'il s'agit de la même intervention.
Temps de Temps de Temps de maintenance Peut être déduit à partir de ACTSTART, ACTFINISH et
maintenance maintenance active par rapport au DURATION module "Work Order".
active. temps d'indisponibilité.
Temps Temps d'indisponibilité FAILDATE, ACTSTART & ACTFINISH module "Work
d'indisponibilité. de l'équipement Order".
concerné.
Commentaires Informations Indiquer toute Dans la "Long Description" du "Work Order".
complémentaires. information utile à cet
emplacement.

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.
Rechercher sur le site:
Recherche
© Memoire Online 2000-2015

Pour toute question contactez le webmaster

Etude de Méthodes D'analyse Des Historiques de Maintenance Dans Un Environnement de Forage Pétrolier Offshore - Philippe JUNG

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Etude de Méthodes D'analyse Des Historiques de Maintenance Dans Un Environnement de Forage Pétrolier Offshore - Philippe JUNG

Transféré par

Droits d'auteur :

Formats disponibles

14/12/2018 Memoire Online - Etude de méthodes d'analyse des historiques de maintenance dans un environnement de forage pétrolier offshor…

WOW !! MUCH LOVE ! SO

Home | Publier un mémoire | Une page au hasard

Memoire Online > Sciences

plaque polypropylene PP - croisillons,

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

Présenté en vue d'obtenir

LE TITRE D'INGENIEUR DIPLOME PAR L'ETAT

Par Philippe JUNG

Monsieur le professeur Pierre Paradinas

Monsieur le professeur Jacques Jouhaneau

Monsieur François-Yves Villemin

Monsieur Daniel Hajage

Monsieur Olivier Beaujard

MAXIMO, CMMS, PARETO, WEIBULL, IS0-14224:1999, OREDA, MTBF.

MAXIMO, CMMS, PARETO, WEIBULL, IS0-14224:1999, OREDA, MTBF.

Et en particulier M. Yves Nerisson, M. Didier Sautron pour leurs conseils avisés.

Table des matières: 1

Index des figures 2

Index des tableaux. 3

Présentation de la TPM (Total Productive Maintenance). 6

La définition de la TPM tient en cinq points: 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

Répertoire des intervenants: 14

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

Droits d'accès aux modules et rapports: 37

Architecture et ressources informatiques. 38

Description de la configuration type: 38

Ressources documentaires de base: 40

Les outils de développement: 40

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

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

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