Tests en réel sur les serveurs des chantiers:
- L'installation du rapport proprement dit et la configuration
de Maximo n'ont posé aucun problème sur aucun des sites. Seule la
lenteur de "Windows Terminal Server" lors des opérations à
distance a imposé des temps de mise à jour non
négligeables avec parfois des coupures de communications
intempestives.
- Le rapport a été implanté sur 5 sites:
PAN, PAF, PNA, PSP, BDA.
- Sur PNA, il a fallu réorganiser la base pour pouvoir
sortir le rapport. Le CPI se trouvait sur le site à ce moment ce qui n'a
pas posé de problème. Cette opération est possible
à distance, mais pose des problèmes en cas de reprise. On
évitera de procéder à distance.
- Sur PSP, le rapport ne fonctionnait pas, car certains
départements n'existaient pas dans le programme. Nous avons
traité le cas avec une colonne supplémentaire comptant les cas
non répertoriés. Cette colonne pourra être utilisée
par les administrateurs de Maximo pour corriger ces valeurs. Dans la mesure ou
nous explorons la totalité des fichiers historiques, il ne nous est pas
possible de ne pas les prendre en considération.
La base de PSP a aussi nécessité une
réorganisation pour fonctionner.
La réorganisation de la base se passe en plusieurs
étapes:
Voir "SQL base, database Administrator's guide" et "SQL base,
SQL language reference".
On évite de faire cette opération à
distance pour des problèmes de récupération s'il se
produit un problème lors du processus. Seuls les opérateurs avec
droits que sont les administrateurs de Maximo peuvent exécuter ces
opérations.
Les opérations à effectuer sont les
suivantes:
- S'assurer qu'aucun utilisateur n'est connecté
à la base de donnée.
- Sortir du moteur de la base de donnée.
- Faire une sauvegarde du fichier .DBS de la base de
données. La base de donnée peut être perdue si une erreur
se produit durant la réorganisation.
- Relancer le moteur de la base.
- Lancer SQLTalk.
- Se connecter à la base de données en tant
qu'Administrateur.
- Lancer les commandes SQL suivantes après s'être
assuré qu'aucun utilisateur n'est connecté à la base de
données:
set recovery off; Principalement pour des
problèmes de performances.
check database; effectue un test
d'intégrité complet de la base donnée (données et
index).
reorganize; Défragmentation de la base de
donnée (Unload to a file, initialize, Reload from Unload file).
set recovery on;
update statistics on database; Remets à jour
les statistiques de la base de données.
exit; Sortie de SQLTalk.
|
Minutes of meeting prototype n°4 par les
utilisateurs des chantiers:
|
|
|
Situation:
|
|
Le prototype n°4 a été installé sur
5 chantiers. Les résultats du mois de juin 2004 ont été
diffusés aux utilisateurs avec un explicatif sur les différentes
informations fournies par le rapport ainsi qu'un mode d'emploi.
Ce document contient le résumé des remarques des
personnels de chantier après installation du prototype sur les chantiers
et après visualisation des résultats du mois de juin 2004. Les
personnes rencontrées ont été variées à tous
les niveaux de la hiérarchie.
|
|
|
Participants: 7 personnes.
Durée1 heure.
|
|
- Ph JUNG CPI: Chef de projet. Superviseur de maintenance.
- TC chantiers: PAN, PAF.
- SM chantier: BDA.
- MSUP Maximo Houston.
|
|
|
Rappel sur l'objectif de la
réunion:
|
|
- L'objectif de ces réunions est d'obtenir les avis des
différentes personnes concernées par le projet à propos du
format du rapport ainsi que l'intérêt de son contenu.
- Le but est de créer un prototype n°5 avec les
nouvelles informations à partir de ces remarques.
|
|
|
Propositions et remarques des
participants:
|
|
- La partie liste des "Material Request" associée aux
"Work Order" dans l'état WMATL est appréciée.
- Les parties "Major PM previsions" et "Equipement down" sont
jugées intéressantes. La période de 6 mois pour la partie
prévision des PM est jugée acceptable, car elle correspond au
temps moyen d'approvisionnement du matériel.
- La partie TOP5 est jugée intéressante, mais
n'indique qu'une situation passée. Elle pourrait être
intéressante sur plusieurs mois si le même équipement
revient dans la liste. Il semble clair que d'autres rapports devront
étayer ces informations.
- Les TC confirment ne pas utiliser les "Downtime" par peur
d'oublier de remettre les équipements Up avant de fermer le "Work
Order".
- Les utilisateurs ont une peur concernant ce rapport:
· Ils pensent que ce rapport servira à la
direction de LDA et de Houston de comparaison entre chantiers afin d'entretenir
une compétition.
· Les différents services s'inquiètent de
voir apparaître les heures cumulées par service. Il leur semble
que ces heures sont faibles par rapport aux équipes et au travail
effectué dans la réalité.
· Les pourcentages d'overdue sont aussi
une source d'inquiétude, car le pourcentage moyen autour de 35%
paraît important. Ils demandent une liste des "Overdue" principaux. On
confirme que les "Major Overdue" sont les PM >1 an et 1000h ayant
dépassé 25% de la période de la maintenance.
- Les TC demandent l'ajout d'une partie financière au
rapport. Pas d'idée précise sur le format. On nous demande de
faire des propositions.
- Tenter d'améliorer la lisibilité du rapport et
corriger certaines erreurs d'affichage.
- Le CPI rappelle que les résultats n'ont toujours pas
été vérifiés complètement et que cette
opération devra être faite un jour ou l'autre avant une
utilisation en réelle des données.
|
|
|
Conclusions:
|
|
- Nous allons ajouter une partie financière au rapport.
Reste à en définir le contenu.
- Nous allons créer une liste des "Major PM
overdue".
|
| 