|
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 |
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:
De ces huit états nous ne garderons que six:
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:
- 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:
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.
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.
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:
Nous aurons une deuxième colonne du même format, mais pour les maintenances correctives: TOP5 list of CM man hours consumption:
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
Equipment down: proposition 2
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:
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.
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 Period from xxxx to yyyyy Preventive Maintenance: MMR v0.1b
Note: Overdue is after 25% of the period of the PM. Corrective Maintenance:
Top 10 list of the CM man hours consumption:
Equipment down:
Major PM prevision: Over 2 Years, or 10000h for the next month.
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.
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.
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
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:
- 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. 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:
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.
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édent 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édent 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édent 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édent 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.
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.
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.
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. 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.
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:
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).
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.
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.
- 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. 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.
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 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.
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: 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.
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.
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.
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.
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".
N'a pas d'équivalent dans les écrans Maximo. Elle pourra être incluse dans les spécifications.
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.
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.
P.ex, Présence de gaz, pression, débit. Elles pourront apparaître dans la liste des données spécifiques à la catégorie.
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":
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:
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.
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.
Table 21 Données de maintenance ISO-14224. 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. 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. 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:
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. 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: 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. 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. - 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. - 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é:
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:
P.ex: Panne d'un automate généralisable aux autres automates d'un système en contenant plusieurs du même type.
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.
- 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. 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. 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:
- 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. - [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. - http://www.maximo-users.net. MRO Maximo User's group. - http://www.mro.com. Site de MRO. - 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. - 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. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
. Le plus souvent on considère que =0 (qui indique le temps entre
la mise en service et la première panne).
