Diagrama de flujo de gestión del cambio (MOC, PSSR, caducidad)

Cómo funciona

1. Renombra los carriles según tu centro

   Sustituye Solicitante, Coordinador de MOC, Autoridad técnica, Equipo de análisis de peligros, Responsable autorizador y Operación por los roles que de verdad existen en tu planta. La mayoría de los centros reparten la autoridad técnica por disciplina —proceso, mecánica, eléctrica, control e instrumentación—, así que decide si eso es un carril o varios. Mantén al coordinador separado de la autoridad técnica: uno hace funcionar el proceso y persigue el registro, la otra responde del criterio de ingeniería. Si las empresas contratistas originan cambios, dilo, porque un carril llamado Solicitante que en la práctica significa solo personal propio es la forma en que las modificaciones de contratistas se escapan del proceso.

2. Escribe la prueba de sustitución idéntica

   «¿Sustitución idéntica?» es la única caja que puede sacar un cambio del proceso por completo, así que necesita criterios escritos y no criterio personal. Define idéntico como igual en especificación, material, timbre o rango, intención de diseño del fabricante y configuración instalada, y después nombra a quién es competente para aplicar esa prueba: encontrar una pieza equivalente en el sistema de almacén no es una determinación de ingeniería. La obsolescencia es donde más centros lo pierden: en cuanto el artículo original deja de fabricarse, el modelo actual más parecido del proveedor es un cambio, y el formulario debería decirlo en lugar de dejárselo a quien tiene más prisa.

3. Fija la regla de enrutado del análisis de peligros

   Convierte «¿Qué nivel de análisis de peligros?» en una tabla y no en una conversación. Riesgo bajo puede ser una lista de comprobación documentada que completan dos personas competentes. Riesgo medio es un what-if o un what-if estructurado con lista de comprobación. Riesgo alto —cualquier cosa que toque una sustancia, un enclavamiento, un sistema de alivio, una filosofía de control o un límite seguro de operación— va a un HAZOP facilitado, con el estudio original abierto delante del equipo. Nombra a quién decide el nivel y exige que el motivo quede registrado junto a la decisión.

4. Publica la matriz de autorización

   La autorización debe seguir al peligro, no al coste. Escribe quién puede autorizar un cambio permanente de riesgo bajo, quién tiene que autorizar cualquier cosa que afecte a una función instrumentada de seguridad, a un caso de alivio o a una envolvente de operación, y quién firma un cambio que modifica el informe de seguridad del establecimiento. Dale dientes de verdad a «Requiere más trabajo» como respuesta: devuelve el cambio a «Documentar la base técnica» en lugar de concederse como una aprobación condicionada cuyas condiciones después no son de nadie.

5. Haz de la PSSR un recorrido de campo con la lista de acciones cerrada

   Una revisión previa al arranque que se puede completar sentado en una mesa no es una PSSR. La lista debe confirmar que lo construido coincide con el diseño, que los procedimientos de operación, mantenimiento y emergencia existen y están vigentes, que las personas que van a operar el cambio están formadas, y que las acciones del análisis de peligros están cerradas y no simplemente asignadas. Decide quién puede declarar que se supera, mantén a esa persona fuera del equipo que construyó el cambio, y enruta cualquier acción pendiente de vuelta por «Cerrar las acciones de la PSSR».

6. Pon dueño a cada fecha de caducidad, después recorre el diagrama y publícalo

   Dale a cada cambio temporal un propietario con nombre y una fecha que el registro avise antes de que llegue, no después. Acuerda después cuál es la vida máxima de un cambio temporal y si un cambio de emergencia vuelve a entrar en el proceso completo en días o en semanas. Por último, recorre el diagrama terminado con un turno de operación, un supervisor de mantenimiento, la autoridad técnica y quien autoriza los cambios, corrígelo hasta que refleje lo que realmente hacen, y publica esa revisión conservando las anteriores, para que cualquiera que lo abra más tarde sepa qué versión está leyendo.

Preguntas frecuentes

¿Cuáles son los pasos de un proceso de gestión del cambio (MOC)?

Proponer el cambio y anotarlo en el registro MOC; cribarlo con la prueba de sustitución idéntica, de modo que las sustituciones idénticas salgan como trabajo de mantenimiento; clasificar lo que queda como permanente, temporal o de emergencia, y dar a los temporales una fecha de caducidad y un plan de retirada; documentar la base técnica; hacer un análisis de peligros dimensionado al riesgo, desde una lista de comprobación del cambio hasta un what-if o un HAZOP completo; evaluar el impacto en los sistemas de seguridad, los límites de operación y el informe de seguridad, y registrar las acciones; autorizar al nivel que el peligro exija; actualizar procedimientos, planos y P&ID; formar a todo el personal afectado, incluidos mantenimiento y empresas contratistas; superar una revisión previa al arranque; implantar y poner en marcha; y cerrar conservando los registros o, si el cambio tiene plazo, revisarlo al vencimiento y convertirlo en permanente o retirarlo. La norma estadounidense de gestión de la seguridad de procesos (OSHA PSM) exige que el procedimiento escrito cubra la base técnica, el impacto sobre la seguridad y la salud, los cambios de procedimiento, el periodo de vigencia del cambio y los requisitos de autorización; este diagrama es esa lista convertida en una ruta con puertas.

¿Qué cuenta como sustitución idéntica?

Una sustitución idéntica es un elemento igual al que reemplaza en especificación, material, timbre o rango e intención de diseño: la misma pieza, según el mismo plano, instalada igual. Cualquier otra cosa es un cambio y entra en el proceso MOC, por pequeña o barata que parezca. La distinción importa porque es la única salida legítima del proceso, y es por donde más fugas tienen los sistemas de MOC. Ejemplos habituales que no son idénticos, los llame como los llame el almacén: una bomba con distinto diámetro de impulsor o distinta disposición del cierre, una junta en un material sustitutivo, una válvula con otro trim o con otra posición de fallo, una válvula de seguridad tarada a una presión nueva, un instrumento con otro rango u otro modo de fallo, y un cambio de versión de firmware o software en un controlador. Ayudan dos reglas prácticas: exigir que la determinación quede registrada con el nombre de la persona competente que la tomó, y auditar las decisiones de sustitución idéntica y no solo los cambios, porque los que nunca entraron en el proceso son los que nadie está mirando.

¿Qué es una revisión previa al arranque (PSSR) y cuándo hace falta?

Una revisión previa a la puesta en marcha, o PSSR por sus siglas en inglés, es la última comprobación antes de poner en servicio una instalación nueva o modificada. Confirma cuatro cosas: que lo construido y los equipos coinciden con la especificación de diseño, que los procedimientos de operación, mantenimiento y emergencia existen y son adecuados, que el análisis de peligros está terminado y sus recomendaciones resueltas o implantadas, y que todo el que vaya a operar o mantener el cambio está formado. La norma estadounidense OSHA PSM la exige para instalaciones nuevas y para instalaciones modificadas cuando la modificación fue lo bastante significativa como para requerir un cambio en la información de seguridad del proceso. En el marco Seveso no aparece con ese nombre, pero es la verificación equivalente y es lo que busca un inspector cuando revisa cómo se gestionó una modificación. Está dibujada como una decisión con bucle, y no como una casilla de firma, porque es la puerta sometida a más presión comercial: el cambio ya está montado, la parada ha terminado y la planta hace falta. En este diagrama, una revisión con acciones pendientes vuelve a «Cerrar las acciones de la PSSR» y se repite, de modo que la única forma de seguir es superándola.

¿Cuánto tiempo puede permanecer un cambio temporal?

Solo hasta la fecha de caducidad acordada cuando se autorizó, y por eso la fecha se fija en la clasificación en lugar de dejarla para decidirla más tarde. Muchos centros limitan los cambios temporales a la siguiente parada programada o a un periodo fijo, por ejemplo seis meses, y exigen que todo lo que sobreviva a ese límite se vuelva a autorizar como cambio permanente pasando por el proceso completo. El modo de fallo es conocido y siempre el mismo: se monta una modificación provisional bajo presión, la presión pasa, nadie es dueño de la retirada, los planos siguen mostrando la disposición original y, años después, alguien planifica un aislamiento a partir de un plano que ya no describe la planta. Dos cosas lo evitan. Que cada cambio temporal tenga un propietario con nombre y no un departamento, y que el registro levante la revisión antes de la fecha de caducidad en lugar de informar del incumplimiento después. En este diagrama, «¿Sigue siendo necesario al vencer el plazo?» tiene exactamente dos ramas: convertirlo en cambio permanente, o retirarlo y restituir la condición original. La prórroga silenciosa no es una de las opciones.

¿En qué se diferencia la gestión del cambio de la gestión de cambios de TI?

Comparten una palabra y casi nada más, y tratar una como sustituta de la otra es un peligro real. La gestión de cambios de TI, en el sentido ITIL que cubre el diagrama de /es/templates/proceso-de-gestion-de-cambios-itil, gobierna las modificaciones sobre un servicio en producción. Pregunta si el cambio provocará una indisponibilidad, si se puede revertir, cuándo es la ventana de cambio y si el CAB lo ha aprobado. La gestión del cambio en el sentido de seguridad de procesos gobierna las modificaciones de instalación, sustancias, límites de operación, sistemas de control, procedimientos y dotación de personal en un establecimiento que puede hacer daño a las personas. Pregunta si la modificación altera un peligro, si sigue siendo válido un caso de alivio o un enclavamiento, si el informe de seguridad sigue vigente y si los operadores están formados antes del arranque. Un CAB no tiene competencia para responder a ninguna de esas preguntas. Los dos procesos sí se solapan en un punto que conviene nombrar: un cambio en el sistema de control o en el sistema instrumentado de seguridad se suele abrir en una cola de cambios de TI o de automatización y además tiene que pasar por MOC. Cuando eso ocurra, haz que el MOC sea la autoridad y que el registro de TI sea el artefacto de planificación, y no al revés.