Ocho percepciones erróneas comunes de la gestión del cambio

Siempre que menciono la gestión del cambio al personal de la planta, generalmente obtengo una de varias respuestas predecibles. Los conocedores citarán la regulación OSHA 1910.119 (a) (2) y me dirán que no son un "proceso cubierto", por lo que no se aplica a ellos, generalmente con un gran suspiro de alivio. Otra respuesta frecuente es:"Tenemos un procedimiento de gestión de dibujos, pero estamos tan atrasados ​​que nos llevaría años y recursos no tendremos que ponernos al día". Otros todavía me dirán que tienen un procedimiento perfectamente bueno para que sus gerentes aprueben pequeños proyectos y modificaciones. Y algunos pensarán tímidamente en los centavos y cinco centavos que llenan el cenicero de su automóvil.

Entonces, ¿qué es la gestión del cambio (MOC)? Volviendo a la fuente, OSHA 1910.119 (l) (1) establece los requisitos para MOC como:“El patrono deberá establecer e implementar procedimientos escritos para manejar cambios (excepto“ reemplazos en especie ”) para procesar químicos, tecnología, equipo y procedimientos; y cambios en las instalaciones que afecten un proceso cubierto ”.

Esa breve descripción cubre mucho territorio, pero dado que fue promulgada únicamente para mejorar la seguridad de los procesos, limita la aplicabilidad legal a los “procesos cubiertos”. Los lectores cuyas instalaciones cumplen con los requisitos de OSHA de un “proceso cubierto” conocen bien los requisitos detallados de MOC. Tienen que estarlo o no seguirían funcionando. Y es de esperar que todos ustedes sepan que muchos de los peores accidentes industriales de la historia reciente tienen como raíz el fracaso del proceso MOC. Algunas fuentes indican que hasta el 80 por ciento de los accidentes graves graves en la industria están relacionados con cambios incontrolados. Por tanto, se puede pensar en MOC como una especie de seguro de vida que se amortiza al prevenir accidentes.

Pero este artículo no se centra en las complejidades de MOC para los procesos cubiertos. Y no está dirigido únicamente a la seguridad. Entonces, ¿por qué estamos discutiendo MOC si no es "requerido" para su industria? En resumen, se debe a que todas las empresas, independientemente de los requisitos legales, necesitan controlar las pérdidas potenciales. Y MOC, aplicado de manera apropiada, es un proceso de prevención de pérdidas excelente y rentable para casi cualquier negocio. Es el proceso complementario perfecto a sus procesos de eliminación de pérdidas. Y todos queremos ser seguros y también respetuosos con el medio ambiente, ¿verdad?

Tenga en cuenta que el MOC solo se ocupa de los cambios en las cosas que existen actualmente. El diseño de nuevos procesos o instalaciones es otro tema completamente diferente. Y, para los propósitos de la discusión del MOC, tenemos que asumir que el nivel de desempeño del sistema existente, si no es adecuado, al menos tiene virtudes y vicios familiares y bien conocidos.

Entonces, ¿qué es MOC en términos no regulatorios y a quién se aplica realmente? Trabajemos con esta definición simple:MOC es un proceso para prevenir o mitigar las pérdidas comerciales, incluida la degradación de la seguridad, la salud o el medio ambiente, como resultado de los cambios realizados en la forma en que construye, opera, administra o repara sus instalaciones o sus procesos. Dejando a un lado los requisitos regulatorios, no hay empresa que pretenda seguir siendo competitiva que pueda permitirse el lujo de no tener implementado un proceso de MOC apropiado. En resumen, MOC tiene sentido para la seguridad y tiene sentido financiero. ¿Tiene sentido un proceso MOC para su negocio?

¿Qué es un "cambio"?
"La parte más difícil de la gestión del cambio es reconocer el cambio". El punto de partida más importante para el programa es definir claramente para la organización qué constituye un “cambio” que desea gestionar. O más simplemente, ¿qué cambio se incluye en el proceso de MOC y qué tipo de cambios no? La falta de una definición clara paraliza efectivamente la efectividad de un programa MOC, invitando a la parálisis del análisis innecesario y creando lagunas para aquellos que desean eludir el proceso.

Hay muchas definiciones de cambio de diferentes fuentes. Es responsabilidad del liderazgo del sitio definir el cambio en términos consistentes con los intereses comerciales y cualquier precedente regulatorio. ¿Qué riesgos desea controlar y qué tipo de cambios, si no se controlan, aumentan esos riesgos? Solo entonces se podrán identificar claramente aquellas actividades que podrían definirse razonablemente como "cambios" y, una vez identificadas, deberán expresarse en el lenguaje más simple y directo posible.
Aunque un poco desordenado, el uso de listas o tablas de ejemplos a menudo es necesario transmitir los puntos. Tenga en cuenta que un "cambio" no tiene que ocurrir en una pieza de hardware para calificar. El software, los procedimientos y los parámetros del proceso son ejemplos de cambios que no son de hardware y que a menudo deben controlarse rigurosamente.

Cuando se trata de hardware, el documento fuente de OSHA 1910 se refiere indirectamente a un cambio que no es un "Reemplazo en especie" (RIK) y define más a RIK como "un reemplazo que satisface las especificaciones de diseño". RIK generalmente se refiere a equipos o componentes que son idénticos en forma, ajuste y función (denominados F3). Pero hay más para cambiar que este enfoque muy estrecho basado en hardware. La definición de cambio de OSHA también se refiere a tecnología, procedimientos y químicos (interpretados de manera más amplia como materias primas). Obviamente, en la definición de “cambio” se incluye más que solo hardware. He encontrado que la mejor definición formal en uso para "cambio" en el proceso MOC se encuentra en una aclaración publicada en OSHA 3313:"El cambio es una alteración o ajuste a cualquier componente, variable o propiedad dentro de un sistema existente (excepto aquellos dentro de límites o responsabilidades claramente definidos) ”.

Dado que cada negocio tiene diferentes áreas de exposición al riesgo y diferente tolerancia a las consecuencias no deseadas, depende de cada negocio evaluar el riesgo y definir su tolerancia al cambio incontrolado. Algunos ejemplos (pero de ninguna manera todos incluidos) de los tipos de cambios que una empresa puede desear administrar son:

• Adición de nuevos equipos de proceso o sistemas comerciales críticos (incluido el software)
• Reemplazo "no en especie" de equipos o piezas de proceso
• Modificaciones o adiciones menores al equipo de proceso
• Modificaciones o adiciones menores al sistema comercial crítico (procedimiento o software)
• Modificaciones o adiciones menores a la infraestructura / equipos que no son de proceso
• Cambios en el control de procesos y / o instrumentación (incluye estrategias de control)
• Cambios en las especificaciones o el abastecimiento de MRO técnico
• Cambios en los límites operativos de los parámetros críticos del proceso (fuera de los rangos especificados en los procedimientos operativos estándar [POE])
• Alteraciones en los sistemas de seguridad (enclavamientos, paradas, extinción de incendios o explosiones, etc.)
• Revisiones de los procedimientos operativos estándar (incluidos los procedimientos de emergencia)
• Cambios en la estructura organizativa a nivel del sitio
• Cambios en los procedimientos de mantenimiento
• Cambios en las especificaciones o el abastecimiento de materias primas / componentes
• Alteraciones o nuevas conexiones a los sistemas de servicios públicos (aire, electricidad, gas, agua, vapor, etc.).
• Alteraciones o nuevas conexiones a redes de datos críticas
• Cambios en los procedimientos de control de calidad o en el equipo de prueba crítico

Unas pocas horas de intercambio de ideas y "qué pasaría si" de calidad por parte de un equipo multidisciplinario al principio del diseño del proceso para desarrollar las definiciones y los ejemplos adecuados para su negocio pagarán enormes dividendos.

¿Qué pasa con los cambios "temporales"?
Recuerde este concepto importante para aplicar al implementar MOC:así como no hay nada en el mundo tan permanente como un impuesto temporal, no hay un cambio más permanente que un “cambio temporal” que escapó del proceso MOC. La experiencia muestra que en realidad solo hay cambios permanentes que están destinados a ser temporales hasta que se hayan restaurado a sus condiciones originales. De todos los cambios incontrolados que ocurren, los cambios “temporales” son los más perniciosos y la causa más frecuente de accidentes e incidentes. Por lo tanto, los cambios "temporales" de un sistema controlado nunca deben estar exentos del proceso de MOC.

Entonces, ¿qué hago para lidiar con los cambios temporales que se deben realizar para realizar negocios de rutina, como un bypass de enclavamiento para realizar el mantenimiento periódico? Si es realmente una rutina, entonces lo que tiene es un estado permanente de desviación periódica del SOP. Y la forma correcta de lidiar con eso es tratar la situación como un cambio permanente, incorporándola a los procedimientos aprobados con las debidas salvaguardas. Si algo está pensado como un cambio temporal no rutinario, trátelo como un cambio. OSHA 3133 en una aclaración dice:"El procedimiento MOC debe garantizar que el equipo y los procedimientos vuelvan a sus condiciones originales al final de un cambio temporal". La historia y la prudencia sugieren que los cambios "temporales" deben gestionarse como "permanentes" con especial atención al procedimiento de MOC porque presentan el mayor riesgo para su negocio.

Ocho conceptos erróneos comunes sobre MOC
1) “Pero no estoy haciendo una modificación real. Solo lo estoy mejorando un poco ".
Si no deja la pieza / equipo / sistema comercial exactamente como estaba antes de comenzar el trabajo (sin, por supuesto, ningún daño que haya sido objeto de la reparación), entonces ha realizado un cambio . Si el cambio pertenece o no al alcance de su proceso de MOC, lo determinan los criterios establecidos en sus procedimientos. El enfoque predeterminado a tomar es asumir que cualquier cambio en la configuración, forma, ajuste, función, materiales o procedimiento está cubierto por MOC hasta que un examen de los criterios en el procedimiento demuestre lo contrario.

En segundo lugar después de los "cambios temporales" no controlados, las mejoras menores bien intencionadas se ubican como la siguiente causa más importante de incidentes que se incluyen en la categoría de fallas de MOC. Sin una evaluación exhaustiva del contexto y el entorno operativos totales, ¿quién puede decir que "mejor" en un sentido no es realmente mucho, mucho peor en otro? El mismo medicamento administrado a un paciente puede ser una cura poderosa; para otro, puede ser un veneno mortal. Lo mismo se aplica a las “mejoras” menores bien intencionadas pero incontroladas, especialmente las sustituciones de materiales que son particularmente riesgosas. Enseñe a su personal en todos los niveles a ser conscientes de este error común y a evitarlo, y luego aplíquelo estrictamente. A nadie le gusta disciplinar a las personas por romper las reglas, especialmente cuando lo hacen con espíritu de mejora. Pero es infinitamente peor tener que decirle a una familia que alguien no volverá a casa esta noche.

2) “Estoy tan atrasado que no puedo empezar a hacer MOC. Nunca me pondré al día con todos esos dibujos sin revisar ".
El control de documentos es un proceso que complementa un proceso de MOC bien diseñado y, a menudo, es lo primero en lo que la gente piensa cuando menciona MOC. La necesidad de actualizar documentos es sin duda un resultado frecuente de un MOC y es necesaria para la integridad a largo plazo de sus procesos e instalaciones, pero no es MOC. Es simplemente un resultado frecuente.

A menudo, al implementar MOC con un proceso de control de documentos, hereda un gran desorden de aquellos que lo precedieron:sin dibujos, dibujos inexactos, documentos desactualizados ... . Tu dilo. Si la situación es grave, es posible que se vea obligado a priorizar sus acciones correctivas, si alguna se basa en la criticidad de los sistemas. Es posible que algunos no necesiten ser corregidos y nunca se corregirán. Ciertamente, un método para corregir información vital cuando se descubre puede y debe incorporarse fácilmente a sus procedimientos de control de trabajo. Pero no aumente la tarea continuando con los malos hábitos.

No puede cambiar lo que sucedió en el pasado. Si el caso comercial existe para corregir o mitigar errores pasados, hágalo. MOC trata sobre la prevención de pérdidas futuras. Entonces, lo único que puede hacer cualquier organización es comenzar a implementar MOC ahora mismo. Hoy es el día para dejar de crear más problemas para mañana. Una pieza sucinta de sabiduría popular dice:"Si tienes que llenar un agujero realmente grande, lo primero que debes hacer es dejar de cavar más profundo". Lo mismo se aplica a una brecha creada por un pobre MOC. Deja de hacerlo más grande.

3) “No tengo tiempo para esperar la evaluación del MOC. ¡Esto es una emergencia! ”
Durante una emergencia es precisamente cuando la autodisciplina impuesta por un proceso de MOC bien establecido es más necesaria. Cuando un avión tiene un problema en vuelo, los pilotos no hacen lo primero que se les ocurre. Más bien, sacan la lista de verificación y piensan, luego actúan. Cuando hay una "emergencia", usted también debe hacerlo. ¿Esta "modificación menor" para permitir una sustitución realmente va a ahorrar tanto tiempo de inactividad en comparación con obtener la pieza correcta? Los cambios menores a menudo toman mucho más tiempo de lo esperado.

Sea realista en su evaluación de cuánto tiempo, cuánto dinero y cuánto aumento de riesgo realmente tomará esta “solución rápida”. Es bueno ser optimista en una emergencia. Es mejor estar preparado para lo peor. Como dice el refrán:"Si estás en un bote con goteras mar adentro, es mejor orar hacia el cielo, pero remar hacia la orilla". ¿Vale la pena el ahorro de tiempo por el riesgo para su negocio asociado con un desvío “temporal”? ¿Puede realmente controlar el riesgo a un nivel aceptable mediante "procedimientos operativos especiales"?

Los informes de accidentes muestran que las decisiones apresuradas, tomadas bajo presión, sin una evaluación equilibrada, han sido la raíz de muchos problemas graves . El tiempo para pensar de manera disciplinada no es una pérdida de tiempo. Y si su proceso de MOC es eficiente, no impedirá indebidamente el progreso en las raras ocasiones en que se trata de una verdadera emergencia. Así como existe un procedimiento para autorizar y emitir una orden de trabajo de emergencia cuando sea necesario, un buen procedimiento MOC tendrá un mecanismo para abordar emergencias reales. Pero ese mecanismo no debería ser ignorar el MOC. No permita que la conveniencia durante una "emergencia" lo prepare para una segunda emergencia mayor y más grave. No desactive una bomba solo para plantar una mina terrestre.

¿Está experimentando fallas frecuentes que requieren una solución alternativa para solucionar, teniendo que hacer constantemente sustituciones de piezas a medianoche para recuperarse de una falla inesperada o constante alteraciones del proceso para acomodar componentes inestables o materias primas? Entonces, su desafío no es ignorar el MOC o diseñar un proceso MOC que apoye la anarquía. Por el contrario, debe concentrar sus esfuerzos en eliminar estas situaciones mediante la implementación de un proceso eficaz de análisis de causa raíz de fallas (RCFA) y programas de mantenimiento preventivo / mantenimiento predictivo para eliminar las fallas crónicas. A continuación, concéntrese en corregir las deficiencias en sus procesos de MRO para asegurarse de tener siempre las piezas correctas. Y, finalmente, debe estabilizar su proceso con procedimientos de trabajo estándar y programas de calificación de proveedores de materiales.

4) “Enviar este formulario para su aprobación lleva tanto tiempo que nunca podremos hacer nada”.
Un proceso de MOC eficaz requiere un nivel apropiado de aprobación y comunicación. Los procedimientos de aprobación de MOC mal diseñados confunden la necesidad de estar informado de un cambio después de que suceda con la necesidad de aprobar un cambio antes de que suceda. Los niveles de aprobación requeridos deben ser apropiados para el cambio y el riesgo potencial asociado con él. También deben ser lo suficientemente flexibles para poder adaptarse a la situación en cuestión. Minimice el número de aprobadores y conviértalos en los adecuados. Su proceso de MOC se puede optimizar de manera segura.

5) "Pero mi gerente de área ya tiene que aprobar los fondos para los cambios".
No confunda la autoridad para tomar una decisión con la posesión del conocimiento necesario para tomar esa decisión. No todos los cambios, y a menudo los más críticos, incluso pasan por la aprobación de la financiación. A menudo, las personas más competentes para evaluar el riesgo de realizar un cambio o la validez técnica de un cambio no son el gerente de área sino los operadores, mecánicos, supervisores o ingenieros más familiarizados con él.

Incluso si el gerente es muy competente, es raro que una persona sea competente en todos los aspectos o consecuencias de un cambio dado. En un proceso de MOC efectivo, es responsabilidad del gerente asegurarse de que los recursos designados apropiados estén involucrados en una evaluación bien balanceada del cambio propuesto. La autoridad de aprobación es secundaria a la competencia para evaluar y un equipo bien equilibrado dará buenos resultados de manera más consistente que depender de una sola persona inteligente.

6) “Somos un almacén / fabricación ligera / datos centro / instalación de reparación. ... No tenemos nada que pueda ser peligroso ".
Recuerde, MOC es un proceso para prevenir o mitigar todas las posibles pérdidas comerciales autoinfligidas asociadas con un cambio. Hay otras pérdidas además de la seguridad del proceso. Es una pérdida si un cambio de proceso incontrolado hace que pierda un cliente valioso debido a un producto contaminado o defectuoso. Es una pérdida si su centro de datos no funciona y la resolución de problemas lleva varias horas en lugar de minutos porque los planos eléctricos no se han mantenido al día con los cambios. Es una pérdida si el apilador automático no funciona y no puede enviar el producto porque una sustitución de pieza a medianoche que requiere una "pequeña modificación" provocó que la única pieza de repuesto que tiene en stock ya no quepa. Es una pérdida si una modificación no documentada del software de control hace que su máquina de prueba automática falle cuando se instala el último parche de seguridad. Todos estos son ejemplos reales y la lista es interminable. Aunque el potencial de cambios para crear situaciones peligrosas en su entorno es pequeño, todos tenemos algo que perder cuando nuestras instalaciones o procesos fallan en sus misiones principales.

7) “Pero MOC ganó no detecta todos los problemas posibles, así que, ¿por qué hacerlo? ”
Tienes toda la razón. A pesar de sus mejores esfuerzos, algunos problemas pasarán desapercibidos. Pero, ¿cuántos pasarán si no haces MOC? La gestión de riesgos se trata de cambiar las probabilidades para que estén más a su favor. Este argumento no se sostiene, no más que el argumento que algunas personas usan contra las bolsas de aire:"Pueden desplegarse y causar un accidente, así que las apago". Las estadísticas simplemente no apoyan esa línea de pensamiento más de lo que apoyan no tener MOC.

Entonces, ¿qué pasa si se pierde una consecuencia no deseada? Un valioso beneficio adicional de MOC en sistemas complejos es cuando se realiza un RCFA. Si hay consecuencias adversas de un cambio y la causa no se puede discernir de inmediato, la RCFA va mucho más rápido si tiene una lista de todos los cambios deliberados que se han realizado. Y ese tiempo puede ser dinero real. En un caso, la investigación de registros MOC redujo el tiempo necesario para encontrar la causa raíz de una serie de fallas en la planta de proceso durante semanas. Con $ 250,000 por día en pérdidas de tiempo de inactividad evitadas, el esfuerzo de MOC tuvo un retorno de la inversión bastante bueno, aunque no evitó el problema.

8) “Esto es solo un cambio de software / procedimiento. No es como si estuviéramos cambiando una pipa o algo así. No necesitamos aprobar ni documentar ".
Se han producido algunos incidentes extremadamente graves y pérdidas graves en varias industrias debido a cambios de software o procedimientos que no estaban sujetos a MOC. Además, el hecho de que un documento o código se haya modificado y refleje el cambio no significa que el cambio esté documentado. Sé que los comentarios en el código y las marcas de revisión en el documento permiten al buscador buscar cambios. Pero cuando ocurren problemas inesperados debido a que el cambio de software o procedimiento no se revisó adecuadamente, ¿de qué sirve?

¿Ha tenido una línea de producción inactiva mientras buscaba desesperadamente miles de líneas de código en busca del cambio que hizo el ingeniero de control dos meses antes de irse a otro trabajo? Los programadores e ingenieros de control, en particular, tienden a "jugar" con el software sin tener en cuenta el MOC. Esto se aplica no solo al control de sus procesos, sino también al software de sistemas comerciales críticos. Si el riesgo potencial existe y lo justifica, entonces trate el cambio de una línea de código de la misma manera que volver a cablear un sistema de apagado de seguridad; debe recibir el mismo nivel de escrutinio y control.

Conclusión
En conclusión, un proceso MOC bien diseñado es una herramienta de prevención de pérdidas esencial para cualquier negocio. No es solo para ciertas industrias peligrosas. El proceso se aplica a cualquier empresa que desee evitar pérdidas futuras derivadas de los cambios de hoy. MOC no tiene por qué ser abrumador o tan difícil de usar que inhiba el cambio. No puede compensar sin esfuerzo omisiones pasadas, solo reducir su riesgo futuro. Por lo tanto, hoy es el momento de comenzar a desarrollar e implementar un proceso de MOC eficaz y eficiente.

Este artículo apareció por primera vez en la edición de julio del boletín informativo de Life Cycle Engineering, RxToday.

Acerca del autor:
Sam McNair es consultor senior de Life Cycle Engineering (LCE). Un ingeniero profesional y un profesional certificado en mantenimiento y confiabilidad, Sam tiene más de 32 años de experiencia en manufactura discreta, industrias de procesos químicos, minería, procesos de maquinaria, automatización, aviación, construcción y servicios públicos. Sam se especializa en ingeniería de confiabilidad con un enfoque en la integración de funciones de mantenimiento y fabricación. Puede comunicarse con Sam en [email protected]. Para obtener más información sobre la ingeniería del ciclo de vida, visite www.LCE.com.