WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


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

 > 

Etude de méthodes d'analyse des historiques de maintenance dans un environnement de forage pétrolier offshore

( Télécharger le fichier original )
par Philippe JUNG
CNAM Paris - Ingéieur DPE Informatique industrielle 2004
  

Disponible en mode multipage

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

PARIS

MEMOIRE

Présenté en vue d'obtenir

LE TITRE D'INGENIEUR DIPLOME PAR L'ETAT

en

INFORMATIQUE INDUSTRIELLE

Par
Philippe JUNG

Etude de méthodes d'analyse des historiques de maintenance dans un environnement de forage pétrolier offshore

Soutenu le:

9 Novembre 2004

JURY:

Président:

Monsieur le professeur Pierre Paradinas

Membres:

Monsieur le professeur Jacques Jouhaneau

Monsieur François-Yves Villemin

Monsieur Daniel Hajage

Monsieur Olivier Beaujard

RESUME EN FRANÇAIS

En 1992, le groupe "Pride International" décide d'implanter la méthode TPM pour améliorer la gestion de sa maintenance. Il sélectionne le produit Maximo de MRO qui est un leader mondial de ce type de logiciels. Depuis sa première implantation avec succès sur le chantier Nymphéa en 1994, tous les chantiers terrestres et maritimes en ont été équipés.

Depuis la première installation, le produit a été adapté à nos besoins par la personnalisation des écrans et la création de nombreux rapports. Il existe trois rapports de synthèse répondant aux besoins des opérationnels, d'analyse des coûts et de la sécurité, mais rien concernant la maintenance.

Après avoir construit quelques prototypes, nous avons créé et implanté un rapport quantitatif mensuel de l'état de la maintenance nommé MMR et répondant aux besoins des utilisateurs.

Après de nombreuses années de fonctionnement, nous disposons de nombreux historiques de maintenance. Nos différents tests sur les données existantes ont montré que les méthodes usuelles d'analyse qualitative des données de maintenance (MTBF, Pareto, Weibull) ne pouvaient être utilisées avec succès sans l'addition d'informations complémentaires et une amélioration de la qualité de la saisie.

A la suite de cet état de fait, nous avons examiné les possibilités d'implantation de la norme ISO-14224:1999 qui permettrait d'améliorer le retour d'expérience et les possibilités d'analyse des données de fiabilité de notre groupe.

Nous préconisons aussi des améliorations générales du produit ainsi que l'utilisation d'un produit OLAP tel que Powerplay pour effectuer des analyses multidimensionnelles de données.

SUMMARY IN ENGLISH

In 1992, the group "Pride International" decides to implant the TPM method to improve the management of its maintenance. It selects the Maximo product of MRO that is a world leader of this type of software. Since its first implantation with success on the rig Nymphéa in 1994, all onshore and offshore rigs have been equipped some.

Since the first installation, the product has been adapted to our needs by the personalization of the screens and the creation of many reports. Three reports of synthesis answering the needs of the operational, of analysis of the costs and the security, exist but nothing concerning the maintenance. After having constructed some prototypes, we created and implanted a monthly quantitative report of the state of the maintenance named MMR and corresponding to the needs of the users.

After numerous years of working, we have many historic of maintenance. Our different tests on the existing data showed that the usual methods of qualitative analysis of the maintenance data (MTBF, Pareto, Weibull) could not be used with success without the addition of complementary information and an improvement of the quality of the inputs.

Taking this fact into account, we examined the possibilities of implantation of the ISO-14224:1999 standard that would permit to improve the return of experience and the possibilities of analysis of the reliability data of our group.

We also recommend the general improvements of the product as well as the use of an OLAP product as Powerplay to do multi-dimensional analysis of data.

MOTS CLEF

En Français:

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

In English:

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

Remerciements:

A M. Christian Girard directeur de la base Luanda pour avoir accepté ce projet.

Tout particulièrement à M. Gilles Bocabarteille (Ing Arts et Métiers) directeur des opérations de la base Luanda qui est à l'origine de ce projet, de sa présentation aux directions et qui l'a soutenu tout au long de sa réalisation en mobilisant les équipes lors des réunions d'expression des besoins.

A M. Jean Pierre Chaix responsable de la maintenance au siège de Houston et qui a accepté que ce projet se fasse localement sur le site d'Angola.

Au service maintenance de la base de Luanda, M. Thierry Manescau et M. Johann Glot qui m'ont donné de précieuses indications concernant la maintenance.

Aux superviseurs de forages des différents appareils, M. Patrick Arberet, M. Jean Lemoal, M. Meno Bosma et M. Raphaël Siri.

Aux différents intervenants des chantiers qui m'ont fourni une critique constructive des différents prototypes et des informations de valeur sur la maintenance dans tous ses aspects.

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

Sommaire.

Table des matières:

Sommaire. 1

Table des matières: 1

Index des figures 2

Index des tableaux. 3

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

Introduction: 6

La définition de la TPM tient en cinq points: 6

Afin d'arriver à ses fins, la TPM repose sur la mise en place de cinq piliers: 6

L'ensemble des règles de la TPM amène à édicter les règles suivantes: 8

L'objectif principal étant le "Zéro défauts": 9

Les indicateurs de performance: 9

Mise en place de la TPM: 10

Description du projet: 11

Répertoire des intervenants: 14

Contexte et contraintes: 16

Analyse de l'existant. 18

Organisation générale de l'application Maximo: 18

Module "Equipment" (EQPT): 18

Module "Preventive Maintenance" (PM): 22

Module "Job plan" (JP): 25

Module "Work Order Tracking" (WO): 26

Schéma relationnel des tables principales: 33

Détails de quelques tables près définies: 33

Schéma d'interconnexion entre modules: 34

Rapports existants: 35

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

Aspects financiers: 37

Architecture et ressources informatiques. 38

Description de la configuration type: 38

Environnement d'installation: 39

Ressources informatiques: 39

Ressources documentaires de base: 40

Les outils de développement: 40

Formation: 41

Réunion initiale d'expression des besoins. 42

Minutes of meeting "Expression des besoins initiale" 42

Revue critique des différents points: 45

Les différents aspects du rapport initial: 47

Format final du prototype papier n°1: 53

Etapes de construction du prototype quantitatif. 54

Les choix de réalisation des prototypes: 54

Installation de Maximo sur le poste de développement: 54

Analyse des données et des écrans: 57

Le prototype n°2 MS-Access: 58

Prototype n°2 chiffré sous MS-Access: 59

Minutes of meeting "Expression des besoins prototype N°2" 60

Construction du prototype n°3 sous SQR: 62

Prototype n°3 sous SQR: 64

Minutes of meeting "Expression des besoins prototype N°3" 65

Prototype n°4 sous SQR: 66

Minutes of meeting "Expression des besoins prototype N°4" 70

Intégration du rapport n°4 dans Maximo: 71

Tests en réel sur les serveurs des chantiers: 73

Minutes of meeting prototype n°4 par les utilisateurs des chantiers: 74

Prototype n° 5: 75

Minutes of meeting "Expression des besoins prototype n°5": 77

Conclusion de la partie quantitative: 78

Etude de la partie qualitative. 79

Qualité de la maintenance et TPM: 79

Marqueurs de base de la fiabilité: 81

Méthodes graphiques de base: 87

Analyse de données statistiques associées aux défaillances. 92

Amélioration du retour d'expérience. 95

Méthodes de recueil de données de fiabilité: 95

Guide pour l'obtention de données de qualité: 96

Formats des données d'équipements, de défaillances et de maintenance: 100

Le développement en interne: 106

Solutions commerciales: 109

Publications de OREDA: 109

Conclusions concernant l'implantation de la norme ISO-14224:1999: 110

Autre piste à explorer: 111

Recommandations d'usage. 112

Module EQUIPMENT: 112

Module "Work Order": 112

Conclusions générales. 115

Partie quantitative: 115

Partie qualitative: 115

Amélioration du retour d'expérience: 115

Annexe A. 117

Littérature: 117

Sites internet: 117

Lexique et acronymes: 117

Annexe B: Exemple de rapport qualitatif final. 119

Annexe C: Résultats des tests Weibull++. 122

Index des figures

Figure 1 Taux de Rendement Synthétique. 9

Figure 2 Prototypage [VONK]. 12

Figure 3 Organisation générale de Maximo. 18

Figure 4 Fenêtre principale du module EQUIPMENT 20

Figure 5 Onglet "Meters" du module EQUIPMENT 21

Figure 6. Ecran "Specification" du module EQUIPMENT. 21

Figure 7 Ecran principal du module PM 23

Figure 8 Onglet "Frequency" du module Preventive Maintenance. 23

Figure 9 Ecran principale du module Work Order. 28

Figure 10 Work Order statut. 31

Figure 11 Diagramme "Work Order tracking". 32

Figure 12 Schéma relationnel des principales tables. 33

Figure 13 Diagramme de retour d'expérience dans Maximo. 35

Figure 14 Installation matérielle et logicielle de Maximo. 38

Figure 15 Entête des rapports Maximo. 47

Figure 16 "SQR4" configuration ODBC. 55

Figure 17 "SQLedit" Ecran principal. 55

Figure 18 "SQLedit" détails de la configuration. 56

Figure 19 Fenêtre principale de SQRWT 62

Figure 20 "SQR viewer" fenêtre d'exemple. 63

Figure 21 Graphique "Time-bases" & Meter-based" overdue. 66

Figure 22 Graphique "PM & CM WO counts". 67

Figure 23 PM & CM other status counts. 67

Figure 24 Graphique "PM ratio & overdue". 68

Figure 25 Module "Reports and other Apps" de Maximo. 72

Figure 26 Prompts des rapports Maximo. 73

Figure 27 Coûts des Work Order CLOSE par département. 76

Figure 28 TOP5 PM & CM stock consumption. 76

Figure 29 Work Order costs. 76

Figure 30 Major WO PM overdue. 77

Figure 31 Marqueurs de base de la fiabilité. 81

Figure 32 Graphique P-F. 82

Figure 33 Exemple de tableau de fiabilité. 85

Figure 34 Diagramme de distribution et de répartition. 87

Figure 35 Diagramme de défaillance. 88

Figure 36 Analyse Pareto descendante. 88

Figure 37 Diagrammes de Pareto, chantier "Pride Angola" toutes périodes. 91

Figure 38 Formes de loi de probabilité en maintenance. 92

Figure 39 Hiérarchie des équipements ISO-14224. 101

Index des tableaux.

Table 1 Principales causes de pertes en TPM [JACQ]. 7

Table 2 Planning prévisionnel. 13

Table 3 Répertoire des intervenants. 15

Table 4 Tables du module EQUIPMENT. 20

Table 5 Tables du module PM. 22

Table 6 Table de calcul pour les maintenances basées sur le temps. 24

Table 7 Table de calcul pour les maintenances basées sur les compteurs. 24

Table 8 Tables du module "Work Order". 27

Table 9 Tables des états d'un "Work Order". 30

Table 10 Contenu des tables prédéfinies LeadCraft & CrewID. 33

Table 11 Valeurs prédéfinies du champ "Classification". 34

Table 12 Downtime codes. 34

Table 13 Liste des rapports existants. 36

Table 14 Exemple de tailles de table Maximo. 41

Table 15 Paramètres de la ligne de commande Maximo. 72

Table 16 VALUELIST classification. 89

Table 17 Comptage des Sub-work type. 89

Table 18 Estimation de la qualité de saisie dans Maximo. 98

Table 19 Données d'équipement ISO-14224. 101

Table 20 Données de défaillances ISO-14224. 105

Table 21 Données de maintenance ISO-14224. 106

Introduction.

Le groupe "Pride Internationnal" dont le siège est à Houston est l'un des leader mondiaux dans les domaines du forage et la maintenance de puits pétroliers ou gaziers. Il fournit ses prestations dans des environnements terrestres ou maritimes dont beaucoup se trouvent dans les endroits les plus difficiles de la planète. Il possède plus de 290 chantiers dans le monde et emploie plus de 10000 employés.

Sa filiale "Pride Foramer" qui a été un précurseur dans le monde du forage en grande profondeur dans les années 70 possède un siège social en France. Elle est représentée en Angola par "Pride Foramer Angola". L'ensemble des appareils fonctionnant en Angola est géré par une "Joint Venture" entre Sonangol, la compagnie pétrolière angolaise à raison de 49% et "Pride Foramer Angola" pour 51%. Ce groupe possède 2 unités à positionnement dynamique, 2 semi-submersibles, 2 tenders et s'occupe de la gestion de deux plateformes TLP (Tension Leg Platform). Ses principaux clients dans cette région sont Total, Exxon et Chevron. C'est au sein de cette entité qu'aura lieu ce projet.

Après avoir utilisé pendant longtemps des méthodes manuelles, faute à l'époque d'informatique et de produits performants, le groupe "Pride International" a décidé en 1992, d'améliorer la gestion de la maintenance en implantant la méthode TPM (Total Productive Maintenance). Cette implantation implique des changements importants dans l'organisation et de choisir un logiciel de suivi de la maintenance ou CMMS (Computerized Maintenance Management System).

Le progiciel Maximo de la compagnie MRO a été sélectionné parmi huit autres produits. Les principaux critères ont été les suivants:

- Facilité d'utilisation et conviviale.

- Facilité de paramétrage et disponibilité de modules complémentaires.

- Il permet de gérer la maintenance, mais aussi les stocks et les achats.

- Il doit permettre de réduire les coûts de maintenance.

- MRO est un leader mondial dans le domaine de la maintenance.

La première implantation se fera sur la plateforme semi-submersible Nymphea en 1994. Après quelques années, les gains sur les coûts de maintenance, du stock mort et la réduction des arrêts de l'appareil ont été significatifs. Ce bénéfice s'est fait sentir non seulement au sein de la compagnie, mais aussi chez le client qui est aussi très concerné par tous les aspects de la maintenance. Depuis, tous les chantiers de "Pride International" ont été équipés avec Maximo, même ceux dont les revenus journaliers sont faible comme les appareils terrestres. Ce que personne n'aurait cru possible à l'origine.

Plus que jamais, les performances économiques d'une entreprise sont le garant de sa longévité. Toutefois, dans un environnement aussi technique que celui des forages pétroliers, l'économie n'est pas le seul critère qu'il faille prendre en compte. Les équipements doivent être maintenu opérationnels pour assurer les revenus de l'entreprise, mais aussi pour d'autres raisons plus prosaïques qui en sont la corollaire:

- Satisfaire les exigences contractuelles des clients.

- Se conformer aux nombreuses réglementations et normes nationales ou internationales telles que:

ISM, IMO, DNV, OSHA, EPA, ISPS, API...

- Assurer la sécurité des biens, des personnes et de l'environnement.

- Améliorer les performances opérationnelles des unités afin d'accroître leur compétitivité internationale et l'image de marque de l'entreprise.

- Améliorer la durée de vie des équipements.

- Favoriser de meilleurs choix d'équipements.

La maintenance est un des outils importants pour arriver à satisfaire toutes ces exigences. Elle ne doit plus être considérée uniquement comme un poste de coût, mais comme un facteur de pérennité des investissements de la société. Toutefois, quel que soit l'outil informatique sélectionné, celui-ci ne fait pas tout. Encore faut-il pouvoir en tirer des informations utiles afin d'améliorer le retour d'expérience. Il ne s'agit pas d'emmagasiner des données, encore faut-il qu'elles soient exploitables et qu'elles contiennent des informations à valeur ajoutée.

Depuis son implantation, Maximo a été grandement adapté pour correspondre à nos besoins. Cela concerne plus particulièrement le format des écrans, mais aussi de nombreux rapports additionnels par rapport au produit de base. Nous disposons maintenant d'outils d'analyse et de suivi des aspects sécurité, économiques et opérationnels de la maintenance. Il nous reste à compléter ce panel par de nouveaux produits d'analyse des résultats et de suivi de la maintenance.

Il existe plusieurs catégories de personnes intéressées par les résultats de la maintenance:

- Les experts qui rechercheront à détecter les principaux équipements à problèmes et les modes de défaillances afin d'en tirer des règles de maintenance.

- Les responsables techniques ou d'exploitation qui rechercheront les performances et des critères de qualité.

- Les gestionnaires qui voudront évaluer l'efficacité globale de la maintenance au travers des coûts.

- Les commerciaux qui voudront pouvoir présenter des résultats synthétiques aux clients et présenter les méthodes de gestion utilisées.

C'est pourquoi il est nécessaire de créer des d'outils permettant d'offrir une vue synthétique de l'état de la maintenance et de ses performances, utilisables par différents publics au sein de l'entreprise.

Il existe de nombreuses façons de représenter les données extraites d'une base de données de maintenance. Il nous faudra rechercher les plus pertinentes pour notre métier avec l'aide des différentes personnes impliquées dans le projet. Seuls des tests en réel nous permettrons de déterminer la qualité des données existantes et dans quelle mesure ces informations sont utilisables pour obtenir des informations pertinentes. A l'issue de ce projet, nous donnerons, le cas échéant des recommandations pour améliorer l'existant dans les limites du produit Maximo.

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

Introduction:

Avant de poursuivre cette étude, il convient de définir succinctement ce qu'est la TPM afin de mieux délimiter notre champ d'action. Nous limiterons cette présentation aux aspects les plus importants, car tous les domaines qu'elle englobe ne nous concernent pas.

Le concept de la TPM a été mis au point au Japon en 1970 à partir des techniques de maintenance préventive mises au point aux Etats-Unis dans les années 1950. Les premières implémentations s'effectueront vers 1960 par le groupe Nippondenso. Le JIPM (Japan Institute of Plant Maintenance) détient les brevets de la méthode et propose des prestations pour la mettre en place et la promouvoir.

Alors que la maintenance préventive concerne un nombre de plus en plus important d'agents de maintenance spécialisés, la TPM inclut aussi les opérateurs formés à la réalisation des maintenances de base. C'est ce que l'on nomme "Maintenance Autonome".

Les opérations essentielles de maintenance sont toujours effectuées par du personnel spécialisé. Ces derniers participent aussi lors de la conception pour améliorer la fiabilité des équipements dés l'origine. Ce que l'on nomme "Prévention de la maintenance".

La TPM était à l'origine plutôt un produit destiné à la production de produits à cycle de vie court, sur un marché très concurrentiel nécessitant une forte adaptabilité. Toutefois, une grande partie des règles qui la gouvernent peuvent être appliquées sur nos unités. La documentation dans ce domaine est importante, mais les interprétations sont nombreuses. Ce qui suit est une tentative de synthèse adaptée à notre cas.

La TPM est avant tout une philosophie d'entreprise devant concerner l'ensemble des acteurs de la société plutôt qu'une méthode au sens strict. Cela implique que les méthodes permettant d'atteindre les objectifs peuvent être différentes suivant les applications.

La définition de la TPM tient en cinq points:

1) Aider à créer une culture de société centrée sur l'amélioration de la productivité générale de l'outil de travail. Voir plus loin la définition de l'indicateur de performance nommé TRS. Il est aussi appelé OEE (Overall Equipment Efficiency) dans la littérature anglo-saxonne.

2) Etablissement d'un système de maintenance pour atteindre les "zéro défauts, zéro pannes, zéro accidents" durant tout le cycle de vie des équipements.

Cela inclut entre autres de mettre en place:

ü Une maintenance préventive.

ü Une maintenance d'amélioration.

ü Une meilleure conception en amont, amenant à une maintenance réduite appelée "prévention de la maintenance".

3) Participation du concepteur, des opérateurs et des services de maintenance, mais aussi les services développement, marketing et administratifs.

4) Implication complète de tous les niveaux de la hiérarchie jusqu'au sommet de la pyramide.

5) Mise en place de la maintenance préventive autonome et des cercles TPM de petits groupes autonomes.

Afin d'arriver à ses fins, la TPM repose sur la mise en place de cinq piliers:

1) Programme d'amélioration générale:

Cette partie qui concerne tous les niveaux de l'entreprise implique la détection et l'enregistrement de tous les petits détails de fonctionnement qui pourraient faire perdre une partie de la productivité à l'entreprise. On procède par l'enregistrement de l'ensemble des problèmes puis par analyse des pannes, de leur cause et leurs effets. Cela revient à:

- Enregistrer chaque défaut.

- Déterminer la proportion de chacune des sources de pertes.

- Juger des obstacles aux pertes de rendement.

- Déterminer les effets des pertes.

- Déterminer des solutions.

Elimination des sources de pertes:

L'objectif est d'éliminer les grandes causes de pertes. Il existe 6 sources de pertes:

- Pannes des équipements.

- Changements de fabrications ou réglage.

- Marche à vide ou petits arrêts.

- Vitesse réduite.

- Défauts de qualité ou retouches.

- Rendement au démarrage inférieur à la vitesse de croisière de la production.

Les pertes peuvent aussi être réparties en 3 familles et 17 causes comme suit:

Fiabilité des équipements

Organisation

méthodes et procédés

Pannes
Réglages
Pertes au démarrage

Micro arrêts

Marche à vide

Sous vitesse

Rebuts et retouches

Arrêts programmés

Temps de changement de fabrication

Activité opérateur

Déplacements et manutention

Organisation du poste

Défauts de logistique

Excès de mesures

Rendement des matériaux

Rendement énergétique

Sur consommation:

- d'outillage,

- d'accessoires

- de consommables

Table 1 Principales causes de pertes en TPM [JACQ].

Amélioration des performances des services administratifs:

Les améliorations ne concernent pas que la partie production, mais aussi les services administratifs qui doivent aussi améliorer leur efficacité en identifiant les sources de moindre performance dans la circulation d'information.

Sécurité, santé et environnement:

Le but est d'atteindre les "zéro problèmes" dans chacun des domaines. Cette partie concerne aussi les parties réglementations et certifications.

2) Mise en place de la "Maintenance Autonome":

Prise en charge d'une partie de la maintenance des équipements par les opérateurs formés pour cet objectif afin de libérer les opérateurs spécialisés pour d'autres tâches à valeur ajoutée. L'opérateur est aussi encouragé à participer à la détection des pannes en amont en utilisant ses connaissances pratiques de l'équipement. Tout défaut doit être considéré comme une honte par l'employé.

Mise en place de la méthode des 5S:

Les 5S proviennent des verbes Japonais (Seiri, Seiton, Seiso, Seiketsu, Shitsuke) que l'on peut traduire en français par: Débarrasser, Ranger, Nettoyer, Standardiser, self discipline.

Ce sont des opérations qui concernent principalement les opérateurs de la production, ceux qui effectuent la maintenance autonome.

3) Mise en place de la maintenance programmée:

On y définira programmes des différents types de maintenance:

- Préventive,

- Corrective,

- Prévisionnelle et d'amélioration,

- Les vérifications routinières incluses dans la maintenance autonome.

Il s'agit de toutes les actions qui permettent de passer de la maintenance réactive à la maintenance proactive. On parle aussi du passage du "Contrôle de la qualité" à "l'Assurance Qualité". On doit pour cela créer des marqueurs qui permettront de détecter les transitions par rapport à l'état normal de fonctionnement et de prendre des décisions.

La détection doit pouvoir être faite en ligne et permettre de catégoriser les défaillances, l'analyse des phénomènes et des causes.

Cette étape ne peut se faire sans avoir recueilli des informations cohérentes et à valeur ajoutée de la part des personnels de maintenance et des utilisateurs.

Cette étape comprend aussi la gestion des améliorations, la gestion des stocks et l'analyse et prévision des pannes.

4) Mise en place d'un programme de formation:

Le but est d'accroître les connaissances des opérateurs et du personnel de maintenance afin de mieux assurer la maintenance autonome pour les premiers et d'améliorer l'efficacité de la maintenance pour les seconds.

5) Prévention de la maintenance:

On y inclut aussi l'amélioration des équipements à la conception de façon à limiter la maintenance à posteriori. Il s'agit d'un système nommé "Prévention de la Maintenance" permettant d'agir en amont lors de la conception des équipements. Elle inclut les notions de maintenabilité, de coût de cycle de vie (LCC Live Cycle Cost) et de fiabilité.

C'est à ce niveau que devront être définis les documents de maintenance utilisables par les opérateurs et les services de maintenance: Les "Job Plans" qui décrivent les opérations de maintenance programmée et la maintenance autonome, les conditions optimales de fonctionnement et des informations de fiabilité en amont.

L'ensemble des règles de la TPM amène à édicter les règles suivantes:

1

Améliorer l'efficacité des équipements.

- Respect des conditions d'utilisation.

- Maintenance préventive.

- Amélioration des équipements.

- Formation des opérateurs.

2

Démarrage rapide des nouveaux produits ou équipements.

- Maîtrise de la conception.

3

Améliorer l'efficacité des services fonctionnels.

Les services administratifs sont engagé à:

- Simplifier leurs procédures et a diminuer le nombre de tâches.

- Fournir les moyens aux opérationnels de fournir les ressources de l'entreprise.

4

Stabiliser les 5S

- Maîtrise de la qualité.

5

Maîtriser la sécurité, les conditions de travail et l'environnement.

- Assurer les différentes certifications et réglementations.

L'objectif principal étant le "Zéro défauts":

Pour atteindre cet objectif qui peut se traduire par les deux points suivants:

1) Maintenir l'état optimal des systèmes homme machine.

2) Améliorer la qualité globale de l'unité de travail.

On peut appliquer trois principes permettant d'arriver au niveau de qualité "Zéro défauts":

1) Maintiens de l'état normal de fonctionnement des systèmes par les opérateurs. Ils doivent effectuer les opérations et vérifications routinières qui leur incombent ainsi qu'appliquer les trois premières règles des 5S (Débarrasser, Ranger, Nettoyer).

2) Découverte très tôt des problèmes de fonctionnement par les opérateurs. Ils doivent pour cela utiliser leurs connaissances des équipements et effectuer les vérifications nécessaires en utilisant les moyens de mesures adéquats.

3) Action rapide de la maintenance.

On peut encore le formuler de la façon suivante:

1) Empêcher la détérioration accélérée en maintenant l'équipement dans un état normal.

2) Maintenir l'installation en bon état.

3) Maintenir des conditions de fonctionnement correctes.

4) Améliorer la qualité de la maintenance.

5) Effectuer des réparations définitives.

6) Eliminer les faiblesses de conception.

7) Utiliser l'expérience de pannes pour améliorer l'existant.

Les indicateurs de performance:

L'outil de mesure des performances de la TPM est nommé TRS ou "Taux Rendement Synthétique" (ou encore OEE Overall Equipment Efficiency). En production, l'unité de référence est le nombre d'unités fabriquées dans un temps donné. Pour notre application, le temps semble beaucoup plus significatif, car nous faisons principalement du service. Le temps des opérations de forage ou de maintenance des puits est planifié, mais la durée réelle n'est pas uniquement fonction de la qualité de la maintenance. Il dépend aussi des problèmes rencontrés dans le puits et d'autres impondérables. Nous verrons si ce type de métrique est utilisable dans notre cas.

Le TRS est le produit de trois taux: La Disponibilité, la Performance et la Quantité. Ces taux sont tous liés à diverses pertes de temps non utilisables pour la fabrication proprement dite et non à des notions directes de coûts.

Les facteurs du TRS sont calculés comme suit (Fig.1):

Figure 1 Taux de Rendement Synthétique.

Il nous faudra déterminer si cet indicateur est utilisable dans notre domaine, car au premier abord, les paramètres sont différents de ceux de notre application.

Le calcul de ce taux repose en grande partie sur la mise en place d'indicateurs qui permettent de caractériser les pertes de la façon suivante:

- Par leur nature: "Problems".

- Par origine: "Causes".

- Par solution: "Remedies".

- Par département ou activité.

- Par classification d'équipement.

Mise en place de la TPM:

La mise en place de la TPM requiert l'implication à des degrés divers de tous les niveaux de la hiérarchie d'une entreprise.

- La direction:

Elle doit définir les objectifs et la politique de l'entreprise.

- La direction technique responsable de la maintenance:

Elle assure le contenu du programme et des moyens nécessaires pour atteindre les objectifs.

- Les cadres intermédiaires:

Ils assurent la mise en place des procédures au niveau opérationnel et effectuent les modifications nécessaires pour atteindre les objectifs.

- Les opérateurs:

Ils assurent le suivi des maintenances à leur portée technique et proposent des améliorations au cours de réunions de petits groupes de travail.

Initialisation du projet.

Description du projet:

L'outil Maximo est maintenant généralisé sur tous les chantiers de la compagnie même ceux à revenu faible. Il a prouvé son efficacité dans le domaine de la maintenance préventive. Maintenant que nous disposons d'un volume d'historiques de maintenance important, la société souhaiterait disposer d'outils d'analyse lui permettant d'avoir des marqueurs de la qualité de la maintenance effectuée. Elle souhaite aussi disposer de moyens pour détecter des problèmes et les prévenir en changeant au besoin les programmes de maintenance ou le contenu des listes d'opérations à effectuer. Rien ne permet de dire que les données actuelles permettent d'obtenir ces informations. Certaines propositions pourront être faites pour améliorer la qualité de l'information enregistrée et y ajouter le contenu nécessaire à une analyse autre que par l'examen manuel des historiques.

Objectifs:

L'objet de cette étude est de fournir les moyens d'analyse des historiques de maintenance du produit Maximo en vue d'améliorer les performances et d'optimiser la maintenance des appareils de forage de notre compagnie.

Pour cela, on se fixera plusieurs objectifs qui seront étudiés séparément:

1) Fournir des outils d'analyse quantitatifs de la maintenance au niveau opérationnel. Ce rapport aura pour nom MMR (Monthly Maintenance Report).

2) Proposer des outils d'analyse qualitatifs au niveau des équipements et définir les moyens de les mettre en place.

3) Proposer le cas échéant d'autres méthodes ou outils permettant d'ajouter de la valeur aux rapports des utilisateurs.

4) Diagnostiquer les dysfonctionnements de l'outil de maintenance et le moyen de l'améliorer.

Limites:

- On utilisera les données et de préférence les outils de Maximo pour obtenir les résultats.

- On essaiera dans la mesure du possible de se limiter aux améliorations de l'usage du produit existant.

- Il ne s'agit pas de proposer de nouvelles méthodes de maintenances, mais d'améliorer l'existant en proposant des outils de diagnostic et de nouvelles méthodes de valorisations des données.

- Dans certains cas, si les contraintes techniques sont trop grandes par rapport au temps imparti, on ne produira pas une solution finale, mais plutôt des résultats chiffrés de façon à juger de la pertinence des données et de leur intérêt. Dans ce cas, on ne préjugera pas des méthodes employées pour les obtenir.

Buts:

- Diminuer les coûts des stocks.

- Diminuer les coûts de maintenance.

- Augmenter la fiabilité et la disponibilité des équipements.

- Assurer une traçabilité de la maintenance.

- Optimiser la gestion des maintenances préventives.

- Augmenter la qualité du service.

- Améliorer les performances de sécurité et les interactions avec l'environnement lorsqu'ils sont liés avec les aspects de la maintenance.

Stratégie:

En regard du contexte de développement, nous ne pourrons pas utiliser une méthode standard (voir le chapitre des contraintes). Toutefois, nous nous inspirerons pour partie de méthodes récentes en utilisant la partie prototypage comme moteur d'avancement de certaines parties du projet.

Dans la mesure ou nous partons déjà d'une base existante et que nous ne ferons qu'utiliser des données supposées cohérentes, nous n'effectuerons qu'une phase de conception rapide issue de l'expression des besoins pour passer rapidement aux prototypes. L'utilisation des données de Maximo s'apparente plus à du "Reverse Engineering" qu'à de la conception pure.

Le prototypage offre les avantages suivants:

- Pas apprentissage de méthodes lourdes et peu adaptées à l'environnement.

- Facilite la communication avec l'utilisateur, car il décrit la future interface.

- Retour d'information plus rapide.

- On pourra utiliser le cas échéant d'autres outils que ceux fournis par Maximo.

- Cela ne préjuge pas des méthodes utilisées en interne par les développeurs.

Figure 2 Prototypage [VONK].

Les réunions d'expression des besoins ne pouvant s'organiser facilement dans un contexte dispersé comme le notre, nous procéderons par courrier électronique ou par des réunions informelles lors du passage du CPI sur les différents sites. Un compte rendu de chaque visite sera envoyé à tous les intervenants concernés pour obtenir leur analyse critique.

Seules les réunions de la base seront consignées. Pour des raisons pratiques, les idées en provenance des différents interlocuteurs des chantiers seront intégrées au niveau de ces réunions ou dans le texte de commentaire des propositions effectuées. Elles ne présenteront pas un aspect aussi formel que celles de la bases et ne pourront être consignées comme telles sans retranscription.

Faisabilité:

Le contexte de travail qui sera décrit dans un chapitre à suivre n'étant pas des plus favorables, il est possible que les délais d'obtention du produit final sortent des contraintes de temps imposé par la présentation du dossier. Le projet devra au moins pouvoir fournir des prototypes aboutis des futurs produits en particulier pour la partie quantitative. Ceux-ci seront le cas échéant transmis à des développeurs dédiés à cette fonction pour les mettre définitivement aux normes de développement de la société.

Les prototypes seront dans tous les cas suffisamment documentés pour être réutilisables. Tous les documents ayant servi au développement devront être consignés et transmirent aux services responsables de la maintenance.

Il en sera de même de toutes les branches explorées qui seront documentées même si elles n'aboutissent pas toujours à des prototypes ou à des usages immédiats.

Budget estimé:

- Les ressources matérielles existent déjà et ne nécessitent pas d'investissements complémentaires. Cela inclut les ressources en équipement informatiques, les frais de déplacement et tous frais annexes.

- Les formations seront incluses dans le budget global de formation 2004 en Angola.

On s'en tiendra à deux semaines de cours d'une valeur de: 3000usd.

- Les ressources documentaires et informatiques seront réparties sur les budgets de fonctionnement des différents chantiers. Ceci s'explique par le simple fait que la supervision ne dispose pas de budget propre.

On peut l'estimer à une licence "Maximo 4.0.3 single user", quelques ouvrages de référence et textes de normes. Le tout ne devant pas dépasser: 10000usd.

- Frais annexes non encore définis: 2000usd.

Le proposition de budget est de l'ordre de: 15000usd.

Planning prévisionnel du projet:

La durée du projet ne devra pas excéder 8 mois dans sa première étape.

Mars

Avril

Mai

Juin

Juillet

Août

Septembre

Octobre

12

24

19

19

14

14

9

8

1

Angola

Congés

Angola

Congés

Angola

(1)

 
 
 
 
 
 
 
 
 

(2)

 
 
 
 
 
 
 
 
 

(3)

 
 
 
 
 
 
 
 
 

(4)

 
 
 
 
 
 
 
 
 

(5)

 
 
 
 
 
 
 
 
 

(6)

 
 
 
 
 
 
 
 
 

(7)

 
 
 
 
 
 
 
 
 

(8)

 

Table 2 Planning prévisionnel.

1) 12 Mars réception du courrier d'acceptation du dossier par le CNAM Paris.

12 Mars au 24 Mars: Acquisition des ressources. Durée d'apprentissage du produit Maximo et des outils associés. Démarrage de l'étude de l'existant.

2) 24 Mars, réunion d'expression des besoins avec les personnes de la base Luanda.

24 Mars au 19 Avril: Développement d'un "prototype n°1" de la partie quantitative sous MS-Access afin de faciliter la visualisation des données. Validation du prototype par la base. Présentation des résultats sur certains chantiers.

3) 19 Avril, réunion d'expression des besoins avec les personnes de la base Luanda.

19 Avril, 19 Mai: Développement sous SQR "prototype n°2" de la version MS-Access. Addition des modules manquants et correction à partir des informations obtenues grâce au premier prototype.

4) 19 Mai, présentation du produit au personnel de la base Luanda. Nouvelle expression des besoins et validation de la solution.

19 Mai,14 Juin développement du "prototype n°3" à partir de l'expression des besoins.

5) 14 Juin, réunion d'expression des besoins avec les personnes de la base Luanda.

6) 14 Juin,14 Juillet développement du "prototype n°4" à partir de l'expression des besoins. Intégration dans Maximo et test en réel sur plusieurs sites. Présentation au personnel des chantiers.

7) 14 Juillet début de l'étude et développement d'éventuels prototypes concernant la partie qualitative.

8) 1 Octobre, envoi du dossier au CNAM.

Octobre 2004, présentation des résultats aux responsables de la maintenance LDA. Prises de décisions concernant l'avenir du projet et sa future implantation dans les standards du groupe.

Note: Les réunions d'expressions des besoins au niveau des chantiers ne sont pas planifiables. Elles se feront lors des passages du CPI et suivant la disponibilité des personnes.

- Le projet a été approuvé par la direction de "Pride Foramer Angola" et par le département maintenance du siège Houston en Février 2004.

- Il devra se faire en parallèle avec les autres activités de supervision de la maintenance du CPI.

- Il se fera en collaboration avec le développeur de siège social de Houston.

Engagements et lancement du projet:

Répertoire des intervenants:

La table 3 contient la liste des intervenants dans le projet. Aucun nom n'est cité volontairement dans ce qui suit, car le rythme des rotations implique une personne différente tous les mois.

Les identifiant des fonctions ne sont pas tous usuels au sein de notre compagnie. Elles ont été créées pour des raisons pratiques et seront utilisées dans le reste du document lorsque leur répétition imposerait un texte trop lourd.

Le contexte de travail des chantiers de forage pétrolier et l'aspect dispersé des différentes compétences feront qu'il ne sera pas possible de réunir ces personnes en même temps dans une salle.

- Le CPI sera le seul à pouvoir rencontrer tous les intervenants.

- La communication s'effectuera principalement par courrier électronique.

- Des réunions informelles se feront avec les chefs de services lors du passage du CPI sur les différents appareils.

- Les réunions sur la base de LDA (LUANDA) se feront lors des débuts et fins des séjours du CPI.

- La planification des réunions sera très dépendante des conditions opérationnelles.

"ID"

Fonction

Responsabilité dans le projet

HHOM

Service maintenance siège social Houston:

Ce service est responsable de la mise en place de Maximo sur les différents appareils de Pride. Elle centralise toutes les informations de maintenance et tente de généraliser les procédures.

Il validera la solution finale et suivant l'état du développement la mettra en oeuvre ou confiera la réalisation par des intervenants internes ou externes. Il pourra être consultée dans les phases intermédiaires du projet.

LDAD

Direction base Luanda:

Elle soutiendra le projet dans ses aspects financiers. Elle approuvera l'initiative et les moyens associés.

LDAO

Direction des opérations base LDA:

Elle est responsable de la partie opérationnelle des chantiers et de l'infrastructure. Il en existe une par client.

Elle proposera des solutions et validera la partie opérationnelle du projet aux différentes étapes du prototype.

LDADS

Drilling Supervisors base LDA:

Ils sont responsables de la gestion d'un chantier de forage.

Ils proposeront des solutions et valideront la partie opérationnelle du projet aux différentes étapes du prototype.

LDAM

Service Maintenance base LDA:

Il gère l'ensemble des opérations de maintenance des appareils d'Angola ainsi que les superviseurs des différentes spécialités.

Ils proposeront des solutions et valideront la partie maintenance du projet aux différentes étapes du prototype.

SM

"Site Manager":

Ils sont responsables de la gestion des opérations au niveau des chantiers pendant les opérations de forage.

Ils proposeront des solutions. Ils n'auront qu'un rôle consultatif.

TC

"Technical Coordinator":

Il coordonne les opérations de maintenance de tous les services sur les chantiers. C'est l'interlocuteur des chantiers en ce qui concerne tous les problèmes liés à l'usage de Maximo.

Ils proposeront des solutions et valideront le prototype pour les aspects liés à son usage au sein du chantier.

HOD

Head Of Department:

Ce sont les responsables du personnel de maintenance dans leur domaine (électricité, mécanique, hydraulique...).

Ils auront un rôle consultatif en ce qui concerne les éventuelles contraintes de saisie additionnelles. Ils ne sont pas concernés directement par le projet.

MCREW

Maintenance CREW:

Ce sont les équipes qui effectuent les maintenances correctives ou préventives sur les équipements. Ils sont pour certains d'eux amenés à faire la saisie des rapports dans Maximo.

On tiendra compte de leur avis pour toute modification liée à la saisie des rapports. Ils sont à même de signaler les imperfections d'un JP à leur chef de service. Ils permettront de définir les limites des écrans de saisie. Ils n'interviendront pas directement dans le projet.

MSUP

Maintenance SUPervisors:

Ce sont les personnes qui supervisent la maintenance sur les différents chantiers. Ce sont les experts dans les domaines qui les concernent.

Ils proposeront des solutions et valideront les prototypes à ses différentes étapes en particulier pour la partie qualitative.

CPI

Chef de Projet Informatique:

L'auteur de ce document.

Il effectuera:

- La conception

- L'animation des réunions d'expression des besoins.

- Le développement des prototypes.

 
 
 

Table 3 Répertoire des intervenants.

Contexte et contraintes:

Environnement:

Dans le titre de ce mémoire, nous avons pris soin de préciser dans quel contexte se ferait l'étude. En effet, il s'agit d'un milieu particulier qui engendre des contraintes spécifiques.

Tout d'abord le milieu. Il s'agit de forage pétrolier en mer sur des unités flottantes à positionnement dynamique. Ces appareils sont le plus souvent situés dans des pays en voie de développement ou la logistique est particulièrement difficile. En l'occurrence pour notre cas, en Angola qui sort d'une guerre qui a duré une vingtaine d'années. L'éloignement des côtes ne fait que compliquer les problèmes d'approvisionnement même pour les choses les plus élémentaires.

Pourtant, il règne au sein de ces unités une organisation et une rigueur importante qui seule permet de maintenir les appareils en état de fonctionnement. Cela nécessite des capacités de prévision importantes et une très bonne connaissance des équipements.

Le personnel encadrant de ces unités est de qualité, mais il doit disposer d'outils adéquats pour pouvoir faire face à tous les évènements auxquels il est confronté sans faire appel le plus souvent à des ressources extérieures. C'est là qu'intervient la gestion de la maintenance par le produit Maximo.

Cependant, pour ces personnes, l'informatique n'est pas une fin en soi. Pour eux, le travail se situe aussi bien dans les bureaux que sur les équipements. Les deux aspects étant complémentaires et ne pouvant pas fonctionner sans l'autre.

Saisir des données informatiques ne leur pose aucun problème, mais ils veulent en savoir la raison et surtout quel en sera le bénéfice direct sur leur activité. Il est parfois souhaitable d'avoir des contraintes fortes pour pouvoir imposer des projets, car la résistance est grande lorsque les objectifs ne sont pas visibles.

Dans certains cas, les données de maintenance ne sont que validées par les responsables et sont saisies par des subalternes. Les propositions d'amélioration de la saisie devront tenir compte de cet état de fait afin de ne pas imposer des travaux de relecture importants aux chefs de service.

Il conviendra de tenir compte des différents interlocuteurs intéressés par les rapports de maintenance. Suivant le point de vue où l'on se trouve, on souhaitera obtenir des informations différentes:

- Les personnes des chantiers ont une vision plutôt locale de la maintenance.

- Les superviseurs ont une vision globale, mais cherchent des outils leurs permettant de cibler leurs recherches des équipements à problèmes ou encore des améliorations à apporter à la maintenance. Ils cherchent à étendre leurs diagnostics à plusieurs unités.

- Les responsables de la base veulent se faire une opinion globale sur la qualité et l'efficacité de la maintenance. Ils veulent à partir de ces informations de synthèse pouvoir trouver des arguments pour débloquer des budgets ou des ressources.

- Les responsables de la maintenance du siège social de Houston (HHOM) cherchent à généraliser les maintenances en comparant les éléments des différents chantiers au sein du groupe.

Contexte:

Le rôle de l'auteur au sein de l'organisation lui permet de connaître toutes les unités et les responsables locaux impliquées dans les choix de maintenance ainsi que les cadres à terre. Il lui faudra synthétiser les réflexions de ces personnes chacune d'elles ayant des domaines de prédilection particuliers. Sauf avec les cadres de la base, il sera physiquement impossible de réunir les personnes concernées en même temps dans un même bureau. C'est pourquoi la communication s'effectuera principalement par courrier électronique sauf les réunions de la base LDA qui s'effectueront à chacun de ses passages à terre.

Techniques:

Il nous faudra tenir compte aussi des contraintes liées au produit Maximo. Celui-ci est très configurable, mais il nous a été demandé expressément de n'utiliser que les outils fournis par le produit Maximo. Si des modules externes devaient être ajoutés, ils devraient pouvoir être implanté dans l'environnement réseau existant et pourvoir migrer avec les versions supérieures du produit.

Dans l'immédiat, la connaissance du produit par le CPI est celle d'un utilisateur averti. Il devra se former à Maximo, son administration ainsi qu'aux outils de développement qui lui son propre.

Temps:

Il se pose aussi une contrainte de temps. En effet, sur les chantiers, nous travaillons 28 jours d'affilés suivis d'une période de congés de même durée. Ce projet n'est pas la seule activité de l'auteur. Il devra l'exécuter en parallèle avec ses autres responsabilités. Ce qui imposera des arbitrages en fonction des conditions opérationnelles.

Autres:

Il faut aussi signaler l'emploi de beaucoup de termes anglais. Cet usage est volontaire et correspond à celui de notre société. Etant une compagnie internationale, la langue parlée principale et celle des rapports sont l'Anglaise. Ce rapport sera traduit en Anglais par la suite. L'auteur n'a pas essayé de traduire tous les termes en usage en Anglais pour de simples facilités de compréhension ce qui explique une certaine pratique du Franglais qui pourrait choquer les puristes.

En résumé, l'auteur devra:

- Améliorer ses connaissances des circuits de données.

- Prendre en compte les contraintes liées aux personnes et à l'environnement.

- Se former à Maximo et à ses outils.

- Se former aux techniques de la maintenance.

- Organiser son temps de travail et arbitrer.

Analyse de l'existant.

Organisation générale de l'application Maximo:

L'application Maximo est découpée en différents modules décrits dans le schéma suivant (Fig.3). Seule la partie "Preventive Maintenance System" (PMS) fera partie de cette étude même si par la suite, les autres modules pourront en être influencés indirectement.

Dans la partie PMS, les trois modules qui nous concernent et les liens qui les unissent sont décrits par la suite en ne détaillant que les parties qui apparaissent dans un premier temps nécessaires à l'étude.

Vu la complexité de chaque module et des liens entre eux, certains points seront approfondis au fur et à mesure des étapes du prototypage et aux différentes périodes de la conception.

De même, on ne s'attardera pas à faire le reverse engineering sur la base de donnée dans la mesure ou celle-ci prés existe. On ne donnera que les détails pragmatiques nécessaires à la conception et le plus directement possible à la création du prototype.

Les écrans de Maximo sont paramétrables et adaptés à notre application. Dans ce qui suit, les copies d'écrans sont celles de ceux utilisés actuellement et non les écrans d'origine de l'application.

Figure 3 Organisation générale de Maximo.

Module "Equipment" (EQPT):

Il contient l'arborescence des équipements d'un chantier. Les équipements des chantiers ont été structurés sous forme d'arbre en partant du général vers le détail. Chaque équipement est identifié par un numéro de 9 caractères.

Les deux premiers niveaux de l'arbre sont définis une fois pour toutes par les administrateurs Maximo du siège social de Houston. Les autres niveaux peuvent être adaptés par les "Super Users" ou les "Technical Coordinator" (TC) au niveau des chantiers. Les utilisateurs normaux n'ont qu'un accès en consultation et ne peuvent en modifier la structure ni les dénominations.

Il faut noter la taille variable des différentes zones du code qui pourra complexifier toute analyse liée à cet arbre en utilisant les différentes subdivisions. Il existe aussi de nombreux exemples où cette hiérarchie n'est pas respectée et où le repérage d'un équipement dans l'arbre ne peut pas être déduit de l'organisation des chiffres qui le compose. On préférera reconstruire l'arbre à partir des données de chaque chantier en utilisant les champs EQNUM & PARENT.

Sur les appareils tels que les bateaux à positionnement dynamique, le nombre d'équipements peut aller jusqu'à 5000. Par contre, il n'est que de l'ordre du millier sur un chantier terrestre.

L'arbre des équipements est organisé comme suit:

Rig code (2 ou 3 caractères) qui correspond au code comptable du chantier.

Family (1 ou 2 caractères) 9 familles de base.

Subfamily (2 caractères) sous ensembles, Systèmes, Etc.

Equipment

(3 caractères incluant les sous équipements) équipements individuels

Equipment

Sub-Equipment

Equipment

- C'est dans ce module que sont entrées les valeurs des compteurs permettant de déclencher les maintenances préventives (PM) programmées (Meter-Based PM).

- Il maintient un historique du statut des équipements (équipement up/down). Il existe une notion d'équipement opérationnel ou non (downtime), mais le statut ne peut être modifié que dans un "Work Order" (WO).

- Il contient des informations propres à cet équipement dont certaines peuvent être utilisées pour les PM.

Structure des différentes tables associées au module EQUIPMENT:

Table: EQUIPMENT main table for the EQUIPMENT module

FIELDS

TYPE

SIZE

Name on screen

Value list/table

Comment

EQNUM

UPPER

10

Equipment

NA

 

DESCRIPTION

ALN

50

NA

NA

 

PARENT

UPPER

10

Belongs To

Drill Down

 

PARENTDESC

ALN

50

NA

NA

 

LOCATION

UPPER

8

JDE Class / Sub-Class

Location

 

LOC_DESCRIPTION

ALN

50

NA

NA

 

VENDOR

UPPER

8

Vendor

Company

 

VENDORDESC

ALN

50

NA

NA

 

MANUFACTURER

UPPER

8

Manufacturer

Company

 

MANUFACDESC

ALN

50

NA

NA

 

EQ15

ALN

16

Meter reading ?

PRUSER

 

EQ3

ALN

1

Critical Level

CRITIC

1, 2 or 3 not used

ISRUNNING

YORN

1

Up?

NA

 

ASSETNUM

ALN

30

Asset

NA

 

EQ9

YORN

1

ISM

NA

ISM flag (Y or N) , update WOEQ9 & PMEQ1 by a script if modified

STATUSDATE

DATETIME

10

Date

NA

 

SERIALNUM

ALN

15

Serial #

NA

 

CLASSIFICATION

UPPER

50

Classification

EQCLASS

 

TOTDOWNTIME

DURATION

8

Total Downtime

NA

 

TOTALCOST

AMOUNT

10

Total

NA

 

INSTALLDATE

DATE

4

Installation Date

NA

 

CHANGEBY

ALN

20

Modified By

NA

 

YTDCOST

AMOUNT

10

YTD

NA

 

PURCHASEPRICE

AMOUNT

10

Purchase Price

NA

 

CHANGEDATE

DATETIME

10

Date

NA

 

EQ16

ALN

40

Certifying Authority #

NA

 

EQ17

ALN

40

Certifying Authority

NA

 

EQ18

DATE

4

Date

NA

 

METERREADING

DECIMAL

15

Last reading

NA

In the Meters tab

READINGDATE

DATETIME

10

Last reading date

NA

In the Meters tab

AVGMETERUNIT

DECIMAL

15

Avg. Unit/day

NA

In the Meters tab

METERUNIT1

ALN

10

Meter Units

NA

In the PM module only

CLASSSTRUCTUREID

UPPER

8

Classification

CLASSSTRUCTURE

Tab "Specification"

 
 
 
 
 
 

Table: EQSTATUS history of the equipment status

FIELDS

TYPE

SIZE

Name on screen

Value list/table

Comment

EQNUM

UPPER

10

NA

NA

 
WONUM

UPPER

10

NA

NA

 

ISRUNNING

YORN

1

NA

NA

Y or N

CHANGEDATE

DATETIME

10

NA

NA

 

CHANGEBY

ALN

20

NA

NA

Login user name

DOWNTIME

DURATION

8

NA

NA

 

CALNUM

UPPER

8

NA

NA

 

LDKEY

INTEGER

4

NA

NA

Link to long description

CODE

UPPER

8

NA

NA

 

OPERATIONAL

YORN

1

NA

NA

Y or N no more used

LOCATION

UPPER

8

NA

NA

 
 
 
 
 
 
 
 
 
 
 
 
 

Table 4 Tables du module EQUIPMENT.

Ecran principal du module EQUIPMENT:

Cet écran contient les informations générales concernant un équipement (Fig.4). Il contient aussi un certain nombre d'informations propres à certaines certifications.

Figure 4 Fenêtre principale du module EQUIPMENT

Les champs qui pourraient être utiles pour l'étude sont les suivants:

- Le champ ISM: Ce champ à Y spécifie un équipement de sécurité critique pour la certification ISM du navire. Cette certification est nécessaire pour l'obtention du certificat de navigabilité du navire. Ce champ n'est accessible à aucun des utilisateurs des chantiers. Il est renseigné par les administrateurs du siège de Houston.

- Le champ "Critical Level": Ce champ n'est pas utilisé, mais possède trois niveaux de criticité. Il n'existe pas de règle d'usage.

- Le champ "Classification": Ce champ qui devrait contenir la classification de type d'équipement n'est pas utilisé la majorité du temps (80% ne sont pas renseignés). La table prédéfinie contient 23 valeurs qui seront décrites plus loin.

- Le champ "Up ?": Qui spécifie si l'équipement est fonctionnel ou non. Il ne peut être mis à jour que par l'intermédiaire d'un "Work Order" (WO). Chaque changement de statut est enregistré dans la table EQSTATUS. Les champs "Date" et "Total Downtime" sont des champs calculés à partir des informations de changement d'état du WO.

Les champs "Certifying Authority" de la zone "Certification" ne sont que des zones de texte. Il n'existe pas de règles de remplissage. Ce sont des informations qui concernent les certificats spécifiques à un équipement et les dates de renouvellement au format date.

Onglet "Meters" du module EQUIPMENT:

Figure 5 Onglet "Meters" du module EQUIPMENT

C'est dans cet écran (Fig.5) que sont entrées les valeurs de compteurs permettant de déclencher les Maintenances Préventives (PM) basées sur les compteurs se trouvant sur les équipements. On entre la valeur du compteur directement dans le champ "New reading" ou le delta par rapport à la dernière mesure dans "Reading Delta". La date du jour de la saisie est automatiquement entrée dans "New reading date".

Les champs "Last reading", "Last reading date" et "Avg. Units/Day" sont mis à jour à partir des valeurs entrées dés que l'on sauvegarde les données. Après la sauvegarde, les champs "New reading", "Reading Delat" et "New reading date" sont mis à blanc.

Si une maintenance préventive (PM) est utilisée pour cet équipement, les champs "Meter Readings" associés du module PM sont mis à jour.

Onglet "Specification" du module EQUIPMENT:

Figure 6. Ecran "Specification" du module EQUIPMENT.

L'écran (Fig.6) de cet onglet n'est pas utilisé dans notre version actuelle, mais il contient les "Classification" et "Subclassification" des équipements. Les éléments caractéristiques de l'équipement sont définis pour chacune de ces classes et sous classes. La table contenant la description de la hiérarchie est nommée CLASSSTRUCTURE. Actuellement, les caractéristiques des équipements sont entrées dans la "Long description" en texte libre ce qui limite les comparaisons entre chantiers.

Le champ classification des équipements se trouvant dans l'écran principal du module équipement n'a pas de lien avec celui-ci et les données ne sont pas extraites de la même table, mais de la table VALUELIST décrite plus loin.

Module "Preventive Maintenance" (PM):

Ce module contient les informations permettant de générer les "Work Order" (WO) des maintenances programmées par le temps ou par les compteurs. Les PM sont créées sur les chantiers par un "Super User" en l'occurrence le TC sur les chantiers. La génération devrait se faire tous les 15 jours. En pratique, elle est effectuée toutes les semaines.

Chaque PM est associée à un ou plusieurs Job Plan (JP) et à un seul équipement (EQPT).

Structure des différentes tables associées au module PM:

Table: PM main table of the preventive maintenance module

FIELDS

TYPE

SIZE

Name on screen

Value list/table

 

PMNUM

UPPER

8

PM

NA

 

DESCRIPTION

ALN

50

NA

NA

 

EQNUM

UPPER

10

Equipment

Drill Down

 

EQDESCRIPTION

ALN

50

NA

NA

 

ROUTE

UPPER

8

Route

NA

 

ROUTEDESCR

ALN

50

NA

NA

 

JPNUM

UPPER

10

Job Plan

NA

Only if no JP sequence

JPDESCRIPTION

ALN

50

NA

NA

 

PMJP1

UPPER

8

Lead Craft

NA

 

WORKTYPE

UPPER

50

Work Type

Work Type Option

 

STORELOC

UPPER

8

Storeroom

Select Storeroom

 

CREWID

ALN

8

Crew

CREWID

 

PMJP4

ALN

20

Sub Work

NA

 

PMEQ1

YORN

1

ISM

NA

EQ9 in PM, WOEQ9 in WO

FREQUENCY

INTEGER

10

Frequency

 

Time based

FREQUNIT

UPPER

8

Frequency Units

 
 

METERFREQUENCY1

DECIMAL

11

Frequency

 

Meter based

LASTMETERREADING1

DECIMAL

8

Reading at last WO

 
 

LASTMETERDATE1

DATETIME

10

Date of last WO

 
 

FIRSTDATE

DATE

4

First Start Date

 
 

LASTSTARTDATE

DATE

4

Last Target Start Date

 
 

LASTCOMPDATE

DATE

4

Last Completion Date

 
 

USETARGETDATE

YORN

1

Use Target Date

 
 

EXTDATE

DATE

4

Extended Date

 
 

ADJNEXTDUE

YORN

1

Adjust Next Due Date

 
 
 
 
 
 
 
 
 
 
 
 
 
 

Table 5 Tables du module PM.

Ecran principal des PM: (Fig.7)

- Le champ "Lead Craft" provient du "Job Plan" (JP). Il est copié dans le champ correspondant du WO généré. Ce champ est obligatoire. Il est issu d'une liste de valeurs prédéfinie.

- Le champ "ISM" provient du module EQPT. Il est Y ou vide (= N).

- Le champ "CMS" (Continuous Machinery Survey) indique un équipement pouvant être certifié par l'intermédiaire d'un processus dit de maintenance continue de l'équipement qui permet d'éviter des tests complets lors des inspections de certifications par DNV. Il sera mis en service dans une prochaine version à paraître en fin 2004 et sera positionné sous le champ ISM.

- Le champ "Worktype" contient l'état initial des PM générées. Il est toujours positionné à WSCH.

- Le champ "Crew" contient l'équipe qui sera copiée dans le WO généré. Ce champ n'est pas obligatoire. Il est sélectionné dans une liste de valeurs prédéfinie.

Figure 7 Ecran principal du module PM

Ecran "Frequency" des PM: (Fig.8)

Cet écran contient toutes les informations nécessaires pour la planification des maintenances préventives.

Figure 8 Onglet "Frequency" du module Preventive Maintenance.

Il existe deux types de méthodes de planification des maintenances situées dans les deux zones correspondantes de l'écran:

- Time-Based: Est la planification par le temps.

Les champs "Frequency" et "Frequency Unit" permettent de définir la périodicité de la maintenance. Le premier est un nombre entier représentant le nombre d'unité de temps. Lorsqu'il est à 0, la PM n'est pas planifiée par le temps. Le second qui correspond à l'unité de temps peut prendre les valeurs: YEARS (365 jours), MONTHS (30 jours) , WEEKS ou DAYS.

La valeur "Next Due Date" est un champ calculé à partir des valeurs de dates contenues dans la zone "Work Order Generation Information". Il est calculé comme suit (Table 6):

Use Target Date

Adjust Next Due Date

Extended Date Exists

Next Due Date

Y

Y

Y

Extended Date + Frequency

Y

N

Y

Last Target Start Date + Frequency

N

Y or N

Y

Last Completion Date + Fequency

Y

N/A

N

Last Target Start Date + Frequency

N

N/A

N

Last Completion Date + Fequency

Table 6 Table de calcul pour les maintenances basées sur le temps.

Note: Si le champ "Use Target Date" est à N, cela indique que la prochaine maintenance sera effectuée à partir du moment de fermeture du "Work Order" qui la concerne. Dans ce cas, le champ "Next Due Date" ne peut être calculé et reste à blanc tant que le "Work Order" n'est pas fermé.

- Meter-Based: Est la planification par les compteurs se trouvant sur les équipements.

Ces compteurs peuvent avoir différentes significations suivant le type d'équipement. Toutefois, dans notre application, cela ne représente que des heures de fonctionnement. Ce type de maintenance est lié au module EQUIPEMENT ou sont entrées les valeurs des compteurs des équipements concernés par ce type de PM.

Le champ "Frequency" est le nombre d'unités de comptage entre deux générations de PM. Les unités de comptage sont celles que mesurent les compteurs des équipements. Sur nos unités, il s'agit d'heures. S'il est blanc ou 0, il n'y a pas de planification par le temps.

Le champ "Avg.Meter Unit/Day" provient de la table équipement. Il s'agit de la valeur moyenne des comptages effectués par jour. Elle est mise à jour au fur et à mesure que l'on entre les valeurs des compteurs dans le module équipement.

Le champ "Reading at last WO" est copié de la table EQUIPEMENT chaque fois qu'un WO est généré.

Le champ "Date of Last WO" est copié de la table EQUIPEMENT chaque fois qu'un WO est généré. Il correspond à la date de la lecture de la dernière mesure.

Les champs "Estimate next reading" et "Estimate Next Due Date" sont des champs calculés. Ils correspondent respectivement à l'estimation de la valeur de la mesure à la date estimée de la génération de la prochaine PM. Ces deux champs sont mis à jour au fur et à mesure que l'on entre des valeurs de compteurs dans le module équipement.

Les champs "Estimate next reading" et "Estimate Next Due Date" sont calculés comme suit (Table 7):

S'il y a eu un enregistrement de compteur dans le module EQPT depuis que le WO a été généré par la PM:

 

Equipment Meter 1 Last Reading Date +

PM Meter 1 Freq - (Equipment Meter 1 New Reading - PM Meter 1 Reading at Last WO)

PM Meter 1 Average Units per Day

S'il n'y a pas eu d'enregistrement de compteur dans le module EQPT depuis que le WO a été généré par la PM:

 

Si Use Target Start = Y

PM Last Target Start Date + (PM Meter 1 Frequency / PM Meter 1 Avg. Units per Day)

 

Si Use Target Start = N

PM Last Completion Date + ( PM Meter 1 Frequency / PM Meter 1 Avg. Units per Day)

Table 7 Table de calcul pour les maintenances basées sur les compteurs.

La zone "Work Order Generation Information" contient les informations de planification des PM des deux types.

- Le champ "First Start Date". Date de démarrage de la planification de cette PM par le temps. La planification par le temps ne démarre que si une valeur existe dans ce champ.

- Le champ "Last Target Start Date" date à laquelle le WO généré par la PM était prévu de démarrer.

- Le champ "Last Completion Date" contient la date de fermeture du dernier WO créé par cette PM.

- Le champ "Use Target Start" lorsqu'il est à N indique que la planification ne se fera qu'à partir de la date de clôture du WO (Last Completion Date) et non à la date prévue par le système. Dans ce cas, toute la planification est décalée dans le temps. Lorsqu'il est à Y, il impose une planification stricte dans le temps et peut dans une certaine mesure accroître le nombre de maintenance en retard (overdue).

- Le champ "Sequenced" indique si la PM utilise une séquence dans le JP qui lui est associé. Le "JP sequence" est une technique permettant de séquencer plusieurs JP au fur et à mesure de leur planification. Cette option n'est pas encore implémentée et l'on considérera que l'on n'a qu'un et un seul JP par PM.

- Le champ "Counter" indique le nombre de PM effectuées depuis "First Start Date".

- Le champ "Use Frequency for Scheduling" indique si le système de hiérarchie des PM sera utilisé ou non lorsque les critères de déclenchement de la PM seront atteints. Cette option n'est pas encore implémentée.

Note: Les notions de JP séquence et de PM hiérarchie serons implémentés dans la nouvelle révision à paraître en fin 2004.

La zone "Override Due Date" contient les informations permettant de décaler une PM dans le temps.

- Le champ "Extended Date" contient la date à laquelle la PM aura lieu. Il ne s'applique qu'à la PM courante et non plus à sa hiérarchie. Il est remis à blanc dés que la PM a été générée. Ce champ est en lecture seule si "First Date" ou "Next Due Date" est vide. Il remplace la valeur de "Next Due Date" par celle de "Adjust Next Due Date" lorsque les conditions sont remplies.

- Le champ "Adjust Next Due Date" n'est accessible que si une valeur est entrée dans "Extend Date". Il doit être à Y pour que cette date soit prise en compte. Il est mis à blanc dés que la PM a été générée.

Module "Job plan" (JP):

Un JP est une liste d'instructions qui décrivent les opérations à effectuer lors des opérations de maintenance préventive. Dans certains cas, ils peuvent aussi s'appliquer aux maintenances correctives.

- Les JP sont majoritairement créés par les superviseurs ou par les HOD des chantiers.

- Les JP sont idéalement communs à l'ensemble des chantiers de la compagnie même si dans la pratique, la plupart sont spécifiques à un chantier.

- Toute création d'un JP doit être faite par l'intermédiaire d'un formulaire spécifique. Les JP sont ensuite validés par les TC ou HOD des autres chantiers de la région possédant le même équipement s'il en existe. La version définitive est transmise au service maintenance de la base LDA qui le transmet au service maintenance de Houston pour approbation.

- Les mises à jour des JP ne peuvent être effectuées que par l'intermédiaire d'un programme de mise à jour en provenance des administrateurs de Maximo au siège social de Houston.

- La majorité des JP sont proposés par les chantiers et adaptés à leurs équipements sauf s'il s'agit d'équipements génériques pour lesquels il existe déjà des JP au niveau du groupe.

Module "Work Order Tracking" (WO):

Ce module permet le suivi des WO des maintenances préventives (PWO) générées par le module PM ou encore les WO de maintenances correctives (CWO) créées par l'utilisateur. Il maintient un historique de l'état des WO pendant leur cycle de vie.

C'est dans les menus des WO que l'on peut définir si un équipement est opérationnel ou non (downtime). Le statut de l'équipement est reporté dans la table EQSTATUS des historiques du module équipement.

Définition des différents types de maintenances:

Même si d'autres types de maintenances existent dans Maximo, seuls deux types de maintenances sont utilisés dans notre application.

- Maintenance Préventive (PM):

Il s'agit d'une maintenance planifiée dans le temps ou par l'intermédiaire de compteurs se trouvant sur les équipements. Elle a pour objectif de réduire la fréquence des dysfonctionnements d'un équipement. A chaque maintenance sont associés des "Job Plan" qui correspondent à une liste d'opérations à effectuer. La maintenance préventive permet de faire des visites de routines, des mesures ou de remplacer des pièces d'usure ou des consommables. Lorsqu'une panne est détectée pendant ces opérations, elle doit faire l'objet d'une maintenance corrective. Une pièce est remplacée au cours de la PM lorsque la probabilité qu'elle soit dégradée avant la prochaine maintenance programmée est trop grande.

Le fait que ces maintenances soient programmées doit permettre de faire les approvisionnements à temps avant qu'elles ne soient déclenchées.

- Maintenance Corrective (CM):

Il s'agit de toutes les maintenances non programmées déclenchées par la défaillance d'un équipement. Elle comprend le diagnostic, la réparation et les tests de remise en service. Dans la mesure où par nature elles ne sont pas prévisibles, les pièces nécessaires à la réparation peuvent ne pas être disponibles (WMATL) ou les conditions opérationnelles adéquates pour pouvoir les réaliser (WOPCOND).

Toutes les activités correctives devraient être enregistrées dans le système afin d'en conserver un historique nécessaire pour améliorer les maintenances.

Structure des différentes tables associées au module WO:

Table: WORKORDER main table of the Work Order module.

FIELD

TYPE

SIZE

Name on screen

Value list/Table

 

WONUM

UPPER
10
Work Order

NA

 

DESCRIPTION

ALN

50

NA

NA

Free for the CWO, from PM for PWO

WOPRIORITY

INTEGER

4

WO Priority

WOPRIOR

 

EQNUM

UPPER

10

Equipment

Drill Down

 

EQDESCRIPTION

ALN

50

NA

NA

Linked to EQNUM

ISRUNNING

YORN

1

Equipment Up?

NA

 

STATUS

UPPER

50

Status

WOSTATUS

 

REPORTDATE

DATETIME

10

Reported Date

NA

 

WOEQ9

YORN

1

ISM

NA

Necessary for ISM certification

EQ9 in EQPT, PMEQ1 in PM

WO1

ALN

20

MR N°

NA

Material request(s) number, free text

STATUSDATE

DATETIME

10

Status Date

NA

 

WORKTYPE

UPPER

50

Work Type

Work Type Opt

 

WOJP3

ALN

1

API RP 8B

NA

 

WO3

YORN

1

Print this WO in the end of Trip report

NA

 

WOJP4

ALN

20

Sub-Work Type

NA

 

JPNUM

UPPER

10

Job Plan

Select Job Plan by Work Asset

 

SAFETYPLAN

UPPER

8

Safety Plan

NA

 

FAILURECODE

UPPER

20

Failure Class

NA

Not used

ORIGINWO

 
 

Originating WO

NA

 

PMNUM

UPPER

8

PM

NA

 

PROBLEMCODE

UPPER

20

Problem Code

NA

Not used

HASFOLLOWUPWORK

YORN

1

Has Follow-up Work?

NA

 

ACTSTART

DATETIME

10

Start Date

NA

 

ACTFINISH

DATETIME

10

Finish Date

NA

 

WO7

ALN

18

Reported By

NA

 

WO2

DURATION

8

Meter reading

NA

 

REMDUR

DURATION

8

Duration

NA

 

WOJP1

UPPER

8

Lead Craft

Leadcraft

In fact department

WO6

ALN

4

% Completion

PERCOMP

 

CREWID

ALN

8

Crew

CREWID

 

SUPERVISOR

UPPER

8

Supervisor

LABOR

 

CHANGEBY

ALN

20

By

NA

Login username

CHANGEDATE

DATETIME

10

Date

NA

 

WOJP1

UPPER

8

Lead Craft

LEADCRAFT

 
 
 
 
 
 
 

Table: WOSTATUS status history of the WO (can be seen in "Action", "View WO status")

FIELD

TYPE

SIZE

Name on screen

Value list/Table

 

WONUM

UPPER

10

Work Order

N/A

 

STATUS

UPPER

8

Status

WOSTATUS

 

CHANGEDATE

DATETIME

10

 

N/A

 

CHANGEBY

UPPER

18

By

NA

Login user name

MEMO

ALN

50

 

NA

 

GLACCOUNT

ALN

20

 

NA

 
 
 
 
 
 
 

Table: MATUSETRANS History of the stock consumptions of the WO.

FIELD

TYPE

SIZE

Name on screen

Value list/Table

 

WONUM

UPPER

10

Work Order

NA

 

EQNUM

UPPER

10

Equipement

Drill Down

 

LINECOST

AMOUNT

10

Line Cost

NA

 
 
 
 
 
 
 

Table 8 Tables du module "Work Order".

Ecran principal du module "Work Order": (Fig.9)

- Le champ "Work order" contient un numéro en 10 chiffres uniques. Il est automatiquement généré soit lors de la génération des maintenances préventives dans le module PM ou encore lorsque l'utilisateur crée une maintenance corrective dans le module WO. Le texte sur la droite du numéro de MR est celui du module PM pour les maintenances préventives. Il est entré par l'utilisateur pour les correctives. Dans le même champ, en cliquant sur un onglet, on peut entrer ce qui est nommé une "Longue description". Cette description doit contenir les informations détaillant les opérations effectuées lors de la maintenance. Elle contient le texte "job done as per job plan nothing abnormal to report" lorsque la PM vient juste d'être générée et se trouve dans l'état WSCH.

- Le champ "Equipment" provient de la PM qui a généré le "Work Order" pour les maintenances préventives. Il est entré par l'utilisateur pour les correctives. Dans ce cas, il est de l'initiative de l'utilisateur de sélectionner ou non une branche détail ou non de l'arbre des équipements. Cela implique que les historiques des maintenances correctives peuvent se trouver à différents niveaux de l'arbre pour une même maintenance faite par un utilisateur différent.

- Le champ "Status" sera explicité plus loin. Le champ "Status date" est renseigné lorsque l'on change le statut d'un WO. Le champ "Reported date" est la date de création du WO.

- Le champ "MR N°" est un champ texte libre, mais il devrait contenir des informations relatives aux requêtes de matériel (MR) faites lorsque le statut du WO est en WMATL.

- Le champ "Work type" ne devrait être que PM ou CM pour maintenances préventives et correctives. Il existe d'autres états disponibles, mais qui ne devraient pas être utilisés dans notre application. Ils seront ignorés par la suite.

- Le champ "Equipement Up?" est à Y lorsque l'équipement est opérationnel, il est à N dans le cas contraire. Il est issu du module PM. Par contre, son statut ne peut être changé que dans un WO à l'aide des menus: "Action", "Report downtime" pour un passage de Y à N ou réciproquement ou encore dans "Action", "Equipement eqpt Up/Down status" après coup lorsque l'action est passée. Dans le premier cas, on ne devra pas oublier de passer l'équipement "Up" avant de fermer le WO. Dans le second, on indique le début de l'état "Down" et la date de retour à l'état "Up". Dans les deux cas, le statut de l'équipement est enregistré dans l'historique des équipements.

Ce champ devrait être utilisé à chaque fois qu'un équipement n'est plus opérationnel.

- Le champ "ISM" principalement utilisé pour les PM signifie que la maintenance est nécessaire à la certification ISM. Il est lié à l'équipement choisi dans le WO.

Figure 9 Ecran principale du module Work Order.

La zone "Job details" indique les numéros de PM et de "Job Plan" utilisés lorsqu'il s'agit d'une PM uniquement. Toutefois, rien n'interdit d'utiliser le champ JP pour une CM.

La zone "Problem" n'est pas utilisée et aucune valeur n'est proposée. L'arborescence des "Problems/Causes/Remedies" devrait être entrée dans le module "Failure code" pour apparaître à cet endroit.

La zone "Scheduling information" contient des informations relatives aux travaux exécutés:

- "Start date" et "Finish date" correspondent aux dates de début et de fin des travaux. Cela peut représenter la période d'indisponibilité des équipements, mais pas la durée des travaux surtout lorsque les travaux sont effectués en plusieurs fois.

- Le champ "Duration" doit indiquer la durée effective des travaux (man-hours). En pratique, il indique le plus souvent la durée des travaux par manque d'information. La tendance va vers un remplissage correct.

- Le champ "% completion" indique le pourcentage de travaux effectué. En pratique, il ne sert que lorsqu'il est à 100% pour indiquer au chef de service qu'il peut passer l'état à COMP après vérification du contenu du WO. Il n'est pas souvent mis à jour sauf parfois lors des changements d'état des WO. Toutefois, la tendance récente est à la mise à jour.

- "Meter reading" et "Estimated duration" ne sont que des indications concernant les compteurs lorsque l'appareil en dispose et du temps estimé pour les travaux.

La zone "Responsability" permet d'indiquer les personnes responsables des travaux:

- "Reported by" contient le nom de la personne ayant fait les travaux. Il s'agit d'un texte libre.

- "Lead craft" est issu de la table prédéfinie "LEADCRAFT". Il désigne le responsable du site ou s'effectuent les travaux.

- "Crew" est issu de la table prédéfinie "CREWID". Il indique l'équipe effectuant les travaux.

- "Supervisor" est issu de la table prédéfinie "LABOR". Il indique la personne qui supervise les travaux.

Ces trois derniers champs seront décrits plus loin dans le chapitre relatif aux tables prédéfinies.

La zone "Modified" indique par qui a été modifié le WO la dernière fois ainsi que la date de la dernière modification. Le champ "By" est issu du "Username" lors du "Login" sur la base. Il peut toutefois être changé sans contrôle de la valeur. Les WO CLOSE devraient tous l'être pas le TC, les COMP par les chefs de service.

Ecran de l'onglet "Actual" du module "Work Order":

Cet écran est utilisé pour entrer les pièces du stock consommées durant les opérations de maintenance préventive ou corrective. Les informations sont ensuite stockées dans la table MATUSETRANS. L'information qui nous concerne est le champ "Line Cost" qui contient le coût total en USD de chaque ligne de chaque élément consommé dans le WO. Il pourra nous servir à calculer la partie financière des rapports.

La signification de chaque état d'un "Work Order" est la suivante: (Table 9)

Signification

Abréviation

Détail

Wait for APPRoval

WAPPR

Il s'agit de l'état initial d'un "Work Order" de maintenance corrective (CWO). Sa date de création n'a pas toujours de lien avec la date réelle de découverte d'un problème même si l'on tend à la faire correspondre.

Wait on SCHedule

WSCH

Il s'agit de l'état initial d'un "Work Order" de maintenances préventives (PWO) après leur génération par le "Technical Coordinator" (TC) dans le module PM. Il s'agit de l'état initial indiqué dans le champ "Work Type" de la PM correspondante. Ce champ est toujours à WSCH dans notre application. Dans la mesure où les PWO sont générées de 1 semaine à 15 jours avant leur échéance, la date de création peut être antérieure à la date de déclenchement.

APPRoved

APPR

Cet état n'est pas utilisé dans notre application. S'il était utilisé, il servirait à mobiliser les ressources de stock de pièces, de personnel et d'outils.

IN PRoGess

INPRG

Il indique que les travaux correspondants au WO sont lancés. Il est le résultat de l'action INITIATE dans les menus. Il devrait correspondre à la date de départ des travaux.

Waiting for OPerating CONDitions

WOPCOND

Cet état indique que le WO ne peut être exécuté faute de conditions opérationnelles adéquates.

Wait for MATeriaL

WMATL

Cet état indique que l'on ne dispose pas des pièces de rechange nécessaires pour effectuer la réparation. On y associe le plus souvent un numéro de requête de matériel dans le champ "MR N°" (Material Request Number).

COMPlete

COMP

Il devrait suivre le passage du champ "% Completion" à 100%. Indiquant au chef de service (HOD) que les travaux ont été terminés par les équipes de maintenance. Le WO doit dans ce cas être complètement rempli et vérifié par le HOD. Les champs commentaire, "Duration" et les dates de début et de fin renseignées.

CLOSE

CLOSE

C'est l'état qui suit COMP. Le "Technical Coordinator" (TC) passe le WO dans cet état après vérification de son contenu et que tous les champs soient correctement renseignés. Il est le seul à pouvoir passer le WO dans cet état. Lorsque des informations manquent, le HOD devra reprendre le WO et le corriger.

Cancel

CAN

Work Order annulé par l'utilisateur.

Les cas d'annulation de PM doivent être rares et justifiés surtout s'il s'agit d'équipements de type ISM.

HISToric EDIT

HISTEDIT

Ce champ n'apparaît pas directement dans la liste des états disponibles aux utilisateurs. Il est toutefois noté dans le fichier historique des statuts des WO. Il indique qu'un WO a été modifié après sa fermeture par le TC. Celui-ci est le seul à pouvoir le faire.

 
 
 

Table 9 Tables des états d'un "Work Order".

Le schéma de passage entre les différents états d'un WO: (Fig.10)

Figure 10 Work Order statut.

Chaque type de WO suivant qu'il soit correctif ou préventif peut prendre différents états. Le schéma de passage d'un état à l'autre est défini non seulement par le progiciel, mais aussi par des règles organisationnelles.

Les règles de passage entre états imposées par le progiciel sont décrites dans le schéma précédent (Fig.10).

Les états intermédiaires WAPPR et WSCH sont les états de départ respectifs des maintenances correctives et préventives. Les états intermédiaires APPR et INPRG sont des états dont la fonction n'est pas claire et reste à définir dans notre organisation. La logique voudrait que les états WSCH et WAPPR aboutissent à INPRG sans passer par APPR qui n'a pas d'application dans notre organisation.

Il faut noter qu'il n'existe pas toujours de lien temporel entre la date de passage dans un état particulier et sa réalisation pratique sur le terrain. Cela pourrait compliquer singulièrement l'utilisation des dates pour faire des calculs qualitatifs sur les équipements.

Les règles de passage d'un état à l'autre sont figées par le système, mais elles correspondent au schéma suivant en terme d'organisation: (Fig.11)

Figure 11 Diagramme "Work Order tracking".

Schéma relationnel des tables principales:

Figure 12 Schéma relationnel des principales tables.

Détails de quelques tables près définies:

Maximo contient un certain nombre de tables prédéfinies servant à contrôler les entrées de certains champs.

Ces deux tables montrent l'ambiguïté de certaines d'entre elles. La première LEADCRAFT représente la personne responsable du site et l'autre, CREWID indique quel département effectue le travail. La nuance est parfois subtile et peu utilisée sur les chantiers sinon incomprise la majorité du temps.

LEADCRAFT
 
CREWID
CE
Chief Electrician
 

BOP

Sub Sea Department
RM
Rig Mechanic
 
DRILL
Drilling Department
HYD
Hydraulic Man
 
ELE
Electric Department
BOP
Sub Sea Engineer
 
MAR
Marine Department
ENG
Chief Engineer
 
MEC
Mechanical Department
STP
Senor Tool Pusher
 
SAF
Safety Department
MAR
Barge Master
 
HYD
Hydraulic Department
CM
Chief mechanic
 
ENG
Engine department
SAF
Safety Officer
 
MAT
Material Man Department
 
 
 
 
 

Table 10 Contenu des tables prédéfinies LeadCraft & CrewID.

Il faut aussi noter que les valeurs RM, MEC et CM représentent la même personne. Il en est de même entre HYD et BOP ainsi que CE et ELE. Ces listes seront simplifiées dans une prochaine version.

Certaines valeurs prés définies des écrans Maximo se trouvent dans la table VALUELIST.

C'est le cas pour le champ "Classification" du module équipement. On les retrouve en sélectionnant le champ LISTNAME=EQCLASS. Cette liste pourra nous être utile pour classer les taux de défaillance par type d'équipement.

VALUE

VALDESC

 

VALUE

VALDESC

ACMOTORS

AC Motors

 

HYDMISC

Hydraulic Miscellaneous

AIRDRYER

Air Dryer

 

MARMISC

Marine Miscellaneous

AIRRCVR

Air Receiver

 

MECMISC

Mechanic Miscellaneous

ALTERNAT

Alternator

 

MOTORS

Motors

COMPRESS

Compressors

 

MUDTREAT

Mud Treatment

COOLING

Cooling System

 

PUMPS

Pumps

DCMOTORS

DC Motors

 

SAFETY

Safety

DRILLEQT

Drilling Equipment

 

SUBSEAEQT

Sub Sea Equipment

DRILLINST

Drilling Instrumentation

 

TANK

Tank

ELEMISC

Electrical Miscellaneous

 

VALVES

Valves

HOISTEQT

Hoisting Equipment

 

WINCHES

Winches

HVAC

Heating/Ventilation/Air Cond

 
 
 

Table 11 Valeurs prédéfinies du champ "Classification".

Lorsque l'on rapporte un "Down time", il est possible d'indiquer un "Down time code ". Ce code permet de caractériser l'opération ayant occasionné l'arrêt. Les codes se trouvent dans la table VALUELIST en sélectionnant le champ LISTNAME= DOWNCODE.

VALUE

VALDESC

 

VALUE

VALDESC

01

Fishing operations

 

07

Marine repair

02

Downtime operator

 

08

Subsea repair

03

Waiting on weather

 

09

Engine repair

04

Drilling repair

 

10

Preventive maintenance

05

Mechanical repair

 

11

Other

06

Electrical repair

 
 
 

Table 12 Downtime codes.

Schéma d'interconnexion entre modules:

Les informations des différents modules sont entrées suivant une certaine organisation. Sans entrer dans les détails opérationnels qui parfois différent singulièrement de la logique dans laquelle cela devrait fait, nous détaillerons les différents modules et leurs interconnexions dans la (Fig.13). Nous ne rentrerons pas à nouveau dans la description de chaque module, car ils ont été décrits plus haut dans les chapitres précédents.

- L'arborescence des équipements est créée lors de l'implantation de Maximo sur un chantier à partir des listes des matériels installés. Elle peut ensuite être adaptée au sein du chantier par le "Technical Coordinator" (TC) en fonction du remplacement d'un équipement ou de sa disparition.

- Chaque équipement possède un certain nombre de documentations qui permettent de définir les "Job Plans" (JP) des maintenances de base. Il existe des JP types définis au sein du groupe pour des mêmes types d'équipements, les autres seront créés la plupart du temps par les superviseurs de chaque spécialité ou à défaut par les personnes du bord, en général les chefs de services (HOD).

Dans tous les cas, toute création ou modification d'un JP passe par une phase d'approbation par les gestionnaires de la maintenance à Houston. Les JP ne peuvent être implantés que par l'exécution d'un programme utilisant des données en provenance du service maintenance de Houston.

- Un JP doit être associé à une maintenance préventive (PM) pour être visible au niveau des opérateurs de maintenance. Chaque PM est associée à un unique équipement et à un JP (parfois plusieurs dans le cas de JP séquences, cette partie n'étant pas utilisée dans l'immédiat, elle ne sera pas traitée). Les experts définiront les fréquences et le type de planification des maintenances dans un premier temps à partir des informations des constructeurs et pourront les adapter suivant les informations complémentaires dont ils disposent.

Figure 13 Diagramme de retour d'expérience dans Maximo.

Le retour d'expérience agit principalement sur le contenu des opérations de maintenance préventive à exécuter décrites dans les JP ou encore, sur la fréquence des PM.

Il peut s'effectuer par différents moyens:

è Adaptation afin de les faire correspondre aux réalités du chantier ainsi qu'en fonction des expériences acquises sur l'équipement.

è Examen des historiques des maintenances correctives et des anomalies apportées.

è Examen de l'historique des maintenances préventives et des paramètres qui s'y trouvent lorsqu'il s'agit de mesure, de notion d'usure ou de toute autre information pertinente.

è Apport extérieur de l'avis des superviseurs avec une vision plus large du même équipement sur d'autres chantiers.

è Apports des constructeurs sous forme de modifications d'améliorations ou de nouvelles recommandations.

Rapports existants:

Chacun des modules décrits précédemment est associé à des rapports permettant leur suivi. Même si chacun de ces rapports présente un intérêt dans son domaine, aucun de ces rapports ne contient d'informations permettant de faire une analyse quantitative ni qualitative de la maintenance effectuée.

Rapport

Module

Description

Commentaire

END-TRIP

EQPT

Rapport de fin de séjour émis une fois par mois.

Liste tous les WO avec détails émis avec le statut"Print in end of trip report".

AUDIT

WO

Liste le statut des WO dans une période et par département.

Donne une somme des WO, mais ne donne pas le détail par type de WO.

DELIN-WO

WO

Liste les PWO ouverts ayant dépassé leur temps d'ouverture.

Fonctionne partiellement, pas de règles décrites.

WO-CLOSED

WO

Liste les WO Closed dans une période.

 

WORKPROG

WO

Ne fonctionnait pas.

?

WO-PREV

WO

Liste des WO Not Closed avec détails.

Pas de récapitulatif par Département ou Statut.

PM-PREVI

PM

Prévision des PM à sortir dans une période.

Nous n'avons pas d'idée sur la façon qui permet de sortir ce rapport.

EQFAIL1

EQPT

Donne le Nombre de CWO, MTBF et "Downtime" moyen d'un équipement.

Pas utilisé dans notre application.

Existe dans la version de base de Maximo, mais utilise le champ FAILDATE non présent dans nos écrans.

EQFAIL2

EQPT

Idem, mais réparti par "Failure Code".

Pas utilisé dans notre application.

Nous n'utilisons pas les "Failure Code".

EQFAIL3

EQPT

Donne la liste détaillée des CWO pour un équipement avec "Downtime", "Failure Code", cause, Remède et dates.

Pas utilisé dans notre application.

Utilise les mêmes informations que précédemment.

LOCFAILx

EQPT

Idem que les trois précédents, mais pour une location particulière.

Nous n'utilisons pas la notion de location.

EQHSTGRA

EQPT

Donne les informations suivantes pour un équipement:

Total labor hours, ?mean response time for emergency work orders, ?total downtime hours, ?mean time to repair, ?mean time between failures.

Nécessite la présence des informations suivantes dans les CWO:

Labor hours, response time, downtime, mean time to repair, and mean time between failures

Pas utilisé dans notre application.

Ne donne les informations que pour un équipement. Les informations ne sont pas présentes dans nos écrans. Rien ne permet de les obtenir.

FAILGRPH

EQPT

Donne les informations suivantes pour un équipement:

Répartition des "Failure Type" en quantité et %.

Utilise Excel pour afficher les données à partir d'un fichier .CSV.

Pas utilisé dans notre application.

Listé dans Maximo, mais exécutable non disponible.

Nous n'utilisons pas les "Failure Code".

RNRBYLOC

WO

Calcule les valeur suivantes pour une location:

- Mean time to respond =

AVG(ActStart - ReportDate)

- Mean time to repair (MTTR) =

AVG(ActFinish - ActStart)

Pas utilisé dans notre application. Listé dans Maximo, mais exécutable non disponible.

Le calcul pour une location ne présente pas d'intérêt dans notre application.

 
 
 
 

Table 13 Liste des rapports existants.

En dehors des rapports standards de Maximo, il n'existe qu'une initiative locale qui présente un intérêt. Il s'agit d'un fichier MS-Access appelé CGOEQPT conçu par le département maintenance. Il semble que les données y soient entrées à la main et non automatiquement. Ce fichier trace différentes courbes pour un même chantier.

La liste des courbes est la suivante:

- Nombre d'équipement hors service (ou Down) par mois.

- Total des maintenances préventives en retard depuis plus de 1 an et 6 mois.

- Total des maintenances préventives en attente par mois.

- Total des maintenances préventives en attente par mois et par département.

- Total des maintenances préventives ISM en attente par mois.

- Total des maintenances préventives CLOSE par mois et par département.

- Total des maintenances correctives CLOSE par mois et par département.

- Total général des maintenances préventives CLOSE par mois.

- Total général des maintenances correctives CLOSE par mois.

- Total des maintenances préventives APPR par mois.

- Total des maintenances préventives WMATL par mois.

- Total des maintenances préventives WOPCOND par mois.

Certaines idées de ce rapport pourront être réutilisées dans le rapport final.

Droits d'accès aux modules et rapports:

Maximo permet de contrôler l'accès à un certain nombre d'objets de l'application. Il s'agit des Modules, les champs et menus dans les différents écrans de chaque module ainsi que la possibilité de lancer un rapport.

Il nous faudra définir qui aura le droit de lancer ce rapport.

Aspects financiers:

Les notions de coûts peuvent se retrouver à plusieurs niveaux de Maximo.

- Dans le module inventaire qui contient l'ensemble des pièces détachées associées à leur coût.

- Au niveau des tables de taux de change. Ces taux doivent normalement être changés une fois par mois à partir d'informations comptables du siège.

- Dans le module "Work Order" ou chaque pièce est sortis avec un coût converti en monnaie de référence (USD). Tout cela dans la table MATUSETRANS aux valeurs du moment ou les pièces ont été sorties.

- Dans le module EQUIPMENT qui contient le coût total de l'installation ainsi que la date de mise en service (zone "Purchase information"). Il contient aussi la totalité des coûts associés à cet équipement depuis sa mise en service et depuis la dernière remise à zéro (zone "Costs"). Ces champs sont mis à jour en lançant le rapport "Equipment cost rollup" et "Zero equipment cost" du menu "Action".

Si des rapports financiers devaient être réalisés, il faudra prendre les précautions d'usage et ne pas confondre Maximo avec une comptabilité. Il est souvent difficile de comparer les résultats comptables avec ceux d'une gestion de stock, car ils n'utilisent pas les mêmes règles de gestion ni parfois les mêmes informations pendant les mêmes périodes.

Nous pouvons aussi garder à l'esprit qu'en terme de maintenance, nous cherchons des ordres d'idée plutôt que des valeurs exactes aux centimes prêts. Cela dit, rien n'empêche de tenter de faire correspondre les deux.

Architecture et ressources informatiques.

Description de la configuration type:

- Serveur dédié "MS-W2K Advanced server" fonctionnant en RAID1 (mirroring) + Hot swap.

- Extension "MS-Windows Terminal Serveur".

- Moteur de base de données People Soft Centura "SQL base 6.1.2".

- Application MRO "Maximo 4i v4.0.3" avec correctifs.

- Générateur de rapport BRIO (HYPERION/SCRIBE) SQR4 viewer, Execute, print.

- Paramétrages d'écrans Maximo et rapports SQR spécifiques de notre groupe.

- MS-Office 2K SP3 installé avec l'extension "Microsoft Office Ressource Kit" pour assurer la compatibilité avec "Windows Terminal Serveur" sur les postes clients.

- Les clients sont des PC installés avec W2K SP3 ou XP et "Windows Terminal Server client".

- Le réseau est de l'Ethernet 10 ou 100baseT utilisant le protocole TCP/IP.

- L'outil de développement des rapports BRIO (HYPERION/SCRIBE) "SQR Workbench" livré avec Maximo n'est pas installé sur les serveurs opérationnels.

Figure 14 Installation matérielle et logicielle de Maximo.

L'application Maximo utilise une connexion Client/Server (locale ou distante) à "SQL base" ou une connexion via ODBC pour l'édition des rapports SQR.

Il peut coexister plusieurs bases de données en même temps sur le serveur. Sur certains chantiers, on dispose des bases de données d'autres chantiers similaires pour référence. On pourra utiliser cette possibilité pour tester les rapports définitifs sur des bases de test.

Toutes les adaptations du produit comme les écrans ou les rapports sont installées sur le serveur et non sur les différents clients. Elles sont communes à toutes les bases de données.

Certaines applications liées à Maximo utilisent la base de donnée Microsoft Access liée à "SQL base" par ODBC. Office doit être installé avec les extensions "Terminal Serveur" disponibles dans le "Microsoft Office Ressource Kit" pour fonctionner dans cet environnement. Les informations d'installation sont disponibles dans le document Q224313 de Microsoft.

Les clients utilisent Maximo par l'intermédiaire d'une fenêtre de "Windows Terminal Server". Aucune application liée à Maximo n'est installée sur le client. Toute modification de la configuration de Maximo ou de ses rapports est donc appliquée implicitement sur tous les postes qui se connectent au serveur. Cela facilite grandement la maintenance.

L'utilisation de "Terminal Server" permet d'accéder aux bases de données des différents chantiers à distance via le réseau satellitaire global du groupe, pourvu que l'on ait un compte sur le serveur concerné et que l'on ne recherche pas la rapidité.

La gestion des licences "Windows Terminal Server" est gérée globalement sur les serveurs du siège par l'intermédiaire du réseau global.

Environnement d'installation:

Il existe des installations types de serveurs Maximo au sein de notre groupe. Les répertoires sont définis dans ce qui suit:

- D:\MAX403: Il contient les programmes de Maximo. On y trouve entre autres les programmes des différents écrans dont certains ont été adaptés à nos besoins par notre compagnie à l'aide de l'outil "Centura Object Nationalizer". Il s'agit de:

Equipment.exe, inventory.exe, pm.exe, po.exe, pr.exe, jobplan.exe et wotrack.exe.

Ce répertoire contient aussi le fichier MAXIMO.INI et SQL.INI. Le premier contient les paramètres de Maximo, le second ceux de la connexion avec "SQL base".

- D:\SQR4: Il contient les programmes de génération des rapports SQR (sqrwt.exe) et ceux nécessaires à leur visualisation (sqrwv.exe).

- D:\SQR4\REPORTS\PRIDE: Contient les versions compilées .SQT des rapports spécifiques à notre compagnie.

- D:\CENTURA: Contient le moteur de la base de donnée "SQL base", le fichier SQL.INI qui définit les connexions avec les bases de données.

- D:\CENTURA\<database name>: Ce ou ces répertoires contiennent les fichiers <database name>.DBS des bases de données. Ils peuvent aussi contenir d'autres fichiers dont ceux de transaction de "SQL base" (.LOG). Ce sont ces fichiers qui sont sauvegardés quotidiennement et archivés après être sorti du moteur de la base de données. Il n'existe pas de procédé pour sauvegarder une base en fonctionnement.

Note: Il peut dans certains cas exister des variations suivant l'ancienneté des installations. Dans ce cas, les répertoires ne se trouvent pas aux emplacements décrits précédemment.

Note: L'installation locale utilisée pour les tests se fera sur un portable ne possédant qu'un disque. Les tests se feront donc dans le disque C: et non sur D:.

Note: Les adaptations des écrans Maximo ont fait disparaître un certain nombre de champs qui ne sont pas documentés.

Ressources informatiques:

Dans la mesure où l'auteur est amené à se déplacer sur de nombreux chantiers, il lui faudra disposer d'une configuration locale installée sur un portable.

Les travaux de prototypage des rapports devront se faire sur cette plateforme et seront ensuite adaptés pour fonctionner sur un serveur opérationnel.

- PC portable Pentium III avec 1024Mo RAM, disque 40Go, W2K SP3, Office 2K SP3.

- CD d'installation "Maximo 4.0.3 for SQLbase 6.1.2" avec les droits de licence et derniers service packs.

- Paramètres de l'application et derniers rapports avec procédures d'installation.

- Mots de passe administrateur de Maximo

- CD installation "SQR Workbench".

- "Windows Terminal Server client".

- Dans la mesure du possible, les sources de certains rapports SQR à titre de référence.

Ressources documentaires de base:

- Maximo User's manual.

- Maximo Admin. manual.

- SQL base Admin. manual.

- SQR user's manual, programmer's manual.

- SQR workbench user's manual.

- MS-Access programmer's manual et user's manual.

- Différents documents cités en bibliographie.

Beaucoup de ces documents sont fournis avec Maximo sous forme de fichiers .PDF. D'autres sources nous ont permis d'obtenir des compléments de documentation.

Les outils de développement:

Les rapports Maximo sont exécutés majoritairement sous SQR4 en utilisant une version pré compilée (.SQT) du langage de développement SQR (.SQR). Les rapports sont ensuite générés en format texte non formaté (.LIS) et en format portable (.SPF) visualisable à l'aide du "SQR viewer". Le .SPF est dit portable car il peut être interprété sur plusieurs plateformes comme Unix, VMS, MVS et VM ou le "Viewer" est disponible.

Le format .LIS permet dans certains cas permettre d'extraire des données des rapports, mais il nécessite des traitements pour être utilisable en tant que tel.

Il faudra à terme arriver à une version SQT du rapport pour l'intégrer dans l'application Maximo. Toutefois, les outils de développement et d'examen des données ne sont pas très puissants et pourraient dans une certaine mesure ralentir le développement. C'est pourquoi nous avons proposé dans un premier temps d'utiliser un outil intermédiaire pour effectuer le prototype de l'application et proposer des données initiales mises en forme pour les utilisateurs.

Certains rapports natifs de Maximo existent sous "Cristal report", mais les développeurs du siège ne l'utilisent pas et aucun de ceux utilisés par notre groupe n'utilisent cet outil. Nous conserverons cette optique. Il s'agit plus d'un outil pour utilisateur final qu'un outil de développement.

Dans l'installation de Maximo se trouve un outil de base "SQLtalk" permettant d'effectuer des requêtes SQL sur les bases de données. Cet outil est une implémentation complète de SQL, mais n'est pas un outil de création de rapport proprement dit.

Il possède les fonctionnalités suivantes:

- Définir la structure de la base.

- Ajouter, effacer ou changer des données dans une base de données.

- Exécuter des requêtes sur une base de données.

- Contrôler les accès et la sécurité d'une base de donnée.

- Tester des requêtes SQL avant de les implanter dans une application.

- Générer des rapports sous forme de texte non formaté.

- Créer, sauver et rejouer des scripts utilisant des commandes "SQLtalk".

L'exportation des données extraites par les requêtes dans d'autres applications n'est pas aisée et rien n'est prévu en ce sens. Nous l'utiliserons uniquement pour tester des requêtes.

En addition à Maximo, nous disposons aussi d'un générateur de rapport "VisualSCRIBE 5.0" qui permet de définir des requêtes et de créer des rapports en utilisant le langage SQR. Il pourra dans une certaine mesure nous permettre de créer le corps de l'application, mais le contenu devra être entièrement programmé pour les requêtes complexes.

Il inclut aussi un éditeur SQR qui permet de coloriser les mots clefs et les commentaires. Cela pourrait nous faciliter le développement par rapport à un éditeur de texte simple.

Aucun de ces outils ne permet d'examiner les données et les résultats sous un format simple permettant de contrôler les résultats. Notre application ne se contentera pas de simples requêtes, mais nécessitera la compilation de nombreux enregistrement afin d'effectuer un travail de synthèse. Les ordres de grandeur hauts pour un navire à positionnement dynamique sont les suivants:

Tables

WORKORDER

WOSTATUS

PM

EQUIPMENT

EQSTATUS

Enregistrements

40000

130000

3000

5000

300

Table 14 Exemple de tailles de table Maximo.

Au regard des informations précédentes, nous avons préconisé d'utiliser MS-Access pour effectuer les premiers prototypes de l'application. L'objectif étant d'extraire des données, de les mettre en forme et de vérifier les résultats le plus rapidement possible afin de les présenter aux futurs utilisateurs.

Un objectif secondaire, mais non négligeable est l'examen des données se trouvant dans la base. En effet, Maximo étant un progiciel, nous ne disposons pas toujours d'informations précises sur la façon dont sont stockées les données ni sur le contenu des différents champs. Seul MS-Access permet un examen rapide et sans programmation des données d'une table ainsi que l'export vers d'autres applications pour les retraiter.

Toutefois, MS-Access possède aussi un certain nombre d'inconvénients:

- L'interface ODBC n'est pas très stable dans la configuration que nous avons testée avec les versions de "SQLbase 6.1.2" et ODBC sous W2K ou XP. C'est un problème connu par l'éditeur "People Soft", mais qui nécessite de passer à une nouvelle version de "SQLbase" incompatible avec notre version de Maximo. Nous avons tenté le passage à une version 8.01 du driver ODBC, mais cela n'a pas changé les problèmes.

- Le SQL généré par les rapports de MS-Access n'est pas toujours utilisable pour extraire des données de "SQLbase" via ODBC. C'est pourquoi les données seront dans un premier temps importées avant d'être traitées.

- Les détails de la programmation "Access VB" peuvent s'avérer complexes et souvent pas très bien documentés. Une formation au "VB access" pourrait nous faire gagner du temps.

L'application définitive devra se faire par la suite avec le langage SQR dont l'auteur fera l'apprentissage en parallèle avec le développement du premier prototype.

La tentative de trouver des librairies de programmes SQR adaptées à nos besoins n'a pas été très concluante. La plupart d'entre elles donnent de bons exemples de programmation SQR, mais ne peuvent pas s'adapter à nos besoins sans un grand travail de reconstruction. La consultation du "Users-group" de Maximo a donné quelques pistes pour la partie qualitative mais pas pour la partie quantitative. Il nous faudra nous créer nos propres outils.

Le langage SQR permet de s'adapter à des bases de données comme Oracle, Sybase, DB2, Informix, SQLBase... Notre développement ne sera adapté qu'à SQLBase, car il n'est pas à l'ordre du jour de changer de base de donnée. Des essais sur SQLserver ont été faits, mais n'ont pas présenté d'intérêt par rapport à l'existant.

Formation:

Dans le temps imparti pour l'étude, il sera difficile de faire tenir beaucoup de formation et de prendre le temps d'apprendre complètement un langage. Toutefois, on peut préconiser:

- "Microsoft Acces VB", une semaine.

- "People Soft" SQR, une semaine.

La familiarisation avec Maximo et ses outils se fera pendant la phase d'analyse des données. Elle devrait pourvoir tenir en trois semaines.

Réunion initiale d'expression des besoins.

Après avoir défini les grandes lignes du projet avec les initiateurs du projet dans la partie initialisation, nous avons organisé une réunion avec les autres décideurs afin de cadrer les objectifs, redéfinir le problème et obtenir une base stable pour le reste du projet. Le but est d'obtenir à la fin de cette réunion une image assez claire des besoins des différents intervenants permettant de définir les spécifications fonctionnelles initiales.

Cette réunion servira de document de base pour la réalisation des différents objectifs du projet.

On y examinera aussi les initiatives locales connues et pouvant répondre à une partit du problème.

Minutes of meeting "Expression des besoins initiale"

 

Situation:

Base "Pride Foramer" Luanda le 24 Mars 2004.

 

Participants: 7 personnes. Durée 2 heures.

- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.

- LDAO: Directeur des opérations client TOTAL. Initiateur du projet.

- 2*LDAM: Directeur de la maintenance LDA et son assistant.

- 2*LDARM: Rig Manager chantiers Pride Africa (PAN) et Pride Angola (PAN).

- 1*TC: Technical Coordinator chantier Pride Africa.

 

Rappel sur les conditions de réalisation du projet:

- Le projet est effectué par Ph JUNG en vue de l'obtention du diplôme d'ingénieur DPE attribué par le CNAM Paris. Ce projet s'effectuera en parallèle avec ses activités de supervision.

- Le projet a été approuvé formellement par le directeur de la base LDA en Février 2004.

- Il se fera en collaboration avec les développeurs du service maintenance de Houston. Cette situation a été officialisée par le courrier électronique du directeur de la maintenance du siège social de Houston en février 2004.

- La durée du projet est de 8 mois à partir de la date de cette réunion. Il devra donc se terminer en fin septembre 2004.

- Les personnes responsables des chantiers et de la base ont été informées de cette situation et de la collaboration qu'ils devront assurer au cours du développement de ce projet.

- Les personnes sont aussi informées que le projet se fera sous forme de prototypes et que l'évolution du produit final sera liée pour une grande part au retour d'informations qu'ils fourniront, mais aussi de l'intérêt des participants à le faire vivre.

- Les chantiers d'expérimentation seront les deux navires à positionnement dynamique PAN et PAF.

 

Rappel des faits:

Il existe sur chaque chantier de forage un certain nombre de rapports de synthèse permettant dans différents domaines de se faire une idée de la qualité des prestations dans le domaine concerné:

- MOCA (Monthly Operational Cost Analysis): Analyse des coûts de la maintenance et des achats d'un chantier.

- MOR (Monthly Operational Report): Etat d'un chantier au niveau opérationnel.

- MSR (Monthly Safety Report): Statistiques de sécurité d'un chantier.

Chacun d'eux permet non seulement de suivre les évolutions des marqueurs spécifiques à chaque métier, mais aussi de comparer les chantiers.

Par contre, il n'existe aucun outil permettant de se faire une idée de l'état de la maintenance ni de faire de comparaison entre chantiers.

 

Rappel sur les objectifs du projet:

L'objet de cette étude est de fournir les moyens d'analyse des historiques de maintenance du produit Maximo en vue d'amélioration les performances et optimiser la maintenance des appareils de forage de notre compagnie.

Pour cela, on se fixera plusieurs objectifs qui seront étudiés séparément:

1) Fournir des outils d'analyse quantitatifs de la maintenance au niveau opérationnel. Ce rapport aura pour nom MMR (Monthly Maintenance Report).

2) Proposer des outils d'analyse qualitatifs au niveau des équipements et définir les moyens de les mettre en place.

3) Proposer le cas échéant d'autres méthodes ou outils permettant d'ajouter de la valeur aux rapports des utilisateurs.

4) Diagnostiquer les dysfonctionnements de l'outil de maintenance et le moyen de l'améliorer.

 

Limites de l'étude:

- On utilisera les données et de préférence les outils de Maximo pour obtenir les résultats.

- On essaiera dans la mesure du possible de se limiter aux améliorations de l'usage du produit existant.

- Il ne s'agit pas de proposer de nouvelles méthodes de maintenances, mais d'améliorer l'existant en proposant des outils de diagnostic et de nouvelles méthodes de valorisations des données.

- Dans certains cas, si les contraintes techniques sont trop grandes par rapport au temps imparti, on ne produira pas une solution finale, mais plutôt des résultats chiffrés de façon à juger de la pertinence des données et de leur intérêt. Dans ce cas, on ne préjugera pas des méthodes employées pour les obtenir.

 

Synthèse des propositions des participants:

Après présentation des objectifs, il a été demandé aux différents intervenants de proposer des éléments pouvant être intégrés dans le futur rapport. Le compte rendu qui suit ne préjuge pas de la faisabilité ni du bien fondé des informations demandées. Il est reproduit d'une façon brute et les propositions seront examinées plus loin.

a) Comptage des maintenances préventives et correctives par département sur une période

b) Comparer les nombres de maintenances préventives relativement aux correctives:

Les utilisateurs veulent voir l'évolution dans le temps afin de déterminer la performance de la maintenance.

c) Comparer les temps de réalisation des maintenances.

d) Comptage des "Work Order" avec détails par statut et par département.

Lister au besoin les demandes de matériel associées à l'état WMATL (Wait for Material).

e) Evolution des maintenances correctives sur une période et par équipement:

Le but serait de pouvoir cibler un équipement à problème.

f) Liste des maintenances préventives retardées et raisons:

Afin de déterminer les principales causes faisant que les maintenances préventives ne peuvent être exécutées.

g) Liste des arrêts par équipements et durée sur une période:

Le but est le repérage des équipements source de problèmes.

h) Liste des équipements générant des arrêts et causes sur une période.

i) Graphique des arrêts par équipement sur un an glissant:

Evolution des arrêts sur un type d'équipement pour voir les effets de la maintenance.

j) Liste des équipements en arrêt sans que le chantier soit en arrêt.

k) Coûts des compagnies de service par type de travaux et par équipement.

l) Faire un lien entre les maintenances et les types de défaillances ISM. Proposer une méthode pour remplir les rapports en utilisant ces notations.

Les rapports de maintenance, qu'ils soient correctif ou préventif ne consistent qu'en un texte non structuré. Ce texte ne permet pas de caractériser les types de pannes et donc de faire des statistiques. Seule une reprise manuelle des commentaires permettrait de le faire.

m) Associer les rapports aux certifications ISM:

Les travaux associés aux certifications ne peuvent supporter de délais. Ils sont nécessaires aux certificats de navigabilité des unités.

n) Notions de MTBF/MTTR par équipements:

Il s'agit de mesurer le taux de pannes dans un équipement ainsi que les temps moyens de réparation. Cela devrait permettre de juger de l'efficacité de la maintenance, mais aussi à pouvoir redéfinir les périodicités des maintenances.

o) Liste des maintenances préventives majeures (>1an ou 1000heures) à effectuer dans le mois suivant:

Ce rapport permettrait de pouvoir préparer les achats et les ressources de personnel ou en équipements.

p) Il a été demandé de proposer tout moyen supplémentaire permettant de donner du contenu aux rapports de maintenance.

q) Il est aussi fait mention de graphiques récapitulatifs sur un an, mais sans vraiment préciser quoi.

En ce qui concerne les améliorations du produit Maximo, il a été demandé d'observer en annexe les points suivants:

r) Faire fonctionner les attachements de fichiers externes à Maximo dans les "Work Order" afin de compléter les rapports avec des informations plus pertinentes que le texte simple des commentaires.

s) Revisiter le rapport de fin de mois qui ne donne pas les informations escomptées.

t) Lister les fichiers externes qui permettraient de compléter les rapports de maintenance.

u) Vérifier la faisabilité d'un "Down time report" à partir de Maximo.

v) Il a aussi été émis l'idée que ce rapport puisse être sorti en milieu de mois pour voir l'évolution des chiffres dans le mois. Nous déciderons de l'intérêt de la chose plus tard.

 

Initiatives locales reconnues:

Il existe un certain nombre de rapports existants dans Maximo, mais qui ne présentent pas selon les utilisateurs, le caractère de synthèse que nous recherchons. Chacun donne des informations partielles et parfois difficiles à interpréter. Certaines personnes ont essayé de les utiliser pour faire des graphiques Excel avec plus ou moins de bonheur.

Il existe aussi certaines tentatives de comptage, mais elles non pu être faites que manuellement dans la mesure ou aucun des outils de développement n'est disponible à l'utilisateur et qu'il n'existe pas non plus de moyen simple de faire des exports de données. La tentative de rapport sous MS-Access par le service maintenance pourrait être une bonne base de départ pour la création des graphiques.

Certaines personnes ont réussi sans grand succès à extraire des données de la base à partir de SQLtalk. Les problèmes d'import des données dans un tableur qu'ils ont rencontré n'ont pas permis de continuer ces tests. En effet, SQLtalk ne fournit pas de moyen de mise en forme des données de sortie.

Le rapport CGOEQPT est une initiative du service maintenance. Elle contient un certain nombre de courbes décrites dans l'analyse de l'existant. La saisie des informations est manuelle, mais la procédure d'obtention des données est inconnue. Il pourrait malgré tout servir de base pour les graphiques que nous proposerons.

 

Conclusions:

En fonction de ce qui précède, il a été décidé les points suivants:

- Mr JUNG continue l'apprentissage du produit et devra présenter un premier prototype chiffré dans un mois à dater de cette réunion.

- Les résultats intermédiaires seront envoyés pour critique aux intéressés par courrier électronique avant son retour en Angola.

- Il présentera la première version du prototype au personnel de la base le 19 Mai 2004.

Revue critique des différents points:

a) Ne pose pas de problème, il s'agit d'un simple comptage.

b) Suggère un pourcentage entre PM et CM. Il suggère aussi la visualisation de ce rapport sur une longue période. Admettons dans un premier temps une période de 1 an glissant à partir de la date du rapport.

c) On veut comparer des temps de maintenance, mais entre quoi et quoi ? On peut suggérer plusieurs solutions:

Comparer les temps des correctives et en sortir celles qui ont mobilisé le plus de temps sur un équipement donné.

Lister les temps cumulés en heures et coûts de maintenance pour chaque département.

d) Reviens à a). Le listage des MR (Material Request) en attente permettrait à la base de juger de ceux qui bloquent un "Work Order". Ce pourrait être une partie séparée du report pour ne pas alourdir le format. Aucun rapport existant ne donne ces valeurs.

e) Ce point paraît difficile à réaliser tel quel. En effet sur les navires, il existe environ 5000 équipements. Cette demande pourrait faire partie de la partie qualitative et être associée avec les MTBF ou MTTR. Il restera à déterminer comment filtrer les équipements que l'on voudra voir apparaître ou non.

f) Les seules causes de délais peuvent être les états WOPCOND et WMATL. Les comptages des cas a) pourraient répondre à cette demande.

g) Tous les "Downtime" ne sont pas reportés dans Maximo. L'exploration des fichiers n'a pas montre l'intérêt de cette information. Un changement de la procédure de déclaration des arrêts pourrait rendre cette information plus pertinente.

h) Même problème que g).

i) De même que pour e), vu la quantité d'équipement en jeu, il faudra trouver une représentation ou une méthode pour représenter ce type d'information.

j) Cette notion n'existe plus dans cette version de Maximo.

k) Recherche où trouver l'information ?

l) ISM ne propose aucun classement des défaillances. Par contre, il existe bien deux champs "Failure Class" et "Problem Code" dans les "Work Order" qui permettraient de caractériser les défauts. Cela fait partie de la partie qualitative. Il existe une norme de ce type qui pourrait convenir pour notre environnements.

m) Il faudra extraire des informations relatives aux équipements certifiés ISM et surtout au retard de maintenances préventives de cette catégorie.

n) Il faudra vérifier que les données existantes permettent d'effectuer ces calculs d'une façon fiable.

o) Ne pose pas de problème.

p) Nous tenterons de noter toute information nécessaire à l'amélioration des rapports.

q) Cela reste à définir.

En ce qui concerne les propositions annexes et améliorations possibles de Maximo:

r) Hors sujet. La procédure a déjà été faite par le CPI. Elle doit être formalisée par le siège de Houston dans les standards.

s) Hors sujet. Nous ne disposons pas des sources du programme.

t) Il existe déjà un certain nombre de fichiers externes permettant de compléter ceux de Maximo. Nous interrogerons les utilisateurs à ce sujet. Un certain nombre de ces modules pourraient faire partie des "Custom Applications" de Maximo.

u) Ce sujet doit être discuté avec les divers responsables opérationnels, car c'est un point très sensible. Le consensus à ce sujet est de garder Maximo hors de ce type de rapport. Il s'agit d'un point très politique que seules les directions pourront trancher.

v) Il faudra attendre les premiers prototypes pour juger de l'intérêt des données. Il ne semble pas dans un premier temps utile de suivre l'évolution des données à très court terme sous peine de mauvaises interprétations.

Conception initiale partie quantitative.

Au cours de ce chapitre, nous reprendrons les idées fournies lors de l'expression des besoins. Nous tenterons de voir comment les utiliser ou les écarter en fonction de leur faisabilité ou de leur distance par rapport au contexte.

Les indices correspondent aux références de l'expression des besoins.

Nous allons construire le format du premier prototype à partir des demandes des utilisateurs sous forme d'une proposition non fonctionnelle.

Les différents aspects du rapport initial:

Paramètres d'entrée du rapport:

Comme son nom l'indique, le MMR (Monthly Maintenance Report) est un rapport mensuel que l'on devrait pouvoir sortir en fin de chaque mois avec les autres rapports de synthèse existants.

Dans un premier temps, nous n'entrerons qu'un seul paramètre qui sera la date de fin de période de l'exercice. Le format sera celui généralement utilisé dans Maximo à savoir: DD/MMM/YYYY.

Par exemple: 01/JUL/2003 pour obtenir les résultats antérieurs à cette date non compris. Soit le mois de juin et les précédents pour les graphiques sur un an.

On ne peut préjuger à ce niveau du résultat si une personne entre une date quelconque. Dans tous les cas, les chiffres du rapport seront calculés un mois en arrière à partir de cette date. Cette situation imposera probablement d'utiliser les historiques.

Il est fort probable que dans le futur produit fini, nous ne rentrerons que le mois et l'année. Ce n'est pas encore le choix des utilisateurs.

Entête et pieds de page du rapport:

L'entête du rapport sera une copie de celui utilisé dans les rapports Maximo existants. Il sera présent sur toutes les pages du rapport. Il n'y aura pas de pied de page.

Figure 15 Entête des rapports Maximo.

- Le logo en haut à gauche.

- La pagination en haut à droite comprenant le numéro de page courant ainsi que le nombre total de pages.

- Au centre, en texte intermédiaire le nom du rapport suivit en dessous des dates de début et de fin du rapport pour les parties mensuelles.

- En bas à gauche, la date d'impression du rapport suivie du nom du chantier.

- En bas à droite, le nom du rapport dans Maximo suivit du numéro de version du rapport afin de permettre un suivi des versions.

- En bas d'entête une barre horizontale séparant les résultats de l'entête.

Les cotes et tailles des différents éléments ainsi que les marges seront reprises d'un rapport existant.

Zone 1 du rapport:

Des points a), b) et c) on peut déduire qu'il existe une demande de comptage des maintenances avec une répartition par département, type de maintenance et statut.

- Les différents "Types" de maintenance d'un "Work Order" (WO) sont: PM, CM, SM, RKS, ALT, RM, RPT. Seuls les deux types de maintenances PM (Preventive Maintenance) et CM (Corrective Maintenance) seront pris en compte dans notre étude. Les autres types n'étant considérés que comme des indications. L'état SM (Safety Maintenance) que nous avions pris en considération au début semble avoir été abandonné dans la nouvelle version à venir.

- Les différents "Status" d'un "Work Order" sont au nombre de neuf:

WAPPR

APPR

WOPCOND

WMATL

INPRG

COMP

CLOSE

CAN

HISTEDIT

De ces huit états nous ne garderons que six:

WOPCOND

WMATL

INPRG

COMP

CLOSE

CAN

En effet, les états intermédiaires WAPPR, APPR et INPRG pourront être regroupés dans un seul et même groupe des "Work Order" en progrès. En pratique, on s'aperçoit que ces états sont confondus par les utilisateurs et ne correspondent à rien de précis en terme de travaux effectués. Ils ne font qu'indiquer qu'un WO est ouvert et le travail en cours ou en phase de l'être.

Le regroupement des valeurs sera nommé improprement INPRG, qu'il faudra ne pas confondre avec le même état spécifique à Maximo.

L'état HISTEDIT n'a pas de signification opérationnelle et ne sera pas comptabilisé.

- La répartition par département pose un problème, car il existe différents champs pouvant correspondre à cette définition. Toutefois, dans l'écran des WO, seul le champ "Lead Craft" est obligatoire les autres sont optionnels. Le champ "Crew" a pratiquement la même signification que celle du "Lead Craft". Le champ "Supervisor" ne présente pas d'intérêt. Nous décidons donc de choisir le champ "Lead Craft" pour effectuer nos sélections.

Dans la liste des "Lead Craft", se trouvent différents champs signifiant la même chose: CM/RM ainsi que BOP/HYD sont les mêmes personnes. On les regroupera respectivement sous les noms: CM et HYD.

Ce qui représente au final sept valeurs:

HYD

CE

CM

ENG

MAR

STP

SAF

- A la suite de discussion avec différents interlocuteurs lors de la création de cette partie, on ajoutera plusieurs colonnes:

· Une colonne de total de chaque ligne "Total M".

· Une ligne correspondant au même total, mais pour le mois précédent notée "M-1".

· Une colonne "Delta" qui correspond à la différence entre le total du mois courant avec celui du mois précédent afin de visualiser l'évolution.

· Enfin une colonne "%" qui indiquera le pourcentage de chaque état d'un WO par rapport au total des WO cités dans le tableau.

Les idées précédentes peuvent nous amener à proposer deux tableaux. L'un pour les PM et l'autre pour les CM regroupant les totaux demandés:

 

HYD

CE

CM

ENG

MAR

STP

SAF

Total M

M-1

Delta

%

WOPCOND

 
 
 
 
 
 
 
 
 
 
 

WMATL

 
 
 
 
 
 
 
 
 
 
 

INPRG

 
 
 
 
 
 
 
 
 
 
 

COMP

 
 
 
 
 
 
 
 
 
 
 

CLOSE

 
 
 
 
 
 
 
 
 
 
 

CAN

 
 
 
 
 
 
 
 
 
 
 

Zone 2 du rapport:

Dans l'expression des besoins c), se trouve aussi une idée d'heures de travail fournies par les équipes. Il ne semble pas très intéressant de calculer les heures avant que le "Work Order" soit dans l'état CLOSE. En effet, les états intermédiaires d'avancement des travaux ne sont que rarement remplis au fur et à mesure des travaux.

Le calcul des heures peut s'effectuer de plusieurs façons:

- En calculant la différence entre les dates de début et fin des travaux. Cela ne peut tenir compte du nombre de personnes ayant fait le travail ni des périodes d'interruption des activités.

- En calculant la différence entre les dates d'ouverture du "Work Order" et celui ou il est CLOSE. Cette solution ne peut être retenue, car elle inclut aussi les états d'attente de matériel ou pour opérations. Les états d'un WO ne permettent pas de connaître la durée des travaux.

- En utilisant le champ REMDUR qui contient la durée des travaux. Pourvu qu'il soit rempli correctement, ce champ est celui qui doit contenir la durée exacte d'heures passées en "man-hours". Ce champ n'est pas obligatoire dans notre version.

Il faut toutefois remarque que la signification des ces heures doit être prise avec circonspection. Elle devrait inclure la somme des travaux effectués par chaque personne d'un même "Lead Craft" (ce qui interdirait les regroupements entre services). Cela inclut:

- Le nombre d'heures pour la réalisation de la tache.

- Les travaux de préparation et de fermeture du chantier.

- Le temps d'écriture des rapports.

- Tout délai additionnel pendant lequel les personnes mobilisées le sont restées sans pouvoir exécuter d'autres taches.

On reprendra le format d'entête du tableau précédent.

 

HYD

CE

CM

ENG

MAR

STP

SAF

Total M

M-1

Delta

CLOSE man hrs

 
 
 
 
 
 
 
 
 
 

Zone 3 du rapport:

Le rapport entre le nombre de maintenances préventives par rapport à celui des correctives est un bon indicateur de la qualité de la maintenance exécutée. En effet, un fort taux de maintenances correctives peut indiquer plusieurs choses:

- Les maintenances préventives sont inadaptées.

- Les maintenances préventives ne sont pas planifiées correctement.

- Les maintenances préventives n'existent pas.

- Un problème sur un ou plusieurs équipements.

On admet en général qu'un taux de maintenances préventives de 80% relativement à toutes les maintenances effectuées est correct. Le pourcentage sera comparé uniquement sur les maintenances fermées (CLOSE) dans le mois du rapport.

Il est possible que ce taux soit différent dans le cas d'équipements redondants. En effet, lorsqu'il y a redondance, il est admis que l'on répare la partie redondante pendant que l'autre partie fonctionne. Certains équipements sont conçus redondants lorsque la fiabilité ne peut être garantie et que les conséquences peuvent être importantes sur la sécurité et les opérations.

C'est pourquoi cette comparaison devra toujours être faite sur des unités similaires.

Le titre sera: "%PM/All WO CLOSE".

Zone 4 du rapport:

Il est fait mention d'une notion de retard (overdue) dans la réalisation des maintenances préventives. En pratique, les maintenances préventives sont émises toutes les semaines (au lieu des 15 jours préconisé dans les manuels). Cela fait que la majorité des maintenances sont déjà en retard sauf celles qui ont une périodicité inférieure à une semaine.

Il a été considéré qu'une maintenance était en retard si sa réalisation excédait 25% de sa période.

Nous donnerons donc un pourcentage des maintenances en retard relativement à toutes les maintenances effectuées dans le mois.

Il existe aussi une notion de maintenances effectuées sur des équipements spécifiques dits ISM. Ces équipements sont ceux liés à la sécurité et aux certificats de navigabilité du navire. On en donnera donc aussi le pourcentage par rapport au nombre total de maintenances effectuées dans le mois. L'indicateur ISM se trouve dans les différentes tables: EQ9 dans la table EQPT, PMEQ1 dans PM, WOEQ9 dans WO. Le champ ISM est très important pour les unités maritimes uniquement, mais il fait partie des requêtes des inspecteurs du DNV à chaque inspection de certification.

Il s'agit de champs libres des tables Maximo et utilisés dans l'adaptation faite par notre société.

Le calcul des champs "Next Due Date" nécessaire à la détermination des "Overdue" a été décrit dans la présentation de l'existant.

Les titres seront respectivement: "% overdue ALL" et "% overdue ISM".

La proposition suivante a été éliminée au profit des pourcentages en bout de chaque ligne de statut. Les pourcentages de PM et "overdue" seront indiqués séparément. Le zone ISPS a été éliminée, car elle fait partie des certifications ISM.

% overdue

ISM overdue

ISPS ovr

%WSCH

%WMATL

%WOPCOND

MR Pending

 
 
 
 
 
 
 

Zone 5 du rapport:

Afin de répondre au point h) et partiellement à g), nous pouvons proposer de donner une liste d'équipement ayant occasionné le plus d'heures de travail dans le mois considéré pour les PM et les CM. Il a été considéré après consultation que les 5 premières valeurs suffiraient. Nous nommerons ces listes "TOP5 list of man hours consumption".

Les heures sont celles du champ DURATION dans les "Work Order". Il avait été proposé initialement de mettre de % d'heures par rapport au total des heures travaillées. Les résultats calculés n'ont pas été très significatifs.

Sur un seul mois, ces informations ne pourront pas donner une information très utile. Par contre, la comparaison sur plusieurs mois permettrait probablement de détecter des équipements à problèmes. Cette partie ne saurait être suffisante pour la détection de ce type d'équipements et devra être complétée par d'autres informations de fiabilité.

Le terme "man-hours" indique la somme des heures de travail cumulées de toutes les personnes ayant effectué le travail. Voir l'explication dans le zone 2.

Nous proposons le format suivant pour les maintenances préventives:

TOP5 list of PM man hours consumption:

Hours

Equipment

Designation

96

053206603

Bridge crane fwd

Nous aurons une deuxième colonne du même format, mais pour les maintenances correctives:

TOP5 list of CM man hours consumption:

Hours

Equipment

Designation

120

053209401

Mud pump set #3

Zone 6 du rapport:

Afin de répondre à g), nous proposons une liste des équipements en arrêt ou ayant été arrêtés pendant la période du rapport. Nous l'appellerons "Equipement down".

Le tableau devra comprendre la date de départ de l'arrêt. Elle sera issue des historiques des équipements. Le nombre de jours écoulés de la date du début de l'arrêt jusqu'à la date de fin du rapport ou de celle de l'arrêt si l'équipement est retourné en service entre temps.

On y ajoutera le numéro du "Work Order" concerné ainsi que l'état du WO. L'état du WO permettra de déterminer s'il s'agit de causes opérationnelles (WOPCOND) ou pour attente de matériel (WMATL). Dans ce dernier cas, on précisera le numéro de requête de matériel (MR#) se trouvant dans le champ "MR N°" du WO. Une case vide indiquerait que le WO a été mal rempli et qu'il manque cette information importante pour le compléter.

Nous avons aussi proposé une deuxième solution qui comprend uniquement un décompte des équipements en arrêt dans les six derniers mois. Nous verrons l'intérêt de chacun au cours de la réalisation du prototype. La première solution donne des détails sur les équipements en arrêt. La seconde solution pourrait faire l'objet d'un graphique sur une année plutôt qu'une solution tabulaire.

Nous proposons les deux formats suivants. Il faudra décider du choix de l'un ou de l'autre lors des réunions d'expression des besoins. La proposition 2 pourrait avantageusement être remplacée par un graphique.

Equipement down: proposition 1

Since

Days

Equipment

Designation

WO#

Status

MR#

11/04/2004

30

053206603

Bridge crane fwd

530029241

WMATL

53006302

02/04/2004

12

053209401

Mud pump set #3

530026084

WOPCOND

 

Equipment down: proposition 2

P-5 and +

P-4

P-3

P-2

P-1 month

Period

 
 
 
 
 
 

Zone 7 du rapport:

Dans le point d), il est fait mention d'une liste de requêtes d'équipement (MR) associée aux "Work Order" préventifs ou correctifs se trouvant dans l'état WMATL. Cette liste permettrait aux gestionnaires de suivre précisément les achats d'équipements liés à des arrêts d'appareils.

Dans le "Work Order", existe un champ nommé "MR N°" qui permet d'entrer un ou plusieurs numéros de MR dans un champ texte. Ce champ n'est pas contrôlé.

On peut proposer le tableau simple qui suit. Le format en est assez compact pour éviter les listes extensives, mais il répond au problème.

WMATL PM and associated MR:

WO#

530029241

530036103

530026084

 
 
 
 

MR#

53006302

 

53005422; 53005162

 
 
 
 

WO#

 
 
 
 
 
 
 

MR#

 
 
 
 
 
 
 

Zone 8 du rapport:

Au final dans le point o), il est demandé de lister une prévision des maintenances majeures à venir dans le mois suivant. L'objectif de cette information est de pouvoir préparer les approvisionnements ainsi que les éventuelles ressources en personnel. Après discussion avec le personnel du bord, cette période sera étendue à 6 mois et non à un mois. En effet, les délais moyens d'achat sont de l'ordre de six mois pour la majorité des pièces.

Par majeures, on entendra les grosses maintenances de périodicité supérieure à 1 an ou à 10000 heures. Il se posera un problème si ces maintenances sont en cours et non exécutés. Dans ce cas, le champ "Next Due Date" n'est pas renseigné. Il faudra donc donner une estimation des dates à partir des informations disponibles dans la PM ou les compteurs des équipements.

Nous proposons le format suivant:

Major PM prevision: Over 2 Years, or 10000h for the next month.

PM#

Due Date

Designation

Equipement

Designation

3867

31-Jul-2004

5 years - obtention MODU safe

053

DRILLSHIP PRIDE ANGOLA

Rapport final:

La proposition de format du premier prototype se trouve sur la page suivante.

Il a simplement été créé dans un document MS-Word afin de donner un format initial. Il n'a rien de fonctionnel.

Format final du prototype papier n°1:

Maintenance Management Report

Pride Drill Ship

Period from xxxx to yyyyy

Preventive Maintenance: MMR v0.1b

 

CE

ENG

HYD

MAR

RM

STP

Total

Reference

Delta

INPRG

 
 
 
 
 
 
 
 
 

WMATL

 
 
 
 
 
 
 
 
 

WSCH

 
 
 
 
 
 
 
 
 

WOPCOND

 
 
 
 
 
 
 
 
 

CLOSE

 
 
 
 
 
 
 
 
 

CAN

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

CLOSE man hrs

 
 
 
 
 
 
 
 
 

% overdue

ISM overdue

ISPS overdue

%WSCH

%WMATL

%WOPCOND

MR Pending

 
 
 
 
 
 
 

Note: Overdue is after 25% of the period of the PM.

Corrective Maintenance:

 

CE

ENG

HYD

MAR

RM

STP

Total

Reference

Delta

INPRG

 
 
 
 
 
 
 
 
 

WMATL

 
 
 
 
 
 
 
 
 

WSCH

 
 
 
 
 
 
 
 
 

WOPCOND

 
 
 
 
 
 
 
 
 

CLOSE

 
 
 
 
 
 
 
 
 

CAN

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

CLOSE man hrs

 
 
 
 
 
 
 
 
 

%PM/CM close

ISM overdue

ISPS overdue

% WSCH

%WMATL

%WOPCOND

MR Pending

 
 
 
 
 
 
 

Total (h):

 

Top 10 list of the CM man hours consumption:

Hours

Equipment#

Designation

 

Hours

Equipment#

Designation

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Equipment down:

P-5 and +

P-4

P-3

P-2

P-1 month

Period

 
 
 
 
 
 

Major PM prevision: Over 2 Years, or 10000h for the next month.

PM#

Due Date

Designation

Equipment#

Equipment designation

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Etapes de construction du prototype quantitatif.

Les choix de réalisation des prototypes:

Afin de nous permettre de visualiser et d'extraire les données se trouvant dans les tables, nous avons choisi d'utiliser la base de donnée MS-Access comme une sorte d'AGL de départ. En effet, comme nous l'avons vu dans la présentation des ressources informatiques, les outils fournis avec Maximo ne présentent pas l'aspect pratique de MS-Access pour effectuer des requêtes ni pour représenter les données simplement sans programmation complexe.

MS-Access peut se lier à des tables ou importer les données de "SQL base" par l'intermédiaire d'ODBC. Nous importerons les données, car certaines requêtes MS-Access ne sont pas acceptées par ODBC.

Le premier prototype se fera dans un premier temps sous MS-Access avec les outils graphiques de base et des extensions "VB Access". Il permettra d'obtenir les premières informations utilisables pour donner du contenu au format proposé pour le "Prototype n°1" dans le chapitre précédent.

Le prototype MS-Access sera ensuite transcrit après validation du format dans le langage de programmation SQR utilisé pour la génération de rapport dans Maximo. Nous aurions pu utiliser Cristal Report, mais nous n'en disposons pas de licence et les développeurs du siège social ne l'utilisent pas.

Afin de pouvoir vérifier les chiffres plus facilement et pour faciliter la mise en page de tableaux sans avoir à tout construire, nous avons pris pour option d'utiliser les données de MS-Access, mais de faire le rapport dans Excel en utilisant les commandes de "VB-Access". Le format tabulaire d'Excel permet une mise en forme tabulaire plus pratique que MS-Access.

Installation de Maximo sur le poste de développement:

La machine de développement est un portable Dell Latitude C510, 40Go disque dur, 1Go ram.

L'installation se fera en locale et nous n'utiliserons pas les possibilités "Windows Terminal Server" des serveurs pour effectuer les développements. Cela permettra de rester indépendant des sites ou l'auteur se trouvera.

Les serveurs ne seront utilisés que lors de la finalisation du projet juste avant le déploiement de la première version jugée opérationnelle.

Etapes de l'installation:

- Installation standard de "Maximo SQLserver 4.0.3i". Nous ne disposons pas de la version "SQL base" sur la base LDA.

- Installation de Centura "SQL base 6.1.2" séparément.

- Installation des outils de développement "Visual Scribe".

- Installation des patches 1 & 2 de Maximo.

- Installation d'ODBC pour "SQL base", "Centura SQLbase 32-bits driver NT&95". La tentative de mise à jour vers la version "Gupta SQLbase 8.01" n'a pas donné de résultats probants avec MS-Access.

- Chargement des fichiers .DBS des bases de test en provenance de plusieurs chantiers:

Le nom des répertoires sera au format C:\Centura\<nom chantier>.

Le nom du fichier de la base de donnée doit avoir le même nom que celui du répertoire C:\Centura\<chantier1>\<chantier1>.DBS.

- Déclaration des bases de données dans ODBC:

Le DSN se nommera du nom de la base suivie du suffixe -O.

Par exemple: PANGOLA-O pour le "Database Name" PANGOLA.

Le nom du serveur est "server1".

Les bases devront être définies dans le fichier MAXIMO.INI. Voir dans les lignes suivantes.

Figure 16 "SQR4" configuration ODBC.

- Configuration des fichiers .INI des répertoires C:\max403 et C:\Centura et C:\WINNT. A noter que ces répertoires seront à un emplacement différent sur les futurs serveurs.

è MAXIMO.INI:

Vérifier les chemins des différents répertoires qui doivent pointer sur C:.

Les connexions ODBC doivent être déclarées dans ce fichier sous la forme

SQR4_SQLBASE_ODBC:{Database Name}={Data source name}

Exemple: SQR4_SQLBASE_ODBC:PANGOLA=PANGOLA-O pour la base PANGOLA.

è SQL.INI:

Il existe un fichier SQL.INI dans les répertoires C:\MAX403 et C:\CENTURA. Les deux doivent être modifié pour pointer sur les bases de données déclarées dans le répertoire C:\CENTURA.

Pour configurer ces fichiers, on utilise le programme SQLEDIT.EXE se trouvant dans chacun

des répertoires.

Figure 17 "SQLedit" Ecran principal.

On effectuera deux configurations: Une pour le "Serveur" et l'autre pour le "Client" sur le même poste.

Etant en local nous utiliserons une connexion par "Anonymous pipe" dans l'environnement "Windows NT single User".

Les installations des serveurs opérationnels sont aussi locales mais "Multi Users". En effet, la connexion par "Windows Terminal Server" n'implique aucune connexion client-serveur distante pour l'utilisation de Maximo. Certains sites sont encore installés avec une version client-serveur, mais ils devraient être migré dans le courant de l'année 2004.

Les figures suivantes décrivent les détails de chaque écran de configuration:

Figure 18 "SQLedit" détails de la configuration.

Le contenu du fichier SQL.INI doit ressembler à ce qui suit:

[dbnt1sv] ! Déclaration pour le serveur

! Déclaration de quatre bases de données.

dbname=PAFRICA,SQLAPIPE

dbname=PANGOLA,SQLAPIPE

dbname=PNA,SQLAPIPE

dbname=PSP,SQLAPIPE

servername=server1,sqlapipe ! Le nom du pipe

centurydefaultmode=0

! Les répertoires d'installation, ils seront sur D: dans les serveurs

dbdir=C:\Centura

logdir=C:\spl

tempdir=C:\temp

[win32client] ! Déclarations du nom client

clientname=PJUNG

[win32client.dll]

comdll=sqlapipe

è SQR.INI:

Il se trouve dans c:\winnt. Il contient les spécificités propres à SQR en particulier les configurations régionales.

Il nous permettra d'obtenir le cas échéant les chemins de certains éléments de SQR.

Analyse des données et des écrans:

Une partie de l'analyse des tables de Maximo ainsi que la correspondance avec les champs des écrans ont déjà été faits dans le chapitre d'analyse de l'existant. Toutefois, certaines tables ne sont pas visualisables facilement dans Maximo et le fonctionnement de certains écrans devra être analysé dans les détails. L'exploration des tables nous a aussi permis d'éliminer celles qui n'étaient pas utilisées.

Après examen d'une part des écrans, mais aussi par exploration des données des différentes tables, on peut donner la liste des tables qui nous concernent pour la création du prototype:

- EQUIPMENT: Qui est la table des équipements.

- EQSTATUS: Qui contient l'historique des statuts Up/Down des équipements (opérationnel ou pas).

- EQHISTORY: Contiens l'historique des compteurs ou "Meter-Readings" d'un équipement.

- PM: Contiens la liste des PM du chantier.

- WORKORDER: Est la table des "Work Order".

- WOSTATUS: Contiens l'historique du statut des "Work Order".

- MATUSETRANS: Contiens les transactions des pièces de rechange. Elle nous servira pour déterminer les coûts des pièces consommées dans un WO.

- VALUELIST: Contiens un certain nombre de valeurs prédéfinies. Les valeurs d'une liste sont obtenues en fonction du champ LISTNAME. Les listes sont configurables dans le menu "Application setup".

Nous avons rencontré certaines anomalies dans les tables. En voici la liste:

WOSTATUS:

WONUM

STATUS

CHANGEDATE

CHANGEBY

MEMO

GLACCOUNT

0000001028

HISTEDIT

10/12/2000 14:57

CE

 

 

0000001028

HISTEDIT

20/11/2000 00:35

CE

 

 

0000001028

HISTEDIT

03/09/2000 14:50

SYSADM

 

 

0000001028

HISTEDIT

03/09/2000 14:49

SYSADM

 

 

0000001028

COMP

17/09/1999 14:56

SEC

 

 

0000001028

CLOSE

17/09/1999 14:56

SEC

 

 

0000001028

INPRG

17/09/1999 14:47

SEC

 

 

- Les dates de chaque statut peuvent être identiques pour des statuts différents. Cela ne permet pas toujours de les remettre en ordre chronologique. C'est ce que représente l'exemple suivant. Il nous faudra trouver des artifices pour remettre les historiques dans un ordre cohérent.

EQSTATUS:

- Si l'on suit la chronologie des équipements Up/Down, certains équipements sont restés Down dans les historiques, mais sont marqués Up dans la table EQUIPEMENT. Il nous faudra toujours comparer l'état actuel de l'équipement avec celui des historiques.

WORKORDER:

- Les champs obligatoires WOJP1 qui contiennent le département contiennent d'anciennes valeurs non référencées dans la liste proposée par les utilisateurs. On considérera l'équivalence suivante pour les cas identifiés:

'ELE'=CE, 'MEC'=CM, 'STS'=STP, 'MEC/MOT'=CM, 'JRTP'=STP, 'RIGENG'=STP.

Tous les autres cas seront indiqués dans une colonne "Other" que nous rajouterons le cas échéant dans la liste des départements.

- Les statuts WAPPR, APPR et INPRG sont utilisés de façon peu orthodoxe. Il existe des allers et retours entre les différentes valeurs qui sont inexplicables par rapport aux procédures d'usage. Cela tend à démontrer que ces notions ne sont pas claires pour les utilisateurs.

Le prototype n°2 MS-Access:

Il est nécessaire de donner quelques détails sur la réalisation du prototype, ses limitations et les problèmes rencontrés:

- Les paramètres d'entrée sont le mois et l'année.

- La possibilité de formater les données dans un tableau MS-Excel nous a permis de vérifier les chiffres et de faciliter la mise en page qui est un peu plus complexe sous MS-Access.

- L'ensemble des comptages des statuts a été détaillé pour mieux pourvoir vérifier les comptes lors du regroupement des états: WSCH, WAPPR, APPP et INPRG sous le nom INPRG.

- Le format ne respecte pas tout à fait celui proposé pour le prototype initial, mais il permet de montrer des résultats chiffrés aux utilisateurs. Ce qui était le premier objectif.

- Les SM ou "Safety Maintenance" ont été imprimées pour informations, car certaines personnes voulaient les voir apparaître. Elles devraient être éliminées des prochains prototypes, car elles ne devraient plus être utilisées dans les prochaines versions de Maximo.

- Les zones "Downtime", "WMATL MR list" et "PM previsions" n'ont pas encore été implémentées.

- Les données de Maximo ont dû être importées dans MS-Access, car les requêtes trop complexes n'étaient pas supportées par ODBC sur des tables liées. La mise à jour d'ODBC vers la version 8.01 n'a pas changé la situation. Elle a créé d'autres problèmes, car la chaîne de connexion n'est pas stockée dans la configuration. Nous sommes donc restés sur l'ancienne version.

Ce prototype sous MS-Access nous aura permis d'explorer les tables et leur contenu, de préparer les futures requêtes qui seront utilisées dans le futur produit SQR. Il ne sera plus utilisé par la suite et nous passerons directement à la programmation sous SQR afin de préparer l'intégration dans Maximo.

Prototype n°2 chiffré sous MS-Access:

 
 
 
 
 

Maintenance Management Report

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

DRILLSHIP PRIDE ANGOLA

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Period : May 2003

 
 
 

Preventive maintenance:

 
 
 
 
 
 
 
 

MMR

V0.1b

 

BOP

CE

CM

ENG

HYD

MAR

RM

SAF

STP

Total M

M-1

Delta

INPRG

0

0

0

0

2

0

2

0

0

4

2

2

WMATL

0

0

0

3

0

2

0

0

0

5

2

3

WSCH

0

55

0

24

24

19

33

0

6

161

257

-96

WOPCOND

0

18

0

1

0

0

3

0

1

23

32

-9

CLOSE

0

166

0

107

36

37

125

0

32

503

570

-67

CAN

0

0

0

11

0

1

0

0

0

12

4

8

APPR

0

0

0

0

0

0

0

0

0

0

0

0

WAPPR

0

0

0

0

0

0

0

0

0

0

0

0

COMP

0

22

0

19

0

0

1

0

11

53

0

53

 
 
 
 
 
 
 
 
 
 
 
 
 

CLOSE man/hrs

0,0

616,2

0,0

158,0

66,5

42,7

142,0

0,0

33,5

1058,9

1170,1

-111,2

 
 
 
 
 
 
 
 
 
 
 
 
 

Overdue All

29,0

 
 
 

%WSCH

%WMATL

%WOPCOND

 
 

Overdue ISM

0,7

 
 
 

21,2

 

0,7

 

3,0

 
 
 

Corrective maintenance:

 
 
 
 
 
 
 
 
 
 

 

BOP

CE

CM

ENG

HYD

MAR

RM

SAF

STP

Total M

M-1

Delta

INPRG

0

0

0

0

5

14

1

0

2

22

26

-4

WMATL

0

29

0

1

0

1

0

0

0

31

37

-6

WSCH

0

0

0

0

0

0

0

0

0

0

0

0

WOPCOND

0

6

0

0

0

0

0

0

0

6

3

3

CLOSE

2

45

0

44

11

5

8

0

26

141

167

-26

CAN

0

0

0

0

0

0

0

0

0

0

0

0

APPR

0

0

0

0

0

0

0

0

0

0

5

-5

WAPPR

0

4

0

0

0

1

0

0

0

5

1

4

COMP

0

7

0

7

1

3

0

0

11

29

5

24

 
 
 
 
 
 
 
 
 
 
 
 
 

CLOSE man/hrs

42,0

163,5

0,0

83,0

18,0

116,0

11,0

0,0

26,0

459,5

807,8

-348,3

 
 
 
 
 
 
 
 
 
 
 
 
 

% PM/All Close

72,8

 
 
 

%WSCH

%WMATL

%WOPCOND

 
 
 
 
 
 
 

0,0

 

13,2

 

2,6

 
 
 

Safety maintenance:

 
 
 
 
 
 
 
 
 
 
 

 

BOP

CE

CM

ENG

HYD

MAR

RM

SAF

STP

Total M

M-1

Delta

INPRG

0

0

0

0

0

0

0

0

0

0

0

0

WMATL

0

0

0

0

0

2

0

0

0

2

2

0

WSCH

0

5

0

5

0

10

0

0

0

20

36

-16

WOPCOND

0

0

0

0

0

0

0

0

0

0

0

0

CLOSE

0

5

0

18

0

24

0

0

0

47

40

7

CAN

0

0

0

0

0

1

0

0

0

1

2

-1

APPR

0

0

0

0

0

0

0

0

0

0

0

0

WAPPR

0

0

0

0

0

0

0

0

0

0

0

0

COMP

0

0

0

2

0

0

0

0

0

2

1

1

 
 
 
 
 
 
 
 
 
 
 
 
 

CLOSE man/hrs

0,0

10,0

0,0

9,8

0,0

76,5

0,0

0,0

0,0

96,3

99,5

-3,3

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

%WSCH

%WMATL

%WOPCOND

 
 
 
 
 
 
 

27,8

 

2,8

 

0,0

 
 
 

Top 5 list of man hours consumption:

 
 
 
 
 
 
 
 
 
 

Hrs

Equipment#

Designation

 

PM

36

53319

VENT FANS

 

27

53101102

DIESEL ENGINE N°2

 

20

53317801

AIR FANS / HVAC SERVICES

 

14

53103202

MDO PURIFIER SET N°1

 

13,5

53209004

MUD PUMP N°1

 

CM

60

53808101

LIFE BOATS

 

31

53319

VENT FANS

 

30

53603008

MINI CONNECTOR F/ CAMERON K & C LINES number 3

 

30

53802

GENERAL ALARM

 

24

53319501

SILO ROOM FANS

 

15

53208230

TALK BACK SYSTEM

 

 
 
 
 
 
 
 
 
 
 
 
 
 

Equipment down:

 
 
 
 
 
 
 
 
 
 
 

Since

Days

Equipment#

Designation

 

12/09/2000

883

53317501

HVAC / MUD LABORATORY

 

Minutes of meeting "Expression des besoins prototype N°2"

 

Situation:

Base "Pride Foramer" Luanda le 19 Avril 2004.

 

Participants: 6 personnes. Durée 1h30.

- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.

- LDAO: Directeur des opérations client TOTAL. Initiateur du projet.

- 2*LDAM: Directeur de la maintenance LDA et son assistant.

- 2*LDARM: Rig Manager chantiers Pride Africa et Pride Angola.

 

Rappel sur l'objectif de la réunion:

- Examen critique du prototype n°2. Nous rappelons que ce prototype n'est pas intégré à Maximo et qu'il s'agit avant tout de donner des valeurs chiffrées au tableau papier du prototype n°1. Il s'agit aussi d'explorer le produit Maximo et ses outils afin d'en apprendre le fonctionnement.

- Visualisation des données produites et justification de leur intérêt.

- Revisiter le format initial du rapport et faire éventuellement de nouvelles positions de modifications.

- Nous rappelons que le prototype est un produit vivant et qu'il ne pourra vivre que par les remarques et propositions des utilisateurs. Il ne s'agit pas encore du produit final, mais une construction intermédiaire.

 

Propositions et remarques des participants:

- Les pourcentages de chaque statut devront être mis en fin de chaque ligne, après la colonne "Delta".

- Les champs BOP&HYD, CM&RM seront regroupés sous les dénominations HYD et CM. Les deux colonnes libérées seront laissées en place.

- Nous mettrons l'entête définitif avec les dates de début et de fin de la période à la place du mois uniquement.

- La partie SM "Safety Maintenance" est définitivement abandonnée, mais les comptages seront inclus dans les maintenances correctives.

- Dans les TOP5 nous conservons les heures à la place des % initialement proposés.

- Le comptage des heures de travail semble singulièrement faible au regard des équipes en présence sur les navires. On peut justifier cette faiblesse par le fait que les données entrées ne sont le plus souvent pas des heures-homme ("man-hours"), mais des heures d'équipes. Toutefois, les valeurs semblent cohérentes entre chantiers. De même, elles n'incluent pas les travaux de préparation et clôture du chantier ni les temps d'attente ou d'écriture des rapports.

- Nous confirmons le regroupement des états intermédiaires: APPR, WAPPR, WSCH, INPRG sous le dénominatif INPRG qu'il ne faudra pas confondre avec l'état correspondant de Maximo.

- Le principe des "Overdue" n'est pas clair. Certains pensent que les maintenances devraient être faites dés leur génération, d'autres considèrent qu'il faut inclure un délai. Le CPI propose un délai variable fonction de certains critères: 50% de la période pour les périodes inférieures à 2 mois, 25% pour le reste.

Nous nous entendons sur 25% de la période de maintenance pour les maintenances planifiées par le temps.

- Il est question de CMS (Continuous Machinery Survey) nécessaire aux certifications DNV. Toutefois, ce concept n'existe pas encore dans Maximo. Cette notion ne sera pas traitée tant qu'elle ne sera pas utilisée et que nous n'aurons pas d'information sur son implémentation et ce qu'elle recouvre exactement.

- Il est question de "Critical Equipement". Il s'agit bien d'un champ utilisé dans le module équipement. Il en existe trois niveaux: 1=Not essential, 2=Can run Without for a short period et 3=Essential. Toutefois, lorsque l'on explore les fichiers, aucun chantier ne l'utilise. Il ne faut pas le confondre avec le statut ISM qui concerne une certification liée aux équipements de sécurité du navire et nécessaire à son certificat de navigabilité. Cette notion ne sera pas traitée.

- Il faudra ajouter la zone "WMATL MR list". Cette liste donnera le détail des demandes de matériels associé à l'état WMATL.

- En ce qui concerne les droits d'accès du rapport et sa situation dans Maximo. Le rapport sera inclus dans le module "PM" sans restriction d'accès. Tous les utilisateurs pourront donc le lancer.

 

Conclusions:

- Constituer une liste des améliorations concernant la saisie des rapports dans les "Work Order".

- Application des différentes remarques dans le "Prototype N°3".

- La prochaine étape est de créer le prototype SQR du rapport. Il inclura les prévisions de PM, les "Major PM overdue" et les "WMATL MR list". Cela imposera de posséder l'outil et pourra représenter un travail important d'auto formation ainsi que de fabrication d'outils.

Construction du prototype n°3 sous SQR:

Nous utiliserons "VisualSCRIBE 5.0" comme éditeur des fichiers source SQR. Cet éditeur ne possède pas de fonctions particulières sauf la colorisation des mots clefs du langage et des commentaires. Il permet aussi une visualisation directe des résultats au format .SPF.

Cet outil est d'origine un outil d'assistance à la génération de rapport. Quelques tests ne nous ont pas prouvé l'efficacité de cet outil pour la création des rapports complexes qui nous intéressent. Tout au plus pourrions-nous l'essayer pour tester quelques requêtes SQL ou profiter de la génération automatique de programme pour nous aider lorsque la syntaxe des instructions ne nous sera pas familière. L'ouvrage SQR cité en référence devrait fournir la majorité des solutions à nos problèmes.

Le SQR n'est certainement pas un langage de dernière génération. La structuration du programme est laissée aux soins de l'utilisateur. Il existe toutefois des notions de procédures Locales et Globales ainsi que la possibilité d'inclure des modules externes par la directive #include. Toutefois, ces notions sont spécifiques à ce langage (par exemple dans une procédure locale, les variables locales gardent leur valeur entre deux lancements).

Pour les besoins du prototype, la programmation ne sera pas adaptée à différents environnements, mais seulement au SQBD "SQL base", dans un contexte uniquement US-English et dans un OS Windows. Il n'est pas à l'ordre du jour ni de changer d'environnement ni de base de donnée.

Nous tenterons toutefois de programmer en vue de la réutilisation des modules même si le prototype n'aboutit pas à la version définitive du produit.

On respectera les règles simples suivantes pour la documentation des programmes:

- En entête de module:

File Name, Author, Creation Date, Description, Parameters.

Une liste des révisions comprenant: Date, Programmer, version, list and details of modifications.

- En tête de chaque procédure:

Description, Input parameters, Output parameters, liste des révisions pour les plus importantes.

- Commenter les programmes de façon à ce qu'il soit réutilisable par un autre programmeur.

Les versions suivies d'un indice "b" seront les versions de travail pendant la phase de prototypage. La version 1.0 sera la première version opérationnelle, elle apparaîtra dans l'entête du rapport. Cette version ne sera officialisée qu'après plusieurs mois de résultats et la vérification des chiffres obtenus.

L'outil que nous utiliserons pour exécuter nos programmes source .SQR est SQRWT.EXE qui se trouve dans le répertoire C:\SQR4.

Il n'existe pas d'outil de "debuggage" proprement dit. Seules quelques fonctionnalités du langage permettent de tracer l'exécution:

- Le langage intègre cependant des fonctionnalités permettant d'imprimer des résultats dans une fenêtre pendant l'exécution à l'aide des commandes SQR show ou display. La commande show est plus puissante que display, car elle permet d'afficher plusieurs variables ou textes dans la même commande.

Figure 19 Fenêtre principale de SQRWT

- Il existe aussi des possibilités de compilation conditionnelle. La compilation de la ligne est déclenchée lorsque l'option -DEBUG est entré dans la ligne de commande.

Dans ce cas, les lignes du source précédées de la directive #debug sont compilées. En fait, l'option -debug peut aussi être suffixée par un certain nombre de chiffres ou lettres et testée de la même façon dans le programme.

La syntaxe de la ligne de commande devient alors:

-debug<string> et le test dans le programme #debug<string> <command line>.

- Certaines variables explicites du programme ou celles des options -debug peuvent aussi être testées à l'aide des directives #ifdef, #ifndef, #else et #end-if. Cela permet de créer des portions de programme à compilation conditionnelle.

- Dans la ligne de commande, on peut aussi préciser les directives suivantes:

-E[file name] qui permet de générer un fichier .ERR contenant tous les messages d'erreur de SQR. Le fichier par défaut est le <nom du program>.ERR.

-CB fait apparaître une fenêtre d'exécution qui permet de visualiser les messages de SQR, ceux du programme (display & show) ainsi que de saisir les entrées du programme.

-S permet d'afficher les commandes SQL, le nombre de fois ou elles sont exécutées, le nombre de lignes sélectionnées.

Le programme source .SQR est directement exécutable par le programme SQRWT. Par contre dans Maximo il est d'usage de le compiler au format .SQT pour qu'il soit exécuté et que le code ne soit pas visible par l'utilisateur.

La compilation s'effectue en utilisant l'option -RS de la ligne de commande.

Le programme "SQR viewer" SQRWV.EXE dans C:\SQR4 permet de visualiser les fichiers de sortie portable d'extension .SPF. C'est l'outil d'édition des rapports utilisé par Maximo.

Il existe aussi par défaut un format .LIS qui est du texte simple sans grande utilité dans notre cas. Il est généré en même temps que le format .SPF sauf option contraire de la ligne de commande.

Figure 20 "SQR viewer" fenêtre d'exemple.

Prototype n°3 sous SQR:

Minutes of meeting "Expression des besoins prototype N°3"

 

Situation:

Base "Pride Foramer" Luanda le 19 Mai 2004.

 

Participants: 7 personnes. Durée 1 heure.

- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.

- LDAO: Directeur des opérations client TOTAL. Initiateur du projet.

- 2*LDAM: Directeur de la maintenance LDA et son assistant.

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

 

Rappel sur l'objectif de la réunion:

- Valider le format du prototype N°3.

- Faire de nouvelles propositions ou corrections du rapport existant.

 

Propositions et remarques des participants:

- Le format est assez bien accepté par l'ensemble des participants.

- Les listes WMATL sont jugées compactes, mais conformes à la demande. Dans la mesure ou le champ est un texte libre, il est difficile de donner d'autres informations complémentaires. Dans tous les cas, le numéro de "Material Request" (MR) permet de trouver tous les autres éléments d'une commande ("Purchase Order").

- Dans les "major PM prévisions", remplacer "Days" par le nom du département trié. Les intervalles sont passés à 1 an et 1000h à la demande des utilisateurs des chantiers. Cela afin de pouvoir effectuer les achats nécessaires à ces maintenances en avance. Cela inclut la moyenne des temps d'approvisionnement normaux.

- Ajouter des graphiques donnant les répartitions des "PM overdue" dans le temps et en pourcentage.

- Ajouter des graphiques de répartition sur une année glissante des: Etats des PM et CM, des overdue et du % de PM/all maintenances.

- CPI précise aux utilisateurs qu'il n'a pu tester les données que sur quelques mois et qu'il existe peut être des lacunes dans ces rapports. Cela ne semble pas les frapper... Il indique qu'il faudra à l'issue du prototype lancer des tests plus complets faits par les administrateurs Maximo de Houston.

 

Conclusions:

- Remplacement des "Days" par le département et trier par cette valeur.

- Nous avons décidé d'ajouter les graphiques récapitulatifs suivants:

§ Pourcentages de "PM overdue" dans le temps.

§ Répartition des différents états des maintenances préventives et correctives sur une année glissante.

§ Répartition des %PM sur un an glissant.

§ Répartition des % d'overdue ISM ou non sur un an.

- Préparation de l'intégration du produit à Maximo.

Prototype n°4 sous SQR:

Les principales modifications proposées par les utilisateurs lors de la dernière réunion d'expression des besoins consistent en l'addition de graphiques. Les fonctions graphiques de SQR ne sont pas très évoluées et rentrent dans un cadre rigide auquel il faudra s'adapter. La documentation SQR en ce domaine est faible et il faudra tester les fonctions dont on ne connaît que les syntaxes et non la représentation graphique des résultats après exécution.

L'usage des tableaux pourrait poser quelques problèmes, car ceux-ci ne sont pas dynamiques dans SQR. L'usage de tables intermédiaire ne nous semble pas souhaitable pour effectuer ce type de travail sur les données. Elles poseraient des problèmes de droits lors de leur création.

Les graphiques suivants ont été ajoutés. Pour chacun d'eux, nous donnerons un descriptif ainsi que des informations concernant leur usage par les services de maintenance.

Les maintenances en retard (Overdue):

Titres: "Time based overdue" et "Meter based overdue".

Dans Maximo, il est possible de planifier les maintenances suivant deux façons:

- Dans le temps pour les maintenances dites "Time-based". P.ex: 1 mois, 6 mois, 1 an etc...

- Par les compteurs des équipements pour les maintenances dites "Meter-readings". P.ex: 250heures, 1000h etc...

Les graphiques proposés proposent de donner deux valeurs calculées sur 1 an précédant la date de fin du rapport:

- Le pourcentage de chaque maintenance d'une périodicité donnée par rapport à l'ensemble du même type. Cette partie devrait plus ou moins rester figée avec le temps sauf addition ou élimination de certaines maintenances.

P.exemple: S'il y a 1000 maintenances préventives et 35 de 360 jours, on aura le chiffre de 35% (partie rouge ou gauche autour de chaque périodicité).

- Le pourcentage des maintenances en retard pour les maintenances de cette périodicité s'étant produite dans l'année précédant la date de fin du rapport.

P.exemple: Si l'on a eu 100 maintenances de 2000 heures dans l'année et 12 en retard, on aura le chiffre de 12% (partie verte ou gauche autour de chaque périodicité).

Figure 21 Graphique "Time-bases" & Meter-based" overdue.

Ce graphique peut donner quelques indications que nous expliciterons sur quelques exemples:

- Les maintenances 7 jours représentent un faible pourcentage des maintenances préventives. Toutefois, 10% d'entre elles sont faites en retard.

- Un pourcentage de 20% des maintenances 250 heures sont faites en retard.

Note: Le graphique tel qu'il est fait pose un problème pour les maintenances supérieures à 1 an (la périodicité du rapport) ou encore pour les équipements tournant peu. Cela ne renseigne pas correctement sur les maintenances longues, mais en retard.

Totaux des maintenances CLOSE ou INPRG:

Titre: "PM & CM WO counts"

Ce graphique est un récapitulatif sur un an glissant des totaux de maintenances préventives (PM) et correctives (CM) pour les statut CLOSE et INPRG.

Il recouvre l'année précédant la date de fin du rapport.

On rappelle que INPRG regroupe les états WSCH, APPR, WAPPR et INPRG.

Ce graphique donne une idée des volumes de maintenances effectuées. Il est un résumé sur un an des tableaux de chiffres de la première page du rapport.

Figure 22 Graphique "PM & CM WO counts".

Totaux des autres status:

Titres: "PM counts other status" & "PM counts other status".

Ce graphique est un récapitulatif sur un an glissant des totaux de maintenances préventives (PM) et correctives (CM) pour les statuts autres que CLOSE et INPRG.

Il recouvre l'année précédant la date de fin du rapport.

Figure 23 PM & CM other status counts.

Il s'agit comme le précédent d'un récapitulatif sur un an des informations du tableau se trouvant dans la première page du rapport.

Suivant que l'on s'intéresse aux PM ou au CM, il ne présente pas le même intérêt.

Pour les PM, on observera en premier les états WMATL et WOPCOND. L'état de WMATL permet de détecter des problèmes d'approvisionnements ou de prévision des maintenances. Trop nombreux, les états WOPCOND indiquent que les opérations empêchent les maintenances de s'effectuer. Cela peut amener à des discussions avec le client pour laisser des fenêtres de travail plus importantes ou encore de tolérer des arrêts programmés.

Le statut CAN qui indique une annulation. Lorsqu'il s'agit de maintenances préventives, il peut signifier deux choses: Soit des maintenances surnuméraires par exemple, une maintenance d'un sous équipement faite dans une autre PM. Ou encore des problèmes de planifications des maintenances.

Pour les CM, un fort taux de WMATL est assez normal même s'il est tentant d'essayer de le réduire. Un fort taux de WOPCOND indiquerait que certains équipements ou parties d'équipements ne peuvent être réparés faute de fenêtres opérationnelles.

Pourcentages des overdue et des PM:

Titre: "PM percents".

Ce graphique regroupe plusieurs informations. Le taux de maintenances préventives relativement à toutes les maintenances effectuées. Le taux global de maintenances exécutées en retard ainsi que les retards des maintenances spécifiques à la certification ISM.

Un taux de maintenances préventives au-dessus de 75% est jugé acceptable dans la littérature de la maintenance, 80% étant une valeur très correcte. Toutefois, ces taux sont à relativiser si les maintenances correctives ne sont pas toutes enregistrées.

Les taux de maintenances en retard doivent être les plus faibles possible surtout en ce qui concerne les maintenances ISM. Toutefois, il faut prendre en compte le mode de comptabilisation qui considère une maintenance "overdue" si la date de sa réalisation a dépassé 25% de la période. Il faudra juger sur exemple du bien fondé de cette technique.

Figure 24 Graphique "PM ratio & overdue".

Critique de ces graphiques:

La plupart de ces graphiques ne sont que des regroupements des chiffres, mais ils ne donnent pas une vision synthétique de la situation. Cela est-il d'ailleurs possible ?

On souhaiterait pouvoir trouver des indicateurs nous indiquant simplement:

- Trop de délais dans les achats.

- Achats mal planifiés.

- Pas assez de fenêtres opérationnelles...

Des valeurs plus directives quant aux points où concentrer notre action.

Il est clair que ces graphiques ne représentent que des synthèses de chiffres et ne pourront se substituer à des analyses plus approfondies au niveau des catégories, équipements ou tout autre critère de regroupement.

Minutes of meeting "Expression des besoins prototype N°4"

 

Situation:

Base "Pride Foramer" Luanda le 20 Août 2004.

 

Participants: 7 personnes. Durée 1 heure.

- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.

- LDAO: Directeur des opérations client TOTAL. Initiateur du projet.

- 2*LDAM: Directeur de la maintenance LDA et son assistant.

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

 

Rappel sur l'objectif de la réunion:

- Valider le format du prototype N°4 et les nouveaux graphiques.

- Faire de nouvelles propositions ou corrections du rapport existant.

 

Propositions et remarques des participants:

- Il est demandé un document permettant de donner des explications sur le rapport MMR. Les utilisateurs veulent savoir d'où viennent les données et ce qu'elles expriment.

- Les utilisateurs sont majoritairement satisfaits du rapport et demandent son implantation sur les chantiers. L'objectif étant de sortir le rapport sur plusieurs mois afin de juger de l'intérêt des données qui s'y trouvent.

- Il est demandé de rajouter une liste des maintenances préventives en retard pour les maintenances majeures. Par maintenances majeures, on entend: au-dessus de 1 an, 1000h ou ISM.

- Les graphiques correspondent bien aux demandes des utilisateurs, mais d'aucun se demandent comment les interpréter. Nous ne pourrons juger que sur des exemples et après analyse d'une situation réelle.

- Une partie financière ne serait-elle pas nécessaire pour compléter ces informations ?

Il s'agit d'un sujet délicat pour des raisons plus politiques que techniques. Maximo n'est pas un logiciel de comptabilité. Dés que l'on sort des montants, certains se voient dans l'obligation de les comparer à d'autres et cherchent des interprétations là ou les calculs sont faits différemment (taux de change, période, coût de la facture ou moyenne des coûts de stock...)

- Le CPI informe que les résultats n'ont pas encore été validés complètement et que cela représente un gros travaille. Cela ne semble pas inquiéter les utilisateurs.

 

Conclusions:

- Rédaction d'un document descriptif du rapport et donnant des détails et explications sur la provenance des données et la signification des graphiques.

- Demande l'implantation du rapport dans le Maximo des cinq chantiers accessibles par le réseau commun de la compagnie. La version restera 0.4b jusqu'à nouvel ordre.

- Nous allons chercher dans la littérature s'il existe des méthodes plus synthétiques pour analyser une situation de maintenance.

- Nous allons chercher à créer une partie financière du rapport sans toutefois essayer de la faire coller au niveau comptable.

- On note un certain essoufflement des utilisateurs en ce qui concerne les idées de modifications du rapport. Ils veulent obtenir des résultats chiffrés rapidement et juger sur pièce de l'intérêt de chaque modèle du rapport.

Intégration du rapport n°4 dans Maximo:

L'ensemble du développement du rapport a été exécuté sur un ordinateur portable ne possèdent qu'un disque C:. Toutes les installations des serveurs se trouvent en D:. Il conviendra donc de changer cette valeur dans les programmes et de les recompiler avant la mise en production.

Le logo de notre société se trouve en général dans le répertoire "SQR4" des postes. Toutefois après observation sur différents serveurs, il peut aussi se trouver ailleurs. A défaut d'avoir pu obtenir d'informations complémentaires, nous ajouterons donc quelques lignes de code pour rechercher ce logo dans différents endroits.

Jusqu'à maintenant, le passage des paramètres entre l'utilisateur et le programme se produisait soit dans la fenêtre d'exécution soit dans une fenêtre de saisie générée par "SQRWT". Dans Maximo, les paramètres sont transmis d'une façon différente. Seuls quatre paramètres textes peuvent être transmis aux programmes par une entrée manuelle de l'utilisateur. Dans ce cas, la fenêtre de saisie est générée par Maximo et non par le programme lui-même. En addition, il existe deux autres paramètres transmis par Maximo sans saisie directe de l'utilisateur, mais issus des sélections d'éléments dans les écrans Maximo.

Format des paramètres passés à SQR par Maximo

Variable

Contenu

$where

Contiens l'éventuelle sélection du WHERE de la clause SELECT. La liste est créée à partir des éléments suivants:

- Les champs peuvent être représentés sous deux formes:

<fieldname>. P.ex: EQNUM= '0533'.

<table>.<fieldname>. P.ex: EQUIPMENT.EQNUM LIKE '0536021%'.

La première est utilisée lorsque l'on ne sélectionne qu'une valeur. La seconde dans les autres cas.

- Sélection dans une suite de valeur limitée:

<table>.<fieldname> IN (<value list comma separated>).

P.ex: EQUIPMENT.EQNUM in ('053901005', '053607910').

- Sélection de plusieurs champs:

<expression list>=<expression [AND <expression list> ]

P.ex: @upper(EQUIPMENT.CLASSIFICATION) = 'ACMOTORS' AND EQUIPMENT.VENDOR = 'GE'.

Note1:

Les valeurs passées dans $where dépendent de la sélection effectuée lors du lancement du rapport. Dans la fenêtre de lancement, le champ "Range" permet de sélectionner:

- "No input": Lorsque le champs $where n'est pas utilisé. Dans ce cas, il contient 1=1.

- "Current record": Sélectionne le champ courant. P.ex: EQNUM= '0533'.

- "Current selection": Toutes les autres possibilités.

Note2:

L'utilisation du paramètre $where nécessitera de construire les requêtes SQL en fonction des paramètres passés. Il faudra enlever l'ambiguïté lorsque l'alias ne sera pas passé par Maximo. Les paramètres passés ne correspondent qu'à ceux de la table principale du module concerné. Il n'existe pas de possibilité de requêtes sur plusieurs tables même si l'écran affiche des valeurs d'autres tables.

 
 

$p1

1er paramètre saisi par l'utilisateur. Vide si rien de saisi.

$p2

2ième paramètre saisi par l'utilisateur. Vide si rien de saisi.

$p3

3iéme paramètre saisi par l'utilisateur. Vide si rien de saisi.

$p4

4iéme paramètre saisi par l'utilisateur. Vide si rien de saisi.

$schema

Apparemment toujours égal à Maximo.

 
 

Note3:

Tous les paramètres sont au format Texte et sont simplement récupérés par une fonction "input" du langage SQR. P.ex INPUT $P1.

Table 15 Paramètres de la ligne de commande Maximo.

Dans notre cas, seul le paramètre $p1 sera utilisé. Il contiendra une date dont le format reste encore à définir. Dans l'immédiat, on y entrera le jour suivant de la date de fin du rapport au format DD/MMM/YYYY.

Par exemple: 01/FEB/2004 pour un rapport couvrant le mois de janvier et précédents pour les graphiques.

Le rapport MMR sera disponible dans la liste des rapports liés au module "PM" uniquement. On ne lui appliquera aucune restriction d'accès et tous les utilisateurs pourront l'exécuter.

Le paramétrage d'un rapport dans Maximo se fait comme suit:

- Se logger en Administrateur Maximo.

- Aller dans les menus "Setup", "Reports and other Apps".

- Aller dans le menu "View", "Application list" et sélectionner "SQRW", "SQR report writer".

- Aller dans le menu "Insert", "New row" et remplir les valeurs des colonnes du tableau comme suit.

- Dans "Filename", entrer "MMR".

- Dans "Maximo application", sélectionner "PM" dans la liste proposée. On suppose dans ce cas que ce rapport ne sera visible que du module "Preventive Maintenance".

- Dans "Description", entrer "Monthly Maintenace Report".

- Dans "Command line", enter "SQRWV {SPOOL}MMR.SPF".

- Sauver les modifications, "File", "Save Application".

Figure 25 Module "Reports and other Apps" de Maximo.

Ensuite, il faut paramétrer les prompts de Maximo pour cette application:

- Sélectionner la ligne du rapport concerné. En l'occurrence, "MMR".

- Aller dans le menu "Action", "Specify Users prompts".

- Saisir le texte du prompt:

"Before date (DD/MMM/YYY):"

dans la fenêtre suivante.

- Sauver l'application, "File", "Save Application"..

Figure 26 Prompts des rapports Maximo.

Dans la mesure où l'auteur ne peut aller sur tous les chantiers dans une période courte, il lui faudra effectuer les opérations à partir du chantier ou il se trouve.

L'installation sur les différents chantiers se fera à distance à l'aide de "Windows Terminal Server". Il nous faudra dans un premier temps, transférer la version compilée .SQT du programme sur un répertoire partagé des serveurs et les copier dans le répertoire D:\SQR4\REPORTS\PRIDE\ qui contient l'ensemble des rapports spécifiques à notre société.

Cela nécessite de disposer des droits d'accès au serveur lui-même ou encore à un répertoire partagé d'un PC du domaine ou se trouve le serveur. Le CPI dispose de tous les droits Administrateur sur tous les postes des réseaux d'Angola. Par contre, il n'existe pas de standard concernant les répertoires partagés.

Ensuite, les opérations de configuration de Maximo se feront comme décrit dans les lignes qui précèdent.

Tests en réel sur les serveurs des chantiers:

- L'installation du rapport proprement dit et la configuration de Maximo n'ont posé aucun problème sur aucun des sites. Seule la lenteur de "Windows Terminal Server" lors des opérations à distance a imposé des temps de mise à jour non négligeables avec parfois des coupures de communications intempestives.

- Le rapport a été implanté sur 5 sites: PAN, PAF, PNA, PSP, BDA.

- Sur PNA, il a fallu réorganiser la base pour pouvoir sortir le rapport. Le CPI se trouvait sur le site à ce moment ce qui n'a pas posé de problème. Cette opération est possible à distance, mais pose des problèmes en cas de reprise. On évitera de procéder à distance.

- Sur PSP, le rapport ne fonctionnait pas, car certains départements n'existaient pas dans le programme. Nous avons traité le cas avec une colonne supplémentaire comptant les cas non répertoriés. Cette colonne pourra être utilisée par les administrateurs de Maximo pour corriger ces valeurs. Dans la mesure ou nous explorons la totalité des fichiers historiques, il ne nous est pas possible de ne pas les prendre en considération.

La base de PSP a aussi nécessité une réorganisation pour fonctionner.

La réorganisation de la base se passe en plusieurs étapes:

Voir "SQL base, database Administrator's guide" et "SQL base, SQL language reference".

On évite de faire cette opération à distance pour des problèmes de récupération s'il se produit un problème lors du processus. Seuls les opérateurs avec droits que sont les administrateurs de Maximo peuvent exécuter ces opérations.

Les opérations à effectuer sont les suivantes:

- S'assurer qu'aucun utilisateur n'est connecté à la base de donnée.

- Sortir du moteur de la base de donnée.

- Faire une sauvegarde du fichier .DBS de la base de données. La base de donnée peut être perdue si une erreur se produit durant la réorganisation.

- Relancer le moteur de la base.

- Lancer SQLTalk.

- Se connecter à la base de données en tant qu'Administrateur.

- Lancer les commandes SQL suivantes après s'être assuré qu'aucun utilisateur n'est connecté à la base de données:

set recovery off; Principalement pour des problèmes de performances.

check database; effectue un test d'intégrité complet de la base donnée (données et index).

reorganize; Défragmentation de la base de donnée (Unload to a file, initialize, Reload from Unload file).

set recovery on;

update statistics on database; Remets à jour les statistiques de la base de données.

exit; Sortie de SQLTalk.

Minutes of meeting prototype n°4 par les utilisateurs des chantiers:

 

Situation:

Le prototype n°4 a été installé sur 5 chantiers. Les résultats du mois de juin 2004 ont été diffusés aux utilisateurs avec un explicatif sur les différentes informations fournies par le rapport ainsi qu'un mode d'emploi.

Ce document contient le résumé des remarques des personnels de chantier après installation du prototype sur les chantiers et après visualisation des résultats du mois de juin 2004. Les personnes rencontrées ont été variées à tous les niveaux de la hiérarchie.

 

Participants: 7 personnes. Durée1 heure.

- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.

- TC chantiers: PAN, PAF.

- SM chantier: BDA.

- MSUP Maximo Houston.

 

Rappel sur l'objectif de la réunion:

- L'objectif de ces réunions est d'obtenir les avis des différentes personnes concernées par le projet à propos du format du rapport ainsi que l'intérêt de son contenu.

- Le but est de créer un prototype n°5 avec les nouvelles informations à partir de ces remarques.

 

Propositions et remarques des participants:

- La partie liste des "Material Request" associée aux "Work Order" dans l'état WMATL est appréciée.

- Les parties "Major PM previsions" et "Equipement down" sont jugées intéressantes. La période de 6 mois pour la partie prévision des PM est jugée acceptable, car elle correspond au temps moyen d'approvisionnement du matériel.

- La partie TOP5 est jugée intéressante, mais n'indique qu'une situation passée. Elle pourrait être intéressante sur plusieurs mois si le même équipement revient dans la liste. Il semble clair que d'autres rapports devront étayer ces informations.

- Les TC confirment ne pas utiliser les "Downtime" par peur d'oublier de remettre les équipements Up avant de fermer le "Work Order".

- Les utilisateurs ont une peur concernant ce rapport:

· Ils pensent que ce rapport servira à la direction de LDA et de Houston de comparaison entre chantiers afin d'entretenir une compétition.

· Les différents services s'inquiètent de voir apparaître les heures cumulées par service. Il leur semble que ces heures sont faibles par rapport aux équipes et au travail effectué dans la réalité.

· Les pourcentages d'overdue sont aussi une source d'inquiétude, car le pourcentage moyen autour de 35% paraît important. Ils demandent une liste des "Overdue" principaux. On confirme que les "Major Overdue" sont les PM >1 an et 1000h ayant dépassé 25% de la période de la maintenance.

- Les TC demandent l'ajout d'une partie financière au rapport. Pas d'idée précise sur le format. On nous demande de faire des propositions.

- Tenter d'améliorer la lisibilité du rapport et corriger certaines erreurs d'affichage.

- Le CPI rappelle que les résultats n'ont toujours pas été vérifiés complètement et que cette opération devra être faite un jour ou l'autre avant une utilisation en réelle des données.

 

Conclusions:

- Nous allons ajouter une partie financière au rapport. Reste à en définir le contenu.

- Nous allons créer une liste des "Major PM overdue".

Prototype n° 5:

Corrections d'erreurs de programmation:

- Problèmes de tailles de certaines colonnes par rapport aux champs affiché.

- Changement de taille de police et mise en gras de certains titres.

- Correction du rapport de prévision. Certains équipements étaient détectés par erreur à cause d'un problème d'initialisation de variable.

- Les listes de détails suivantes seront imprimées à partir de la deuxième page: "WMATL WO and associated MR", "PM previsions" et la liste additionnelle à ce rapport "Major PM overdue".

Rapport financier:

A défaut d'avoir plus d'informations de la part des utilisateurs, nous proposons d'ajouter trois types d'informations au rapport existant. Dans la mesure ou il s'agit d'un rapport de synthèse, nous ne donnerons pas d'information détaillée pour tous les équipements.

Ce type de rapport sera à prendre avec précautions, car les "Work Order" correctifs n'incluent pas seulement les maintenances, mais aussi des ajustements de stock.

Les calculs seront directement issus des lignes de consommation des "Work Order" CLOSE et pourront être différents des chiffres du rapport financier MOCA qui est en cours de mise au point et pour lequel nous n'avons pas d'information sur les moyens utilisés pour le créer.

Nous avons délibérément choisi de ne pas inclure les consommations de stock des "Work Order" ouverts ceux-ci se retrouvant dans les mois suivants dés leur fermeture.

L'objectif étant d'avoir une idée des consommations plutôt qu'un rapport comptable, nous pensons que cela ne posera pas de problème. Ce qui n'empêche pas d'essayer d'avoir un rapport juste par ailleurs...

Proposition 1:

De même que nous avions donné le détail des heures consommées par chaque service et pour chaque département, nous proposons d'ajouter une ligne détaillant la répartition des coûts par département avec les totaux du mois courant, du mois précédent et la différence entre les deux. Les calculs seront faits pour les maintenances préventives et correctives et uniquement sur les "Work Order" CLOSE dans le mois.

Ils pourront être comparés aux budgets mensuels attribués à chaque département.

Figure 27 Coûts des Work Order CLOSE par département.

Proposition 2:

De même que nous avions fait une liste des 5 premiers équipements consommateurs de temps, nous proposons une liste des 5 premiers équipements consommateurs de budget. Les calculs seront faits pour les maintenances préventives et correctives pour les "Work Order" CLOSE dans le mois uniquement.

L'objectif de ce type de liste est d'essayer de repérer les équipements les plus consommateurs de budget. Ces listes devront être examinées au cours de mois pour être utiles.

Figure 28 TOP5 PM & CM stock consumption.

Proposition 3:

Nous proposons aussi un graphique récapitulatif des coûts engendrés par les maintenances préventives et correctives sur un an glissant à partir de la date du rapport.

Ces chiffres seront à comparer aux budgets mensuels du chantier et pourraient servir à préparer les budgets à venir.

Figure 29 Work Order costs.

Liste des principales maintenances préventives en retard:

Les utilisateurs veulent pourvoir obtenir un récapitulatif des principales maintenances en retard. Par principales, on entend de période supérieure à 1 an, au-dessus de 1000h ou encore celles liées aux équipements de catégorie ISM.

Il faut noter que si le rapport est imprimé après coup, les "Work Order" seront indiqués majoritairement CLOSE. En effet, nous avons décidé d'imprimer le statut du "Work Order" au moment de l'impression. Par contre, la liste provient des historiques et correspond bien aux "Overdue" de l'époque concernée. Ce rapport ne sera utilisé que de mois en mois pour le suivi courant, il n'aura plus d'intérêt après coup.

Figure 30 Major WO PM overdue.

Minutes of meeting "Expression des besoins prototype n°5":

 

Situation:

Base "Pride Foramer" Luanda le 10 Août 2004.

 

Participants: 3 personnes. Par courrier électronique.

- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.

- LDAO: Directeur des opérations client TOTAL. Initiateur du projet.

- LDAM: Assistant au directeur de la maintenance LDA.

 

Rappel sur l'objectif de la réunion:

- Statuer sur l'état d'avancement du prototype.

- Critique du prototype n°5 et propositions d'améliorations.

- Statuer sur les résultats obtenus des chantiers après l'installation du rapport n°5 sur les chantiers.

 

Propositions et remarques des participants:

- Les utilisateurs sont majoritairement satisfaits des corrections apportées.

- Demande est faite d'ajouter une ligne concernant les certifications expirant dans les trois mois. L'information est maintenant disponible dans le module équipement. Nous statuons que ces informations devront faire l'objet d'un rapport spécifique additionnel, car il ne s'agit pas de maintenance proprement dite.

- Décision est prise de transmettre le prototype au siège de Houston afin de l'inclure dans les standards de rapport de la société. Nous précisons qu'il ne s'agit que d'un prototype et que les phases suivantes seront:

§ Test complet des résultats du rapport sur plusieurs mois. Actuellement, les tests non été fait que par échantillonnage.

§ Amélioration de la documentation du programme.

§ Documenter les résultats du rapport de façon plus complète en créant un manuel utilisateur.

§ Adaptation du programme aux différentes configurations de Maximo dont nous n'avons pas connaissance.

§ Vérifier la finitude du programme et ajouter des contrôles d'erreurs plus efficaces.

Il restera toutefois à convaincre le siège de Houston que ce rapport doit être implanté sur nos unités avec le nouveau standard de rapports qui est en cours d'installation. Notre implantation actuelle n'a pas eu l'aval officiel d'une façon très explicite et l'on sent que nous marchons sur des oeufs même si l'accord initial de développement a été obtenu.

 

Conclusions:

- Décision est prise d'installer cette nouvelle version v0.5b sur l'ensemble des six chantiers d'Angola sans attendre l'accord explicite du département maintenance de Houston.

- Communication du rapport au département de maintenance de Houston pour approbation de l'installation sur l'ensemble des chantiers d'Angola. L'envoi comprendra les sources de prototype ainsi que les documentations créées pendant le projet.

Conclusion de la partie quantitative:

Conclusions:

- Nous avons réalisé un prototype qui correspond aux requêtes des utilisateurs.

- Il a été implanté sur cinq sites pilotes pour des tests en réel.

- Malgré le bon accueil des utilisateurs, il est encore difficile de savoir de quelle façon il sera utilisé ni quelle sera son influence sur la gestion de la maintenance. Rien n'indique que les souhaits des utilisateurs correspondent à des informations utiles mêmes si elles ont été choisies à priori à bon escient.

- Il reste encore à valider les données obtenues d'une façon définitive. Dans l'immédiat, seuls des échantillons nous ont permis de tester les résultats obtenus.

- Nous avons découvert un certain nombre de disfonctionnement ou d'améliorations à apporter. Ils seront regroupés dans un chapitre spécial.

Note: Un exemple du format définitif de cette partie est donné en Annexe B.

Etude de la partie qualitative.

Dans les chapitres précédents, nous avons extrait et mis en forme des informations de Maximo, mais sans pour autant leur donner un sens précis. Il s'agit d'informations factuelles dont le sens ne peut être extrait qu'après analyse des chiffres ou du contenu. Elles peuvent donner une information sur le passé, mais rien de précis en ce qui concerne les actions à entreprendre sur les maintenances. L'objectif n'était pas d'obtenir des informations détaillées mais une synthèse permettant d'avoir des tendances.

Ce chapitre tente de répondre au problème qui consiste à détecter les défaillances potentielles à partir des historiques de maintenance de façon à d'éviter les défaillances fonctionnelles futures.

Il existe de nombreuses méthodes plus ou moins élaborées pour obtenir des informations qualitatives à partir des données d'historiques de maintenance. Nous allons examiner les plus répandues et juger de leur intérêt et de la fiabilité des données de Maximo nécessaires pour les obtenir. Certaines parties feront l'objet d'un prototype de rapport. Les prototypes prendront en compte les remarques faites lors de l'expression des besoins initiale. Nous resterons dans la phase d'exploration des solutions et ferons des propositions sur les solutions qu'il faudrait explorer plus avant.

Cette partie devrait plus intéresser les TC ou MSUP que les gestionnaires. En effet, ceux-ci sont plus au fait des problèmes de terrain et plus à même de juger de la valeur des résultats et de leurs implications en terme de maintenance.

A chaque fois, il conviendra de considérer les risques que l'on peut prendre en changeant un plan de maintenance à partie de données statistiques. Plusieurs critères doivent être pris en compte:

- Le calcul des avantages / risques. En clair, quels sont les gains en coûts de maintenance par rapport au risque d'avoir mal interprété les données. Il faut pouvoir évaluer la qualité des données enregistrées au moins sur un lot d'équipements sensibles.

- Il faut aussi savoir si contractuellement on peut outrepasser les préconisations des constructeurs par le simple fait de statistiques internes.

- Pour les équipements engageant la sécurité des installations ou des personnes ou encore l'environnement, ces décisions ne pourront pas être prises au niveau du chantier, mais seulement après discussion avec des experts du domaine et les responsables opérationnels. Cela peut aussi impliquer d'autres interlocuteurs auxquels nous devrons fournir des justificatifs en cas de défaillances liées à des défauts de maintenance.

Qualité de la maintenance et TPM:

Nous avons vu dans la présentation de la TPM que la métrique utilisée pour juger de la qualité de la maintenance était nommée TRS (Taux de Rendement Synthétique).

Cette valeur est le produit de trois résultats appelés respectivement:

- Taux brut de disponibilité: B/A.

- Taux de performance: C/B.

- Taux de qualité: D/C.

Chaque valeur peut être exprimée comme suit:

- A "Temps d'ouverture": Est la durée de travail potentiel de la période de calcul. Dans notre cas, nous travaillons 24h/24h tous les jours de l'année.

- B "Temps brut de fonctionnement" = A - Temps d'arrêts planifiés:

Cela pourrait concerner seulement les maintenances, mais en TPM cela concerne aussi tous les autres arrêts normaux pendant lesquels l'outil de production n'est pas actif (programme de production, réunions, maintenance préventive). Toutefois, en pratique même si les maintenances préventives sont planifiées à intervalles réguliers, elles ne sont faites le plus souvent que pendant des fenêtres opérationnelles n'engageant pas d'arrêt. Dans le cas où elles occasionnent des arrêts ceux-ci ne sont pas distinguables des maintenances préventives normales.

- C "Temps net de fonctionnement" = B - pannes ou moindres performances:

Les pannes peuvent être caractérisées par un rapport de "Downtime" dans le module équipement. On pourrait aussi prendre en compte les temps globaux de pannes calculés à partir des maintenances correctives pour caractériser la moindre performance.

- D "Temps utile de fonctionnement" = C - Non qualité:

Dans la TPM, la non qualité concerne les pièces mises au rebut ou qu'il faut retoucher. Cela inclut aussi le temps perdu lors du démarrage de la production et la mise au point des outils. Il n'existe pas de telles notions dans notre environnement. Il existe bien une notion de tarif journalier réduit à la suite de litiges contractuels (équipement non opérationnel ou manquant, vitesse réduite), mais les chiffres ne peuvent être obtenus de Maximo.

Il faut noter aussi que les heures cumulées des maintenances correspondent au travail de plusieurs équipes, mais pas d'un équipement seul.

Exemple de calcul:

Sur le chantier PAN, entre le 01 mars 2004 et le 31 mars 2004 = 744 heures. Nous avons eu 1324h de maintenances préventives, 922 heures de maintenances correctives. Nous considérons que la non qualité n'existe pas ou n'est pas calculable.

TRS = (B/A)*(C/B)*(D/C)=(1324/744)*(922/1324)*(922/922)=1.24.

Ce résultat n'a pas un sens précis, car les calculs de temps des maintenances sont calculés sur l'ensemble du personnel de maintenance et non sur des calculs de taux liés à des quantités de fabrication sur une chaîne de production. Il nous faudrait trouver d'autres informations non disponibles dans Maximo ou une autre méthode pour calculer ce rendement.

Conclusions:

- Nous ne pensons pas qu'il soit possible d'utiliser le taux de rendement synthétique (TRS) comme marqueur de qualité de le TPM en tant que tel dans notre contexte.

- Ce type de marqueur est trop global pour pouvoir donner des informations utiles sur la qualité de la maintenance et les actions à entreprendre.

- Le pourcentage de maintenances préventives par rapport à l'ensemble des maintenances effectuées paraît être un marqueurs plus significatif si il s'agit de n'avoir qu'un chiffre de synthèse. Ce marqueur a déjà été calculé dans le prototype quantitatif.

Nous pourrions remplacer les paramètres temps par des paramètres économiques, mais nous ne disposons pas de ces informations dans Maximo (coût horaire des employés, coûts de l'arrêt ou de moindres performances, coûts du stock...)

Marqueurs de base de la fiabilité:

Nous avons vu que l'un des objectifs de l'analyse des historiques de maintenance était d'optimiser les maintenances préventives. L'une des méthodes pour le faire est l'analyse de la fiabilité des équipements au cours du temps. Ce type d'informations pourrait nous aider à préciser les points suivants:

- Changer la périodicité des maintenances préventives pour les faire correspondre au taux de panne.

- Détecter les équipements à problèmes en examinant les taux de pannes.

- Changer les "Job Plan" afin de les faire correspondre aux problèmes le plus fréquemment détectés.

Il existe un certain nombre de marqueurs de base de la fiabilité que nous allons examiner dans ce chapitre (Fig.31). Ces marqueurs sont tous basés sur des moyennes d'évènements et doivent être utilisés avec circonspection. Bien entendu, ces marqueurs sont tous basés sur l'analyse des maintenances correctives et non des maintenances préventives. On peut citer:

- MTTF (Mean Time To Failure): Il s'agit de la moyenne du temps de vie de l'équipement avant la première panne. Il nécessite de définir correctement l'état initial t=0.

- MTTR (Mean Time To Repair): C'est le temps moyen de réparation d'un équipement. Lorsque l'équipement possède plusieurs modes de défaillance, on devra définir un taux pour chacun d'eux.

- MDT (Mean Down Time): Est le temps moyen entre un défaut et la remise en service de l'équipement.

- MUT (Mean Up Time): Est le temps moyen de fonctionnement entre la dernière remise en service après réparation et le prochain défaut.

- MTBF (Mean Time Between Failure): C'est le temps moyen de fonctionnement entre deux défaillances de l'équipement. MTBF=MDT+MUT.

- Taux de défaillance : Est l'inverse du MTBF. =1/MTBF.

- Taux de réparation : Est l'inverse du MTTR. =1/MTTR.

- Disponibilité: Elle est égale au rapport MTBF/(MTBF+MTTR).

Figure 31 Marqueurs de base de la fiabilité.

Chacun de ces marqueurs est utilisé principalement pour juger de la qualité de la maintenance dans les domaines suivants:

- Fiabilité: L'aptitude d'un équipement à fonctionner dans des conditions données d'utilisation est caractérisée par le MTBF et le MTTR.

- Disponibilité: L'aptitude d'un équipement à fonctionner quand on le sollicite est caractérisée par le MUT et le MDT.

- Maintenabilité: L'aptitude à être entretenu et remis en fonctionnement est caractérisée par le MTBF et MTTR.

- Sûreté: L'aptitude à fonctionner tout en respectant les individus et l'environnement. Elle n'est pas caractérisée par un de ces paramètres, mais est souvent liée à une situation dépendante de l'état des paramètres précédents.

Il convient aussi de se poser les questions et de considérer les points suivants:

- Pour chacun de ces paramètres, il serait bon d'introduire la valeur de l'écart type "" qui nous indiquera la variabilité des valeurs autour de la moyenne. Les valeurs pouvant varier de (Moyenne +- 2*). Un écart type faible indiquera une faible variation autour de la moyenne.

- Il conviendra aussi de déterminer les conditions de départ des calculs. Ferons-nous les calculs sur la totalité du cycle de vie de l'équipement, entre les PM ou seulement sur une année ? Un calcul sur plusieurs périodes permettrait de comparer plusieurs périodes entre elles et de voir l'évolution.

- Au regard de l'organisation de l'arbre des équipements, devrons-nous faire le calcul du MTBF et MTTR sur un équipement seul ou sur l'ensemble des branches à partir de cet équipement. La réponse est très dépendante de la partie de l'arbre ou l'on se trouve. Un MTTR ou un MTBF sur l'ensemble du chantier n'a pas de sens précis. Il n'a un intérêt que si on l'associe à un sous équipement et surtout si l'on peut catégoriser les types de défauts.

L'objectif principal de ce type d'information étant la gestion des maintenances préventives (PM). On peut citer les règles de base suivantes:

· Trop de maintenances correctives et pas de PM: Création de PM adaptées aux problèmes rencontrés.

· Trop de maintenances correctives malgré les PM existantes: Changement des périodicités ou du contenu des "Job Plan".

· MTBF inférieur à l'intervalle entre PM: Changement du contenu des Job Plans ou de la périodicité.

· MTTR trop important: Analyse des rapports de maintenance pouvant justifier les délais.

Il existe aussi dans la littérature une notion de "Fault Finding Interval" ou FFI [MOUB]. Le but de cette valeur est de déterminer l'intervalle entre les interventions à partir des informations de fiabilité des équipements et si des possibilités de détection de pannes potentielle existent. On part du principe que les défauts peuvent être détectés avant qu'il se produise dans la mesure ou les informations statistiques sont disponibles. Même si beaucoup de défauts ne sont pas directement liés au temps de service de l'équipement, il est souvent possible de détecter des défauts en analysant un certain nombre d'alertes données par le matériel lui-même. C'est ce que tente d'exprimer le diagramme suivant (Fig.32).

Figure 32 Graphique P-F.

Entre le moment où commencent à se produire le défaut et le point F ou il s'est produit, se trouve un ou plusieurs points P permettant de détecter que le défaut va se produire. Il peut exister plusieurs points P suivant la technique employée pour détecter la faute. La zone P-F dite zone d'alerte est celle pendant laquelle des maintenances peuvent se produire avant le défaut complet de l'équipement. On peut l'exprimer en unités différentes du temps si la pratique le justifie. Si les maintenances préventives sont faites à des intervalles supérieurs à cet intervalle, il est possible de rater la détection. Si elles sont faites à des intervalles trop courts, il s'agit plutôt d'une mauvaise utilisation des ressources de la maintenance entraînant des coûts supplémentaires.

Nous effectuerons les calculs à partir des éléments suivants:

- Le ou les équipements ont subi des maintenances préventives à un intervalle donné FFI et les défauts ont été enregistrés pendant une période donnée.

Temps total de service = Nombre d'équipement * période de mesure des défauts.

- Le MTBF a été calculé avec les informations précédentes.

MTBF = Temps total de service / Nombres total de pannes pendant la période.

Comme on ne sait pas si la panne se produira en début ou en fin de période, on choisira le milieu de la période.

- Le taux de panne, %TDP doit être choisi par l'utilisateur de l'équipement en fonction de critères qui lui sont propres.

On calcule alors: FFI = 2 * %TDP * MTBF.

Ce type de calcul ne peut se faire en automatique que si l'on connaît le %TDP désiré pour l'utilisateur. Ce paramètre ne peut être défini facilement pour les 5000 équipements des chantiers. Il faudra utiliser le MTBF obtenu par le prototype que nous allons créer ou par des données externes fiables (constructeurs, bases de données de données de fiabilité...) et choisir les équipements qui pourraient être concernés par ce type de calcul. De la qualité des données dépendra le résultat. Il faudrait aussi considérer le cas des pannes multiples pour lesquelles ce type de calcul n'est pas valable sauf si l'on calcule le MTBF des différents éléments à considérer. Il faut savoir aussi que les probabilités de pannes d'un équipement sont liées à tous ses sous-équipements et non pas seulement aux branches de l'arbre.

Il paraît donc difficile d'automatiser ce type de calculs. Tout au plus pourrons-nous donner les informations de fiabilité obtenues à l'aide des MTBF. Il restera à déterminer de façon précise la fiabilité des données obtenues.

Données de Maximo:

Afin d'effectuer ces calculs, il nous faut disposer des informations concernant l'état des équipements ainsi que le détail des opérations concernant les interventions.

Dans Maximo, ces informations peuvent se trouver dans plusieurs modules:

- Les historiques du statut des équipements pour les arrêts (downtime). Cela ne concerne que les arrêts complets des équipements et non les maintenances correctives. Donc, cette information n'est pas utilisable telle qu'elle se présente.

- Un "Work Order" contient un certain nombre de champs qui nous permettraient de retrouver ces informations.

· Le champ "Duration": Contient le temps passé pour effectuer les opérations de maintenance, il est facultatif et (rempli correctement 8 fois sur 10). Il devrait contenir le nombre d'heures homme pour effectuer le travail. Toutefois, cette valeur pose un problème, car rien n'indique le nombre de personnes ayant effectué le travail. Nous pourrions calculer le MTTR à partir de cette valeur, mais cette valeur sera à prendre avec précautions, car elle correspondra à une moyenne d'un total d'heures et non à une durée entre le démarrage des opérations et la fin des opérations.

En pratique, à l'examen des données entrées dans Maximo, on s'aperçoit que cette valeur correspond plutôt au temps passé entre le début et la fin des opérations de maintenance. Elle ne tient pas en compte le nombre de personnes. Elle est évalué au jugé par les personnes effectuant le travail ce qui le rend difficile à utiliser.

· Les champs "Start Date" et "Finish Date": Doivent indiquer les dates de début et de fin de la maintenance, mis à part la chronologie, ils ne sont pas contrôlés et ne sont pas lié aux dates des statuts du WO. Ce ne sont pas des champs obligatoires, mais ils sont remplis pratiquement systématiquement. Cette valeur serait de meilleure qualité que le champ "Duration" pour calculer le MTTR.

· Le champ "Status" associé aux dates "Status date" ou "Reported date" pourraient nous fournir des informations. Toutefois, il n'y a pas forcement de lien temporel entre ces dates et celles des opérations sur le terrain.

- Dans les historiques des "Work Order" se trouvent les dates des différents états pris par un WO de maintenance corrective. Le statut d'un WO ne préjuge pas des dates ni des durées de la maintenance sur le terrain. Il n'y a pas forcement de lien temporel entre les opérations de maintenance et les rapports effectués dans Maximo.

- Dans notre version actuelle de Maximo, il n'existe pas de méthode permettant de caractériser le mode de défaillance de l'équipement. Tout calcul de MTTR se fera donc sur l'ensemble des modes de défaillances.

- Un certain nombre de "Work Order" sont créés pour sortir des consommables ou pour ajuster les stocks. Il ne s'agit pas de travaux de maintenance sur les équipements. Il faudra trouver une méthode pour les éliminer des moyennes. Il semble que le mot REGULARIZATION soit toujours présent dans le texte de description de ce type de WO. Toutefois, ce n'est pas une pratique formalisée et elle pourrait être différente sur d'autres chantiers que ceux examinés. Nous n'utiliserons pas cette méthode de filtrage.

En conclusion, seul le MTTR pourrait être calculé d'une façon relativement précise, mais seulement sur l'ensemble des modes de défaillances d'un équipement. Ce qui limitera singulièrement son intérêt pour détecter les parties des équipements générant le plus de défaillances.

Il est difficile à partir des données de Maximo de déterminer les dates exactes des évènements étant intervenus sur un équipement. Ce qui rend difficile ou approximatif le calcul des autres valeurs. Seule l'utilisation du champ FAILDATE permettrait de palier au problème du MTBF.

Il nous faudra faire des essais d'extraction de données avec les approximations suivantes pour pouvoir obtenir d'autres valeurs:

- Les dates les plus fiables sont les "Start Date" et "Finish Date".

- Les temps t0, t1 et t2 seront confondus et correspondront à "Start Date".

- Les temps t3 et t4 seront confondus et correspondront à "Finish Date".

- Dans ce cas, le MDT=MTTR et MTBF=MDT+MUT=MTTR+MUT.

Le résultat des calculs dépendra grandement de la fiabilité des données entrées dans Maximo. Les écarts types calculés pour les MTBF et MTTR nous permettront de juger de la variabilité des valeurs autour des moyennes, mais pas de la qualité des données. Les maintenances correctives sont par nature aléatoires. Une forte variabilité peut aussi signifier: Des pannes aléatoires ou des durées de réparation aléatoires.

Proposition de prototype de calcul des marqueurs de base de la maintenance:

Nous choisirons dans un premier temps de ne mettre que les valeurs suivantes pour chaque équipement et pour chaque "Work Order" CLOSE sur une période:

- Le nom du rapport sera EQPTSTAT1. L'indice laisse supposer que nous pourrons créer d'autres rapports de mêmes types, mais avec des affichages un peu différents. Ceci, pour la simple raison que les paramètres de Maximo sont imités à 4.

- Les paramètres d'entrée seront les dates de début et de fin de la période du rapport.

- L'entête sera celui utilisé en standard pour les rapports Maximo.

- Numéro de l'équipement. Le numéro d'équipement sera décalé d'un nombre d'espaces égal à sa profondeur dans l'arbre. On pourra au besoin choisir une autre représentation du type "----->" pour signifier le niveau.

- Classement par équipement et sous équipements. Ce qui impliquera de reconstituer une partie de l'arbre des équipements à partir des données EQNUM et PARENT de la table EQUIPMENT. Désignation de l'équipement limitée aux 50 premiers caractères.

- Le nombre de maintenances correctives CLOSE pendant la période concernée.

- Le nombre de maintenances préventives associées à cet équipement.

- Si l'équipement est lié à la certification ISM. Cela permettra de vérifier d'une part que ces équipements possèdent des maintenances préventives et que leur taux de panne est faible.

- MTTR et variance des moyennes trouvées. La variance est nommée SD pour "Standard Déviation".

- MTBF et variance à partir du premier "Work Order" CLOSE de la période. On lui donnera le nom de MTBW (Mean Time Between Work order) afin de limiter l'ambiguïté avec la valeur vraie qui n'utilise pas exactement les mêmes dates.

- Seuls les équipements ayant eu au moins une maintenance corrective seront affichés.

- Nous avons choisi pour ce premier prototype de calculer le MTBF à chaque niveau de l'arbre et non de descendre dans chaque branche. Il reste que cette autre logique devra être explorée aussi dans une autre version. Dans ce cas, il doit être clair que certaines valeurs n'auront pas de sens au fur et à mesure que nous remonterons dans l'arbre. Un MTBF sur un groupement d'équipement de différents types n'a pas de sens.

Analyses des données du prototype:

Après examen des données d'un des chantiers les plus significatifs sous MS-Access, il s'avère que sur 5000 équipements, prés de 2000 sont concernés par les maintenances correctives sur toute la durée de vie du chantier. D'où un problème important de représentation des résultats. Il faut donc limiter les affichages aux valeurs les plus significatives et déterminer s'il est nécessaire de cumuler les résultats à tous les niveaux de l'arbre.

Nous avons donc créé un prototype sous SQR qui permet de sortir le format suivant: (Fig.33)

Figure 33 Exemple de tableau de fiabilité.

L'affichage de tous les équipements donne plus de 80 pages de rapport. Une taille rédhibitoire pour un utilisateur standard. Si on se limite aux équipements ayant eu des WO pendant la période entrée en paramètres, on devrait obtenir une quinzaine de pages sur une période d'un an.

On remarque les points suivants:

- La position d'une maintenance dans l'arbre des équipements n'est pas claire. Certains utilisateurs mettent les WO à la racine et d'autres dans les détails. Nous avons trouvé certaines maintenances correctives à des niveaux de l'arbre où elles n'auraient pas dû être.

- On peut noter une forte variance du MTBF sur certains équipements. Cela peut vouloir dire soit des pannes aléatoires soit des données fantaisistes. Nous avons trouvé beaucoup de valeur du champ DURATION à 0 et parfois plusieurs maintenances correctives identiques à quelques minutes d'intervalles. Il ne s'agit pas de généralités, mais de points à surveiller.

- A l'inverse, une faible variance pourrait indiquer des pannes récurrentes à intervalles réguliers. Dans ce cas, il faudrait déterminer s'il existe un lien entre les pannes rencontrées afin de pouvoir éliminer le problème s'il en est. On pourra aussi vérifier la périodicité des PM ainsi que le contenu des JP pour les adapter au problème.

- Le programme ne traite que les données brutes et non des données censurées. Cela veut dire que les "Work Order" qui ne sont pas des maintenances sont aussi traités comme des défaillances.

- Ce rapport permet d'identifier les équipements suivants:

· Ceux qui ont des maintenances correctives et pas de maintenance préventive. Pour ceux la, il faudra vérifier que des PM n'existent pas à des niveaux supérieurs de l'arbre et qu'elles traitent les cas trouvés dans les CM.

· Ceux dont le MTBF est inférieur au temps entre maintenances préventives. Certains éléments pourraient ne pas être traités dans les PM et devraient être ajoutés au JP.

· Les équipements ISM à fort taux de maintenances correctives ou sans maintenances préventives.

Présentation des résultats aux utilisateurs:

Nous avons présenté le prototype à certains utilisateurs (TC, MSUP). Ils jugent ce type des données difficiles à interpréter. Ils ne voient pas toujours l'intérêt de ces informations qu'ils trouvent trop théoriques.

Conclusions:

- L'analyse des défaut à partir du MTBF et MTTR doit être faite avec beaucoup de prudence surtout si les échantillons ont une faible population.

- Il ne traite pas le cas des appareils travaillant par intermittence.

- Les MTBF et MTTR doivent être calculé par catégorie de panne et non sur la globalité d'un équipement. Cela n'est pas possible dans notre version.

- Les résultats ne doivent être utilisés que sur des équipements sensibles et bien identifiés pour lesquels les données sont entrées avec soin. On pourra procéder par expérimentation sur quelques équipements pour valider la technique. Toutefois le programme ne traite que les données brutes.

- On n'utilisera pas ce type de technique sur des équipement à risque surtout si il s'agit d'aller à la baisse en ce qui concerne la périodicité des maintenances. Dans ce cas, seules les recommandations du constructeur peuvent faire foi en cas de problème et lorsqu'il faudra justifier une défaillance au client ou aux assurances. Par contre rien n'interdit de rajouter des points additionnels ou d'éliminer les maintenances à risques dans les "Job Plan" ou de réduire les fréquences.

- Il faudrait éliminer des calculs tous les "Work Order" ne correspondant pas à de la maintenance proprement dite (sortie de consommables, ajustement de stock...). Cela rends difficile l'automatisation de la méthode car rien ne permet de les identifier.

Méthodes graphiques de base:

Diagrammes de Pareto:

Le diagramme de Pareto permet d'avoir une vision rapide de la contribution d'une catégorie d'éléments par rapport à d'autres. En maintenance, on pourrait par exemple l'utiliser pour visualiser l'importance relative des éléments suivants:

- Nombre de défaillances par équipement.

- Nombre de types de défaillances par équipement.

- Quantités cumulées d'indisponibilité par équipement.

- Quantités cumulées d'indisponibilité par type de défaillance.

Le "diagramme de distribution" contient les cumuls de chaque élément de la catégorie classés par ordre croissant.

Le "diagramme de répartition" ou cumulatif s'obtient de la même façon, mais en traçant la courbe de la somme des critères que l'on a choisi.

Ils s'obtiennent en appliquant la méthode suivante:

- Faire la somme des contributions de chaque élément de la liste (nombre de pannes, cumul des temps, cumul des coûts...)

- Classer les contributions par ordre croissant et leur donner un rang dans la liste.

- Calculer pour chaque élément le pourcentage de chaque ligne et le pourcentage cumulé.

Un exemple suivant permettra d'expliciter ce qui précède à partir du tableau suivant:

Ce tableau donne une répartition des défauts par type d'équipement. On a aussi calculé les pourcentages de chaque ainsi que les pourcentages cumulés. Le tableau est classé par ordre croissant du nombre de défauts.

Equipement

Classe

Défauts

%

% Cumulé

Pompes

1

40

57,1428571

57,1428571

Moteurs continus

2

15

21,4285714

78,5714286

Moteur Alternatifs

3

10

14,2857143

92,8571429

Compresseurs

4

5

7,14285714

100

On obtient le graphique suivant: (Fig.34)

Figure 34 Diagramme de distribution et de répartition.

Le graphique en barres est le diagramme de distribution, celui en courbe est celui de répartition. On a choisi de le tracer en % pour des raisons pratiques de représentation.

Ce type de courbe de défaillance ne donne toutefois qu'une information à la fois et ne tient pas compte d'autres critères. Elle devrait être utilisée en parallèle avec d'autres représentations détaillant par exemple: Les heures d'indisponibilité cumulées, les coûts cumulés ou tout autre paramètre présentant un intérêt pour ce type d'équipement tel que la répartition par type de pannes ou causes de pannes.

Méthode ABC:

La méthode ABC revient à construire le diagramme de répartition de Pareto et de le séparer en trois zones A, B et C. Les éléments de la zone A sont considérés comme les plus importants, ceux de la zone B d'une moindre façon et ceux de la zone C sont ceux qui peuvent faire l'objet d'une simple maintenance corrective vu leur importance. On le nomme souvent 20-80 car il permet de représenter les 20% des éléments qui représentent 80% du critère d'intérêt (P.ex: 20% des pièces représentent 80% du coût).

Figure 35 Diagramme de défaillance.

Sur le graphique précédent (Fig.35), la zone A se trouve entre 0 et 73%, le zone B entre 73% et 97%. Ces zones peuvent être définies autrement afin d'inclure plus ou moins de la proportion du paramètre concerné dans chaque zone. On peut aussi définir une quatrième zone au besoin.

Dans le graphique qui suit (Fig.36), on construit les graphiques sur les catégories d'équipements puis sur les sous catégories pour atteindre les "Failure codes".

Il est possible d'utiliser cette méthode pour effectuer une analyse descendante en partant des catégories, en descendant aux sous catégories pour atteindre le niveau des défauts d'un équipement.

Figure 36 Analyse Pareto descendante.

Utilisation à partir des données de Maximo:

Dans notre version de Maximo, nous n'utilisons pas beaucoup de catégories. Les seules qui soient utilisables sont les suivantes:

- Les "Départements" du module "Work Order". La courbe de Pareto peut être obtenue en reprenant les chiffres du rapport MMR. Il serait aisé de reprendre les chiffres par département pour en sortir une courbe.

- Les "Classifications" et "Sub-classifications" du module EQUIPMENT. Sur un chantier significatif, seuls 30% des équipements (sur ~4800) sont classés par catégories (Table 15). Il faudra donc se méfier des informations non classées et voir si elles ne représentent pas la majorité des totaux.

Table: VALUELIST champ LISTNAME='EQCLASS' sur 4800 équipements

VALUE

VALDESC

Qté

 

VALUE

VALDESC

Qté

ACMOTORS

AC Motors

1148

 

ALTERNAT

Alternator

18

PUMPS

Pumps

532

 

DRILLEQT

Drilling Equipment

18

VALVES

Valves

430

 

Alternat

Alternators

9

TANK

Tank

306

 

MARMISC

Marine Miscellaneous

3

AIRRCVR

Air Receiver

276

 

ELEMISC

Electrical Miscellaneous

1

Valves

Valves, Fittings, Piping

215

 

HOISTEQT

Hoisting Equipment

1

Tank

Tanks,,Bulk System,Ballasts

153

 

MECMISC

Mechanic Miscellaneous

1

COMPRESS

Compressors

66

 

SAFETY

Safety

1

WINCHES

Winches

64

 

Safety

Safety

1

MOTORS

Motors

60

 

SUBSEAEQT

Sub Sea Equipment

1

Compress

Compressor: GD,Atlas...

33

 

HVAC

Heating/Ventilation/Air Cond

1

 
 
 
 
 
 
 

Table 16 VALUELIST classification.

- Par EQUIPEMENT ou sous branches de l'arbre. Toutefois, cela risque de poser un problème de représentation sauf si l'on tolère de larges listes.

- La notion de "Failure class" et "Problem code" n'existe pas encore même si les champs sont représentés dans les WO.

- Les "Sub-Work type" du module WO (champ WOJP4) nous offrent une classification des WO par type de travaux. Ces types ne représentent pas d'intérêt certain et nous n'en tiendrons pas compte. Sur l'exemple suivant, nous obtenons le décompte dans le tableau suivant (Table 16). Cela montre le peu d'intérêt de l'utilisation de cette catégorie.

Sub-Work types utilisés dans la table: WORKORDER, 37000 enregistrements.

Qté

WOJP4

Désignation 

 

Qté

WOJP4

Désignation  

0

 

 

 

104

NDT

Non destructive test

1

CAL

Calibration

 

107

INS

Insulation

7

CMS

Continuous Machinery Survey

 

128

OTHER

 

7

ANA

Analysis

 

220

MPI

 Magnetic Particle Test

36

BOTH

????

 

768

DRN

Drainage

Table 17 Comptage des Sub-work type.

Construction du prototype:

Les paramètres d'entrée du prototype seront les dates de début et de fin du rapport.

Nous ne chercherons pas à effectuer une représentation graphique des résultats dans SQR à cause des limitations graphiques de l'outil. Nous représenterons les données sous forme d'une table que nous pourrons reprendre sous MS-Excel pour tracer les courbes de résultats. Les données seront extraites d'une base de donnée MS-Access dans laquelle nous avons importé les tables de Maximo lors de la construction du deuxième prototype du rapport MMR.

Le prototype effectuera les calculs suivants pour les "Work Order" CLOSE uniquement:

- Coûts cumulés des CM par classification sur la période.

- Heures de maintenances cumulées CM par classification sur la période.

- Quantités de CM associées à chaque classification sur la période.

Exemples de résultats obtenus par l'intermédiaire du prototype:

Les trois exemples de la figure ci-après (Fig.37) nous indiquent que la loi de Pareto est respectée pour nos échantillons. On s'aperçoit qu'une minorité d'équipement consomme la majorité des ressources en temps et en coût et qu'il y a adéquation entre les courbes de coût et de temps passé. Ce type de courbe pourrait être utilisé pour analyser les stocks associés à ces équipements de façon à en prévoir les achats et éventuellement en négocier les prix sur des quantités. On pourra aussi sortir un autre rapport permettant de déterminer quelles sont les pièces les plus coûteuses par département et revenir sur les WO pour en examiner les raisons qui font que l'on consomme ces éléments. Dans ce cas, nous ne pourrons pas utiliser de représentation graphique vu la quantité de pièces concernées.

Dans notre cas, on s'aperçoit que quatre équipements mobilisent plus de 80 des ressources: Les PUMPS, ACMOTOR, VALVES et TANK dans tous les domaines de recherche. Il s'agit d'une piste pour commencer une investigation, mais rien ne nous donne d'indication sur les causes. Seule une répartition des modes de pannes et types de pannes pour chaque classification nous permettrait de pourvoir approfondir l'analyse.

La répartition aurait pu être différente: Peu de ressources humaines, mais forts coûts liés dans ce cas aux prix de pièces détachées ou encore l'inverse.

Ce qui veut dire qu'un graphique seul ne peut résumer l'ensemble des informations. Plusieurs doivent être examinés de concert puis associés à une recherche en détail dans les "Work Order" pour pouvoir déterminer la source des problèmes ou des coûts.

Commentaire des utilisateurs:

Nous avons présenté ces graphiques aux personnes les plus concernées par ce type d'informations. En particulier, les TC et les MSUP. Ils nous ont fait part des limites du système dans la mesure ou les équipements ne sont pas tous classés dans des catégories. Dans l'immédiat, ils ne voient pas l'intérêt d'une telle représentation tant que la classification n'est pas généralisée et qu'il n'existe pas de notion de "Failure Code".

Conclusions des essais Pareto:

Conclusions:

- Ce type d'analyse représente bien d'une façon synthétique les éléments les plus significatifs d'un lot suivant les critères de regroupement choisis.

- Toutefois, dans la mesure ou il n'existe pas dans la version actuelle de Maximo de classification fine des équipement pour une analyse descendante dans les détails, nous arrivons aux limites du système.

- Seule une comparaison de plusieurs graphiques suivant différents critères permettrait de faire une analyse descendante complète des données pour aboutir aux défauts de chaque équipement sélectionné.

- Les rapports sous SQR sont trop rigide pour ce type d'application. Il faudrait trouver un outil permettant de faire ce type de rapport à la demande suivant les critères définis par l'utilisateurs.

- Le produit "Powerplay" de la société Cognos est une piste à explorer pour générer ce type de rapport. Il sera examiné succinctement plus loin.

Figure 37 Diagrammes de Pareto, chantier "Pride Angola" toutes périodes.

Analyse de données statistiques associées aux défaillances.

En supposant que les données de Maximo sont saisies avec une suffisante fiabilité et que la qualité des informations est satisfaisante, il devrait être possible de les utiliser pour calculer un certain nombre d'informations utilisables pour déterminer:

- Des arbres de défaillance.

- Les intervalles des maintenances préventives.

- Des indicateurs de la fiabilité des équipements.

- De fournir des indicateurs de la qualité de la maintenance.

Il existe des méthodes statistiques permettant de donner des informations sur la fiabilité du matériel. Ces méthodes sont à utiliser avec beaucoup de précautions surtout si elles sont utilisées par des personnes peu familières avec les statistiques et les probabilités (une denrée rare). Elles peuvent donner des résultats entachés d'erreurs importantes si les échantillons ont une population faible.

L'utilisation de ces lois suppose les points suivants:

- D'avoir des échantillons de qualité suffisante et censurés ou non suivant la méthode.

- De sélectionner la loi de probabilité parmi la liste des cinq.

- Faire des calculs sur des échantillons, valider la loi utilisée et définir des intervalles de confiance.

Les six loi de probabilité de défaillances:

Il existe six formes de lois de probabilité de modes de défaillance. Les six diagrammes qui suivent décrivent la probabilité de défaut en fonction du temps en abscisse. Suivant le type d'équipement auquel on a affaire, il entre dans l'une ou l'autre de ces formes. En aviation, les pourcentages sont de A=4%, B=2%, C=5%, D=7%, E=14% et F=68%. Toutefois, cela ne préjuge pas des pourcentages de nos équipements. Les formes A, B et C sont liées directement à l'âge de l'équipement alors que D, E et F ne le sont pas. Les trois dernières formes sont celles pour lesquelles la maintenance conditionnelle (MBF) est applicable et où la maintenance préventive est difficile à appliquer.

Figure 38 Formes de loi de probabilité en maintenance.

- Forme A (dite en baignoire): La zone IM (Infant Mortality) indique les défaillances précoces. La zone WO (Wear Out) indique une usure. La zone intermédiaire indique un taux de pannes aléatoire. La période de vie de l'équipement se situe entre ces deux zones. Ce type de courbe tendrait à indiquer des pannes multiples à identifier.

- Forme B: Indique de l'usure. Dans ce cas, le MTBF n'est pas directement applicable car le temps de vie de l'équipement se trouve avant le MTBF. Le remplacement de l'équipement à l'issue du temps de vie impliquerait des coûts de maintenance élevés.

- Forme C: Avec un accroissement de la probabilité de défaut avec le temps, cela peut indiquer une fatigue, des problèmes d'isolation.

- Forme D: Est difficile à interpréter, mais peut dans certains cas correspondre à de la fatigue.

- Forme E: Indique un équipement dont le taux de pannes est aléatoire. C'est le cas ou le MTBF n'est pas très utile sauf par comparaison entre deux équipements différents.

- Forme F: Indique un fort taux de défauts précoces. Il s'agit dans ce cas plutôt de problèmes de conception, d'installation, de méconnaissance de l'équipement... Ce n'est pas un cas que peut traiter la maintenance préventive.

Il n'y a pas toujours consensus entre les auteurs quand à l'interprétation de ces courbes. Il s'agit aussi pour certaines d'elles de recherches de laboratoire et non d'essais en réel.

Les résultats expérimentaux montrent que ces modes de défaillances des équipements peuvent être décrites par cinq lois fondamentales de probabilité:

Exponentielles, normales, log-normales, Weibull et dite en "Baignoire".

On choisit la loi la mieux adaptée en fonction du type d'équipement et de ses courbes de défaillances.

L'exemple Weibull:

Nous allons tenter de donner une description succincte de l'utilisation de la loi Weibull sans toutefois entrer dans les détails précis de son interprétation.

La loi Weibull est une méthode graphique ou analytique utilisée pour caractériser les modes de défaillances d'éléments à partir de peu d'information. Elle permet de représenter la majorité des formes de lois de probabilité des modes de défaillance sauf la courbe en baignoire.

La distribution est décrite par une formule à trois paramètres: . Le plus souvent on considère que =0 (qui indique le temps entre la mise en service et la première panne).

On cherche donc à déterminer ces paramètres à partir des données de maintenance.

Dans le cas d'une méthode graphique sur du papier au quadrillage Weibull. Si =0, on obtient la méthode suivante:

1) On ordonne les données par temps croissant de panne à partir du point ou commence l'enregistrement des données.

2) A partir des données, on calcule les médianes de chaque ligne:

3) On trace le graphique sur le papier Weibull.

4) On détermine le paramètre = X/Y soit la pente de la droite sur le graphique. Il indique la tendance du mode de défaillance. Lorsqu'il ne s'agit pas de droites, le mieux est d'utiliser des méthodes analytiques (P.ex: Logiciel Weibull++).

5) On détermine le paramètre qui se trouve à l'intersection de la droite avec Y=63,2%. Il indique le temps de vie caractéristique ou moyen de survie (50% de survie).

Lorsque le paramètre est différent de 0, le cas est plus complexe et ne peut être entièrement résolu graphiquement.

A partir du paramètre , on peut déterminer quelques caractéristiques du mode de panne de l'équipement:

- <1: Indique une mortalité précoce. Soit encore probablement des problèmes de qualité, de montage, d'installation...

- =1: Indique un taux de panne aléatoire indépendant du temps (distribution exponentielle).

- =3: Usure prématurée.

- =6: Usure normale.

Il est aussi possible d'obtenir directement les valeurs suivantes à partir du calcul des paramètres:

MTBF, écart type, taux de panne, moyennes, médiane, .

Exemple extrait de Maximo:

Nous avons créé un programme sous SQR permettant de récupérer les temps cumulés depuis le premier CWO de la période concernée. Le tracé sur du papier Weibull n'a jamais donné de droite. Ce qui nous a incités à utiliser une méthode analytique plutôt qu'une méthode graphique. Nous avons donc essayé ces données sur deux logiciels du marché les plus répandus.

A partir des données issues du prototype, nous avons entré les chiffres dans deux programmes différents: "Quart" et "Weibull++". Ces programmes sont tous deux des versions de démonstration avec des fonctionnalités limitées, nous nous contenterons de ces résultats pour juger de l'intérêt de la méthode.

Le programme d'extraction n'est pas destiné à une réutilisation future. Il s'agit d'une simple sortie au format CSV (Coma Separated Values).

Pour des problèmes de place, les résultats de nos essais sont regroupés dans l'Annexe C.

- Graphique A: Equipement 053106102, FRESH WATER GENERATOR N°1 (PS).

Les coefficients =2,6 ; =5500 tendrait à indiquer des usures prématurées de certains éléments de l'équipement (forme A précoce). Ce qui est confirmé par les opérateurs de maintenance.

- Graphique B: Equipement 053209204 MUD PUMP N°2.

Les coefficients =1,5 ; =4379 tendrait à indiquer un taux de pannes aléatoires difficile à traiter par la maintenance préventive.

- Graphique C: Equipement 053211601 HIGH GRAVITY DRYER SET.

Les coefficients =0,7 ; =3627 tendrait à indiquer une forte mortalité précoce suivie d'un taux de panne aléatoire (forme D). Les maintenances correctives en début de vie de l'équipement ont corrigé les problèmes infantiles.

- Graphique D: Equipement 053401106 MIXER BEAR 30.

Les coefficients =1 ; =3134 tendrait à indiquer un taux de pannes aléatoires indépendantes du temps (forme F). Les maintenances préventives ne sont pas applicables.

Ces résultats présentés aux MSUP semblent conforter les impressions qu'ils ont de ces équipements. La confrontation avec les données de maintenance de Maximo donne les mêmes résultats. Il reste que l'interprétation de telles données nécessite une meilleure connaissance de ce type d'outils et des statistiques pour pouvoir être utilisée avec sécurité.

Les MSUP ne sont pas convaincus que de telles méthodes sont utilisables dans notre contexte.

Conclusions de l'analyse des données statistiques:

Conclusions:

- Ce type d'outil ne peut être utilisé que par des utilisateurs avertis et féru de statistiques ou de fiabilité des équipements.

- Il paraît illusoire de vouloir recréer nous même ce type d'analyse avec les outils de Maximo.

- Il est préférable d'extraire les informations de Maximo afin de les importer dans un logiciel spécialisé tel que Weibull++.

- Il n'est pour l'instant pas possible de fournir des données censurées automatiquement. Seule une validation manuelle permettra d'extraire des information de valeur.

- Les saisies de Maximo devraient être améliorées afin d'obtenir des données fiables et utilisables par ce type de logiciel.

Amélioration du retour d'expérience.

Méthodes de recueil de données de fiabilité:

Nous avons vu que l'un des outils nécessaires à la mise en place de la TPM reposait sur un recueil des informations de maintenances et leur analyse en vue d'effectuer des actions correctives (de type FRACAS). La version actuelle de Maximo telle que nous l'utilisons gère les historiques de maintenance, mais ne permet pas d'analyse facile ni de comparaison des données qui permettraient de cerner les problèmes qu'ils soient techniques ou économiques. L'un des moteurs de la TPM consiste à créer un système permettant en plus des commentaires libres de pouvoir catégoriser les sources de coûts, de pannes, les types de pannes et leurs conséquences. On veut aussi pouvoir comparer les niveaux de fiabilité entre équipements identiques fonctionnant sur des chantiers différents. Ce type d'information impose une standardisation de la saisie d'un certain nombre de données obligatoires qu'il faudra ajouter à Maximo. Nous pourrions créer notre propre standard, mais le mieux serait de s'inspirer de l'expérience déjà acquise par d'autres.

Il existe une norme internationale nommée:

ISO-14224:1999 "Industries du pétrole et du gaz naturel"

"Recueil et échange de données de fiabilité et de maintenance des équipements"

Cette norme offre des spécifications de recueil d'information, d'échange et de contrôle de la qualité des données de fiabilité dans le domaine des industries du forage, production, raffinage, et distribution de produits gaziers ou pétroliers.

Par contre, elle ne définit pas la façon dont seront utilisées les données par la suite ni les moyens de les analyser.

Elle est issue de l'expérience d'un projet nommé OREDA (Offshore REliability DAta) mené depuis les années 80 par le SINTEF et DNV Norway avec initialement huit des plus grandes compagnies pétrolières mondiales: BP, ENI, ExxonMobil, Hydro ASA, Conoco Phillips, Shell, Statoil, TOTAL. Chevron Texaco a rejoint ce groupe depuis 2001.

Ce recueil d'information avait pour objectif principal d'obtenir des données de fiabilité et de maintenabilité afin de définir des niveaux de risques pour les personnes, les équipements ou écologiques. Les données de OREDA ont été publiées dans les "OREDA Offshore Reliability Data Handbook" dont la dernière version est sortie en 2002. Une nouvelle révision du standard devrait sortir vers 2005 (Phase VII).

Certaines études prouvent qu'une maintenance efficace ne peut se faire sans une collecte et une analyse des données de défaillance, de modes de défaillances et des activités de maintenance [MOUB]. D'ou l'intérêt de disposer d'une normalisation de collecte, d'échange d'information de maintenance. L'analyse des données ne fait pas partie de la norme.

La spécification des données collectées permettra d'effectuer les analyses suivantes:

- Sécurité, fiabilité, disponibilité et maintenabilité des systèmes.

- Planification, optimisation et réalisation des tâches de maintenance.

- Lors de la conception d'équipements industriels nouveaux ou pour remplacer des équipements existants et les configurer.

- Analyse du coût de cycle de vie.

Le format normalisé des données permettra les échanges, les comparaisons entre différents interlocuteurs ainsi que le contrôle de la qualité des informations enregistrées.

Le texte suivant reprendra l'essentiel de la norme et donnera chaque fois les indications relatives à notre application. On tentera de faire ressortir ce qui est utilisable en tant que tel et de définir ce qui devrait être ajouté ou amélioré sans toutefois entrer dans l'étude complète de la migration qui demandera un travail plus approfondi.

Certains éléments de la norme seront notés en référence et ne seront pas reproduits dans ce document. Les annexes fournies dans la norme sont données à titre informatif et ne constituent pas un cadre rigide même si elles correspondent à des implantations existantes. Nous trouverons plus d'informations applicatives dans les documents publiés par le projet OREDA, mais la norme reste la référence pour la mise en oeuvre.

Guide pour l'obtention de données de qualité:

La mise en place de cette norme repose sur un certain nombre de mesures à prendre afin de garantir une saisie de données de qualité. Elle recommande de se poser un certain nombre de questions auxquelles nous allons répondre:

- Examen des sources de données:

Les sources de données de défaillances et de maintenance proviendront des rapports de maintenance et de "Downtime" du module "Work Order Tracking" de Maximo. Toutes ces informations sont saisies par les opérateurs des chantiers. Il n'existe aucune saisie automatique dans Maximo. Les écrans de Maximo devront être adaptés pour inclure les informations obligatoires préconisées par la norme.

Les informations d'équipement proviendront du module équipement après modification des écrans. Cela consistera principalement en l'addition de catégories d'équipement et des données spécifiques qui leur sont propres. Les données spécifiques d'équipement existent pour une grande partie, mais devront être transcrites de la "Long Description" vers le format imposé par la catégorie d'équipement.

- Objectif de la collecte:

Les données de fiabilité et de maintenance peuvent servir à cinq types d'applications décrites dans l'annexe D de la norme. Chacune d'elles nécessitera un certain nombre d'informations dont la saisie sera obligatoire ou non suivant les cas. Il nous faudra choisir le ou les types d'applications adaptés à nos besoins.

1) Augmenter les objectifs en terme de sécurité de fonctionnement et diminuer les risques (EQR).

2) Optimiser l'utilisation des équipements au travers d'une maintenance appropriée (FMD). Les coûts de maintenance plus élevés doivent être compensés par une meilleure performance de l'installation.

3) Maintenance basée sur la fiabilité (MBF): Il s'agit d'un type de maintenance ou les mesures sur les équipements permettent d'obtenir des informations de fiabilité qui font partie des historiques au même titre que les informations manuelles.

4) Permettre de comparer les performances de fiabilité de différents équipements (EVP).

5) Analyse du Coût de Cycle de Vie (CCV) et possibilité d'effectuer des comparaisons entre équipements.

L'objectif premier est d'obtenir des données de Fiabilité, de Maintenabilité et de Disponibilité (FMD) destinées aux services de maintenance du siège social et aux superviseurs de maintenance.

Il existe aussi un besoin concernant le calcul du Coût de Cycle de Vie (aussi nommé LCC), mais il s'agit d'une utilisation annexe qui ne fait pas directement partie du projet même si l'analyse des coûts ne peut être dissociée de la maintenance. Le produit Maximo ne dispose pas de toutes les informations pour fournir la totalité des coûts associés à un équipement (coûts de stock, du personnel, de la logistique, d'arrêts...). Les données de Maximo devront être associées à d'autres pour fournir ces informations.

Il n'existe pas de saisie automatique de données de maintenances dans Maximo (compteurs horaires ou donnés de Maintenance Basée sur la Fiabilité ou MBF). Ce n'est pas encore une pratique courante. Les données MBF actuelles sont issues des mesures d'huile, isolement et thermographie. Nous n'en tiendrons pas compte dans cette étude. Ces informations lorsqu'elles existent sont traitées dans le cadre des maintenances préventives. Il n'est pas encore envisagé de monter une maintenance de type MBF. Nous ne pensons pas en utilisant cette norme migrer vers une maintenance de type MBF (ou RCM) qui nécessiterait une trop grande rigueur pour notre type d'environnement.

La sécurité peut dans un premier temps être considérée comme une conséquence d'une bonne maintenance même si elle nécessitait un traitement à part pour certains équipements. En offshore, elle sera traitée au travers des indicateurs "ISM" qui servent à spécifier une certification couvrant tous les équipements de sécurité du navire. Les données FMD incluent l'ensemble des données de sécurité.

Le fait de choisir les données FMD donne une des contraintes de saisie les plus fortes. Cela veut dire que si toutes les données FMD sont disponibles, nous pourrons obtenir les données des autres applications hors MBF qui requièrent en plus la notion "Activité de maintenance" (Tableau Annexe B4).

La sélection des données obligatoire par type d'application décrite dans l'annexe D n'est qu'une recommandation et nous pourrons y ajouter toute donnée complémentaire.

- S'assurer de la qualité des données de défaillances:

La saisie des données de maintenance se fait dans le module "Work Order" où l'on peut mettre un équipement en arrêt (Downtime) et où sont saisis les rapports des maintenances préventives et correctives.

Lors de la saisie des "Work Order" correctifs, nous disposons des informations décrites dans le tableau suivant, certaines sont obligatoires (colonne OB) d'autres non. Nous allons détailler pour chaque champ, les valeurs qu'ils peuvent prendre et les commentaires subjectifs sur leur validité (Table 17). Notre jugement est issu de l'examen des données de deux chantiers offshore représentatifs. Ces chantiers sont ceux sur lesquels ont été testés les prototypes des autres chapitres. Il est volontairement sévère. Nous donnerons une note sur 5 pour chaque champ afin de juger de la qualité des informations entrées.

WORKORDER

Valeur saisie

OB

Commentaire

Note

N° d'équipement

O

L'équipement peut être choisi à plusieurs niveaux de l'arbre suivant l'utilisateur. Il n'existe pas de consigne particulière. Seul le bon sens prévaut.

4

Work Type

O

Les valeurs possibles sont:

ALT Alerte. SM Safety maintenance.

CM Maintenances correctives. PM Maintenances préventives.

RKS Remarques. RM Routine maintenance.

RPT RMS report (offshore only).

Les maintenances de type SM ont été abandonnées.

La sélection PM est indiquée automatiquement lors de la génération des PWO dans le module PM tous les 15 jours.

Les sélections autres que CM sont très peu utilisées. Autre que pour PM & CM, il n'existe pas de règle d'usage. Certains ajustements de stock ou remarques sont mis dans des CM sans différenciation utilisable. De nouvelles consignent indiquent d'utiliser RM à la place.

4

Sub Work Type

N

Il peut prendre les valeurs suivantes:

NDT Non destructive test. CAL Calibration.

INS Insulation. CMS Continuous Machinery Survey.

ANA Analysis. MPI Magnetic Particle Test.

DRN Drainage. SJ Survey jobs (Lloyds, ABS, BV, DNV).

OTHER

Ce champ n'est pratiquement pas utilisé en CM sauf parfois pour les valeurs CAL et INS.

3

Priority

N

Optionnel, valeurs "Normal" ou "High level". Très peu utilisé.

1

Failure code

N

Non utilisé.

0

Problem code

N

Non utilisé.

0

Start Date

N

Contiens la date de début des opérations de maintenance. Son remplissage n'est pas formalisé.

4

Finish date

N

Par défaut, il s'agit de la date ou le WO est passé en statut COMP. Il devrait contenir la date de finition des travaux. Elle doit être obligatoirement après la date de début. Son remplissage n'est pas très formalisé, mais il semble correct sur quelques chantiers.

4

Duration

N

Durée des travaux en heure-homme. Elle devrait inclure les temps de préparation, rangement et d'écriture des rapports ainsi que ceux liés à cette maintenance. Ce n'est pas souvent le cas. Il semble toutefois y avoir une certaine cohérence entre deux travaux identiques. De nouvelles consignes ont été données pour le remplissage de ce champ avec des données valides.

4

Meter reading

N

Ce champ texte optionnel devrait contenir la valeur du compteur de l'équipement lorsque la panne s'est produite. Il s'agit d'une simple information et ne peut être utilisé d'une façon sure. Il est très rarement utilisé.

1

%Completion

N

Ce champ optionnel contient le % de réalisations des travaux. Il n'est pas systématiquement mis à jour régulièrement. Le plus souvent, il n'est mis à jour que lors d'un changement de statut.

2

Reported by

N

Il s'agit d'un champ texte libre. Pas de contrôle de la saisie, car les personnes physiques ne sont pas répertoriées.

1

Lead Craft

O

Le "Lead Craft" contient la liste des différents départements du chantier. Il s'agit du département pour lequel on travaille et responsable de l'appareil ou se passe l'intervention. Il peut être différent du "Crew" pour lequel travaille l'intervenant.

4

Crew

N

L'équipe d'intervention. La différence avec "Lead Craft" n'est pas claire.

3

Supervisor

N

Optionnel, contient la liste des titres des superviseurs. La dénomination n'est pas claire par rapport aux "Lead Craft" et "Crew".

3

Modified by

N

Saisie automatique du nom de Login de l'utilisateur. Il s'agit d'un texte libre.

3

Modified date

N

Date à laquelle les modifications ont été faites sans lien avec le statut du WO.

3

Status Date

X

Ce champ contient la date de dernière modification du statut du WO. Elle correspond assez bien à la date à laquelle s'est passé l'événement qui a fait changer le statut.

3

Reported date

X

La date de création du "Work Order". Elle n'a pas de lien avec la date ou s'est produit le problème. Il s'agit de la date du premier état WAPPR pour les CM, celle de la génération des maintenances pour les PM.

5

Report downtime

X

Ce menu permet d'entrer des arrêts après coup alors que l'équipement est déjà retourné en service. On doit entrer les dates de début et de fin de l'arrêt ainsi que le "Downtime code". Les historiques enregistrent un état UP et un état DOWN aux dates entrées.

Ce menu est peut utilisé et les "Downtime code" ne sont pas toujours entrés. Lorsqu'il est utilisé, les dates sont justes. Les raisons qui font que ce menu est peu utilisé sont purement politiques, car certains arrêts ne sont pas comptabilisés ou l'objet de négociations et ne doivent pas apparaître en tant que tels.

4

Change Eqpt statut UP/Down

X

Permet de mettre un équipement dans un états opérationnel ou non en entrant une date et un "Downtime code". Même statut que le précédent.

4

Failure Report Date

N

N'est jamais utilisé (onglet "Failure report").

0

Failure Classe

N

N'est jamais utilisé (onglet "Failure report").

0

 
 
 
 

Table 18 Estimation de la qualité de saisie dans Maximo.

Le tableau qui précède (Table 17) nous permet de dire que la qualité de saisie des données de Maximo peut être grandement améliorée. La compétence des utilisateurs ne peut être remise en cause la plupart du temps. Il s'agit plutôt d'un manque de formaliste, il est vrai assez difficile à mettre au point dans notre type d'environnement. Nous travaillons dans un milieu dispersé ou l'information a parfois du mal à circuler.

Un certain nombre d'informations devront être rendues obligatoires et d'autres redéfinies pour en expliciter le contenu aux utilisateurs de façon plus formelle. La dernière partie du projet donnera des indications pour améliorer les saisies des données existantes. Les données de défaillances additionnelles nécessaires à l'implantation de la norme seront définies dans la suite du document.

- Identification des sources de données et des périodes:

La période d'exploitation des données démarre avec l'implantation de Maximo sur l'appareil. Certains appareils qui ont été rachetés d'autres sociétés possédaient des historiques de maintenances, mais peu d'entre eux ont été repris dans Maximo. Le plus souvent, l'ancien outil de gestion de la maintenance est gardé comme outil indépendant, mais uniquement pour la consultation des historiques. Il n'existe pas de liens immédiats entre les produits anciens et Maximo.

Il se posera toutefois le problème des données historiques des maintenances existantes qui ne possèdent pas de notions de défaillances.

Nous ne prendrons donc en compte les données présentes dans Maximo qu'à partir du moment ou seront implantés les codes de défaillances et les nouvelles spécifications d'équipements.

Il serait possible de reprendre les historiques et de leur attribuer des codes de défaillances. Mais l'étendue du travail pour chaque chantier ne permettra certainement pas d'effectuer cette opération. Tout au plus pourrions-nous le faire sur des sélections d'équipements principaux dont le suivi présente un fort intérêt économique.

- Vérification des méthodes de collecte de données:

Il n'existe pas de méthode automatique de saisie des données dans Maximo. L'ensemble est manuel et très dépendant de la formation de l'utilisateur. Ces derniers devront être formés aux standards de saisie que nous allons définir à l'aide de cette norme. Les saisies sont effectuées pour une part par les opérateurs de maintenance, contrôlées par les HOD et en final par les TC. Ce ne sont pas les utilisateurs finaux de ces données.

Les données de fiabilité des équipements seront principalement utilisées a posteriori par les personnels superviseurs ou par les responsables de la maintenance du siège de Houston. Toutefois, la qualité de saisie ne pourra être atteinte que si les utilisateurs n'appartenant pas à ce groupe voient les résultats de leurs saisies. De fortes contraintes de saisie sans résultats visibles par les opérateurs de maintenance pourraient entraîner des dérives. Si la norme est mise en place, il faudra tenir compte de ces contraintes et remonter certaines informations au niveau des chantiers. Garder l'information uniquement dans des sphères élevées serait une grave erreur.

- Plan du processus de collecte:

Il existe deux types principaux de rapports de maintenance: Les maintenances correctives et les maintenances correctives. Le processus de collecte des informations est déjà formalisé et ne nécessite pas de restructuration profonde. Il a déjà été décrit dans l'analyse de l'existant (voir Fig.11). Seules des données complémentaires devront être saisies lors des rapports de maintenance. Cela ne concernera pas nécessairement la totalité des équipements du chantier, mais les plus significatifs pour le fonctionnement opérationnel de l'unité. Cela inclura ceux de la norme plus une liste additionnelle à définir.

- Plan de formation du personnel à la saisie des données:

Les nouvelles normes de saisie seront intégrées aux formations Maximo et diffusées sous forme d'additifs à la partie PMS des manuels de référence normalisés de la société (Q-SMS).

Ils feront l'objet de documents de référence additionnels. Seuls ces additifs seront distribués localement aux différents départements jusqu'à mise à jour du Q-SMS.

Il existe déjà un plan de formation du personnel impliqué dans la maintenance et utilisant Maximo. Les supports de formation devront inclure ces nouvelles normes de saisie et faire l'objet d'une description spécifique durant le cours. On pourra prévoir des supports plus spécifiques pour les personnes chargées du contrôle de la qualité des données saisies (superviseurs, HOD, TC).

- Assurance qualité de la collecte de données: Annexe C de la norme.

La qualité des saisies des "Work Order" est déjà contrôlée à deux niveaux avant qu'ils soient fermés: Par le HOD lorsque le "% completion" est à 100%. Le HOD ne le passe dans l'état COMP que si la saisie est correcte et les champs renseignés. Il est ensuite vérifié par le TC avant sa fermeture (CLOSE).

L'assurance qualité des données se fera par l'intermédiaire des superviseurs des différents domaines et lors du passage de ceux du siège social de Houston. Ceux-ci ont déjà pour rôle de contrôler le contenu (cohérence, complétude, périodicité...) des champs et des commentaires libres inscrits dans les maintenances de Maximo. Leur rôle sera ainsi amplifié pour inclure la qualité des données faisant partie de la norme. Cela inclura les données spécifiques d'équipement et le contrôle du contenu des WO.

Il nous faudra créer des outils d'audit de la qualité des données sur des échantillons de données d'équipement et de WO préventifs et correctifs. Cela devra inclure des informations concernant les causes d'écarts et de mauvaise interprétation.

Formats des données d'équipements, de défaillances et de maintenance:

Les trois chapitres qui suivent donnent la liste des informations nécessaires faisant partie de la norme et les mettent en correspondance avec les informations disponibles dans Maximo.

La norme décrit trois formats de données nécessaires pour s'assurer que les données sont réutilisables. Il s'agit des données d'équipement, de défaillances et de maintenance.

Les équipements:

La normalisation des catégories d'équipements est essentielle pour pouvoir comparer les données entre elles d'un chantier à l'autre, mais aussi avec des données externes provenant d'autres sources ("OREDA handbook", constructeurs...). Elle sera construite sous forme d'arbre dont le niveau dépendra de la complexité de l'équipement et du niveau de détails requis. L'arbre dont le niveau le plus haut est la catégorie d'équipement doit indiquer les sous-équipements ainsi que les interfaces avec l'environnement. La norme définit quatre niveaux:

- La catégorie d'équipement,

- le type,

- le sous-ensemble,

- l'entité maintenable (EM).

Les données de fiabilité devront être rattachées à un niveau de l'arbre en fonction de leur usage.

La norme définit un certain nombre de données nécessaires et optionnelles à la description d'un équipement. Nous allons reprendre celles du module EQUIPMENT qui nous paraissent les plus réalistes par rapport à notre application.

Catégorie

Ss-Catégorie

Données

Données de Maximo

Identification

Emplacement

Numéro d'identification

EQNUM et DESCRIPTION. C'est l'arbre existant dans Maximo.

Classification

Catégorie d'unité d'équipement. (a)

Type d'équipement. (a)

Application. (a)

"Catégories" et "Type" peuvent être entrés dans l'onglet "Specifications" sous forme de "Classification" et "ss-classifications". (Specs)

N'est pas utilisé dans notre version.

"Application" n'a pas d'équivalent, mais peut être inclus dans les caractéristiques de conception.

Données d'installation

Nom de l'installation ou code. (a)

Type d'installation. (a)

Type d'opérations. (a)

Zone géographique.

Ce type d'information est enregistré dans la "Longue description" (LD) de l'équipement à la racine de l'arbre ou dans les "Specs" (à définir).

On y trouve les spécifications complètes de l'appareil.

Données d'unité d'équipement

Description de l'unité d'équipement.

Numéro unique (N°série ou autre).

Dans la LD ou "Linked documents" (format PDF préféré).

Champ SERNUM.

Conception

Données du fabricant

Désignation du fabricant.

Modèle.

Champ VENDOR.

Champ MANUFACTURER.

Champ ASSETNUM.

Caractéristiques de conception

Suivant la catégorie d'équipement: Puissance, vitesse, pression... (a)

Contenu dans la LD.

Maximo inclut ce type de renseignement dans un onglet "Specifications". Les spécifications entrées sont dépendantes des sous classifications sélectionnées.

N'est pas utilisé dans notre version.

Application

Exploitation en condition normale

Type de redondance.

Mode de fonctionnement.

Date d'installation.

Périodes de surveillance calendaire.

Durée de fonctionnement/période.

Nombre de sollicitations/période.

Paramètres de fonctionnement. (a)

Pas d'équivalent. Dans "Specs".

Pas d'équivalent. Dans "Specs".

Champ INSTALDATE.

Pas d'équivalent.

Compteurs horaires.

Pas d'équivalent.

Pas d'équivalent. Dans "Specs".

Facteurs d'environnement

Extérieur (b) et intérieur (c).

(extrême, modérée, favorable)

Pas d'équivalents.

Peut-être inclus dans "Specifications".

Commentaires

Compléments

Fiches techniques.

Peut être inclus en texte libre dans la LD ou encore comme document attaché pour les documents autres que du texte simple (format PDF de préférence).

 
 
 
 

Note: Les caractères en gras indiquent les éléments nécessaires à la norme pour une application FMD.

Note: Les caractères en italique indiquent le minimum requis pour la norme.

a) Voir l'annexe A de la norme pour consulter les listes proposées.

b) Paramètres à prendre en compte: Protection de l'enceinte, vibrations, humidité, corrosion...

c) L'environnement interne de l'équipement. Acidité, pressions chaleur...

 

Table 19 Données d'équipement ISO-14224.

L'annexe A définit (à titre indicatif) les caractéristiques des équipements à partir des informations suivantes:

Figure 39 Hiérarchie des équipements ISO-14224.

- Catégorie d'équipement: P.ex, "Moteur électrique".

Directement applicable en tant que "Classification" dans le module équipement. Chaque équipement ne peut appartenir qu'à une catégorie. Le lien entre catégorie et désignation de l'équipement dans Maximo doit être univoque. Dans le cas contraire, la classification n'est pas applicable. Il faudra soit la modifier ou descendre à un niveau inférieur de l'arbre.

P.ex: "053101001 Diesel Engine #1 (Eng+Alt)" contient deux catégories, "Engine" et "Alternator". La classification n'est pas applicable.

- Type d'équipement: P.ex, Continu ou Alternatif.

Directement applicable en tant que "SubClassification" dans le module équipement. Chaque équipement ne peut appartenir qu'à un type qui lui-même est lié à une seule catégorie. Dans le cas contraire, descendre dans l'arbre pour assigner les classifications.

P.ex: "053101002 Diesel Engine #1 Wartsila" appartient à la catégorie "Combustion engine". Le titre indique aussi le type de l'équipement qui est "Diesel".

- L'application: P.ex, Energie de secours, Energie principale, Secours incendie.

N'a pas d'équivalent dans les écrans Maximo. Elle pourra être incluse dans les spécifications.

- Les notions de sous-ensemble et d'entités maintenables (EM):

P.ex, pour les "Sous-ensemble": Moteur, Circuit de commande, Lubrification.

P.ex, pour les EM du système de lubrification: Réservoir, filtre.

Ces deux valeurs sont communes à tous les types d'une catégorie. Chaque sous-ensemble contient un certain nombre d'entités maintenables.

Cela nécessitera la création de deux niveaux de classification supplémentaires dans le module "Inventory", "Asset Catalog setup". Actuellement, l'application ne propose que deux niveaux, mais cinq sont possibles. Il faudra faire apparaître les champs dans le module équipement et "Asset Catalog setup" à l'aide du "Centura Object Nationalizer" qui permet de paramétrer les écrans de Maximo.

- Les données spécifiques à la catégorie: P.ex, Puissance, vitesse.

Directement applicable dans l'onglet "Specifications" du module équipement. Il faudra créer les listes dans le module "Inventory", "Asset Catalog setup".

Ces données ne seront rattachées qu'aux niveaux des "catégories" ou "catégorie+type" et non aux niveaux inférieurs. Le choix de l'un ou l'autre dépendra de la façon dont a été conçu l'arbre des équipements dans Maximo. Toutefois, rien n'empêche d'ajouter celles qui nous paraîtrait nécessaire à d'autres niveaux ou d'inclure des informations non présentes dans la norme.

- Lorsque c'est applicable, les données environnementales:

P.ex, Présence de gaz, pression, débit.

Elles pourront apparaître dans la liste des données spécifiques à la catégorie.

- A chaque catégorie d'équipement sont associées des listes de "Modes de défaillances". Il faudra faire apparaître le champ FAILURECODE dans le module équipement à l'aide du "Centura Object Nationalizer" et créer ces valeurs dans le module "Failure codes".

Note: Le "Failure Code" est aussi appelé "Failure Class" dans Maximo.

Les catégories d'équipements traités sont les suivants dans le domaine "Equipement de procédés":

- Moteurs à combustion.

- Compresseurs.

- Unités logiques de commande.

- Générateurs et moteurs électriques.

- Systèmes incendie et gaz.

- Turbine à gaz.

- Echangeurs thermiques.

- Capteurs et procédés.

- Pompes.

- Turbines de détente.

- Soupapes et robinets.

- Capacités et procédés de stockage.

Les parties "Equipement sous-marins" et de "Complétion de puits" ne sont pas applicables telles qu'elles. Elles sont très adaptées à la production et non à la partie forage.

La partie "Equipement de Forage" est réduite à sa plus simple expression, car elle ne concerne que les équipements "Tête d'injection motorisée" qui ne sont en général utilisés que lors des forages déviés.

La majorité des catégories équipements sont décrits dans les annexes, mais il nous faudra créer nos propres caractéristiques pour celles qu'il manque. On peut citer dans un premier temps, les plus importantes:

- "Equipement sous-marin": BOP, acoustique.

- "Equipement de forage": Tiges, risers.

- "Equipement marine ou positionnement": DGPS, gyroscopes, radio/navigation, télécoms.

La majorité de nos chantiers sont déjà équipés de Maximo et les arbres d'équipements existent déjà. Les trois premiers niveaux de l'arbre sont trop génériques pour correspondre à la classification de la norme. Ils correspondent respectivement au chantier (racine de l'arbre), aux grandes familles d'équipements et aux sous ensembles ou systèmes. Les équipements ne sont décrits qu'à partir du quatrième ou cinquième niveau. C'est à partir de ces niveaux que l'on pourra appliquer les classifications et/ou de "Failure code" à chaque branche des équipements.

Exemple d'arbre d'équipement:

Equipement

Catégorie

Type

Sous-ensemble

Entité maintenable (EM)

053 Drill Ship Pride Angola

Drill Ship (catégorie à créer pour chaque type de chantier)

0531 Power & Associated

Regroupement générique.

053101 Main Generators

Regroupement générique.

053101001 Diesel Engine #1 (Eng+Alt)

Pas de catégorie applicable, car cela regroupe moteur et générateur.

053101002 Diesel Engine #1 Wartsila

Moteur à Combustion (CE)

Moteur Diesel (DE)

Pas de Sous-ensemble ni EM.

Données spécifiques entrées à ce niveau.

...

 
 
 
 

053101011 Fuel feed pump

CE

DE

Unité du moteur à combustion

Pompe à carburant

053101015 Starting Equipement

CE

DE

Système de démarrage

Unité de démarrage

...

 
 
 
 

053101003 Alternator/Diesel Eng #1

Générateur Electrique (EG)

Entraîné par moteur (MD)

Pas de SS-Ensemble ni EM.

Données spécifiques entrées à ce niveau.

 
 
 
 
 

Il ne sera pas toujours facile de faire correspondre la hiérarchie de la norme avec celle des équipements, car les arbres ne sont pas superposables. Il conviendra de vérifier si la hiérarchie existante peut être changée ou re-découpée sans remettre en cause les historiques de maintenance ni les maintenances préventives qui leurs sont associées.

Les données spécifiques ne seront définies qu'aux niveaux des "catégories" ou "catégorie+type". Il est toutefois difficile de donner des règles précises, car tous les arbres ne sont pas identiques entre chantiers.

La norme spécifie d'indiquer les sous-ensembles et "Entités Maintenables" (EM) dans les saisies des données de défaillances. Dans notre cas, ils seront implicites et contenus dans le numéro de l'équipement, car ces champs n'existent pas dans Maximo. Le numéro d'équipement est entré dans le "Work Order" avec les autres informations de défaillance.

La majorité des informations requises par la norme existent déjà dans les saisies actuelles.

Les données spécifiques sont renseignées la majorité du temps dans la "Long Description" (LD). L'onglet "Specification" commence à être utilisé depuis peu et les données de la LD y sont transférées progressivement. Les données spécifiques à chaque catégorie d'équipement n'ont pas été créées à partir des données de cette norme.

La conversion des données spécifiques entre les LD et le nouveau format devront être faite manuellement et cela représentera un gros travail de saisie.

La conversion des spécifications existantes (hors LD) vers le nouveau format pourra être faite automatiquement. Cela nécessitera une comparaison entre ce qui est proposé par la norme et les 21 catégories existantes.

Il est prématuré de juger de la faisabilité. Il nous faudra examiner les possibilités d'adaptation et juger de l'intérêt de le faire. On notera que cela ne concernera que les équipements décrits dans la norme ainsi que ceux que l'on aura souhaité y ajouter et non l'ensemble.

Les données de défaillances:

Cette partie concerne principalement les données de maintenances correctives. L'ensemble des défaillances doit être consigné dans Maximo avec un minimum d'informations nécessaires à leur exploitation. Ce tableau résume les informations recommandées par la norme et celles qui sont le minimum nécessaire.

La majorité de ces informations sont déjà présentes dans notre version et sont contenues dans les "Work Order" correctifs. La différenciation entre une donnée de maintenance (préventive) et un rapport de défaillance (corrective) étant faite par le "Work Type".

Maximo dispose d'un module permettant de créer une hiérarchie de "Failure Class" et "Problems, Causes, Remedies". Ce module n'est pas utilisé dans notre configuration actuelle. Il devra être renseigné pour être utilisé dans les rapports de maintenance.

Catégorie

Donnée

Description

Données de Maximo

Identification

Enregistrement de la défaillance

Numéro unique

Numéro "Work order" corrective: WONUM.

Emplacement de l'équipement

Numéro d'identification de l'équipement

Numéro d'équipement: EQNUM.

Données de défaillances

Date de défaillance

Date de détection

Pas d'équivalent. Correspond à "Failure Date" (FAILDATE) onglet "Failure reporting" module WO.

Non utilisé dans notre version.

Mode de défaillance

Voir (a).

"Failure Class" (FAILURECODE) dans le module WO. Spécifique à un équipement.

Peut être lié à l'équipement.

Non utilisé dans notre version.

Conséquences sur la production ou la sécurité

Echelle d'impact.

Le "Downtime" de l'équipement dans le module "Work Order" contient aussi un "Downtime code" qui permet de caractériser le problème, mais pas forcement l'impact.

Classe de sévérité

Effet critique ou non sur l'unité.

Il existait une notion de "Downtime" opérationnel ou non dans les précédentes versions. Il faudrait la réactiver. Le champ "WO priority" pourrait aussi être utilisé.

Indicateur de la défaillance

Voir (b).

Champ PROBLEM du "Work Order" et compléments dans la "Long Description" (LD).

Non utilisé dans notre version.

Cause de défaillance

Voir (c).

Champ CAUSE du "Work Order" et compléments dans la LD.

Non utilisé dans notre version.

Sous-Ensemble défectueux

Sous-ensemble défaillant.

Voie (a)

Implicite dans le numéro d'équipement lorsque applicable.

Entités maintenables défaillantes

Détail des unités défaillantes. Voir (a).

Implicite dans le numéro d'équipement lorsque applicable.

Méthode d'observation

Méthode de détection de la défaillance. Voir (d)

Dans la "Long Description" du "Work Order". Peut faire l'objet de l'ajout de DETECTION dans les PROBLEM/CAUSES/REMEDIES.

Commentaires

Informations complémentaires

Informations complémentaires sur les conditions et cause de défaillances, diagnostic et méthodes de réparation.

Dans la "Long Description" du "Work Order".

 
 
 
 

Note: Les caractères en gras indiquent les éléments nécessaires à la norme pour une application FMD.

Note: Les caractères en italique indiquent le minimum requis pour la norme.

a) Voir l'annexe A de la norme pour consulter les listes proposées.

b) Tableau B1 de la norme "Indicateurs de défaillance".

c) Tableau B2 de la norme "Causes de défaillances.

d) Tableau B3 de la norme "Méthodes de détection".

 

Table 20 Données de défaillances ISO-14224.

L'annexe A donne une liste des "Modes de défaillances" par catégories d'équipements. Cette liste qui est assez similaire aux indicateurs de défaillances de la liste B1 doit correspondre à la description de la défaillance observée reportée au niveau du type d'équipement de la catégorie.

Le titre correspondrait aux "Failure Class" de Maximo. Le "Failure Class" d'un équipement peut être défini dans le module équipement ou par défaut dans le "Work Order", onglet "Failure Reporting". Il apparaîtra dans "Failure Class" lorsqu'un "Work Order" sera généré pour cet équipement. Ce champ n'est pas apparent dans la version actuelle du module équipement.

Les annexes B donnent à titre indicatif les listes générales des informations suivantes:

- B1: Les indicateurs généraux de défaillances (fuite, court circuit...) avec une répartition par catégorie (mécanique, électrique...). Il doit indiquer la cause de la défaillance au niveau le plus base de la hiérarchie de l'équipement (sous-ensemble ou entité maintenable). Cette distinction n'existe pas dans Maximo. Nous ferons correspondre les titres des "Modes de défaillances" avec "Failure Class". A chaque "Failure Class" correspondra une liste de PROBLEM correspondants à la liste des "Modes de défaillances" de l'annexe A.

- B2: Une liste commune de causes de défaillances: P.Ex, erreur humaine, mauvaise conception. On l'associera au champ CAUSE des "Failure Class" de Maximo.

- B3: Une liste commune de modes de détection: P.ex, observation, contrôle.

- B4: Une liste commune d'activités de maintenance: P.ex, PM, CM, réglage, remplacement.

Les listes B2, B3 et B4 seront communes à toutes les classes de défaillances.

Ces listes ne sont pas complètes et devront être revues avec le concours des personnels qualifiés de chaque discipline. Elles pourront servir de base solide pour de futures améliorations. Chaque élément de ces listes fera l'objet d'une codification adaptée à Maximo. On utilisera la codification de la norme si elle existe. Il faudra veiller à ne pas entrer dans une trop grande complexité afin de ne pas rebuter les personnes et de ne pas engendrer des temps de recherche trop longs de la bonne information dans des listes interminables.

Les données de maintenance:

Ce module est complémentaire du précédent. Dans Maximo, la différenciation entre rapports de défaillance et rapport de maintenance n'existe pas sous cette forme. Les rapports sont faits dans le module "Work Order" quel qu'en soit le type. La différentiation provient du champ "Work Type" qui définit si l'on a affaire à une maintenance préventive ou corrective. Les données de défaillances sont incluses dans les rapports dans le cas des maintenances correctives.

Catégorie

Donnée

Description

Données de Maximo

Identification

Enregistrement de maintenance.

Identifiant unique de la maintenance.

Numéro de "Work order" préventif: WONUM.

Emplacement de l'équipement.

Identification de l'équipement.

Numéro d'équipement: EQNUM.

Enregistrement de défaillance.

Pour les maintenances correctives uniquement.

N'est pas applicable.

Les maintenances préventives et correctives sont enregistrées dans le même module "Work Order".

Données de maintenance

Date de maintenance.

Date à laquelle s'est effectuée la maintenance.

ACTSTART & ACTFINISH module "Work Order".

Catégorie de maintenance.

Préventive ou corrective.

WORKTYPE du module "Work Order", inclut entre autres les PM et CM.

Opération de maintenance

Voir (b).

Pas d'équivalent. Pourrait correspondre à une liste modifiée des "Sub Work Type".

Conséquence sur la production.

Echelle d'impact.

Le "Downtime" de l'équipement dans le module "Work Order" contient aussi un "Downtime code" qui permet de caractériser le problème.

Sous ensemble soumis à la maintenance.

Sous ensemble concerné par la maintenance. Voir (a).

Pas d'équivalent. Implicite dans le numéro d'équipement.

Entité maintenable soumise à la maintenance.

Spécifier l'entité concernée. Voir (a).

Pas d'équivalent. Implicite dans le numéro d'équipement.

Moyens de maintenance

Maintenance en homme-heures par discipline.

Voir (c).

Les heures sont entrées dans le champ DURATION du module "Work Order". Chaque discipline devrait faire un "Work Order" différent. Ce n'est pas toujours le cas.

Durée totale de la maintenance en homme-heure.

 

Pas d'équivalent. Sauf à cumuler les heures des différentes disciplines. Toutefois, il ne sera pas possible de déterminer facilement s'il s'agit de la même intervention.

Temps de maintenance

Temps de maintenance active.

Temps de maintenance active par rapport au temps d'indisponibilité.

Peut être déduit à partir de ACTSTART, ACTFINISH et DURATION module "Work Order".

Temps d'indisponibilité.

Temps d'indisponibilité de l'équipement concerné.

FAILDATE, ACTSTART & ACTFINISH module "Work Order".

Commentaires

Informations complémentaires.

Indiquer toute information utile à cet emplacement.

Dans la "Long Description" du "Work Order".

 
 
 
 

Note: Les caractères en gras indiquent les éléments nécessaires à la norme pour une application FMD.

Note: Les caractères en italique indiquent le minimum requis pour la norme.

a) Voir l'annexe A de la norme pour consulter les listes proposées.

b) Tableau B4 de la norme "Méthodes de détection".

c) Pour les équipements sous-marins, préciser la logistique et les ressources externes.

 

Table 21 Données de maintenance ISO-14224.

Le développement en interne:

Nous avons vu que l'implantation de la norme était possible, mais qu'elle demandait un certain nombre de modifications de Maximo et de gros efforts de saisie si elle devait être implémentée complètement. Nous ne prétendons dans ce qui suit, donner une liste exhaustive, mais plutôt un ordre d'idée des opérations à effectuer. Le but étant principalement de faire une première évaluation des travaux afin de faciliter la prise de décision.

Avant de commencer l'étude, il conviendra de répondre aux questions suivantes:

- Quel effort de normalisation sommes-nous prêts à assumer et en voyons-nous les avantages?

Les plus gros travaux de normalisation concernent la classification des équipements dont il faudra évaluer la faisabilité.

La situation actuelle convient pour planifier les maintenances et pour une exploration manuelle des historiques uniquement.

- Voulons-nous une normalisation pour un usage interne uniquement et à quelle échelle?

Il est toujours possible de s'inspirer de la norme sans l'implémenter complètement. Dans ce cas, les données risquent de n'être utilisables qu'en interne et difficile à comparer aux données OREDA. Il est aussi possible de ne l'implanter que sur certains équipements sélectionnés. Nous pourrions limiter l'implantation à certains secteurs à forte valeur ajoutée comme le offshore qui seraient probablement plus demandeurs que d'autres.

- Quels sont les bénéfices espérés et comment présenter le projet aux directions?

Il s'agit d'un projet d'envergure et cela demandera l'implication des directions du groupe. Il ne s'agit pas d'un projet à court terme, car les données de maintenances et les résultats ne se feront sentir qu'au delà de deux ans dans le meilleur des cas. Nous comptons un an de mise en place et un an d'historiques minimum. La reprise des anciens historiques ne parait pas réalisable et n'est pas souhaitable car les règles utilisées n'auront pas été les mêmes.

- Vérifier que des solutions commerciales n'existent pas ou que nous ne pouvons pas bénéficier de l'expérience d'autres implémentations de la norme dans Maximo. MRO propose un élément de solution qu'il faudra explorer.

- Il serait aussi souhaitable d'entrer en contact avec les membres du projet OREDA pour en discuter les différents aspects et voir l'intérêt d'y participer. La normalisation et l'appartenance à ce projet sont dissociés.

On donnera dans ce qui suit, une liste préliminaire des opérations à effectuer pour mettre en place cette norme au sein de nos chantiers. Celle-ci peut servir de point de départ pour démarrer l'étude, mais devra être revue en détail pour s'assurer de la faisabilité de certains points. Il se peut que la situation soit différente sur d'autres installations, car nous n'avons exploré que les chantiers d'Angola et notre vision n'est pas celle de la situation du groupe.

Afin de compléter cette étude, nous devrons disposer du "OREDA Offshore Reliability Data Handbook" qui nous permettra d'avoir une idée d'implémentation de la norme.

En ce qui concerne le module équipement, la norme donne des indications qui pourraient nous permettre de créer une taxinomie ainsi que les listes de spécifications de chaque classification d'équipements. L'application de ces catégories à l'arbre des équipements existant pourra s'avérer difficile sur les chantiers ou il n'aura pas été conçu à partir de cette norme. Il conviendra de faire une étude de faisabilité avant d'entreprendre ces opérations. Les modifications ne devraient pas concerner tous les équipements, mais seulement ceux décrits par la norme et ceux que nous aurons voulus y ajouter.

- Afin de faciliter les futures saisies. Remettre en forme les formats proposés par la norme pour les faire correspondre à ceux de Maximo. Codifier les quatre niveaux de la hiérarchie des équipements. Les Catégories et Types ont déjà un code attribué dans la norme, nous pourrons le conserver (P.ex: CE pour la catégorie "Combustible Engine" et DE pour le type "Diesel Engine").

- Faire apparaître quatre niveaux de classifications dans le module "Asset Catalog Setup" du menu "Inventory" et dans l'onglet "Specification" du module équipement à l'aide du "Centura Object Nationalizer". Les nommer: Category, Type, Sub-assembly et Maintenable Entity.

- Faire apparaître le champ "Failure Code" dans l'onglet principal du module équipement. Associer les équipements sélectionnés avec une "Failure Code".

- Faire disparaître le champ "Classification" de l'onglet principal du module équipement. Il sera remplacé par les données de l'onglet "Specifications".

- Créer les "Classifications", "Sous Classifications", "sous-ensembles", "Entités maintenables" ainsi que les "Données spécifiques" décrites par la norme dans le module "Asset Catalogue Setup" du menu "Inventory".

- Etendre les classifications aux équipements manquants dans la norme. Cela demandera l'expérience des personnes expertes du domaine.

- Assigner une classification à chaque niveau de l'arbre des équipements ou c'est applicable. Cela revient à assigner dans l'ordre un ou plusieurs des niveaux suivant de la hiérarchie: Catégorie, Type, sous-ensemble et Entité maintenable. Pour les équipements qui poseraient des problèmes, vérifier s'il est possible de modifier l'arbre ou la dénomination.

- Pour les équipements où c'est applicable. Reporter toutes les données d'équipement se trouvant dans les "Long Descriptions" dans le format proposé dans l'onglet "Classifications". Vu l'étendue de ce travail, celui-ci ne pourra pas être réalisé par les personnes du bord, mais par les superviseurs de Maximo lors de leur passage.

Les données de défaillance ne peuvent être définies que si les équipements le sont aussi. A chaque type d'équipement correspondra une "Failure Class".

- Afin de faciliter les futures saisies. Remettre en forme les formats proposés par la norme dans les annexes A & B pour les faire correspondre à ceux de Maximo.

- Créer la hiérarchie des "Failure class", "Problems", "Causes" et "Remedies" dans le module "Failure codes" de Maximo.

- Ajouter le niveau de hiérarchie DETECTION dans le module "Failure codes". Il est nécessaire pour les rapports de défaillances

- Etendre cette hiérarchie aux cas non décrits par la norme. Cela demandera l'expérience des personnes expertes du domaine.

- Assigner une "Failure Class" aux équipements. On préférera les niveaux ou seuls "Catégory+Type" sont définis. A défaut on l'indiquera au niveau "Category". Il s'agit de la valeur qui apparaîtra dans le "Work Order" lors de sa génération. A défaut, l'utilisateur devra choir dans les listes.

- Explorer les solutions pour créer les champs obligatoires manquant dans les écrans et dans la base de données. On vérifiera que ces champs ne sont pas inclus dans une partie de Maximo non encore utilisée. Cela concerne les champs suivants: Classe de sévérité, Echelle d'impact, les temps de maintenance.

Tâches additionnelles:

- Ecrire les scripts SQL d'installation.

- Choisir un site pilote et définir la façon de mettre à jour les données d'équipements.

- Créer et diffuser la documentation additionnelle décrivant les normes de création de la hiérarchie d'équipements et de remplissage des rapports de maintenance.

- Définir des critères de qualité des données enregistrées et se donner les moyens pour les évaluer.

- Créer les outils d'analyse des données de maintenance à partir des nouvelles informations. Les tests que nous avons faits dans la partie qualitative devront pouvoir être réutilisés pour définir les meilleurs outils.

- Pour le siège social: Créer les outils de regroupement et d'analyse d'informations de maintenance à partir des données des différents chantiers. Il existe un projet nommé MIMOSA qui pourrait répondre à ce type de problème.

Solutions commerciales:

MRO, l'éditeur de Maximo propose deux solutions permettant d'entrer des données conformes au standard ISO-14224.

- En ce qui concerne les d'équipement, il existe une extension nommée "Maximo asset specifications" qui contiennent à la fois les taxinomies des 17 catégories d'équipements cités dans la norme avec les différents types, sous-équipements, entités maintenables, et les tables de données spécifiques qui leurs sont propres (onglet "Specifications" du module EQUIPMENT). Un script SQL permet de mettre à jour Maximo avec ces données.

- En ce qui concerne les tables des "Problems, Causes & Remedies" pour chacun des équipements cités dans la norme, il existe une extension à Maximo nommée "Maximo Failure code for oil and gas"

Ce produit est livré avec des scripts SQL de chargement et contient environ 500 "Failure Class" d'équipements associées chacune aux "Problems", "Causes" et "Remedies".

Avantages:

- Il propose un cadre de normalisation pour les catégories et données caractéristiques des équipements décrits dans la norme.

- Il propose un cadre pour la saisie des rapports de défaillance dans les "Work Order".

- Ces produits peuvent être utilisés sur de nouvelles bases ou des bases existantes pour compléter les données.

Inconvénients:

- Ces deux produits font l'objet d'une licence par site et peuvent s'avérer un investissement lourd si on doit l'étendre à l'ensemble des chantiers.

- Ils ne proposent apparemment pas de solution pour les champs obligatoires ne se trouvant pas dans Maximo.

- Nous ne disposons toujours pas de moyen simple pour convertir les formats existants des données caractéristiques des équipements à partir de la "Long Description" ni à partir des données déjà saisies dans les "Specifications". Ce travail peut s'avérer important et ne pourra pas être fait par le personnel des chantiers.

- Les outils d'analyse des données de maintenance ne font pas partie de la proposition.

Note: Nous n'avons pas pu obtenir ni d'informations complémentaires ni de cotation concernant ces deux modules (hors documents commerciaux). Les achats étant regroupés au siège de Houston, nos demandes n'ont pas encore obtenu de réponse à la rédaction de ce document.

Note: Il pourrait s'avérer utile de disposer d'au moins une licence du produit pour pouvoir étudier les détails de l'implémentation proposée par MRO.

Publications de OREDA:

La 4ième édition du "OREDA Offshore Reliability Data Handbook" est sortie en 2002 (période 1997-2000, Phase IV & V) et contient des données concernant les taux de pannes, les modes de pannes et les temps moyens de réparation pour les équipements utilisés principalement dans les installations offshore.

Il semble que OREDA collabore maintenant avec de nouveaux fournisseurs en ce qui concerne les équipements sous-marins: ABB, Cameron Controls, FMC, Kvaerner. Toutefois, il s'agit principalement de données concernant les équipements de production.

Les équipements traités dans cet ouvrage sont plus nombreux que ceux proposés par la norme:

Rotating machinery

Mechanical equipment

Control & Safety

Subsea equipment

Combustion engines

Cranes

Fire & Gas detectors

Control systems

Compressors

Heat exchangers

Control Logic Units

Pipelines

Electric generators

Heaters and Boilers

HVAC

Manifolds

Electric motors

Swivels

Nozzles

Risers

Gas turbines

Turrets

Process sensors

Running tools

Pumps

Vessels

UPS

Subsea pumps

Steam turbines

Winches

Valves

Templates

Turbo expanders

 
 

Wellhead & X-mas trees

 
 
 
 

Note: A cause des délais d'achats d'environ six mois, il ne nous a pas été possible d'utiliser cet ouvrage comme référence pour traiter complètement de l'implantation de cette norme.

Conclusions:

Nous avons examiné les différents aspects de la norme et revu les moyens de l'implanter dans Maximo. Ce ne sont que des éléments de prise de décision que nous avons observé de notre point de vue local. Il restera à effectuer une analyse plus complète avant toute prise de décision au niveau du groupe.

Avantages:

- La norme ISO-14224:1999 est le cadre idéal pour normaliser à la fois la hiérarchie des équipements et des données spécifiques les concernant mais aussi pour valoriser les données de défaillances de nos historiques de maintenance.

- Elle impose peu de saisie complémentaires par rapport à l'existant.

- Elle permettra de valoriser nos données de maintenance et d'effectuer des comparaisons entre appareils.

- Les comparaisons pourront s'étendre aux mêmes équipements dans d'autres sociétés. Pour cela il nous faudra acquérir le:

"OREDA Offshore Reliability Data Handbook 4th edition"

- Elle peut ne s'adapter qu'à certains équipements spécifiques.

Inconvénients:

- Elle ne sera pas facile à mettre en place car les structures existent déjà et cela pourrait engendrer des travaux de saisie importants.

- Elle peut s'avérer chère si l'on utilise les produits proposés par MRO sur tous les chantiers car elle fait l'objet de deux licences par site.

- L'adaptation par nos services internes de cette norme pourrait s'avérer longue si elle doit être étendue à tous les chantiers.

- Il faudra attendra encore au moins un ou deux ans d'historiques de maintenance pour pouvoir en tirer des résultats tangibles. Les bénéfices ne pourraient se faire sentir qu'après cette période.

Note:

Les conclusions sur cette partie ne peuvent être que partielles pour plusieurs raisons:

- Nous n'avons pu disposer d'information concernant les extensions de Maximo proposées par MRO.

- Nous n'avons pu obtenir l'ouvrage de référence "OREDA handbook" afin d'en juger l'intérêt.

Conclusions concernant l'implantation de la norme ISO-14224:1999:

Autre piste à explorer:

Le produit Cognos Powerplay est un des outils que nous n'avons pu explorer faute d'en disposer sur notre site. Il s'agit d'un outil qu'utilise déjà MRO pour sortir certains rapports de maintenance ou financiers à partir de Maximo.

Powerplay est un outil dit OLAP (On Line Analytical Processing).

Il est conçu pour effectuer des analyses multidimensionnelles de jeux de données. A partir d'une base de données relationnelle ou non, on peut construire des diagrammes variés dont le modèle est construit graphiquement à partir des données croisées entre elles.

Ce type de rapport permet de faire des analyses croisées avec le niveau de détail adapté aux analyses demandées. Chaque dimension peut être scindée en ses sous ensemble pour obtenir une analyse fine (Drilldown).

Ce type de produit repose sur trois concepts:

- Le premier est la dimension. Une dimension est une entité de classification qui permet à l'organisation d'en mesurer les performances. Dans notre cas, ce serait par exemple: Le temps, les équipements, les services, les données de fiabilité, les locations, les données de défaillances.

- Le second concept repose sur les membres des dimensions ou catégories. Pour le temps, on pourrait citer l'année, le mois ou une période. Certaines catégories peuvent être des sous-ensembles d'autres catégories. Le mois est un sous-ensemble de l'année.

- Le troisième concept est celui des mesures qui représentent les rapports que l'on peut créer en croisant les membres des dimensions en fonction de l'activité exercée (maintenance, finance...).

Powerplay permet aussi de sortir des graphiques de type Pareto type 80/20. Ces graphiques n'ont pu être sortis avec les outils de Maximo, mais seulement après l'export des données vers d'autres applications.

Ce type de produit ou tout autre produit concurrent déjà interfacé avec Maximo pourraient être une solution aux analyses multidimensionnelles que nous avons tentées d'explorer au travers de nos différents prototypes SQR.

Il s'agit d'un produit que l'utilisateur final peut utiliser sans recours au service informatique. On pourrait disposer de vues spécifiques communes pour comparer les données des chantiers.

Les comparaisons entre vues ne pourront se faire que si les données de Maximo sont comparables entre chantiers. Nous revenons au problème de normalisation que nous avons déjà exploré dans le chapitre précédent.

Les produits concurrents sont: Business Object, MicroStrategy, SAP BW, Brio ou Oracle Discoverer. Nous n'avons pas exploré ces solutions.

Recommandations d'usage.

A la suite de l'étude de l'existant et de l'exploration des données de Maximo sur plusieurs chantiers, nous sommes à même de donner quelques indications pour corriger certains défauts ou améliorer la saisie des informations d'équipement et de maintenance.

Module EQUIPMENT:

- A l'examen des données d'historiques, on s'aperçoit que tous les arrêts ("Downtime") ne sont pas reportés dans le module équipement. Il semble que le principal frein vient du fait que l'équipement n'est pas remis en service automatiquement (statut UP) lors de la fermeture du "Work Order" qui a permis de le mettre en arrêt (statut DOWN).

Actuellement, la notion de "Downtime" est faite sur des formulaires standards à part de Maximo par les opérationnels des chantiers.

Il existe une forte opposition des chantiers et de la base pour inclure les "Downtime" dans Maximo. Certains font l'objet de négociations avec le client et ne peuvent être inclus dans le rapport final même s'ils ont généré des pertes opérationnelles. Il existe aussi une notion de tarif client en fonction du type de problème rencontré. L'aspect financier domine par rapport aux aspects techniques même s'ils s'influencent mutuellement. Il faudra que les directions statuent sur ce sujet.

- Rétablir la notion d'arrêt opérationnel ou non. Cette différenciation existait dans la version précédente de Maximo. Elle permettrait de pouvoir traiter le point précédent sans pour autant générer des alertes inutiles dans les rapports. On garderait dans ce cas un historique des arrêts opérationnels ou non séparément.

- Utiliser l'onglet classification du module EQUIPMENT pour entrer les caractéristiques d'équipements choisis dans la norme ISO-14224 et ajouter ceux qui ne s'y trouvent pas en respectant la taxinomie. Le champ "Classification" de la page principale devra disparaître au profit de celle de la norme. On disposera toujours de la "Long Description" pour donner les spécifications d'éléments non classifiables.

- Etendre la classification à tous les équipements du bord de façon à améliorer les diagrammes de Pareto qui pourraient être utilisés. La catégorie "Other" pourra être utilisée le cas échéant pour inclure les éléments non classifiables dont la description se trouve dans la "Long Description".

- Faire apparaître le champ "Failure Class" dans l'écran principal des équipements. Attribuer une "Failure Class" aux équipements suivant leur classification.

Module "Work Order":

- Améliorer les rapports dans les "Work Order" correctifs en imposant la saisie des informations suivantes dans les "Long description" qui contiennent le rapport de maintenance sous forme de texte non formaté:

· Description détaillée du problème.

· La cause du problème.

· Les actions entreprises pour le corriger.

· Le détail de ce qui permettrait d'éviter le problème à nouveau.

Si la hiérarchie des "Problems, Causes & Remedies" est mise en place ainsi que la mise en place de la norme ISO-14224, ces informations seront complémentaires de celles données dans le format imposé. Elles donneront des détails sur les opérations exécutées alors que les codes permettront de faire des statistiques plus générales.

- La phrase habituelle "job done as per job plan nothing abnormal to report" se trouvant dans les "Long Description des "Work Order" préventifs devra être remplacée par une autre donnant des conseils de remplissage d'informations utiles du type:

Mesures, consommations, remarque sur l'état, statut des pièces changées...

On peut proposer la phrase suivante:

"Enter any information regarding the result of the PM: Measurement, consumptions, remarks about the status of the equipment and the spare parts replaced".

- Ne pas hésiter à ajouter des documents attachés dans l'onglet "Linked documents" aux informations du rapport. Toutes les photos ou compléments techniques (tableaux, graphiques, rapport de visite de fournisseurs...) sont à prendre en compte pour valoriser l'expérience acquise. On préférera le format Acrobat .PDF à tout autre.

- Le champ "Duration" du "Work Order" doit devenir obligatoire et contenir la totalité des heures-homme effectuées et non le temps de réparation. Dans la mesure où chaque service doit faire son propre "Work Order", cela permettra de faire une répartition entre services.

- Les champs "Start Date" et "Finish Date" doivent devenir obligatoires et contenir des informations valables sur le temps passé sur un problème.

- Le champ "Failure report date" de l'onglet "Failure reporting" des "Work Order" doit devenir obligatoire et contenir la date de la panne. Cette date pourra être utilisée pour les calculs des statistiques de fiabilité comme le MTBF à la place du début des opérations de maintenance.

- Il faut définir des règles pour sélectionner la partie de l'arbre des équipements auxquels rattacher le "Work Order" . Actuellement, les avis divergent et il est difficile d'édicter une règle stricte tant le découpage est varié. On peut cependant donner les règles de bon sens suivantes:

è Lorsque le défaut peut être généralisé aux autres branches, remonter à la racine des branches. Préciser toutefois dans le titre, à quel élément on se réfère pour continuer à pouvoir identifier une panne propre à un des équipements.

P.ex: Panne d'un automate généralisable aux autres automates d'un système en contenant plusieurs du même type.

è Rester au niveau spécifique lorsque l'on veut donner une information de l'ordre du sous-ensemble ou de l'entité maintenable.

P.ex: S'il existe des parties électriques et hydrauliques, classer les pannes dans la bonne catégorie et non dans la racine de l'équipement.

è Ne descendre au fond de l'arbre que pour des éléments bien identifiés du sous-ensemble. Dans le cas contraire, rester au niveau de la racine des branches de l'équipement considéré et non au sommet d'un arbre général.

è Garder une même profondeur d'arbre pour des problèmes similaires. Regarder l'historique existant des problèmes similaires et garder la même logique de rapport.

è Ne pas créer de maintenance dans les trois premiers niveaux de l'arbre qui ne contiennent pas d'informations d'équipement, mais plutôt un découpage. On pourra faire exception à cette règle pour les parties certifications propres au chantier qui pourront être placées au sommet de l'arbre.

- Les utilisateurs doivent générer un "Work Order" correctif s'ils découvrent un défaut ne faisant pas parti du processus de maintenance préventive normal.

On rappelle que la maintenance préventive ne doit comprendre que: les opérations normales de maintenance (graissage, serrage, mesures...) et changement de pièces d'usures (charbons, lampes...) ou de consommables (huile, graisse...). Lorsqu'il y a recherche de panne, il s'agit le plus souvent de maintenances correctives.

Par contre, les éléments de diagnostics comme les échantillons d'huile ou la thermographie sont des maintenances préventives. Ils devraient faire parties de maintenances conditionnelles, mais cette pratique ne fait pas partie de notre organisation de la maintenance (MBF).

- Faire un "Work Order" par service et non global. Actuellement, sur certaines opérations de grosses maintenances, des WO génériques sont créés en début d'opération afin de regrouper les coûts. D'une part, les coûts peuvent être facilement calculés par équipement avec récursivité sur les sous équipements en sortant le rapport CO-BY-EQ du module équipement. D'autre part, cela fausse les historiques, car ceux-ci ne sont pas attachés aux bons équipements ni aux bons services.

- Ne pas enregistrer les mouvements de stock dans un "Work Order" correctif, mais sous le type RM (pour routine maintenance). Cela évitera de les inclure dans les décomptes des maintenances. On fera de même pour les sorties de matériel consommable qui n'en sont pas non plus. Les remarques ou alertes ne sont pas non plus à mettre en CWO.

Conclusions générales.

Partie quantitative:

En terme de réalisation:

- Nous avons atteint l'objectif que nous nous étions fixé.

- Les utilisateurs sont satisfaits et le prototype correspond aux besoins exprimés.

- Le prototype a été implanté sur cinq sites de test en Angola.

Toutefois, certains travaux restent à faire:

- Valider les données du prototype sur plusieurs mois.

- Finaliser la version du programme afin de la faire correspondre aux normes de développement et d'installation du groupe. Compléter la documentation du programme. A l'issue de cette étape, créer la version de production initiale 1.0.

- Créer les documentations pour inclure ce rapport dans les manuels de Maximo.

- Même si les utilisateurs sont satisfaits, rien n'indique pourtant que les données fournies puissent être utilisées avec bénéfice pour le suivi de la maintenance. Il nous faudra suivre les comptes rendus des utilisateurs dans les mois à suivre pour avoir une idée plus précise de la situation.

- Le fichier source du programme et sa documentation ont été envoyées au siège de Houston, mais le produit n'a pas encore eu d'approbation définitive à l'écriture de ce document.

Ce produit reste une création locale et ne pourra être utilisé officiellement qu'après réception de l'accord officiel du siège social.

Partie qualitative:

Nous avons examiné plusieurs méthodes d'analyse qualitative des rapports de maintenance.

Aucune de ces méthodes n'a donné de résultats utilisables d'une façon sure pour les raisons suivantes:

- La saisie des données de maintenance n'est pas assez contraignante pour donner des informations fiables.

- Il n'existe pas de catégorisation des équipements.

- Il n'existe pas de catégorisation des défaillances. Les données de défaillance sont stockées sous forme de texte libre inutilisable pour une analyse automatique.

Tant que ces problèmes ne seront pas résolus, il serait illusoire de vouloir obtenir d'autres informations que quantitatives à partir des données de Maximo sans retraitement manuel.

Les méthodes statistiques examinées ne sauraient dans tous les cas être mises en place sans une formation adéquate aux problèmes de la fiabilité des équipements. Leur interprétation reste complexe et ne pourra être faite que par un nombre restreint de personnes au siège social ou sur les bases importantes. Les conséquences des décisions prises avec ce type d'outils devront être examinées sur des sélections d'équipements bien maîtrisés avant d'être généralisées.

Dans notre environnement, il serait préférable d'utiliser des outils de type Powerplay permettant aux utilisateurs d'extraire des données sous différents formats sans recours au service informatique du siège. Nous recommandons les analyses de type Pareto qui paraissent les plus accessibles et les plus faciles à interpréter.

Amélioration du retour d'expérience:

Tout d'abord, une mise au point avant de commencer ce chapitre. Il ne s'agit pas ici de remettre en cause les techniques de maintenance telles qu'elles sont utilisées dans notre organisation. Les maintenances préventives ont fait leurs preuves pour ce qui est d'améliorer la fiabilité des équipements sur nos chantiers. Toutefois, l'utilisation des historiques comme source d'information pour le retour d'expérience pourrait être améliorée.

Nous avons proposé un certain nombre de règles d'usage destinées à améliorer la qualité de saisie des rapports de Maximo. Il ne s'agit que des règles minimales qui permettraient d'améliorer le produit existant, mais pas de le transformer notablement.

Nous proposons en revanche l'implémentation de la norme ISO-14224:1999 qui permettra d'améliorer le circuit de retour d'expérience. Nous avons donné les éléments nécessaires pour décider du bien fondé d'une telle migration.

L'implantation de la norme nous permettrait de normaliser la hiérarchie des équipements, mais aussi les rapports de défaillances. Les objectifs de la collecte d'informations normalisées seraient les suivants:

- Analyse des problèmes d'un chantier et possibilité de comparaison avec d'autres.

- Optimisation des maintenances préventives:

Elimination des maintenances redondantes ou inutiles.

Ajout des maintenances manquantes.

Changement des "Job Plan" des maintenances inadéquates, présentant des risques ou accroissant les risques de pannes.

Adaptation de périodicités trop courtes ou trop longues.

Utilisation de maintenances conditionnelles.

- Plus lointains, mais possibles: Construction des FMEA, des arbres de causes, Ishikawa...

Aucun d'eux ne peut être atteint à partir des informations extraites de la base actuelle autrement que par un retraitement manuel important.

Malgré les avantages d'une telle normalisation, l'implantation complète d'une telle norme ne sera pas simple et devra dans un premier temps faire l'objet d'une étude de faisabilité et d'opportunité. Elle ne constitue qu'une première étape permettant de construire une base de donnée fiable et réutilisable. Il restera à sélectionner les outils d'analyse parmi ceux que nous avons explorés, mais aussi et surtout à interpréter les résultats et à en tirer des enseignements utiles pour la gestion de la maintenance.

Comme nous l'avons dit en introduction, quel que soit l'outil informatique choisi, seule l'interprétation humaine des résultats conduira à une prise de décision. C'est là ou se jouera tout le talent des professionnels de nos chantiers.

Si nous avons atteint nos objectifs quand à la partie quantitative, les autres domaines ne restent que dans le domaine de la prospective. Ils ne dépendent que des améliorations de Maximo que nous voudrons implémenter.

Nous avons exploré un certain nombres de domaines et donné des solutions pour atteindre nos objectifs. Ce document devra servir de base pour les prises de décisions qui s'imposent si nous voulons améliorer le retour d'expérience de notre outil de gestion de la maintenance.

Annexe A.

Littérature:

- [ZWINa] "La maintenance basée sur la fiabilité guide pratique d'application de la RCM", Hermes, ZWINGELSTEIN.

- [ZWINb] "Diagnostic des défaillances: Théorie et pratique pour les systèmes industriels", Hermes, ZWINGELSTEIN.

- [FRAN] "La fonction maintenance", AFNOR, Jean Claude Francastel.

- [HENG] "Pratique de la maintenance préventive", Dunod, l'Usine Nouvelle, Jean Héng.

- [AFNO] "Comment réussir votre maintenance", AFNOR.

- [JACQ] Exposé "Maintenance Productive Totale", Philippe Jacquemier.

- [SHIR] "Le guide TPM de l'unité de travail", Dunod, Kunio Shirose.

- [MOUB] "Reliability-Centered Maintenance, 2nd ed", Industrial Press, MOUBRAY John.

- [BLON] "Aide mémoire Gestion Industrielle", Dunod , François Blondel.

- [BENA] "La gestion des stocks", Hermes, Jean Bénassy.

- [VONK] "Prototypage", Masson Printice Hall, R. VONK.

- [HUGU] "RAD, une méthode pour développer plus vite", InterEditions, Jean Hugues/Bernard Leblanc/Chantal Morley.

- [UML3] "Visual Paradigm for UML Community Edition 3.0", User's Manual.

- [VICK] "Systèmes d'information et processus agiles", Hermes, Jean-Pierre Vickoff.

- [ORED] "OREDA Reliability Data Book" or ISO 14224:1999.

- [PSDI] PSDI "Maximo User's manual" & "Administrator's manual".

- [CENT] Centura "SQLbase administrator & user's manual".

- [GALI] "SQR in PeopleSoft and other applications", Manning, Galina et Vlad Landres.

- [LEAR] "Programmation Microsoft Access", Learning Tree.

- [GETZ] "Access en action", O'Reilly, Ken Getz.

- [CLLH] "Access 2000 visual basic applications", Microsoft Press, Evan Cllhan.

Sites internet:

- http://www.maximo-users.net. MRO Maximo User's group.

- http://www.mro.com. Site de MRO.

- http://www.weibull.com.

- http://www.sintef.no. Projet OREDA.

- http://www.rad.fr. Développement RAD, processus agiles.

- http://perso.wanadoo.fr/nathalie.diaz/index.htm. Normes de qualité ISO.

- http://www.jipm.or.jp/en/home/. Japan Institute of Plant Maintenance ( JIPM ).

- http://www.afim.asso.fr. Association de maintenance.

- http://www.cnam.fr/. Site du Conservatoire National des Arts et Métiers.

Lexique et acronymes:

- 5S: (Seiri, Seiton, Seiso, Seiketsu, Shitsuke) en français (Débarrasser, Ranger, Nettoyer, Standardiser, self discipline).

- CCV: Coût global du cycle de vie.

- CMMS: Computerized Maintenance Management System.

- CPI: Chef de projet informatique.

- CSV: Coma Separated Values.

- CWO: Corrective Work Order.

- EPE ou EVP: Évaluation de performances.

- EQR: Estimation Quantitative du Risque.

- EM: Entité Maintenable.

- FMD: Analyse de Fiabilité, Maintenabilité et Disponibilité

- FM: Fiabilité et Maintenance

- FRACAS : Failure reporting and corrective action systems.

- FTA: Fault tree analysis.

- ISM: International Safety Management.

- JP: Job plan. Liste d'opérations à réaliser pour effectuer une maintenance préventive.

- LCC: Live Cycle Cost.

- LDA: Luanda, capitale de l'Angola, par extension base opérationnelle de Luanda.

- MBF: Maintenance Basée sur la Fiabilité.

- MCF: Maintenance centrée sur la fiabilité

- MMR: Monthly Maintenance Report.

- MR: Material Request. Requête pour l'achat d'équipements, consommables ou service.

- MRO: Les fabricants du progiciel de la PMS Maximo.

- MTBF: Mean Time Between Failure.

- MTTR: Mean Time To Repair.

- OEE: Overall Equipment Efficiency = TRS.

- OLAP: On Line Analytical Analysis.

- OREDA: Projet de collecte de données de fiabilité et de maintenance des équipements utilisés dans les industries du pétrole et du gaz naturel.

- PM: Preventive Maintenance.

- PMS: Preventive Maintenance System.

- PO: Purchase Order. Commande d'équipement, consommables ou de service.

- PWO: Preventive Work Order.

- TC: Technical Coordinator.

- TPM: Total Productive Maintenance.

- TRS: Taux de Rendement Synthétique en TPM.

- WO: Work Order.

Annexe B: Exemple de rapport qualitatif final.

Exemple de résultats fourni par le prototype quantitatif à l'issue de la version 0.5b.

Annexe C: Résultats des tests Weibull++.

Résultats des tests obtenus à l'aide du logiciel Weilbull++ 6.0.