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.
¿Qué es plantilla de historial de revisiones de un SOP?
Un historial de revisiones es el registro que responde a una única pregunta sobre un SOP: qué cambió, cuándo, quién hizo el cambio, quién lo aprobó y qué versión sustituye la actual. Es un artefacto independiente del propio SOP: el procedimiento describe cómo se hace el trabajo hoy, el historial de revisiones es el registro de solo adición de cada versión que lo precedió. Los auditores y los nuevos propietarios de proceso leen primero el historial, porque es la forma más rápida de establecer si el procedimiento que tienen delante es la versión vigente y controlada o algo que un revisor olvidó actualizar.
Este diagrama modela el historial como un flujo de trabajo propio y no como una nota al pie de la aprobación del SOP. Un cambio propuesto se contrasta contra la criticidad de seguridad para decidir si pasa por revisión acelerada o estándar, y después se contrasta contra el propio historial: si ya hay otra entrada abierta para el mismo SOP, los dos cambios se coordinan para que el historial nunca tenga que conciliar dos entradas que reclaman el mismo número de versión. Solo después de eso la redacción produce la entrada real del historial (fecha, resumen del cambio, autor y el número de versión que sustituye), que es la razón por la que los pasos de redacción y finalización usan la forma Archivo en lugar de Proceso: son los momentos en los que algo se escribe en el registro, no solo se hace avanzar.
Esto no es el flujo de aprobación del propio documento SOP, que es la plantilla de SOP controlado en /es/templates/plantilla-sop-controlado: esa página encauza el contenido del procedimiento a través de la redacción, la revisión y la firma. Es el registro en el que ese flujo de trabajo escribe una entrada cada vez que produce una versión nueva. También es más estrecho que el control documental general, que rige la redacción, la emisión, la distribución y la revisión periódica de todo tipo de documento controlado en /es/templates/proceso-de-control-de-documentos; este diagrama cubre solo el historial en sí, el artefacto que indica qué cambió y qué versión sustituyó.
Qué cubre este diagrama de flujo
En esta plantilla
- Cinco fases en la parte superior (Cambio identificado, Entrada de historial redactada, Revisión, Aprobación e Historial finalizado) emparejadas con cinco carriles para los roles que intervienen en una entrada del historial de revisiones: Propietario del proceso, Autor del SOP, Revisor, Aprobador y Controlador de documentos.
- Entrada y enrutamiento: se identifica y describe un cambio, y a continuación la decisión «¿El cambio afecta a un paso crítico para la seguridad?» lo envía a revisión acelerada o estándar antes de que empiece la redacción.
- Una comprobación de entrada duplicada antes de redactar: «¿El historial de revisiones ya tiene una entrada pendiente para este SOP?» dirige a coordinarse con el propietario de la entrada abierta, de modo que dos cambios sobre el mismo SOP nunca se registran como dos revisiones que compiten entre sí.
- La propia entrada, redactada y más tarde finalizada con la forma Archivo en lugar de Proceso: fecha, resumen del cambio, autor y el número de versión que sustituye, enviada a revisión y después a aprobación.
- Un bucle de revisión: «¿Hay comentarios pendientes antes de la aprobación?» devuelve la entrada al autor del SOP para que la actualice y se revise de nuevo, en lugar de obligar al aprobador a rechazarla sin más.
- Aprobación y cierre: la decisión «¿Aprobado?» devuelve la entrada a retrabajo si se rechaza, o permite al controlador de documentos registrarla como definitiva, actualizar el número de versión y la fecha de entrada en vigor del SOP, y archivar la versión que sustituyó.
Cuándo usar esta plantilla
- Estás configurando un historial de revisiones para SOP y quieres una estructura que separe entrada, redacción, revisión, aprobación y finalización, en lugar de un único paso abierto de «añadir una fila».
- Dos personas pueden proponer cambios sobre el mismo SOP a la vez, y necesitas un punto de control que detecte una entrada duplicada antes de que llegue a aprobación como dos revisiones que compiten entre sí.
- Necesitas mostrarle a un auditor cómo llegó a existir una línea concreta del historial de revisiones: quién propuso el cambio, quién lo revisó, quién lo aprobó y qué versión sustituyó.
- Estás separando el historial de revisiones del propio flujo de aprobación del SOP, porque ese mismo historial tiene que registrar cambios propuestos sobre un SOP por más de un propietario a lo largo de su vida.
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.
