Entienda Management of Change, replacement in kind, cambios temporales, análisis de riesgos, MOC en SIS y automatización, PSSR, documentación y gobernanza.
¡Descúbrelo!
Management of Change — MOC es el proceso formal utilizado para identificar, evaluar, autorizar, implementar y cerrar cambios capaces de alterar peligros, riesgos, barreras de protección o condiciones operativas de una instalación. En Seguridad de Procesos, MOC existe para impedir que una modificación aparentemente simple —un nuevo setpoint, una sustitución de equipo, un cambio de materia prima, una revisión de lógica o una condición temporal— invalide silenciosamente premisas técnicas que sostienen la operación segura.
Un MOC eficaz no es solamente un formulario de aprobación. Conecta la base técnica del cambio con el análisis de riesgos, documentación, capacitación, pruebas, preparación para la puesta en marcha y cierre. El cambio solo se considera concluido cuando los impactos han sido tratados y la configuración real de la instalación vuelve a estar representada en los documentos, procedimientos y sistemas de gestión aplicables.
Qué es Management of Change
Management of Change puede entenderse como una disciplina de gobernanza aplicada al cambio técnico y operativo. Su objetivo es responder, antes de la implementación, si la modificación cambia el riesgo y qué controles deben actualizarse para que la instalación continúe operando dentro de condiciones conocidas y autorizadas.
OSHA 29 CFR 1910.119, una de las referencias internacionales más utilizadas en Process Safety Management, exige procedimientos escritos para gestionar cambios en productos químicos de proceso, tecnología, equipos, procedimientos e instalaciones que afecten procesos cubiertos, excepto replacements in kind. El requisito también determina la evaluación de la base técnica, impactos de seguridad y salud, cambios en procedimientos, plazo y autorizaciones antes del cambio.
En Brasil, este requisito no debe presentarse como obligación legal automática para toda instalación. OSHA es una referencia técnica extranjera. La aplicabilidad regulatoria brasileña debe analizarse conforme a las NRs, legislación y requisitos sectoriales pertinentes. Aun así, el principio de controlar técnicamente los cambios es plenamente compatible con las buenas prácticas de ingeniería y con la necesidad de mantener análisis de riesgos, procedimientos y documentación coherentes con la instalación real.
Por qué los cambios son una fuente relevante de riesgo
Gran parte de las instalaciones industriales evoluciona continuamente. La producción aumenta, las campañas cambian, los proveedores descontinúan componentes, se introducen nuevos productos, se moderniza la automatización, se desvían líneas, los equipos reciben upgrades y los procedimientos se adaptan para responder a necesidades operativas.
Cada cambio puede parecer local, pero sus efectos pueden atravesar varias disciplinas. La sustitución de una válvula puede alterar el tiempo de cierre; una nueva bomba puede cambiar la presión de shutoff; un nuevo setpoint puede reducir el margen operativo; una modificación de software puede alterar una secuencia de interlock; una nueva materia prima puede introducir incompatibilidad química.
El riesgo surge cuando la organización gestiona la ejecución física, pero no reevalúa las premisas. Por eso MOC es un elemento central del framework Risk-Based Process Safety del CCPS.
Qué debe activar un MOC
Un programa maduro necesita criterios claros para reconocer cambios. Sin esta definición, cada área decide informalmente qué considera significativo y modificaciones importantes escapan del proceso.
Ejemplos típicos de disparadores incluyen:
- cambio de materia prima, composición, concentración o proveedor cuando características relevantes puedan variar;
- modificación de temperatura, presión, caudal, nivel, inventario o capacidad;
- cambio de material de construcción, clase de presión o especificación de equipo;
- modificación de ruta de tubería o conexión de proceso;
- modificación de PLC, DCS, SIS, software, lógica, permisivo, interlock o alarma;
- cambio de setpoint, tiempo de retardo o estrategia de control;
- modificación de procedimientos de puesta en marcha, parada, emergencia o mantenimiento;
- instalación temporal de bypass, manguera, jumper, línea provisional o equipo alquilado;
- sustitución por un componente que no sea técnicamente equivalente;
- cambio de layout que afecte acceso, ventilación, drenaje, segregación o respuesta a emergencias;
- modificación de condiciones de utilidades o infraestructura crítica;
- cambio organizacional que afecte responsabilidades esenciales de Seguridad de Procesos.
La lista no sustituye el juicio técnico. El objetivo es crear disparadores suficientemente claros para que la duda se encamine a evaluación, en lugar de resolverse informalmente.
Replacement in kind: cuándo una sustitución no es un cambio
Replacement in kind es una sustitución que preserva especificación, función, desempeño, materiales, interfaces y demás características relevantes para el riesgo. El concepto no significa simplemente “colocar otro equipo en el mismo lugar”.
Si una válvula antigua se sustituye por un modelo diferente, es necesario verificar Cv, clase, material, tiempo de actuación, fail position, certificaciones, accesorios y comportamiento dinámico. Si cambia alguna característica relevante, la sustitución deja de ser claramente in kind.
Lo mismo aplica a instrumentos y componentes de automatización. Un transmisor de nueva generación puede tener rango, tiempo de respuesta, diagnóstico, protocolo o comportamiento de falla diferentes. La equivalencia debe ser técnica, no solamente comercial.
OSHA Appendix C refuerza esta lógica al diferenciar replacements in kind de cambios en proceso, equipo, instrumentación y condiciones de operación.
El MOC temporal también necesita gobernanza
Los cambios temporales son particularmente peligrosos porque frecuentemente nacen de una urgencia: equipo no disponible, parada parcial, falla de componente, necesidad de producción o contingencia. El carácter provisional crea la percepción de que el cambio puede recibir menos rigor.
En la práctica, una condición temporal puede permanecer meses o años. Por eso, el MOC debe registrar vigencia, responsable, condiciones de operación, compensaciones de riesgo, inspecciones, plazo de reversión y criterios para extensión.
Bypasses, overrides e inhibiciones en sistemas de protección requieren atención especial. El período durante el cual una barrera está indisponible debe gestionarse con controles compensatorios y autorización proporcional al riesgo.
Cambios de emergencia
Una emergencia no elimina la necesidad de análisis; modifica el flujo. Un procedimiento de emergency MOC puede prever aprobación simplificada y evaluación rápida, pero debe preservar los elementos críticos: justificación, riesgo, responsables, condición temporal, comunicación y revisión posterior.
Después de la estabilización, el cambio debe regularizarse o revertirse. El mayor error es transformar una excepción de emergencia en una condición permanente sin completar la ingeniería, documentación y aprobación necesarias.
Cómo funciona el flujo de MOC
Cuando los cambios ocurren por correo electrónico, conversación de campo o aprobación informal, el problema no es la falta de formulario: es la ausencia de gobernanza técnica capaz de conectar decisión, riesgo, documentación y aceptación.
El proceso debe comenzar con una solicitud suficientemente clara. La propuesta debe explicar el problema, la condición actual, la condición deseada y la base técnica del cambio. Solicitudes vagas dificultan identificar interfaces y riesgos.
A continuación ocurre la clasificación. La organización determina si la modificación es in kind, temporal, permanente, de emergencia o de otra categoría interna y define el nivel de evaluación proporcional a la criticidad.
El análisis técnico identifica documentos, disciplinas, sistemas y barreras afectados. Dependiendo del caso, puede ser necesaria una revisión de HAZOP, LOPA, SIL, clasificación de áreas, alivio, hidráulica, integridad, sistemas eléctricos, ciberseguridad u otros estudios.
Después de las aprobaciones, el cambio se detalla, adquiere e implementa. Antes de la entrada en servicio deben completarse las pruebas, actualizaciones documentales, capacitación y PSSR cuando corresponda. El cierre confirma que todas las acciones fueron concluidas o tratadas formalmente.
Base técnica del cambio
Todo MOC necesita una razón técnica comprensible. “Mejorar el proceso” o “cambiar equipo” son justificaciones insuficientes. La base debe registrar el problema, premisas, datos utilizados, alternativas evaluadas y límites de la solución.
Este registro es importante porque los equipos futuros necesitan entender por qué se realizó el cambio. Sin contexto, las decisiones pueden revertirse años después sin percibir que determinado detalle existía para controlar un riesgo específico.
La base técnica también reduce decisiones puramente comerciales. Una sustitución de proveedor puede ser ventajosa en precio y plazo, pero necesita preservar los requisitos de ingeniería que originaron la especificación.
Análisis de riesgos dentro del MOC
Un cambio solo debe avanzar después de que sus impactos sobre escenarios, barreras y condiciones temporales hayan sido comprendidos y registrados con un rigor proporcional a la criticidad.
No todo cambio exige un HAZOP completo. El nivel de análisis debe ser proporcional al impacto potencial. Los cambios simples pueden evaluarse mediante checklist técnico y revisión multidisciplinaria; las modificaciones significativas pueden exigir HAZID, HAZOP, What-If, LOPA o estudios especializados.
La decisión sobre la técnica debe considerar la naturaleza de la modificación, consecuencias potenciales, novedad, complejidad, interacciones con barreras y calidad de la información disponible.
Cuando el cambio afecta un escenario ya analizado, el equipo necesita verificar si causas, frecuencias, consecuencias o salvaguardas fueron modificadas. Una revisión de LOPA puede ser necesaria si cambia el desempeño de una IPL.
El análisis también debe identificar nuevos escenarios creados por la propia transición, como riesgos durante cutover, operación en paralelo, pruebas o retorno a la configuración original.
MOC y HAZOP
HAZOP proporciona una base valiosa para MOC porque registra desviaciones, causas, consecuencias y salvaguardas. Cuando una modificación cambia un nodo o premisa relevante, el estudio necesita revisitarse.
No es necesario volver a ejecutar integralmente HAZOP para cualquier cambio. Lo importante es determinar el impacto sobre los nodos y escenarios afectados y registrar la decisión.
En proyectos de gran porte, una matriz de trazabilidad puede conectar MOC con recomendaciones de HAZOP, LOPA y documentos de ingeniería.
MOC y SIL
Los cambios en sensores, logic solver, elementos finales, intervalos de prueba, arquitectura, setpoints, tiempos de respuesta o independencia pueden afectar el desempeño de una SIF. Por eso, MOC debe evaluar el impacto sobre el SIL requerido y verificado.
La sustitución de una válvula de shutdown por un modelo con comportamiento diferente, por ejemplo, puede modificar PFDavg, tiempo de actuación y cobertura de proof test. Una modificación aparentemente de mantenimiento puede exigir una nueva verificación.
La regla práctica es preservar la trazabilidad entre escenario, SRS, arquitectura instalada, datos de confiabilidad y pruebas periódicas.
MOC en Sistemas Instrumentados de Seguridad
IEC 61511-1 incorporó un requisito explícito de management of change en su segunda edición. El ciclo de Seguridad Funcional necesita controlar las modificaciones realizadas durante la operación y mantenimiento del SIS.
En el SIS, los cambios de aplicación, hardware, instrumentos, lógica, interfaces y procedimientos pueden afectar funciones críticas. MOC debe asegurar evaluación, autorización, verificación y actualización de documentación antes del retorno al servicio.
La existencia de software hace especialmente importante el control de versión y configuración. Un cambio pequeño en código puede alcanzar múltiples funciones cuando hay bibliotecas, bloques compartidos o variables comunes involucrados.
Setpoints, alarmas e interlocks
Los setpoints son uno de los ejemplos clásicos de cambio subestimado. Modificar un límite de alarma o trip puede reducir el margen entre operación y condición peligrosa, cambiar el tiempo disponible para respuesta o crear interacción con otra protección.
MOC debe exigir una base técnica para cambios de setpoint y verificar consistencia con causa y efecto, filosofía de alarmas, SRS, procedimientos y pantallas de operación.
Interlocks y permisivos tampoco deben deshabilitarse informalmente para facilitar mantenimiento o producción. Un bypass necesita control propio, plazo y compensaciones.
Cambios en BPCS, SCADA y redes OT
Los sistemas de automatización industrial evolucionan mediante actualizaciones de firmware, servidores, switches, controladores, virtualización, integración con sistemas corporativos y nuevas funciones analíticas. Estos cambios pueden afectar disponibilidad, latencia, redundancia, seguridad e independencia.
La gestión necesita incluir backup, rollback, compatibilidad, pruebas, cybersecurity y plan de cutover. Cuando existen interfaces con SIS o barreras críticas, la revisión necesita ser multidisciplinaria.
Los cambios de red también pueden alterar caminos de comunicación, sincronización de tiempo y capacidad de diagnóstico. No deben tratarse solamente como una actividad de TI.
Cambios de proceso y capacidad
El aumento de producción es uno de los cambios más comunes en plantas existentes. Puede modificar velocidades, inventarios, tiempos de residencia, carga térmica, generación de vapor, capacidad de alivio y márgenes de equipos.
Debottlenecking exige revisar el proceso como sistema. La bomba puede soportar el caudal deseado mientras el recipiente siguiente, la válvula de control o el flare no soportan la nueva condición.
MOC debe evitar optimizaciones locales que transfieran el riesgo a otro punto de la planta.
Cambios de materia prima y producto
Cambiar la materia prima puede modificar corrosividad, inflamabilidad, toxicidad, viscosidad, punto de inflamación, tendencia a polimerización o incompatibilidad con materiales existentes. Incluso las variaciones de impurezas pueden ser relevantes.
La evaluación necesita considerar SDS, datos de proceso, materiales de construcción, equipos de protección, detección, emergencia, residuos y calidad del producto.
Los cambios de proveedor también pueden exigir revisión cuando las especificaciones comerciales permiten variaciones con impacto técnico.
MOC en equipos mecánicos
Equipos rotativos, válvulas, tuberías y recipientes poseen características que interactúan con el proceso. Modificar una bomba, impulsor, motor, sello, material o diámetro puede cambiar condiciones hidráulicas y de integridad.
El análisis debe considerar design conditions, materiales, compatibilidad, esfuerzos, vibración, presión, temperatura, protección contra sobrepresión y mantenibilidad.
Para válvulas de seguridad y dispositivos de alivio, las sustituciones deben preservar capacidad, set pressure, contrapresión y demás premisas de dimensionamiento.
MOC en sistemas eléctricos
Los cambios eléctricos también pueden tener impacto en Seguridad de Procesos. La sustitución de un motor puede modificar carga, arranque, protección y desempeño del proceso. Los cambios en UPS, generadores o alimentación de sistemas críticos pueden afectar la disponibilidad de control y protección.
El análisis debe considerar selectividad, cortocircuito, coordinación, puesta a tierra, clasificación de áreas, cargas críticas y tiempo de autonomía cuando sean relevantes.
La integración entre disciplinas es esencial porque la consecuencia final puede aparecer en el proceso, no en el sistema eléctrico aisladamente.
MOC y clasificación de áreas
Un cambio de sustancia, ventilación, inventario, equipo o layout puede modificar la clasificación de áreas potencialmente explosivas. La revisión necesita verificar si los equipos instalados siguen siendo adecuados para la zona, grupo y temperatura aplicables.
Los cambios físicos también pueden crear confinamientos u obstrucciones que modifiquen dispersión y ventilación.
Este tipo de impacto frecuentemente pasa desapercibido cuando el cambio es analizado solamente por la disciplina que lo solicitó.
MOC en procedimientos operativos
Los cambios procedimentales también pueden modificar el riesgo. Cambiar una secuencia de puesta en marcha, lógica de alineamiento, método de drenaje o forma de transición entre productos puede crear estados no analizados.
La organización necesita diferenciar una mejora editorial de un cambio operativo. Corregir ortografía no requiere MOC; modificar una instrucción que cambia la condición del proceso puede exigir evaluación.
Cuando cambian los procedimientos, los trabajadores afectados deben ser informados y capacitados antes de que la nueva condición entre en servicio.
Documentos que pueden verse afectados
Un único MOC puede exigir la revisión de diferentes documentos. Entre los más comunes están:
- PFD y P&ID;
- datasheets y especificaciones;
- lista de equipos y líneas;
- causa y efecto;
- lista de alarmas y setpoints;
- filosofía de control;
- SRS y documentos de SIS;
- clasificación de áreas;
- procedimientos operativos y de mantenimiento;
- planos eléctricos y de instrumentación;
- plan de inspección y mantenimiento;
- lista de repuestos;
- plan de respuesta a emergencias;
- As-Built y base de activos.
El cierre debe confirmar qué documentos fueron actualizados y en qué revisión.
MOC y control de configuración
MOC decide y gobierna el cambio; configuration management garantiza que la configuración aprobada esté identificada y controlada. Son procesos complementarios.
Un cambio puede estar técnicamente aprobado, pero todavía ser mal gestionado si planos, códigos, backups o listas de activos no reflejan el resultado. Inversamente, controlar revisiones sin evaluar el riesgo no sustituye MOC.
Esta distinción es especialmente importante en automatización, donde hardware, firmware, application program, parámetros y red forman una configuración conjunta.
MOC vs. Engineering Change Management
Engineering Change Management — ECM trata principalmente del control de cambios durante el desarrollo de ingeniería: requisitos, alcance, documentos, interfaces, baseline e impactos en costo y plazo.
MOC en Seguridad de Procesos tiene como centro la pregunta: ¿la modificación cambia peligros, riesgo o barreras de la instalación?
Los procesos pueden conectarse. Un MOC aprobado puede originar Engineering Change Notice y revisiones de diseño. Un cambio de ingeniería puede exigir MOC antes de implementarse en una planta existente. La integración debe evitar duplicidad sin perder los objetivos distintos.
Procurement y sustituciones de proveedor
Procurement es una fuente frecuente de cambios. Durante la adquisición, los proveedores pueden proponer equivalentes, desviaciones técnicas o modelos alternativos para reducir costo o plazo.
La aprobación comercial no debe cerrar el análisis. La desviación necesita evaluarse frente al requisito original y, cuando afecte el riesgo o la configuración de la instalación, debe ingresar al proceso de MOC o change control correspondiente.
Una Technical Bid Evaluation bien estructurada ayuda a identificar desviaciones antes de la compra, reduciendo cambios tardíos en campo.
Contratistas y cambios en campo
Las empresas contratistas frecuentemente identifican interferencias durante el montaje y proponen soluciones prácticas. La ejecución inmediata de un cambio en campo sin análisis es uno de los principales mecanismos de pérdida de configuración.
Los field changes deben formalizarse mediante RFI, TQ, redline o proceso equivalente y evaluarse respecto de la necesidad de MOC. El hecho de que una solución “funcione” mecánicamente no demuestra que preserve seguridad, operación y mantenimiento.
La Ingeniería de Campo necesita autoridad para detener cambios no aprobados.
Brownfield, cutover y rollback
Los proyectos brownfield concentran cambios porque los nuevos sistemas deben convivir con instalaciones existentes. Cutover es una condición transitoria que puede crear combinaciones de equipos y lógicas que no están presentes ni en el estado antiguo ni en el nuevo.
MOC debe incluir plan de migración, secuencia, responsables, pruebas, criterios de go/no-go y rollback. La reversión necesita ser técnicamente viable y documentada, no solamente una frase genérica en el plan.
En automatización, backups e imágenes de configuración deben probarse o, al menos, verificarse antes de la intervención.
PSSR después del cambio
No todo MOC exige PSSR formal, pero las modificaciones significativas necesitan una revisión de preparación antes de la puesta en marcha. La PSSR verifica si la instalación, procedimientos, capacitación, documentación, acciones de riesgo y demás condiciones están listas para operación.
La relación es directa: MOC autoriza y gobierna el cambio; PSSR confirma que la condición resultante está lista para entrar en servicio.
Un MOC cerrado administrativamente antes de concluir las acciones de PSSR es una falla de gobernanza.
Pruebas y commissioning
El cambio necesita criterios de aceptación definidos antes de la prueba. Loop checks, pruebas funcionales, SAT, pruebas de interlock, calibración, verificación de alarmas, ensayos eléctricos u otros procedimientos deben seleccionarse conforme al alcance.
El commissioning genera evidencia de que la solución implementada cumple los requisitos. En sistemas críticos, el registro debe permitir rastrear requisito, prueba, resultado y pendiente.
Las fallas encontradas durante las pruebas pueden generar una nueva revisión del cambio y no deben simplemente corregirse en campo sin control.
Capacitación y comunicación
Las personas afectadas necesitan conocer la nueva condición antes de la puesta en marcha. Esto incluye operación, mantenimiento y contratistas cuando sus tareas hayan sido modificadas.
La capacitación no debe limitarse a comunicar que “hubo un cambio”. Es necesario explicar nuevos límites, riesgos, respuesta a alarmas, procedimientos, condiciones temporales y responsabilidades.
Cuando el cambio modifica la interfaz hombre-máquina, las pantallas y alarmas deben actualizarse junto con la capacitación.
Cierre del MOC
El cierre no es la fecha en que terminó el montaje. Ocurre cuando los requisitos técnicos, documentos, capacitaciones, pruebas, acciones de riesgo y pendientes fueron concluidos o transferidos formalmente a un sistema controlado.
Una buena lista de cierre incluye:
- documentación As-Built emitida;
- procedimientos actualizados;
- capacitaciones concluidas;
- pruebas aprobadas;
- acciones críticas cerradas;
- PSSR concluida cuando corresponda;
- cambio temporal revertido o convertido formalmente;
- activos y planes de mantenimiento actualizados;
- responsables y aprobaciones registrados.
Los MOC permanentemente abiertos indican que el proceso no está completando el ciclo.
Indicadores de desempeño del MOC
Los indicadores deben mostrar calidad y exposición, no solamente cantidad. Métricas útiles incluyen tiempo medio de cierre, número de MOC temporales vencidos, porcentaje de acciones críticas atrasadas, MOC implementados antes de aprobación, reincidencia de desviaciones y documentación pendiente.
También es útil acompañar la distribución por tipo de cambio y área. Un crecimiento repentino de emergency MOC puede revelar problemas de planificación, mantenimiento o Procurement.
Los KPIs necesitan generar decisiones. Un dashboard sin tratamiento del backlog solamente hace visible la falla.
Auditoría de MOC
La auditoría debe muestrear cambios concluidos y verificar si la instalación real corresponde al registro. No basta comprobar que los campos fueron completados.
Una auditoría robusta puede rastrear un cambio desde la solicitud hasta el campo y comparar P&ID, especificación, lógica, procedimiento, capacitación, pruebas y configuración final.
Los cambios no registrados encontrados en campo son un indicador importante de fragilidad del sistema.
Gobernanza corporativa y estandarización
Las empresas con múltiples unidades necesitan estandarizar principios sin volver el proceso excesivamente burocrático. El procedimiento corporativo puede definir categorías, responsabilidades, criterios de riesgo, campos mínimos, gates e indicadores, mientras los anexos locales tratan particularidades de la instalación.
Los templates deben facilitar el análisis, no sustituir el pensamiento técnico. Un formulario con decenas de casillas marcadas puede generar una falsa sensación de control si no existe revisión competente.
Las matrices de aprobación deben ser proporcionales a la criticidad. Los cambios simples no necesitan el mismo nivel de gobernanza que una modificación que afecte SIS, alivio o inventario peligroso.
Papel de la Ingeniería Consultiva en MOC
La Ingeniería Consultiva puede apoyar diagnóstico, diseño del proceso, estandarización, facilitación de análisis, revisión independiente y auditoría del sistema MOC. Este papel es particularmente útil cuando la organización posee cambios acumulados, baja trazabilidad o múltiples proveedores.
Los entregables posibles incluyen procedimiento corporativo, diagrama de flujo, matriz RACI, criterios de clasificación, checklists multidisciplinarios, templates, workflow de aprobación, matriz de documentos afectados, indicadores y auditoría de madurez.
La Consultoría Técnica de Ingeniería puede estructurar este trabajo como gobernanza, sin necesidad de asumir suministro de equipos o ejecución del cambio.
Gestión de riesgos aplicada al cambio
MOC no sustituye el proceso más amplio de gestión de riesgos. Funciona como disparador para revisar riesgos siempre que cambia la configuración.
La integración con la Gestión de Riesgos de Ingeniería permite priorizar acciones, definir responsables, tratar riesgos temporales y verificar eficacia.
Los cambios de alta criticidad pueden exigir gobernanza adicional, con revisión independiente y gates antes de implementación y puesta en marcha.
Ingeniería del Propietario y MOC en proyectos contratados
En proyectos con múltiples contratos, MOC necesita atravesar fronteras de alcance. La Ingeniería del Propietario ayuda a verificar interfaces y preservar la visión del activo como sistema.
En ambientes con EPC, EPCM, integradores y proveedores especializados, los cambios pueden originarse en cualquier contrato. El propietario necesita un proceso único para evitar que cada proveedor trate modificaciones solamente dentro de su alcance.
La Ingeniería del Propietario puede funcionar como capa de integración, verificando impactos entre disciplinas, documentos, contratos y sistemas. La responsabilidad de cada proyectista o proveedor permanece definida, pero el cambio se analiza desde la perspectiva del activo como un todo.
Este papel es especialmente importante en brownfield, donde una modificación del nuevo proyecto puede afectar sistemas existentes fuera del contrato principal.
Errores recurrentes en Management of Change
Algunos patrones reducen la efectividad del proceso:
- tratar MOC solamente como formulario administrativo;
- usar “replacement in kind” sin demostrar equivalencia técnica;
- implementar antes del análisis por presión de plazo;
- olvidar cambios temporales y bypasses;
- modificar setpoints o lógica sin registrar la base técnica;
- no revisar HAZOP, LOPA o SIL cuando corresponda;
- cerrar sin actualizar documentos y procedimientos;
- dejar acciones críticas abiertas después de la puesta en marcha;
- usar MOC para toda pequeña revisión y burocratizar el sistema;
- no diferenciar ECM, configuration management y MOC;
- no auditar si el campo corresponde al registro.
El objetivo no es aumentar el número de MOC, sino garantizar que los cambios relevantes sean reconocidos y tratados con rigor proporcional al riesgo.
Cómo implementar o recuperar un sistema de MOC
Una organización sin un proceso maduro puede comenzar con un diagnóstico de brechas. Es necesario mapear cómo ocurren hoy los cambios, dónde se aprueban, qué documentos se actualizan y dónde las modificaciones informales escapan del control.
Después se define el alcance y la taxonomía de cambios, criterios para in kind, temporales y de emergencia, roles, niveles de aprobación e integración con mantenimiento, proyectos, Procurement, automatización y Seguridad de Procesos.
La implementación debe incluir capacitación con ejemplos reales. Los casos prácticos ayudan a los equipos a reconocer el disparador y evitan dos extremos: subnotificación y burocracia excesiva.
Finalmente, las auditorías iniciales deben probar la eficacia del proceso y ajustar criterios conforme a la experiencia.
Consideraciones finales
Management of Change es una de las principales disciplinas que preservan la validez de las decisiones de ingeniería después de que la instalación comienza a cambiar. Conecta la necesidad operativa con base técnica, análisis de riesgos, aprobación, diseño, Procurement, implementación, pruebas, documentación, capacitación y preparación para operación.
Su valor aparece precisamente en los cambios que parecen pequeños. Setpoints, componentes equivalentes, bypasses temporales, revisiones de software y cambios de procedimiento pueden modificar la arquitectura de riesgo sin producir una obra visible.
Un MOC maduro no busca impedir cambios; permite cambiar con trazabilidad. La organización sabe qué se modificó, por qué fue autorizado, qué riesgos se revisaron, qué documentos cambiaron, cómo se probó la solución y quién aceptó la condición final.
Para la Ingeniería Consultiva, el mayor espacio está en gobernanza y estandarización: construir un proceso proporcional al riesgo, integrar disciplinas, reducir cambios informales y asegurar que el activo real continúe coherente con las premisas técnicas que sostienen su operación segura.
Referencias técnicas
[1] UNITED STATES. Occupational Safety and Health Administration — OSHA. 29 CFR 1910.119 — Process Safety Management of Highly Hazardous Chemicals, item 1910.119(l) Management of Change. Disponible en: https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.119
[2] UNITED STATES. Occupational Safety and Health Administration — OSHA. Appendix C to §1910.119 — Compliance Guidelines and Recommendations for Process Safety Management. Disponible en: https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.119AppC
[3] CENTER FOR CHEMICAL PROCESS SAFETY — CCPS. Guidelines for Risk Based Process Safety. New York: AIChE/Wiley, 2007. Disponible en: https://ccps.aiche.org/publications/books/guidelines-risk-based-process-safety
[4] INTERNATIONAL ELECTROTECHNICAL COMMISSION — IEC. IEC 61511-1:2016+AMD1:2017 CSV — Functional safety — Safety instrumented systems for the process industry sector — Part 1. Disponible en: https://webstore.iec.ch/en/publication/61289
[5] BRASIL. Ministério do Trabalho e Emprego. NR-20 — Segurança e Saúde no Trabalho com Inflamáveis e Combustíveis. Disponible en: https://www.gov.br/trabalho-e-emprego/pt-br/acesso-a-informacao/participacao-social/conselhos-e-orgaos-colegiados/comissao-tripartite-partitaria-permanente/normas-regulamentadora/normas-regulamentadoras-vigentes/norma-regulamentadora-no-20-nr-20
Preguntas frecuentes
MOC significa Management of Change. Es el proceso formal para evaluar, autorizar, implementar y cerrar cambios que puedan afectar peligros, riesgos, barreras, procedimientos o configuración de una instalación.
Engineering Change Management controla cambios de requisitos, alcance, documentos y configuración durante proyectos de ingeniería. MOC se concentra en el impacto de un cambio sobre peligros, riesgos y barreras de la instalación. Los procesos pueden integrarse, especialmente en proyectos brownfield.
Es una sustitución técnicamente equivalente que preserva función, especificación, desempeño, materiales, interfaces y demás características relevantes para el riesgo. Colocar un equipo diferente en el mismo lugar no es suficiente para caracterizar replacement in kind.
Sí, cuando alteran condiciones relevantes de proceso, equipo, protección, procedimiento u operación. Los cambios temporales deben tener plazo, responsable, controles compensatorios y criterio de reversión o formalización.
No. La técnica de análisis debe ser proporcional al riesgo y a la complejidad. Los cambios simples pueden tratarse mediante revisión técnica estructurada; los cambios más significativos pueden exigir HAZOP, What-If, LOPA o estudios especializados.
Puede necesitarlo. Si el setpoint influye en límites operativos, alarmas, interlocks, SIFs o márgenes de seguridad, el cambio debe tener base técnica, evaluación de impacto y actualización de los documentos correspondientes.
MOC gobierna el cambio; PSSR verifica la preparación de la instalación modificada antes de la puesta en marcha cuando el cambio es significativo. PSSR confirma que montaje, procedimientos, capacitación, documentación y acciones de riesgo son adecuados para la entrada en servicio.
Sí. La consultora puede actuar en diagnóstico, estandarización, procedimientos, matriz RACI, criterios de clasificación, workflows, auditoría, facilitación de análisis y revisión independiente, mientras el diseño detallado y la ejecución permanecen con los responsables definidos.
Materiales técnicos complementarios
Soluciones relacionadas
Servicios relacionados
- Consultoría Técnica de Ingeniería: diagnóstico, estrategia y apoyo a la decisión
- Gestión de Riesgos de Ingeniería: identificación, análisis, mitigación y contingencia
- Ingeniería del Propietario — Owner’s Engineering
- Diseño de Automatización Industrial
Contenidos principales sobre el tema
- Seguridad de Procesos en Ingeniería: principios, barreras, análisis de riesgos y gobernanza
- Engineering Change Management (ECM) en Proyectos de Ingeniería
- HAZOP en Ingeniería
