8 conceptos erróneos sobre la Gestión del Cambio (MOC) — Por qué MOC importa para todas las empresas

Cuando hablo de Gestión del Cambio (MOC) con personal de planta, surgen caras familiares: el profesional experimentado que cita OSHA 1910.119(a)(2) y suspira que su proceso no es un «proceso cubierto», y el menos experimentado que se queja de que su sistema de gestión de planos va rezagado y que ponerse al día consumiría años de recursos.

Otras respuestas son igualmente comunes: «Ya tenemos un procedimiento para que los gerentes aprueben pequeños proyectos y alteraciones», o un comentario irónico sobre los «céntimos y nickels» que llenan la cenicero de su coche. Estas reacciones revelan una incertidumbre compartida: ¿qué es exactamente MOC y por qué debería importar a una instalación no regulada bajo el marco OSHA 1910.119?

OSHA 1910.119(l)(1) define los requisitos de MOC: «El empleador establecerá e implementará procedimientos escritos para gestionar cambios (excepto «reemplazos en tipo») a químicos de proceso, tecnología, equipos y procedimientos; y cambios en instalaciones que afecten un proceso cubierto». Aunque la regulación se centra en seguridad de procesos, el principio central —controlar el cambio para prevenir pérdidas— tiene relevancia mucho más allá de industrias reguladas.

Para instalaciones que califican como «proceso cubierto», los requisitos de MOC son bien entendidos y esenciales para la operación continua. Más alarmante, sin embargo, es que estudios atribuyen hasta el 80 % de accidentes industriales mayores a cambios no controlados. En ese sentido, MOC puede verse como un seguro de vida: menos accidentes, mayor retorno de inversión.

Incluso si su planta no está sujeta a las reglas específicas de MOC de OSHA, todo negocio que busque mantenerse competitivo debe gestionar el cambio. MOC es una herramienta rentable de prevención de pérdidas que complementa programas de seguridad, fiabilidad y gestión ambiental.

Es importante recordar que MOC solo aplica a cambios en sistemas existentes; el diseño de nuevos procesos o instalaciones está fuera de su alcance. El proceso MOC asume que el sistema actual tiene fortalezas y debilidades conocidas, y busca mitigar los riesgos asociados a modificarlo.

En términos simples, MOC es un enfoque estructurado para prevenir o mitigar pérdidas —ya sea que afecten seguridad, salud, medio ambiente o rendimiento empresarial— resultantes de cambios en cómo se construye, opera, mantiene o repara una instalación. Todo negocio que quiera proteger sus activos y reputación se beneficiará de un programa MOC robusto.

¿Qué constituye un «cambio»?

«Reconocer el cambio» es a menudo la parte más desafiante de MOC. El primer paso es una definición clara que coincida con sus objetivos empresariales y regulaciones aplicables. Una definición vaga lleva a la parálisis y crea lagunas para quienes desean eludir el proceso.

La dirección debe decidir qué riesgos quiere controlar la organización y luego identificar los cambios que aumentarían esos riesgos. Por ejemplo, un cambio podría involucrar hardware, software, procedimientos o parámetros de proceso. Incluso modificaciones no de hardware —como un nuevo parche de software o un límite operativo revisado— deben considerarse.

El documento fuente de OSHA distingue un cambio de un «Reemplazo en Tipo» (RIK), que es un reemplazo que satisface las especificaciones de diseño originales. La definición más amplia en OSHA 3313 clarifica que un 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)». Esta visión reconoce que tecnología, químicos y procedimientos son tan críticos como el equipo físico.

Dado que cada organización tiene un perfil de riesgo único, la definición de cambio debe reflejar su tolerancia a la modificación no controlada. A continuación, ejemplos comunes que la mayoría de empresas considerarían elegibles para MOC:

• Añadir nuevo equipo de proceso o sistemas empresariales críticos, incluyendo software
• Reemplazar equipos o piezas que no sean «en tipo»
• Modificar o añadir a equipos de proceso o sistemas críticos
• Ajustar control de proceso o instrumentación, incluyendo estrategias de control
• Cambiar especificaciones o abastecimiento de piezas de mantenimiento, reparación y operaciones (MRO)
• Alterar sistemas de seguridad —interbloqueos, paradas, supresión de incendios o explosiones
• Revisar procedimientos operativos estándar (SOPs) o procedimientos de emergencia
• Modificar estructura organizativa de planta o procedimientos de mantenimiento
• Cambiar especificaciones o abastecimiento de materias primas o componentes
• Alterar conexiones de servicios —aire, eléctrico, gas, agua, vapor, etc.
• Ajustar conexiones de red de datos críticas
• Actualizar procedimientos de garantía de calidad (QA) o equipos de prueba

Una breve sesión de lluvia de ideas multidisciplinaria al inicio de la fase de diseño puede ayudar a asegurar que las definiciones y ejemplos elegidos se alineen con prioridades empresariales y tolerancia al riesgo.

¿Qué pasa con los cambios «temporales»?

No existe cambio permanente —solo un cambio temporal que eventualmente vuelve a su estado original. Sin embargo, los cambios temporales son la causa más frecuente de incidentes. Por tanto, MOC debe tratar los cambios temporales igual que los permanentes, con atención especial al proceso de retorno. OSHA 3313 clarifica que «los procedimientos MOC deben asegurar que equipos y procedimientos vuelvan a sus condiciones originales al final de un cambio temporal». Tratar cambios temporales como permanentes protege contra la mayor exposición al riesgo.

Ocho conceptos erróneos comunes sobre MOC

1. «No estoy haciendo una modificación real; solo estoy mejorando algo».
   Cualquier cambio en configuración, forma, ajuste, función, material o procedimiento cae bajo MOC a menos que esté explícitamente excluido por sus criterios. Mejoras menores que alteran el contexto del sistema pueden aumentar inadvertidamente el riesgo. Capacite a empleados para reconocer y reportar tales cambios antes de que se vuelvan críticos.
2. «Voy retrasado; no puedo empezar MOC porque tenemos planos desactualizados».
   El control documental es un complemento, no un sustituto, de MOC. Priorizar acciones correctivas según criticidad del sistema le permite avanzar sin esperar a que cada documento sea perfecto. MOC protege el futuro; no puede enmendar errores pasados.
3. «Esto es una emergencia; no tenemos tiempo para MOC».
   En emergencias, la disciplina de un proceso MOC bien establecido es aún más esencial. Un enfoque controlado y documentado para bypasses o sustituciones temporales a menudo ahorra más tiempo y reduce riesgo que soluciones ad-hoc. MOC debe incluir un procedimiento de emergencia claro que no eluda los principios fundamentales.
4. «Enrutar este formulario para aprobación lleva demasiado tiempo».
   Los niveles de aprobación deben ser proporcionales al riesgo del cambio. Agilice el proceso limitando aprobadores a aquellos con la experiencia y autoridad adecuadas, y adaptando el flujo de trabajo a la situación.
5. «El gerente de área ya aprueba la financiación; eso es suficiente».
   La autoridad para aprobar fondos no es lo mismo que el conocimiento necesario para evaluar el impacto técnico o de seguridad de un cambio. Un equipo de revisión equilibrado y multidisciplinario entrega resultados más fiables.
6. «Somos un almacén o centro de datos; no hay peligro».
   MOC protege contra todas las formas de pérdida —calidad del producto, confianza del cliente, tiempo de inactividad de equipos, integridad de datos, y más. Incluso entornos de bajo riesgo pueden sufrir fallos costosos si los cambios no se controlan.
7. «MOC no atrapará todos los problemas, así que ¿para qué molestarse?».
   Aunque ningún sistema es perfecto, MOC reduce drásticamente la probabilidad de accidentes. También proporciona una valiosa pista de auditoría que acelera el análisis de causa raíz cuando surgen problemas imprevistos. El coste de incidentes no detectados a menudo supera con creces el gasto de MOC.
8. «Los cambios de software o procedimientos no necesitan MOC».
   Actualizaciones de software y cambios de procedimientos han causado incidentes significativos en muchas industrias. Trate cualquier alteración que pueda afectar seguridad o rendimiento igual que una modificación física —revisión completa, documentación y aprobación.

Conclusión

Un programa MOC bien diseñado es una herramienta vital de prevención de pérdidas para toda organización, independientemente de la industria o estado regulatorio. No necesita ser oneroso; con la estructura adecuada, MOC puede coexistir con mejora continua y gestión ágil de cambios. El momento de implementar un proceso MOC robusto es ahora.

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

Sobre el autor

Sam McNair es consultor senior en Life Cycle Engineering (LCE). Ingeniero Profesional y Profesional Certificado en Mantenimiento y Fiabilidad, Sam tiene más de 32 años de experiencia en manufactura discreta, industrias de procesos químicos, minería, procesos de máquinas, automatización, aviación, construcción y servicios públicos. Se especializa en ingeniería de fiabilidad con enfoque en integrar funciones de mantenimiento y manufactura. Contacte a Sam en smcnair@LCE.com. Para más información sobre Life Cycle Engineering, visite www.LCE.com.