Tableau de bord/Chapter 9/1.1 — Safety Plans
Chapter 9 · leçon 1 sur 2
Les plans de sécurité dans Maximo Manage sont des entités fondamentales pour garantir la sécurité des opérations de maintenance. Ils sont conçus pour être intégrés de manière transparente dans le processus de gestion des ordres de travail, assurant que les considérations de sécurité sont prises en compte dès la planification et jusqu'à l'exécution du travail.
L'architecture des plans de sécurité repose sur une structure hiérarchique et relationnelle, permettant de définir des mesures de sécurité génériques ou très spécifiques. Ils peuvent être associés à des actifs, des emplacements, des tâches d'ordre de travail, et même des plans de travail (`JOBPLAN`), ce qui en fait un outil polyvalent pour la gestion des risques.
Il est essentiel de distinguer les plans de sécurité d'autres documents ou processus de Maximo qui, bien que liés à la sécurité, ont des objectifs et des portées différentes. Cette distinction permet une application correcte et efficace de chaque outil.
Le tableau suivant compare les plans de sécurité avec les plans de travail (`JOBPLAN`) et les codes de défaillance (`FAILURECODE`), qui sont souvent utilisés en conjonction mais ne remplissent pas la même fonction principale.
| Caractéristique | Plan de Sécurité | Plan de Travail (`JOBPLAN`) | Code de Défaillance (`FAILURECODE`) |
|---|---|---|---|
| Objectif Principal | Prévenir les incidents et assurer la sécurité du personnel. | Définir les étapes et ressources pour exécuter un travail. | Classer et analyser les causes des pannes. |
| Contenu Typique | Dangers, précautions, EPI, procédures d'urgence. | Tâches, main-d'œuvre, matériaux, services, outils. | Hiérarchie des problèmes, causes, remèdes. |
| Association Clé | Ordres de travail, actifs, emplacements. | Ordres de travail, PM, actifs, emplacements. | Actifs, ordres de travail (rapport de défaillance). |
| Focus Temporel | Avant et pendant l'exécution du travail. | Planification et exécution du travail. | Après la survenue d'une panne. |
| Impact sur le travail | Conditions préalables à l'exécution, instructions de sécurité. | Description détaillée des étapes à suivre. | Analyse post-événement pour amélioration. |
| Révision | Régulière, en fonction des risques et réglementations. | Périodique, en fonction des meilleures pratiques. | Basée sur l'analyse des incidents. |
La gestion des plans de sécurité dans Maximo Manage implique plusieurs étapes, de la création à l'application et à la révision. Une approche structurée est essentielle pour garantir leur efficacité et leur pertinence continue.
L'application `Safety Plans` (ou une application similaire selon la configuration spécifique de l'instance Maximo) est le point central pour la création et la maintenance de ces plans. Les utilisateurs autorisés peuvent y définir les détails de chaque plan, y compris les dangers, les précautions et les EPI.
Le cycle de vie d'un plan de sécurité dans Maximo Manage est un processus structuré qui garantit sa pertinence et son efficacité tout au long de son utilisation. Il commence par la création et passe par des phases d'approbation, d'activation, d'utilisation et de révision, se terminant potentiellement par son obsolescence.
Chaque étape du cycle de vie est cruciale pour maintenir l'intégrité et l'applicabilité des mesures de sécurité définies. Les changements de statut sont souvent soumis à des workflows d'approbation pour assurer la conformité et la validation par les parties prenantes.
Un piège courant est de créer des plans de sécurité détaillés mais de ne pas les associer correctement aux ordres de travail (`WORKORDER`). Les techniciens peuvent alors exécuter des tâches sans être pleinement conscients des dangers ou des précautions requises. Maximo permet l'association manuelle ou automatique via les actifs/emplacements ou les plans de travail (`JOBPLAN`). L'examen peut présenter un scénario où un plan de sécurité existe mais n'est pas appliqué, entraînant un incident. La solution réside dans la vérification des associations et l'intégration des plans de sécurité dans les `JOBPLAN` standards.
Les conditions de travail, les équipements et les réglementations évoluent. Un plan de sécurité qui n'est pas régulièrement révisé peut devenir obsolète, conduisant à des informations de sécurité incorrectes ou incomplètes. Maximo ne force pas la révision, mais il est de la responsabilité de l'organisation de mettre en place des processus de revue périodique. Un piège d'examen pourrait décrire un incident dû à un plan de sécurité non mis à jour, testant la compréhension de l'importance de la gestion du cycle de vie des plans de sécurité.
Bien que les plans de sécurité puissent être intégrés aux plans de travail (`JOBPLAN`), ils ne sont pas interchangeables. Un `JOBPLAN` décrit les étapes techniques pour accomplir une tâche, tandis qu'un plan de sécurité se concentre spécifiquement sur les dangers et les précautions. Un piège pourrait consister à suggérer qu'un `JOBPLAN` détaillé suffit à couvrir tous les aspects de sécurité sans un plan de sécurité dédié. Il est crucial de comprendre que le plan de sécurité complète le `JOBPLAN` en ajoutant la dimension de gestion des risques.
L'objectif principal est de prévenir les incidents en identifiant les dangers, en spécifiant les précautions et les EPI. Il est intégré en étant associé aux ordres de travail (`WORKORDER`), aux actifs (`ASSET`), aux emplacements (`LOCATION`) et aux plans de travail (`JOBPLAN`), garantissant que les mesures de sécurité sont communiquées et appliquées lors de l'exécution des tâches.
Les composants clés incluent les dangers identifiés, les précautions à prendre, les équipements de protection individuelle (EPI) requis et les procédures d'urgence. Il est crucial de les maintenir à jour car les conditions de travail, les équipements et les réglementations évoluent, et des informations obsolètes peuvent compromettre la sécurité du personnel et l'intégrité des actifs.
Maximo permet l'application des plans de sécurité aux ordres de travail (`WORKORDER`) de manière manuelle ou automatique. Les méthodes d'association incluent la liaison directe à un `WORKORDER`, l'association à un actif (`ASSET`) ou un emplacement (`LOCATION`) qui est ensuite référencé par le `WORKORDER`, ou l'intégration du plan de sécurité dans un `JOBPLAN` qui est appliqué au `WORKORDER`.
Questions d’examen de style IBM. Cliquez une option, puis « Vérifier ma réponse ». Progression enregistrée localement.
Bonne réponse : C
Pourquoi cette question existe — STU §9.1 — la question vérifie les 3 cibles exactes auxquelles une opération de lock out peut s'appliquer dans une procédure de Tag Out : Location, Asset, ou Device Description, par opposition à des distracteurs proches mais incorrects (Lockbox, Item, Locks and Keys). En pratique, supposer qu'une opération de lock out peut viser un Item plutôt qu'un Device Description fait mal configurer la procédure de consignation.
Le contexte théorique d'abord — Une tag out procedure dans l'application Lock Out / Tag Out liste une ou plusieurs lock out operations. Chaque opération de lock out s'applique à une Location, un Asset, ou une Device Description (description libre de dispositif quand l'élément n'est pas formellement un asset ou une location enregistrée), et précise l'état requis (Required State) après application.
Ce que Maximo en fait — version opérationnelle — Dans Lock Out / Tag Out > créer une tag out procedure > section Lock Out Operations > New Row > choisir si l'opération s'applique à une Location, un Asset, ou saisir une Device Description > définir le Required State attendu après consignation.
Exemple chiffré — Une tag out procedure comportant 5 lock out operations peut viser 2 Assets, 1 Location et 2 Device Descriptions, soit 3 catégories de cibles couvertes sur un total de 5 opérations.
Analogie quotidienne — C'est comme une fiche de consignation électrique qui précise pour chaque cadenas posé s'il verrouille un disjoncteur identifié (asset), une armoire électrique (location), ou un dispositif décrit textuellement faute de référence formelle.
Pourquoi A est faux — Pattern D9 quasi-synonyme : « Lockbox » n'est pas une des 3 cibles officielles d'une lock out operation ; c'est Location qui figure dans la liste correcte.
Pourquoi B est faux — Pattern D9 quasi-synonyme : « Item » remplace à tort « Device Description » dans cette liste de 3 cibles.
Pourquoi D est faux — Pattern D5 champ-frère : « Locks and Keys » décrit le matériel physique de consignation, pas les cibles fonctionnelles de l'opération de lock out.
Bonne réponse : B
Pourquoi cette question existe — STU §9.1 — la question distingue ce qui peut être formellement « tagué » (Tag Out) dans l'application — Location ou Asset — des cibles plus larges utilisables dans une lock out operation (qui incluent aussi Device Description, cf. Q7). En pratique, confondre les cibles du Tag Out lui-même avec celles des opérations internes de lock out fait mal interpréter la portée de la consignation enregistrée.
Le contexte théorique d'abord — Un enregistrement Tag Out dans l'application Lock Out / Tag Out se crée et s'applique à une Location ou à un Asset formellement enregistré dans Maximo. C'est cet enregistrement principal de Tag Out qui sert ensuite de point d'ancrage pour empêcher l'exécution de travail sur cette location/asset jusqu'à sa levée.
Ce que Maximo en fait — version opérationnelle — Dans Lock Out / Tag Out > créer un nouveau Tag Out > sélectionner soit une Location soit un Asset comme cible principale > appliquer la tag out procedure correspondante > tant que le Tag Out est actif, l'asset/location concerné est protégé contre toute intervention non autorisée.
Exemple chiffré — Sur 10 Tag Outs actifs dans un site, 6 peuvent être appliqués à des Assets et 4 à des Locations, couvrant ainsi les 2 seules catégories de cibles principales possibles pour un enregistrement Tag Out.
Analogie quotidienne — C'est comme apposer un panneau « hors service » soit directement sur une machine (asset), soit à l'entrée d'une zone entière (location), mais pas sur un simple composant décrit textuellement sans existence formelle dans le registre.
Pourquoi A est faux — Pattern D5 champ-frère : un Configuration Item relève d'une autre structuration de données (CI), pas la cible standard d'un Tag Out.
Pourquoi C est faux — Pattern D9 quasi-synonyme : remplacer Asset par Item dans la paire change la nature de la cible ; un Item (article de stock générique) n'est pas une cible de Tag Out.
Pourquoi D est faux — Pattern D4 demi-vérité : un Device (Device Description) est une cible valide pour une lock out operation interne (cf. Q7), mais pas la cible principale formelle de l'enregistrement Tag Out lui-même.
Bonne réponse : B
Pourquoi cette question existe — STU §9.1 — la question vérifie quelle association précise devient en lecture seule une fois qu'un hazard a des précautions associées : Tag Out, par opposition à d'autres associations réelles (Qualifications, Hazardous Materials, Risk Assessment) qui restent éditables indépendamment de cette configuration. En pratique, ignorer ce comportement fait chercher à tort à modifier manuellement une association qui est désormais pilotée automatiquement par les précautions.
Le contexte théorique d'abord — Lorsqu'un Hazard a la case Can Have Precautions cochée et qu'une ou plusieurs Precautions lui sont associées dans l'application Precautions, l'association Tag Out du hazard devient read-only : les tag outs associés au hazard sont désormais dérivés/gérés via les précautions elles-mêmes, plutôt que configurés directement et indépendamment sur le hazard.
Ce que Maximo en fait — version opérationnelle — Dans Hazards > créer le hazard, cocher Can Have Precautions > dans Precautions > associer une ou plusieurs précautions au hazard > retourner sur le hazard > l'association Tag Out apparaît désormais grisée (read-only), reflétant les tag outs définis au niveau des précautions associées.
Exemple chiffré — Un hazard associé à 3 précautions, chacune référençant son propre Tag Out, affichera ces 3 Tag Outs en lecture seule sur le hazard, contre une édition libre possible si 0 précaution n'était associée.
Analogie quotidienne — C'est comme un protocole de sécurité générique qui, une fois rattaché à des consignes détaillées spécifiques, ne peut plus être modifié directement à la source : il faut passer par les consignes détaillées pour en changer le contenu.
Pourquoi A est faux — Pattern D5 champ-frère : Qualifications reste une association indépendante des précautions associées au hazard.
Pourquoi C est faux — Pattern D5 champ-frère : Hazardous Materials reste configurable indépendamment de l'ajout de précautions sur le hazard.
Pourquoi D est faux — Pattern D5 champ-frère : Risk Assessment n'est pas affectée par cette règle de lecture seule liée aux précautions.
Bonne réponse : A
Pourquoi cette question existe — STU §9.1 — la question vérifie le niveau de segmentation de données exact des enregistrements Tag Out : SITE, cohérent avec le fait que les Tag Outs s'appliquent à des Locations/Assets eux-mêmes définis au niveau Site, par opposition à des niveaux plus larges (ORG, SYSTEM) ou à un niveau inventé (ORGSITE). En pratique, confondre ces niveaux fait mal anticiper la visibilité d'un Tag Out entre sites d'une même organisation.
Le contexte théorique d'abord — Maximo segmente ses tables selon les niveaux System, Organization et Site (Table des niveaux de configuration de base de données). Les enregistrements Tag Out sont stockés au niveau SITE, cohérent avec le fait que les Locations et Assets auxquels ils s'appliquent sont eux-mêmes des données de niveau Site : un Tag Out créé sur un site n'est donc pas visible ni applicable depuis un autre site, même de la même organisation.
Ce que Maximo en fait — version opérationnelle — Dans Lock Out / Tag Out > créer un Tag Out dans le contexte du site courant > l'enregistrement est stocké avec le siteid correspondant > un utilisateur connecté à un autre site de la même organisation ne pourra ni le voir ni l'appliquer sans changer de site.
Exemple chiffré — Une organisation comptant 4 sites peut avoir jusqu'à 4 ensembles distincts de Tag Outs actifs, chacun visible uniquement depuis son site d'origine, sur un total de 4 sites configurés.
Analogie quotidienne — C'est comme un badge d'accès valable uniquement dans le bâtiment où il a été émis : même si l'entreprise possède plusieurs bâtiments (sites) au sein d'une même société (organisation), le badge ne fonctionne que localement.
Pourquoi B est faux — Pattern D2 inventé : « ORGSITE » n'est pas un niveau de segmentation de données reconnu dans Maximo.
Pourquoi C est faux — Pattern D9 quasi-synonyme : le niveau ORG est plus large que SITE et permettrait un partage entre sites, ce qui ne correspond pas au comportement réel des Tag Outs.
Pourquoi D est faux — Pattern D9 quasi-synonyme : le niveau SYSTEM est le plus large possible (toute l'instance), bien au-delà du périmètre réel des Tag Outs.
Certavia