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

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.

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.

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

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

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.

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.

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.

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.

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)

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.

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.

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.

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

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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.

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.

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.

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

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.

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.

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

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

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.

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.

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.

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)

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.

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

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.

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.

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.

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.

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.

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

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.

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

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.

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

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

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.

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.

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

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:

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.

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

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:

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

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.

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.

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.

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

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

Initialisation du projet.

Fonction

WONUM

UPPER

10

Work Order

Abréviation

WAPPR

WSCH

APPR

LEADCRAFT

CREWID

CE

Chief Electrician

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