Cómo controlar versiones de un SOP
El control de versiones de un SOP significa numerar cada revisión, enrutar los cambios críticos para la seguridad por un reciclaje práctico y una lista de verificación firmada en vez de leído y confirmado, y retirar la copia sustituida.
El control de versiones de un SOP es la disciplina que ata cada revisión del procedimiento a un número, un registro de aprobación y un requisito de reciclaje, de modo que ningún operario ejecute nunca un paso crítico para la seguridad contra una copia sustituida.
En resumen
- Numera cada revisión del SOP e imprímela en cada página: el número es lo que un registro de formación y una pista de auditoría señalan los dos.
- Enruta los cambios críticos para la seguridad por una evaluación documentada de impacto en seguridad y un reciclaje práctico, no por leído y confirmado.
- Una lista de verificación de competencia firmada es evidencia de reciclaje; un acuse de recibo de lectura solo es evidencia de que alguien abrió el archivo.
- Las dos rutas de revisión (crítica para la seguridad y estándar) convergen igualmente en un paso: marcar la revisión anterior como sustituida.
- El registro de cambios y la vista de comparar versiones de QueryChart (/features/version-control) muestran quién cambió qué campo, sin un registro aparte.
Un SOP desactualizado no es un problema de archivo
Un SOP no es un registro de lo que debería pasar en general: es la secuencia exacta que alguien en su turno ahora mismo está siguiendo, y por eso el control de versiones de un SOP tiene en juego algo que una política o una plantilla de hoja de cálculo no tienen. Una revisión desactualizada de un informe de marketing le cuesta a alguien una tarde de retrabajo. Una revisión desactualizada de un procedimiento de bloqueo y etiquetado o de una lista de verificación de liberación de lote le cuesta a alguien una mano, o expide un lote no conforme, porque un operario que hace exactamente lo que dice el papel en la pared está haciendo exactamente lo que el proceso le pidió, incluso cuando el papel va dos revisiones por detrás.
El control de versiones genérico de documentos, cubierto en /es/guides/como-controlar-versiones-de-un-documento, pregunta qué archivo está vigente y quién lo aprobó. El control de versiones de un SOP añade una pregunta más para cada cambio: quién tiene que reciclarse antes de ejecutar el paso de otro modo, y cómo lo demuestras. Un número que sube en un registro no impide que un operario siga el método antiguo; solo lo impide un registro de formación completado, fechado y firmado, ligado al nuevo número de revisión, y por eso el flujo de aprobación de un SOP controlado (ver /es/templates/plantilla-sop-controlado) tiene que entregarse a un paso de reciclaje en lugar de detenerse en «aprobado».
El diagrama de abajo se bifurca justo en ese juicio («¿Se ve afectado un paso crítico para la seguridad?») porque las dos respuestas exigen evidencias distintas. Un cambio crítico para la seguridad pasa por una evaluación documentada de impacto en seguridad, una aprobación con puerta de calidad y un reciclaje práctico con lista de verificación de competencia firmada; un cambio no crítico recibe una revisión de idoneidad estándar y leído y confirmado. Colapsar las dos rutas en una, o tratar un acuse de recibo de lectura como prueba de competencia en un paso crítico para la seguridad, es el hallazgo de auditoría que este proceso existe para prevenir. El propio historial de versiones de QueryChart (ver /features/version-control) le da a un equipo de calidad un registro de cambios y una vista de comparar versiones para comprobar que cada revisión siguió en verdad esta ruta, sin un registro paralelo en hoja de cálculo que se desincronice de lo que dice el diagrama.
La bifurcación crítica para la seguridad, etapa por etapa
Un cambio de SOP que pasa de la solicitud a la decisión que lo envía o bien a una revisión de seguridad y reciclaje práctico, o bien a una revisión estándar y un acuse de recibo de lectura.
Una solicitud registrada contra una revisión
«Se propone un cambio de SOP» inicia la cadena, y después «Enviar solicitud de cambio con motivo» y «Registrar la solicitud contra la revisión vigente del SOP» atan la solicitud a una versión concreta antes de que empiece «Evaluar el impacto operativo del cambio propuesto»: nada aquí ha juzgado todavía el cambio, solo ha registrado qué es y qué sustituye.
La bifurcación que decide cuánta exigencia hay
«¿Se ve afectado un paso crítico para la seguridad?» bifurca el proceso: un Sí enruta hacia «Realizar una evaluación documentada de impacto en seguridad» y después «Enviar el paquete de cambio a aprobación con puerta de calidad», con una segunda decisión «¿Aprobado?» que rechaza directamente de vuelta a la evaluación de seguridad en lugar de sobrepasarla.
Reciclaje práctico frente a revisión estándar
Los cambios críticos para la seguridad aprobados pasan a «Programar el reciclaje práctico obligatorio» y «Completar la formación práctica y firmar la lista de verificación de competencia» (un ensayo supervisado y firmado, no un acuse de recibo de lectura) mientras que la rama No ejecuta «Completar la revisión de idoneidad estándar» hacia su propia «Enviar el paquete de cambio a aprobación» y la puerta «¿Aprobado?».
Ambas rutas convergen en una actualización de registro
La ruta estándar sigue terminando en «Distribuir el SOP actualizado para lectura y confirmación» y «Leer y confirmar la nueva versión», y las dos rutas se encuentran en «Actualizar el registro del SOP y marcar la revisión anterior como sustituida» antes de que «Publicar la nueva revisión como la versión controlada vigente» la ponga en vigor.
Cómo funciona
Fija el esquema de numeración del SOP antes de la primera revisión
Asigna a cada SOP un identificador y una revisión con número entero, impresos en el encabezado de cada página junto con la fecha de vigencia y el aprobador. Decide esto una sola vez, porque renumerar más adelante rompe todos los registros de formación y toda pista de auditoría que citara el número antiguo.
Registra la solicitud contra la revisión que cambia
Abre una solicitud con el paso exacto que cambia y el motivo (un incidente, un casi accidente, una desviación) antes de que nadie toque el borrador. Tecléalo en la columna «Box text» de un diagrama y usa «Line to» para apuntarla a la fila que registra la solicitud contra la revisión vigente, de modo que la solicitud quede atada a una versión en vez de flotar suelta.
Fuerza explícitamente la decisión crítica para la seguridad
Dale al flujo una fila de tipo Decision que pregunte si se ve afectado un paso crítico para la seguridad, con dos ramas etiquetadas en la columna «Line text». Enruta el «Sí» hacia una evaluación documentada de impacto en seguridad y el «No» hacia una revisión de idoneidad estándar. Nunca dejes que un solicitante o un aprobador se salte la pregunta por dar algo por hecho.
Condiciona la ruta crítica para la seguridad al reciclaje práctico, no al acuse de recibo
Tras la aprobación, programa la formación práctica obligatoria y exige una lista de verificación de competencia firmada antes de que el cambio pueda entrar en vigor. Una fila que solo diga «leer y confirmar» pertenece a la ruta estándar, no a la crítica para la seguridad. Mantén las dos como filas separadas para que la distinción sobreviva a una reordenación posterior.
Converge ambas rutas en una actualización de registro
Sea cual sea la rama que tomó un cambio, enrútalo hacia una única fila de tipo File que actualice el registro del SOP y marque la revisión anterior como sustituida, antes de publicar la nueva como vigente. Un único punto de convergencia significa un único sitio donde comprobar que todas las rutas llegan de verdad a la retirada de la copia antigua.
Confirma a todos los operarios afectados, no solo a los del turno de siempre
Antes de publicar, marca reciclaje o acuse de recibo contra cada turno y cada contratista al que afecta el paso, no solo el equipo que estaba en planta cuando se aprobó el cambio. Un turno de noche pasado por alto es el hallazgo que se repite en cada ciclo de auditoría.
Errores que debes evitar
Leído y confirmado en un paso crítico para la seguridad
Un acuse de recibo de lectura demuestra que alguien abrió el archivo, no que pueda ejecutar el paso con seguridad. Enruta cualquier cambio a un paso crítico para la seguridad por un reciclaje práctico y una lista de verificación de competencia firmada, como en «Completar la formación práctica y firmar la lista de verificación de competencia».
Un cambio rechazado reentra en la revisión, no solo en el borrador
Es tentador enlazar «¿Aprobado?» de vuelta directamente al paso de solicitud para que un cambio rechazado se pueda redactar de nuevo y reenviar. En la ruta crítica para la seguridad, enruta el rechazo de vuelta a «Realizar una evaluación documentada de impacto en seguridad» en su lugar (exactamente como hace este diagrama) para que un borrador revisado se vuelva a evaluar en materia de seguridad, no solo se reteclee y reenvíe.
Una entrada de registro que no nombra el turno
«Actualizar el registro del SOP y marcar la revisión anterior como sustituida» solo es cierto una vez que cada turno y contratista afectado se ha reciclado o ha confirmado, no en cuanto lo ha hecho el turno de día. Nombra la población a la que llega el paso, o un equipo de noche sigue usando la versión retirada.
Crea tu propio proceso de control de cambios de SOP
Abre el ejemplo de control de cambios de SOP como diagrama propio, fija tu esquema de numeración y mantén intacta la bifurcación crítica para la seguridad para que el reciclaje siga siendo obligatorio y no opcional.
Guías relacionadas
Preguntas frecuentes
¿Es el control de versiones de un SOP distinto del control de versiones genérico de documentos?
Sí, en un aspecto concreto: el control de versiones de un SOP tiene que responder quién necesita reciclarse antes de que la nueva revisión entre en vigor, no solo qué copia está vigente. El control de versiones genérico de documentos (cubierto en /es/guides/como-controlar-versiones-de-un-documento) gobierna la numeración, la aprobación y la retirada de cualquier documento controlado. Un SOP añade debajo de eso una pregunta de competencia: un número de revisión que sube no impide que un operario siga el método antiguo hasta que se ha reciclado en el nuevo, así que el registro de control de versiones de un SOP tiene que llevar un estado de formación o de acuse de recibo junto al rastro habitual de aprobación.
¿Cómo debería enrutarse de forma distinta un cambio crítico para la seguridad en un SOP frente a uno menor?
Un cambio crítico para la seguridad (uno en el que hacer mal el paso arriesga una lesión, un producto no conforme o un incumplimiento normativo) necesita una evaluación documentada de impacto en seguridad, una aprobación con puerta de calidad y un reciclaje práctico con lista de verificación de competencia firmada antes de poder entrar en vigor. Un cambio no crítico para la seguridad puede pasar por una revisión de idoneidad estándar, una aprobación ordinaria y leído y confirmado. Enrutar ambos por la misma vía ligera es cómo un ajuste de redacción y un cambio a un paso de bloqueo acaban sujetos al mismo nivel de evidencia, que es demasiado poco para uno y demasiado para el otro.
¿Es un registro de formación lo mismo que el control de versiones de un SOP?
No: responden a preguntas distintas y un proceso de SOP necesita ambos. El control de versiones rastrea qué revisión está vigente, quién la aprobó y qué sustituyó; un registro de formación rastrea quién ha demostrado competencia en esa revisión. El historial de versiones de QueryChart en /features/version-control cubre lo primero: un registro de cambios con diferencias por campo, una vista de comparar versiones y restauración. La lista de verificación de competencia firmada que exige un cambio crítico para la seguridad, descrita arriba, cubre lo segundo, y las dos tienen que referenciar el mismo número de revisión o un auditor no podrá saber si la persona formada corresponde al procedimiento en vigor.
¿Cuál es la evidencia mínima que espera un auditor para una revisión de SOP?
Un número de revisión y una fecha de vigencia impresos en el documento, un registro de quién lo aprobó y cuándo, un motivo del cambio documentado y atado a la solicitud que lo inició, y (para cualquier cosa crítica para la seguridad) un registro de competencia fechado y firmado que nombre a quién se recicló y en qué versión. Para la mecánica de enrutamiento y aprobación del propio documento SOP, ver la plantilla de SOP controlado en /es/templates/plantilla-sop-controlado; para la pregunta más estrecha de qué cambió entre dos revisiones, ver /es/guides/como-registrar-cambios-en-un-sop.
