Plantilla de historial de revisiones de un SOP
Una plantilla de historial de revisiones de un SOP: cómo un cambio propuesto se convierte en una entrada fechada, se contrasta con los cambios pendientes, se revisa, se aprueba y se finaliza con la versión que sustituye.
Cómo funciona
Renombra los carriles con tus roles reales
Sustituye Propietario del proceso, Autor del SOP, Revisor, Aprobador y Controlador de documentos por los títulos que realmente usas. En un equipo pequeño, el autor del SOP y el propietario del proceso suelen ser la misma persona: fusiona esos carriles en lugar de mantener uno vacío; si un responsable de calidad hace tanto la revisión como la firma, fusiona en su lugar Revisor y Aprobador.
Fija el criterio de criticidad de seguridad
Deja por escrito qué dirige un cambio a revisión acelerada en lugar de dejar «¿El cambio afecta a un paso crítico para la seguridad?» al criterio individual: un cambio en un paso de bloqueo, en un punto de control crítico o en una comprobación exigida por la normativa debería calificar siempre, y todo lo demás va por defecto al ciclo estándar.
Fija los campos que debe llevar cada entrada del historial
En el paso de redacción, fija los campos exactos que necesita tu registro: fecha de la entrada, número de SOP, un resumen del cambio en lenguaje sencillo, autor y el número de versión que se sustituye. Mantén los mismos campos para las entradas aceleradas y las estándar, de modo que el historial siga siendo coherente sea cual sea la vía que produjo cada entrada.
Decide cómo se resuelve una entrada duplicada
Fija la regla que hay detrás de «¿El historial de revisiones ya tiene una entrada pendiente para este SOP?»: ¿el segundo cambio espera a que se cierre el primero, se fusiona en la misma entrada, o se registra por separado con una nota que remite a la otra? Cualquiera de las tres opciones funciona mientras el historial no acabe con dos entradas que reclaman el mismo número de versión.
Fija tu regla de numeración de versiones y de fecha de vigencia
Fija cómo se incrementan los números de versión (lo habitual es número entero para las revisiones emitidas y decimal para los borradores) y cuánta antelación necesita la fecha de vigencia para que el controlador de documentos pueda actualizar el registro maestro y retirar la copia sustituida antes de que entre en vigor.
Preguntas frecuentes
¿Qué es el historial de revisiones de un SOP?
Es el registro fechado que enumera todas las versiones de un SOP y qué cambió entre ellas: la fecha de la entrada, quién propuso el cambio, un resumen de qué cambió, quién lo revisó y lo aprobó, y el número de versión que sustituyó. Es independiente de la propia firma de aprobación del SOP: el SOP registra quién aprobó la versión vigente, el historial de revisiones registra la secuencia de versiones que llevaron hasta ella.
¿En qué se diferencia esto del propio flujo de aprobación del SOP?
La plantilla de SOP controlado en /es/templates/plantilla-sop-controlado encauza el propio contenido del procedimiento a través de la redacción, la revisión y la aprobación, y produce una única versión vigente y firmada. Este diagrama es el registro en el que ese flujo de trabajo escribe cada vez que produce una versión nueva: el historial de solo adición de fechas, autores, resúmenes y números de versión sustituidos, conservado como un artefacto propio para que la secuencia sobreviva con independencia del documento.
¿Por qué comprobar si hay una entrada pendiente antes de redactar una nueva?
Porque dos personas pueden proponer cambios sobre el mismo SOP dentro del mismo ciclo de revisión sin saber la una de la otra, y si las dos entradas llegan a aprobación de forma independiente, el historial acaba con dos filas que reclaman sustituir la misma versión. Comprobarlo al principio, antes de redactar, hace que el segundo cambio se coordine dentro de la primera entrada en lugar de descubrirse como un conflicto durante la aprobación.
¿Todo cambio de un SOP tiene que pasar por la vía acelerada?
No. La vía acelerada existe para cambios en pasos críticos para la seguridad, donde el intervalo entre identificar el cambio y su entrada en vigor tiene que ser corto. Todo lo demás (aclaraciones, formato, cambios de procedimiento no críticos) debería pasar por el ciclo de revisión estándar, porque enrutar todo como acelerado anula el sentido de tener dos vías.