Organigramme de gestion du processus de changement (MOC, PSSR, expiration)

Un organigramme de processus de gestion du changement (MOC) pour la sécurité des processus : sélection de remplacement en nature, classification, examen des dangers, autorisation, PSSR avant le démarrage et boucle d'expiration des…

Utiliser ce modèle

Qu'est-ce que le processus organigramme de gestion du processus de changement (moc, pssr, expiration) ?

La gestion du changement est le contrôle qui échoue silencieusement. Personne n'écrit une procédure MOC qui permet une modification non vérifiée ; ce qui se passe à la place, c'est que le processus s'articule autour d'une petite décision à la fois. Une pompe est remplacée par une pompe légèrement différente et appelée à l'identique. Un tuyau de dérivation est installé jusqu'au prochain arrêt et est toujours là quatre ans plus tard. Un changement est effectué les soirs et la paperasse est remontée la semaine suivante pour décrire ce qui est déjà installé. Un contrôle avant démarrage est signé sur la base d'une vérification que personne n'a effectuée, car l'usine devait être restituée. Les enquêtes sur les incidents majeurs liés à la sécurité des processus aboutissent toujours au même endroit : il ne s’agit pas d’un danger inconnu et exotique, mais d’un processus connu qui n’a jamais été appliqué à un changement dont personne ne pensait qu’il était considéré comme un changement. Flixborough est le cas que tout ingénieur de procédés apprend (une conduite de dérivation temporaire installée entre deux réacteurs sans dessin, sans calcul et sans test de pression). C'est pourquoi un organigramme MOC mérite d'être dessiné correctement. La valeur ne réside pas dans la séquence de cases, que tout le monde connaît déjà, mais dans les deux ou trois points où le processus doit refuser de continuer, et dans le fait de rendre ces points visibles au changement qui est sous pression pour les ignorer.

Ce tableau représente la gestion du changement en matière de sécurité des procédés : une modification d'une usine, d'un procédé, de produits chimiques, de limites d'exploitation, de systèmes de contrôle, de procédures ou d'une organisation sur un site où une erreur entraîne un rejet, un incendie ou une explosion. Il ne s’agit pas de gestion du changement de service informatique, et les deux ne sont pas interchangeables. Le processus de gestion du changement façonné par ITIL chez /fr/templates/processus-de-gestion-des-changements pose des questions sur les temps d'arrêt, les restaurations et les risques liés au service ; effectuez une modification d'usine via celui-ci et vous obtenez une approbation du CAB, une fenêtre de modification et aucun examen des dangers. Le processus général de contrôle des modifications chez /fr/templates/processus-de-controle-des-changements est la version du système qualité, régissant les documents contrôlés et les processus validés. Une modification apportée à un produit, un dessin ou une nomenclature lancé est une modification technique et se trouve chez /fr/templates/organigramme-du-processus-de-demande-de-modification-technique-ecr-a-ecn, tandis qu'une modification de la portée, du coût ou des dates d'un projet appartient à /fr/templates/organigramme-du-processus-de-demande-de-changement-de-projet-portee-cout-calendrier. Les réparations qui rétablissent véritablement les spécifications d'origine sont des opérations de maintenance et s'effectuent via /fr/templates/organigramme-du-processus-de-maintenance-des-equipements, le « Remplacement en nature ? » La décision ici est exactement la frontière entre les deux. Et si le changement est effectué parce que quelque chose s'est déjà mal passé, l'enquête qui détermine ce qu'il faut changer se déroule chez /fr/templates/organigramme-du-processus-d-enquete-sur-les-incidents-de-securite-de-la-scene-aux-controles ; ce processus permet d'installer le correctif convenu en toute sécurité.

Quatre décisions en valent la peine, et la plupart des procédures écrites laissent au moins deux d'entre elles implicites. « Remplacement en nature ? » est placé en premier, avant que quoi que ce soit ne soit dépensé, car il décide si le processus se déroule ou non, et c'est la question à laquelle on répond le plus souvent dans un couloir. « Permanent, temporaire ou d'urgence ? » vient en deuxième position, car la classification détermine la durée du processus à suivre : un changement d'urgence fait l'objet d'un examen accéléré des risques et d'une autorisation d'équipe assortie d'une limite de temps, mais il rejoint l'itinéraire principal à "Mettre à jour les procédures, les dessins et les P&ID", il atteint toujours "Former le personnel concerné", et il fait toujours face à la même porte avant le démarrage. « L'examen de sécurité avant démarrage a été réussi ? » est dessiné comme une boucle plutôt que comme une signature, de sorte que les actions en suspens soient clôturées et que l'examen soit repris ; rien ne part d'une promesse. Le quatrième est celui que la plupart des procédures omettent entièrement. "Toujours nécessaire à la **date d'expiration ?**" donne à un changement temporaire deux avenirs possibles : revenir dans le processus en tant que changement permanent, ou supprimé avec la restauration de l'état d'origine. Il n’y a volontairement aucune branche pour l’étendre tranquillement.

Ce que couvre cet organigramme

Dans ce modèle

  • Six couloirs (initiateur, coordinateur du MOC, autorité technique, équipe d'examen des dangers, responsable de l'autorisation et opérations) répartis en six phases : demande, sélection, examen technique, autorisation, préparation et PSSR, et mise en œuvre et clôture.
  • « Remplacement en nature ? » comme première porte, prise après « Enregistrer le changement dans le registre MOC » afin que la détermination soit inscrite dans le dossier dans les deux cas : un remplacement identique part à « Traité comme travail de maintenance », et tout le reste se poursuit comme un changement.
  • Un triptyque « Permanent, temporaire ou d'urgence ? » classification, où les modifications temporaires reprennent « Fixer la date d'expiration et le plan de retrait » et les modifications d'urgence empruntent un court chemin via « Effectuer un examen accéléré des dangers » et « Autoriser le quart de travail et fixer un délai » avant de rejoindre l'itinéraire principal.
  • Examen des dangers adapté au risque à « Quel niveau d'examen des dangers ? » (une liste de contrôle des risques liés aux changements, un examen de simulation ou un HAZOP complet) suivi de « Évaluer l'impact sur les systèmes et les limites de sécurité » et d'un ensemble d'actions enregistrées.
  • Autorisation avec trois réponses possibles à "**Autorisé** au niveau requis ?" : autorisé, refusé vers un terminateur fermé "Modification refusée et clôturée", ou renvoyé vers "Documenter les bases techniques" pour plus de travail.
  • Les deux portes que le graphique ne vous permettra pas de sauter : "**Examen de sécurité avant démarrage** réussi ?", qui passe par "Clôturer les actions PSSR" jusqu'à ce qu'il soit réussi, et "Toujours nécessaire à la **date d'expiration ?**", dont les seules réponses sont la conversion en une modification permanente ou la suppression et la restauration.

Quand utiliser ce modèle

  • Vous rédigez ou réécrivez une procédure MOC pour un site COMAH, Seveso ou OSHA PSM et souhaitez le test de dépistage, les niveaux d'examen et la matrice d'autorisation en une seule image.
  • Votre registre regorge de modifications temporaires sans date d'expiration, et vous avez besoin que la décision de suppression ou de conversion soit intégrée au processus plutôt que de la laisser à un nettoyage annuel.
  • Les changements d'urgence sont effectués pendant le quart de travail et rédigés par la suite, et vous souhaitez que l'itinéraire accéléré soit tracé de manière à ce qu'il s'exécute à l'intérieur du processus plutôt que de le contourner.
  • Vos examens de sécurité avant le démarrage sont signés avec des actions toujours ouvertes, et vous avez besoin que cette porte soit affichée comme une boucle qui renvoie la modification plutôt que comme une case qui est cochée.
  • Vous formez des ingénieurs, des chefs d'équipe et des opérateurs sur ce qui compte réellement comme un changement, et souhaitez que le test de remplacement en nature soit enseigné à partir du même diagramme que le reste du processus.

Comment cela fonctionne

  1. Renommez les voies de votre site

    Remplacez l'initiateur, le coordinateur MOC, l'autorité technique, l'équipe d'examen des risques, le gestionnaire autorisant et les opérations par les rôles réels de votre site. La plupart des sites répartissent l'autorité technique par discipline (procédés, mécanique, électricité, contrôle et instrumentation), il faut donc décider s'il s'agit d'une voie ou de plusieurs. Gardez le coordonnateur séparé de l'autorité technique : l'un dirige le processus et suit le registre, l'autre est propriétaire du jugement technique. Si les sous-traitants sont à l'origine des changements, dites-le, car une voie appelée Originateur qui signifie discrètement uniquement les employés est la manière dont les modifications des sous-traitants échappent au processus.

  2. Notez le test de remplacement en nature

    « Remplacement en nature ? » est la seule boîte qui peut supprimer complètement un changement du processus, elle nécessite donc des critères écrits plutôt que du jugement. Définissez la nature comme étant identique en termes de spécifications, de matériaux, de caractéristiques, d'intention de conception du fabricant et de configuration installée, puis nommez qui est compétent pour appliquer ce test : trouver une pièce équivalente sur le système du magasin n'est pas une détermination technique. C'est dans l'obsolescence que la plupart des sites le perdent : une fois que l'article d'origine n'est plus fabriqué, le modèle actuel le plus proche du fournisseur est un changement, et le formulaire devrait l'indiquer plutôt que de le laisser à la personne la plus pressée par le temps.

  3. Définir la règle d'acheminement de l'examen des risques

    Tournez « Quel niveau d'examen des dangers ? » dans une table plutôt que dans une conversation. Un faible risque pourrait être une liste de contrôle de changement documentée complétée par deux personnes compétentes. Le risque moyen est une simulation ou une simulation structurée avec une liste de contrôle. Un risque élevé (tout ce qui touche à un produit chimique, un verrouillage, un système de décharge, une philosophie de contrôle ou une limite de fonctionnement sûre) est soumis à un HAZOP facilité avec l'étude originale ouverte devant l'équipe. Nommez qui décide du niveau et exigez que la raison soit enregistrée à côté de la décision.

  4. Publier la matrice d'autorisation

    L'autorisation doit être fonction du risque et non du coût. Notez qui peut autoriser un changement permanent à faible risque, qui doit autoriser tout ce qui affecte une fonction instrumentée de sécurité, un dossier de secours ou une enveloppe d'exploitation, et qui signe un changement qui modifie le rapport de sécurité COMAH ou le dossier de sécurité. Donnez « Plus de travail nécessaire » comme réponse : cela renvoie le changement à « Documenter la base technique » plutôt que d'être concédé comme une approbation conditionnelle dont personne ne possède ensuite les conditions.

  5. Faites du PSSR une analyse détaillée avec une liste d'actions fermée

    Un examen de sécurité avant démarrage qui peut être effectué à un bureau n’en est pas un. La liste de contrôle doit confirmer que la construction correspond à la conception, que les procédures d'exploitation, de maintenance et d'urgence sont en place et à jour, que les personnes qui dirigeront le changement ont été formées et que les actions d'examen des risques sont terminées plutôt qu'assignées. Décidez qui est autorisé à déclarer une passe, gardez cette personne en dehors de l'équipe qui a construit le changement et acheminez toute action en suspens via « Clôturer les actions PSSR ».

  6. Possédez chaque date d'expiration, puis parcourez le graphique et publiez-le

    Donnez à chaque changement temporaire un propriétaire nommé et une date que le registre soulève avant son arrivée, pas après. Convenez ensuite de la durée de vie maximale d'un changement temporaire et si un changement d'urgence réintègre le processus complet dans quelques jours ou semaines. Enfin, parcourez le tableau terminé avec un équipe d'exploitation, un superviseur de maintenance, l'autorité technique et quiconque autorise les modifications, corrigez-le selon ce qu'ils font réellement et publiez cette révision tout en conservant les précédentes, afin que toute personne l'ouvrant plus tard sache quelle version ils lisent.

Questions fréquentes

Quelles sont les étapes d’un processus de gestion du changement (MOC) ?

Proposer le changement et l'enregistrer dans le registre MOC ; examinez-le par rapport au test de remplacement en nature, afin que les remplacements identiques soient effectués en tant que travaux de maintenance ; classer ce qui reste comme permanent, temporaire ou d'urgence, et donner aux temporaires une date d'expiration et un plan de retrait ; documenter la base technique ; effectuer une analyse des dangers adaptée au risque, depuis une liste de contrôle de changement en passant par une étude de simulation jusqu'à un HAZOP complet ; évaluer l'impact sur les systèmes de sécurité, les limites d'exploitation et le dossier de sécurité, et enregistrer les actions ; autoriser au niveau que l'aléa exige ; mettre à jour les procédures, les dessins et les P&ID ; former toutes les personnes concernées, y compris la maintenance et les entrepreneurs ; réussir un examen de sécurité avant le démarrage ; mettre en œuvre et démarrer ; puis clôturez avec les enregistrements conservés ou, pour une modification limitée dans le temps, examinez-le à l'expiration et convertissez-le en modification permanente ou supprimez-le. Selon la norme de gestion de la sécurité des processus de l'OSHA, la procédure écrite doit couvrir la base technique, l'impact sur la sécurité et la santé, les changements de procédure, la période de changement et les exigences d'autorisation : ce tableau est cette liste transformée en un itinéraire avec des portes.

Qu’est-ce qui constitue un remplacement en nature ?

Un remplacement en nature est un élément identique à celui qu'il remplace en termes de spécifications, de matériaux, de caractéristiques et d'intention de conception : la même pièce, selon le même dessin, installée de la même manière. Tout le reste est un changement et entre dans le processus MOC, aussi petit ou bon marché soit-il. La distinction est importante car il s’agit de la seule sortie légitime du processus, et c’est là que la plupart des systèmes MOC fuient. Exemples courants qui ne sont pas en nature, quel que soit le nom du magasinier : une pompe avec un diamètre de roue ou une disposition de joint différent, un joint dans un matériau de remplacement, une vanne avec un élément interne différent ou une position de défaillance différente, une soupape de décharge réinitialisée à une nouvelle pression, un instrument avec une plage ou un mode de défaillance différent et un changement de version du micrologiciel ou du logiciel dans un contrôleur. Deux règles pratiques sont utiles : exiger que la détermination soit enregistrée avec le nom de la personne compétente qui l'a prise, et auditer les décisions en nature plutôt que seulement les changements, car celles qui ne sont jamais entrées dans le processus sont celles que personne ne regarde.

Qu’est-ce qu’un examen de sécurité avant démarrage et quand est-il nécessaire ?

Un examen de sécurité avant démarrage, ou PSSR, est le dernier contrôle avant la mise en service d'une installation nouvelle ou modifiée. Il confirme quatre choses : que la construction et l'équipement correspondent aux spécifications de conception, que les procédures d'exploitation, de maintenance et d'urgence sont en place et adéquates, que l'examen des dangers a été réalisé et ses recommandations résolues ou mises en œuvre, et que toutes les personnes qui exploiteront ou entretiendront le changement ont été formées. Conformément à la norme de gestion de la sécurité des procédés de l'OSHA, un PSSR est requis pour les nouvelles installations et pour les installations modifiées où la modification était suffisamment importante pour nécessiter une modification des informations sur la sécurité des procédés. La raison pour laquelle il s'agit d'une décision avec une boucle plutôt qu'une boîte de signature est qu'il s'agit du portail soumis à la plus grande pression commerciale : le changement est construit, la panne est terminée et la centrale doit être récupérée. Dans ce graphique, un examen des actions en suspens revient à « Clôturer les actions PSSR » et est repris, de sorte que la seule façon de continuer est de le faire.

Combien de temps un changement temporaire peut-il rester en place ?

Seulement pour autant que la date de péremption ait été convenue au moment de l'autorisation, c'est pourquoi la date est fixée lors de la classification plutôt que laissée à être décidée ultérieurement. De nombreux sites plafonnent les modifications temporaires lors du prochain arrêt planifié ou à une période fixe telle que six mois, et exigent que tout ce qui dépasse ce plafond soit réautorisé en tant que changement permanent tout au long du processus. Le mode de défaillance est bien connu et cohérent : une modification temporaire est installée sous pression, la pression passe, personne n'est propriétaire du retrait, les dessins montrent toujours la disposition originale, et des années plus tard, quelqu'un planifie une isolation à partir d'un dessin qui ne décrit plus l'installation. Deux choses l’empêchent. Chaque changement temporaire a un propriétaire nommé plutôt qu'un service, et le registre déclenche l'examen avant la date d'expiration plutôt que de signaler la violation par la suite. Dans ce tableau « Toujours nécessaire à la date d'expiration ? » a exactement deux branches : le convertir en un changement permanent, ou le supprimer et restaurer son état d'origine. L’extension silencieuse ne fait pas partie des options.

En quoi la gestion du changement est-elle différente du processus de gestion du changement informatique ?

Ils partagent une parole et presque rien d’autre, et traiter l’un comme un substitut à l’autre est un véritable danger. La gestion des changements informatiques, au sens ITIL couvert par l'organigramme du processus de gestion des changements de /fr/templates/processus-de-gestion-des-changements, régit les modifications apportées à un service en direct. Il demande si le changement entraînera une panne, s'il peut être annulé, quand la fenêtre de changement arrive et si le CAB l'a approuvé. La gestion du changement au sens de la sécurité des procédés régit les modifications apportées à l'usine, aux produits chimiques, aux limites d'exploitation, aux systèmes de contrôle, aux procédures et au personnel sur un site qui peuvent nuire aux personnes. Il demande si le changement modifie un danger, si un cas de secours ou un verrouillage est toujours valable, si le dossier de sécurité est toujours valable et si les opérateurs ont été formés avant le démarrage. Un CAB n’a aucune compétence pour répondre à aucune de ces questions. Les deux processus se chevauchent en un seul endroit qui mérite d'être mentionné : une modification d'un système de contrôle ou d'un système instrumenté de sécurité est souvent soulevée dans une file d'attente de modifications informatiques ou d'automatisation et doit également passer par MOC. Lorsque cela se produit, faites en sorte que le MOC soit l'autorité et que le service informatique enregistre l'artefact de planification, et non l'inverse.

Où ce processus s'inscrit

Dans la plupart des opérations, ce processus suit Organigramme du processus d'enquête sur les incidents de sécurité (de la scène….

Précède

Fait partie de

Fonctionnalités QueryChart pour ce processus

Utiliser ce modèle

Browse all Modèles de processus opérationnels