Huit perceptions erronées courantes de la gestion du changement

Chaque fois que je mentionne la gestion du changement au personnel de l'usine, j'obtiens généralement l'une des nombreuses réponses prévisibles. Les plus avertis citeront le règlement OSHA 1910.119(a)(2) et me diront qu'il ne s'agit pas d'un « processus couvert », donc il ne s'applique pas à eux - généralement avec un grand soupir de soulagement. Une autre réponse fréquente est :« Nous avons une procédure de gestion des dessins, mais nous sommes tellement en retard qu'il faudrait des années et des ressources que nous n'avons pas à rattraper. » D'autres encore me diront qu'ils ont une procédure parfaitement fine pour que leurs gestionnaires approuvent les petits projets et les modifications. Et, quelques-uns penseront d'un air penaud aux centimes et aux centimes qui remplissent le cendrier de leur voiture.

Alors, qu'est-ce que la gestion du changement (MOC) ? Pour en revenir à la source, l'OSHA 1910.119(l)(1) définit les exigences relatives au MOC comme suit :« L'employeur doit établir et mettre en œuvre des procédures écrites pour gérer les changements (à l'exception des « remplacements en nature ») pour traiter les produits chimiques, la technologie, l'équipement et procédures; et, les modifications apportées aux installations qui affectent un processus couvert. »

Cette brève description couvre une grande partie du territoire, mais comme elle a été promulguée uniquement pour améliorer la sécurité des processus, elle limite l'applicabilité juridique aux « procédés couverts ». Les lecteurs dont les installations répondent aux exigences OSHA d'un « processus couvert » sont bien conscients des exigences détaillées du MOC. Ils doivent l'être, sinon ils ne fonctionneraient pas encore. Et j'espère que vous savez tous que bon nombre des pires accidents industriels de l'histoire récente ont pour cause première l'échec du processus MOC. Certaines sources indiquent que jusqu'à 80 pour cent des accidents majeurs graves dans l'industrie sont liés à des changements incontrôlés. Ainsi, on peut considérer le MOC comme une sorte d'assurance-vie qui rapporte en prévenant les accidents.

Mais cet article ne se concentre pas sur les subtilités du MOC pour les processus couverts. Et, il n'est pas uniquement orienté vers la sécurité. Pourquoi alors discutons-nous du MOC s'il n'est pas « requis » pour votre industrie ? En bref, c'est parce que chaque entreprise, indépendamment des exigences légales, doit contrôler les pertes potentielles. Et MOC, correctement appliqué, est un excellent processus de prévention des pertes rentable pour presque toutes les entreprises. C'est le processus complémentaire parfait à vos processus d'élimination des pertes. Et nous voulons tous être sûrs et respectueux de l'environnement, n'est-ce pas ?

Veuillez noter que le MOC ne traite que les modifications apportées aux éléments existants. La conception de nouveaux procédés ou installations est un tout autre problème. Et, nous devons supposer aux fins de la discussion MOC que le niveau de performance du système existant, s'il n'est pas adéquat, a du moins des vertus et des vices familiers et bien connus.

Alors, qu'est-ce que le MOC en termes non réglementaires, et à qui s'applique-t-il vraiment ? Travaillons avec cette définition simple :le MOC est un processus visant à prévenir ou à atténuer les pertes commerciales - y compris la dégradation de la sécurité, de la santé ou de l'environnement - à la suite de modifications apportées à la façon dont vous construisez, exploitez, gérez ou réparez votre installation ou vos processus. Mis à part les exigences réglementaires, aucune entreprise ayant l'intention de rester compétitive ne peut se permettre de ne pas mettre en place un processus MOC approprié. En bref, le MOC est logique pour la sécurité et il est logique sur le plan financier. Un processus MOC a-t-il un sens pour votre entreprise ?

Qu'est-ce qu'un « changement » ?
« La partie la plus difficile de la gestion du changement est de reconnaître le changement. » Le point de départ le plus important du programme est de définir clairement pour l'organisation ce qui constitue un « changement » que vous souhaitez gérer. Ou plus simplement, quel changement relève du processus MOC et quels types de changements ne relèvent pas du processus ? Un manque de définition claire paralyse efficacement l'efficacité d'un programme MOC, invitant à la fois une paralysie inutile de l'analyse et créant des échappatoires pour ceux qui souhaitent contourner le processus.

Il existe de nombreuses définitions du changement provenant de nombreuses sources différentes. Il est de la responsabilité de la direction du site de définir le changement en des termes compatibles avec les intérêts commerciaux et tout précédent réglementaire. Quels risques souhaitez-vous contrôler et quels types de changements, s'ils ne sont pas contrôlés, augmentent ces risques ? Ce n'est qu'alors que les activités qui pourraient raisonnablement être définies comme des « changements » peuvent être clairement identifiées, et une fois identifiées, elles doivent être transmises dans le langage le plus simple et direct possible.
Bien qu'un peu désordonné, l'utilisation de listes ou de tableaux d'exemples est souvent nécessaire pour faire passer le message. Gardez à l'esprit qu'il n'est pas nécessaire qu'un « changement » se produise dans un élément matériel pour être admissible. Les logiciels, les procédures et les paramètres de processus sont tous des exemples de modifications non matérielles qui doivent souvent être rigoureusement contrôlées.

Lorsqu'il s'agit de matériel, le document source OSHA 1910 fait indirectement référence à un changement comme n'étant pas un « remplacement en nature » ​​(RIK) et définit davantage RIK comme « un remplacement qui satisfait les spécifications de conception ». RIK fait généralement référence à un équipement ou à des composants dont la forme, l'ajustement et la fonction sont identiques (appelés F3). Mais il y a plus à changer que cette approche matérielle très étroite. La définition du changement de l'OSHA fait également référence à la technologie, aux procédures et aux produits chimiques (interprétés plus largement comme des matières premières). De toute évidence, la définition du « changement » ne se limite pas au matériel informatique. J'ai trouvé que la meilleure définition formelle utilisée pour le « changement » dans le processus MOC se trouve dans une clarification publiée dans OSHA 3313 : « Le changement est une modification ou un ajustement de tout composant, variable ou propriété au sein d'un système existant (sauf limites ou responsabilités clairement définies). »

Étant donné que chaque entreprise a différents domaines d'exposition aux risques et différentes tolérances aux conséquences indésirables, il appartient à chaque entreprise d'évaluer les risques et de définir sa tolérance aux changements incontrôlés. Voici quelques exemples (mais en aucun cas exhaustifs) des types de changements qu'une entreprise peut souhaiter gérer :

• Ajout d'un nouvel équipement de traitement ou d'un système commercial critique (y compris un logiciel)
• Remplacement « pas en nature » ​​d'équipements ou de pièces de traitement
• Modifications ou ajouts mineurs à l'équipement de traitement
• Modifications ou ajouts mineurs au système commercial critique (procédural ou logiciel)
• Modifications ou ajouts mineurs à l'infrastructure/à l'équipement hors processus
• Modifications apportées au contrôle de processus et/ou à l'instrumentation (y compris les stratégies de contrôle)
• Modifications des spécifications ou sourcing de MRO technique
• Modifications des limites de fonctionnement des paramètres de processus critiques (en dehors des plages spécifiées dans les procédures opérationnelles standard [SOP])
• Modifications des systèmes de sécurité (verrouillages, arrêts, suppression des incendies ou des explosions, etc.)
• Révisions des procédures opérationnelles standard (y compris les procédures d'urgence)
• Modifications de la structure organisationnelle au niveau du site
• Modifications des procédures de maintenance
• Modifications des spécifications ou de l'approvisionnement des matières premières/composants
• Modifications ou nouvelles connexions aux systèmes de services publics (air, électricité, gaz, eau, vapeur, etc.).
• Modifications ou nouvelles connexions aux réseaux de données critiques
• Modifications des procédures d'assurance qualité ou de l'équipement de test critique

Quelques heures de brainstorming de qualité par une équipe multidisciplinaire au début de la conception du processus pour développer les définitions et les exemples qui conviennent à votre entreprise rapporteront d'énormes dividendes.

Qu'en est-il des changements « temporaires » ?
N'oubliez pas ce concept important à appliquer lors de la mise en œuvre du MOC :de même qu'il n'y a rien au monde d'aussi permanent qu'une taxe temporaire, il n'y a pas de changement plus permanent qu'un « changement temporaire » qui a échappé au processus MOC. L'expérience montre qu'il n'y a vraiment que des changements permanents qui sont censés être temporaires jusqu'à ce qu'ils aient été restaurés dans leurs conditions d'origine. De tous les changements incontrôlés qui se produisent, les changements « temporaires » sont la cause la plus pernicieuse et la plus fréquente d'accidents et d'incidents. Ainsi, les modifications « temporaires » d'un système contrôlé ne devraient jamais être exemptées du processus MOC.

Alors, que dois-je faire pour gérer les modifications temporaires qui doivent être apportées pour effectuer des tâches de routine, telles qu'un dérivation de verrouillage pour effectuer une maintenance périodique ? Si c'est vraiment une routine, alors ce que vous avez est un état permanent d'écart périodique par rapport à la SOP. Et la bonne façon de gérer cela est de traiter la situation comme un changement permanent, en l'intégrant dans des procédures approuvées avec des garanties appropriées. Si quelque chose est conçu comme un changement temporaire non routinier, traitez-le comme un changement. L'OSHA 3133 dans une clarification dit :« La procédure MOC doit garantir que l'équipement et les procédures sont remis dans leurs conditions d'origine à la fin d'un changement temporaire. L'histoire et la prudence suggèrent que les changements « temporaires » doivent être gérés comme « permanents » avec une attention particulière à la procédure MOC, car ils présentent le risque le plus élevé pour votre entreprise.

Huit idées fausses courantes sur le MOC
1) « Mais je ne fais pas une vraie modification. Je l'améliore juste un peu."
Si vous ne laissez pas la pièce/l'équipement/le système commercial exactement tel qu'il était avant le début des travaux (en l'absence, bien entendu, de tout dommage ayant fait l'objet de la réparation), alors vous avez effectué une modification . Le fait que le changement entre ou non dans le cadre de votre processus MOC est déterminé par les critères définis dans vos procédures. L'approche par défaut à adopter est de supposer que tout changement de configuration, de forme, d'ajustement, de fonction, de matériaux ou de procédure est couvert par le MOC jusqu'à ce qu'un examen des critères de la procédure prouve le contraire.

Après les « modifications temporaires incontrôlées », les améliorations mineures bien intentionnées se classent comme la deuxième cause d'incidents relevant de la catégorie des échecs de MOC. Sans une évaluation approfondie de l'ensemble du contexte et de l'environnement d'exploitation, qui peut dire que « mieux » d'une manière n'est pas vraiment beaucoup, bien pire d'une autre ? Le même médicament donné à un patient peut être un remède puissant; à un autre, cela peut être un poison mortel. Il en va de même pour les « améliorations » mineures bien intentionnées mais incontrôlées, notamment les substitutions de matériaux qui sont particulièrement risquées. Apprenez à votre personnel à tous les niveaux à être conscient et à éviter cet écueil courant, puis à l'appliquer strictement. Personne n'aime discipliner les gens pour avoir enfreint les règles, surtout quand ils le font dans un esprit d'amélioration. Mais, c'est infiniment pire de devoir dire à une famille que quelqu'un ne rentrera pas à la maison ce soir.

2) « Je suis tellement en retard que je ne peux pas commencer à faire du MOC. Je ne rattraperai jamais tous ces dessins non révisés."
Le contrôle des documents est un processus qui complète un processus MOC bien conçu, et c'est souvent la première chose à laquelle les gens pensent lorsque vous mentionnez MOC. La nécessité de mettre à jour les documents est certainement un résultat fréquent d'un MOC et nécessaire à l'intégrité à long terme de vos processus et installations, mais ce n'est pas un MOC. C'est simplement un résultat fréquent.

Souvent lors de la mise en œuvre de MOC avec un processus de contrôle de documents, vous héritez d'un sacré bordel de ceux qui vous ont précédé :pas de dessins, dessins inexacts, documents périmés.. . vous l'appelez. Si la situation est grave, vous pouvez être contraint de hiérarchiser vos actions correctives, le cas échéant, en fonction de la criticité des systèmes. Certains n'auront peut-être pas besoin de l'être et ne seront jamais corrigés. Il est certain qu'une méthode pour corriger les informations vitales lorsqu'elles sont découvertes peut et doit être facilement intégrée à vos procédures de contrôle du travail. Mais n'ajoutez pas à la tâche en continuant de mauvaises habitudes.

Vous ne pouvez pas changer ce qui s'est passé dans le passé. Si l'analyse de rentabilisation existe pour corriger ou atténuer les erreurs du passé, faites-le. Le MOC concerne la prévention des pertes futures. Donc, la seule chose que toute organisation peut faire est de commencer à mettre en œuvre MOC dès maintenant. Aujourd'hui est le jour pour arrêter de créer plus de problèmes pour demain. Un extrait succinct de la sagesse populaire dit :« Si vous devez combler un très gros trou, la première chose à faire est d'arrêter de le creuser plus profondément. La même chose s'applique à un écart créé par une mauvaise MOC. Arrêtez de l'agrandir.

3) « Je n'ai pas le temps d'attendre l'évaluation du MOC. C'est une urgence !"
Pendant une situation d'urgence, c'est précisément lorsque l'autodiscipline imposée par un processus MOC bien établi est le plus nécessaire. Lorsqu'un avion de ligne a un problème en vol, les pilotes ne font pas la première chose qui leur vient à l'esprit. Au contraire, ils sortent la liste de contrôle et ils réfléchissent, puis ils agissent. Quand il y a une « urgence », vous devriez le faire aussi. Cette « modification mineure » ​​pour permettre une substitution va-t-elle vraiment économiser autant de temps d'arrêt par rapport à l'obtention de la bonne pièce ? Les changements mineurs prennent souvent beaucoup plus de temps que prévu.

Soyez réaliste dans votre évaluation du temps, de la somme d'argent et de l'augmentation des risques que prendra réellement ce « contournement rapide ». Il est bon d'être optimiste en cas d'urgence. Il vaut mieux se préparer au pire. Comme le dit le proverbe :« Si vous êtes dans un bateau qui fuit loin au large, il vaut mieux prier vers le ciel, mais ramer vers le rivage. » Le risque pour votre entreprise associé à un contournement « temporaire » vaut-il le gain de temps ? Pouvez-vous vraiment contrôler le risque à un niveau acceptable par des « procédures d'exploitation spéciales » ?

Les rapports d'accidents montrent que des décisions hâtives, prises sous pression, sans évaluation équilibrée, ont été à l'origine de nombreux problèmes graves . Le temps de penser de manière disciplinée n'est pas du temps perdu. Et si votre processus MOC est efficace, il n'entravera pas indûment les progrès dans les rares cas où il s'agit d'une véritable urgence. Tout comme il existe une procédure pour autoriser et émettre un ordre de travail d'urgence en cas de besoin, une bonne procédure MOC disposera d'un mécanisme pour répondre aux urgences réelles. Mais ce mécanisme ne devrait pas être d'ignorer le MOC. Ne laissez pas l'opportunité au cours d'une « urgence » vous préparer à une deuxième urgence plus importante et plus grave. Ne désamorcez pas une bombe juste pour poser une mine terrestre.

Êtes-vous confronté à des pannes fréquentes qui nécessitent une solution de contournement, devez constamment effectuer des remplacements de pièces à minuit pour récupérer d'une panne inattendue, ou constante des modifications de processus pour s'adapter à des composants instables ou à des matières premières ? Ensuite, votre défi n'est pas d'ignorer le MOC ou de concevoir un processus MOC qui supporte l'anarchie. Vous devez plutôt concentrer vos efforts sur l'élimination de ces situations en mettant en œuvre un processus efficace d'analyse des causes des défaillances (RCFA) et des programmes de maintenance préventive/maintenance prédictive pour éliminer les défaillances chroniques. Ensuite, concentrez-vous sur la correction des lacunes de vos processus MRO pour vous assurer de toujours disposer des bonnes pièces. Et, enfin, vous devriez stabiliser votre processus avec des procédures de travail standard et des programmes de qualification des fournisseurs de matériaux.

4) « L'acheminement de ce formulaire pour approbation prend tellement de temps que nous ne pouvons jamais rien faire. »
Un processus MOC efficace nécessite un niveau approprié d'approbation et de communication. Des procédures d'approbation MOC mal conçues confondent le besoin d'être informé d'un changement après qu'il se produise avec le besoin d'approuver un changement avant qu'il ne se produise. Les niveaux d'approbation requis doivent être à la fois adaptés au changement et au risque potentiel qui y est associé. Ils doivent également être suffisamment flexibles pour pouvoir être adaptés à la situation actuelle. Minimisez le nombre d'approbateurs et faites-en les bons. Votre processus MOC peut alors être rationalisé en toute sécurité.

5) « Mais mon responsable de secteur doit déjà approuver les fonds pour les changements. »
Ne confondez pas l'autorité de prendre une décision avec la possession des connaissances nécessaires pour prendre cette décision. Tous les changements, et souvent les plus critiques, ne passent même pas par l'approbation du financement. Souvent, les personnes les plus compétentes pour évaluer le risque d'un changement ou la validité technique d'un changement ne sont pas le responsable de zone mais les opérateurs, mécaniciens, superviseurs ou ingénieurs qui le connaissent le mieux.

Même si le manager est très compétent, il est rare qu'une seule personne soit compétente sur tous les aspects ou conséquences d'un changement donné. Dans un processus MOC efficace, il est de la responsabilité du gestionnaire de s'assurer que les ressources désignées appropriées sont impliquées dans une évaluation bien équilibrée du changement proposé. L'autorité d'approbation est secondaire à la compétence à évaluer et une équipe bien équilibrée donnera de bons résultats de manière plus constante que de dépendre d'une seule personne intelligente.

6) « Nous sommes un entrepôt / une fabrication légère / des données centre / centre de réparation. … Nous n'avons rien qui puisse être dangereux. »
N'oubliez pas que le MOC est un processus permettant de prévenir ou d'atténuer toutes les pertes commerciales potentielles auto-infligées associées à un changement. Il y a d'autres pertes en plus de la sécurité des processus. C'est une perte si un changement de processus incontrôlé vous fait perdre un client précieux en raison d'un produit contaminé ou défectueux. C'est une perte si votre centre de données est en panne et que le dépannage prend plusieurs heures au lieu de quelques minutes, car les schémas électriques n'ont pas suivi les changements. C'est une perte si l'empileur automatique est en panne et que vous ne pouvez pas expédier le produit car une substitution de pièce à minuit nécessitant une "petite modification" a fait que la seule pièce de rechange que vous avez en stock n'est plus adaptée. C'est une perte si une modification non documentée du logiciel de contrôle provoque l'échec de votre machine de test automatique lorsque le dernier correctif de sécurité est installé. Tous ces exemples sont réels, et la liste est interminable. Même si le potentiel de changements pour créer des situations dangereuses dans votre environnement est faible, nous avons tous quelque chose à perdre lorsque nos installations ou processus échouent dans leurs missions principales.

7) « Mais MOC a gagné n'attrapez pas tous les problèmes possibles, alors pourquoi le faire ?"
Vous avez tout à fait raison. Malgré tous vos efforts, certains problèmes passeront inaperçus. Mais combien passeront si vous ne faites pas de MOC ? La gestion des risques consiste à changer les chances pour être plus en votre faveur. Cet argument ne tient pas debout - pas plus que l'argument que certaines personnes utilisent contre les coussins gonflables :"Ils pourraient se déployer et provoquer un accident, alors je les désactive." Les statistiques ne soutiennent tout simplement pas cette ligne de pensée, pas plus qu'elles ne soutiennent l'absence de MOC.

Alors, que se passe-t-il si vous manquez une conséquence imprévue ? Un avantage supplémentaire précieux de la MOC dans les systèmes complexes est l'exécution d'une RCFA. S'il y a des conséquences négatives d'un changement et que la cause n'est pas immédiatement discernable, le RCFA va beaucoup plus vite si vous avez une liste de tous les changements délibérés qui ont été apportés. Et ce temps peut être de l'argent réel. Dans un cas, la recherche d'enregistrements MOC a réduit de plusieurs semaines le temps nécessaire pour trouver la cause première d'une série de défaillances d'usines de traitement. À 250 000 $ par jour en pertes d'arrêt évitées, l'effort MOC a eu un assez bon retour sur investissement même s'il n'a pas empêché le problème.

8) « Ceci est juste un changement de logiciel/procédure. Ce n'est pas comme si nous changions une pipe ou quelque chose du genre. Nous n'avons pas besoin d'approuver ou de documenter. »
Des incidents extrêmement graves et des pertes sévères se sont produits dans un certain nombre d'industries en raison de modifications de logiciels ou de procédures qui n'étaient pas soumises au MOC. De plus, ce n'est pas parce qu'un document ou un code a été modifié et reflète le changement que le changement est documenté. Je sais que les commentaires dans le code et les indicateurs de révision dans le document permettent au chercheur de rechercher des modifications. Mais lorsque des problèmes inattendus surviennent parce que le changement de logiciel ou de procédure n'a pas été correctement examiné, alors à quoi cela sert-il ?

Avez-vous eu une chaîne de production en panne pendant que vous cherchiez désespérément parmi des milliers de lignes de code à la recherche du changement qui a été fait par l'ingénieur de contrôle deux mois avant qu'il ne parte pour un autre travail? Les programmeurs et les ingénieurs de contrôle en particulier ont tendance à « jouer » avec les logiciels sans tenir dûment compte du MOC. Cela s'applique non seulement à votre contrôle de processus, mais également à vos logiciels de systèmes d'entreprise critiques. Si le risque potentiel existe et le justifie, traitez le changement d'une ligne de code de la même manière que le recâblage d'un système d'arrêt de sécurité ; il devrait recevoir le même niveau d'examen et de contrôle.

Conclusion
En conclusion, un processus MOC bien conçu est un outil essentiel de prévention des pertes pour toute entreprise. Ce n'est pas seulement pour certaines industries dangereuses. Le processus s'applique à toute entreprise qui souhaite éviter les pertes futures résultant des changements d'aujourd'hui. MOC n'a pas besoin d'être accablant ou si difficile à utiliser qu'il inhibe le changement. Il ne peut pas compenser sans effort les omissions passées, seulement réduire votre risque futur. Le moment est donc venu de commencer à développer et à mettre en œuvre un processus MOC efficace et efficient.

Cet article est paru pour la première fois dans l'édition de juillet du bulletin d'information de Life Cycle Engineering, RxToday.

À propos de l'auteur :
Sam McNair est consultant senior chez Life Cycle Engineering (LCE). Ingénieur professionnel et professionnel certifié de la maintenance et de la fiabilité, Sam a plus de 32 ans d'expérience dans la fabrication discrète, les industries de procédés chimiques, l'exploitation minière, les procédés mécaniques, l'automatisation, l'aviation, la construction et les services publics. Sam est spécialisé dans l'ingénierie de la fiabilité en mettant l'accent sur l'intégration des fonctions de maintenance et de fabrication. Vous pouvez joindre Sam à [email protected]. Pour plus d'informations sur l'ingénierie du cycle de vie, visitez www.LCE.com.