Cómo registrar cambios en un SOP
Cómo registrar cambios en un SOP: qué tiene que anotar una entrada de historial de revisiones (qué cambió, quién lo cambió, cuándo, por qué y qué versión sustituye), más la bifurcación de vía rápida para lo crítico en seguridad.
Registrar cambios en un SOP significa anotar una entrada fechada en el historial de revisiones (qué cambió, quién lo cambió, cuándo, por qué y qué versión sustituye) en lugar de confiar en control de cambios en línea.
En resumen
- Una entrada de historial de revisiones necesita cinco campos: el SOP/paso afectado, qué cambió y por qué, la fecha de vigencia, el autor y la versión que sustituye.
- Los pasos críticos para la seguridad toman una vía de revisión acelerada; todo lo demás toma el ciclo de revisión estándar.
- Comprueba el registro por si hay una entrada pendiente contra el mismo SOP antes de redactar una nueva: dos entradas abiertas producen dos números de versión que compiten.
- Finalizar una entrada bloquea su fecha, aprobador y números de versión para que el registro no pueda reescribirse en silencio después.
- Para un SOP basado en un diagrama, el registro de cambios de QueryChart anota automáticamente cada edición a nivel de campo (ver /features/version-control).
El registro es una entrada, no un marcado de cambios
«Control de cambios» es lenguaje de Word y Google Docs: una burbuja de comentario y un tachado que viven dentro del propio archivo. Un SOP que toma prestada la frase pero no el mecanismo acaba con su historial de cambios repartido entre hilos de correo y copias con marcas de cambio que nadie fusionó, y un responsable del procedimiento incapaz de decir con certeza qué cambió en la última revisión, cuándo o por qué. Registrar un cambio en un SOP significa algo más estrecho y más duradero: una entrada fechada en un registro de historial de revisiones que anota qué cambió, quién lo cambió, cuándo, por qué y qué versión sustituye.
Cada entrada necesita los mismos campos con independencia de quién la escriba o qué haya cambiado: el SOP y el paso afectados, una descripción en lenguaje sencillo del cambio y el motivo, la fecha de vigencia, el autor y el número exacto de versión que la entrada sustituye (el campo que más registros omiten). Un cambio a un paso crítico para la seguridad se gana una vía de revisión acelerada en lugar de esperar detrás de la cola habitual, y antes de empezar a redactar se comprueba el propio registro: ¿hay ya una entrada pendiente abierta contra este mismo SOP? Dos entradas abiertas contra un procedimiento producen dos números de versión candidatos, que es un problema que el registro tiene que resolver antes de que nadie pueda confiar en él.
Un SOP basado en un diagrama construido en QueryChart no necesita un registro llevado a mano para los campos que un historial de revisiones existe para capturar. Cada edición del diagrama ya queda registrada automáticamente, campo a campo, en su panel de historial de versiones: ábrelo y una vista de comparar versiones muestra exactamente qué cambió entre dos versiones guardadas cualesquiera y quién lo cambió, y un clic restaura una anterior sin perder lo que vino después. La entrada manual de abajo sigue importando cuando el contenido del SOP vive fuera del diagrama, o cuando una norma nombra un historial de revisiones como su propio artefacto; ver /features/version-control para lo que hace la versión integrada por debajo sin que nadie la mantenga a mano.
Un cambio propuesto, registrado hasta una entrada finalizada
Un único cambio propuesto a un SOP, registrado fila a fila desde el momento en que se identifica hasta la entrada finalizada del registro que nombra la versión que sustituye.
Lo que se registra, antes que nada
El diagrama empieza en «Se identifica un cambio en un SOP», y después «Describir el cambio propuesto y su motivo» (el SOP, el paso, qué está cambiando, por qué y la fecha de vigencia) antes de que «¿El cambio afecta a un paso crítico para la seguridad?» decida qué vía de revisión toma la entrada.
La bifurcación de vía rápida y la comprobación de duplicados
Un cambio crítico para la seguridad queda «marcado para revisión acelerada» mientras que todo lo demás se «encauza por el ciclo de revisión estándar»; ambos llegan después a «¿El historial de revisiones ya tiene una entrada pendiente para este SOP?» antes de que se redacte «Redactar la entrada del historial: fecha, resumen del cambio, autor, versión sustituida» como una fila de tipo File.
Dos comprobaciones antes de que una entrada sea de fiar
«El revisor contrasta la entrada con el contenido vigente del SOP» va primero; «¿Hay comentarios pendientes antes de la aprobación?» devuelve una entrada sin resolver al autor del SOP para una nueva revisión, y solo entonces la contrasta el aprobador contra «el maestro del SOP y la versión que sustituye».
Finalizada, y después se cierra la versión antigua
«Registrar la entrada aprobada como definitiva en el historial de revisiones» bloquea la fecha, el aprobador y los números de versión antes de que se actualicen el propio número de versión y la fecha de vigencia del SOP, y «Retirar o archivar la versión indicada como sustituida» cierra la entrada que reemplazó la nueva.
Cómo funciona
Registra los cinco campos en cada entrada
Anota el SOP y el paso afectados, qué cambió y por qué, la fecha de vigencia, el autor y el número exacto de versión que sustituye esta entrada. Una entrada sin la versión sustituida deja un hueco en el registro que nadie puede cerrar después.
Enruta los cambios críticos para la seguridad por la vía rápida
Pregunta si el cambio toca un paso crítico para la seguridad antes de que llegue a revisión. Si es así, márcalo para revisión acelerada en lugar de dejarlo en cola detrás de los cambios rutinarios; si no lo es, envíalo por el ciclo de revisión estándar.
Comprueba si hay una entrada pendiente antes de redactar
Busca en el registro una entrada ya abierta contra el mismo SOP antes de empezar una nueva. Dos entradas abiertas contra un procedimiento producen dos números de versión candidatos: coordínate con el otro autor o secuencia los cambios en lugar de redactar en paralelo.
Bloquea la entrada una vez aprobada
Registra la entrada aprobada como definitiva, y después actualiza el número de versión y la fecha de vigencia del SOP y retira la versión que sustituye. Una entrada que sigue siendo editable después de la aprobación no es un registro, es un borrador con el nombre de un aprobador encima.
Deja que el registro de cambios haga el registro por ti en un SOP basado en diagrama
Si el propio SOP es un diagrama de flujo de QueryChart, sáltate el registro manual para todo lo capturado en el diagrama: cada edición ya se rastrea campo a campo. Abre el historial de versiones, usa Comparar versiones para ver qué cambió entre dos versiones guardadas y restaura una anterior con un clic (ver /features/version-control).
Errores que debes evitar
La entrada sin versión sustituida
Una entrada de historial de revisiones que registra qué cambió pero no qué versión sustituyó no se puede reconstruir en una línea temporal después. Haz de la versión sustituida un campo obligatorio antes de empezar a redactar, no una nota opcional.
Dos entradas abiertas para un SOP
Dos autores que abren entradas de historial de revisiones para el mismo SOP en la misma semana producen dos números de versión que compiten. Comprueba si hay una entrada pendiente antes de redactar, y coordínate en lugar de reconciliar la colisión después de que ambas se aprueben.
Marcas de cambio en lugar de un registro
Los archivos con control de cambios que se pasan por correo dispersan la secuencia real de quién-cambió-qué-cuándo entre bandejas de entrada. Una entrada de registro fechada, o el propio registro de cambios de un diagrama, es un registro; un adjunto con marcas de cambio olvidado en una bandeja de entrada no lo es.
Confundir una entrada con todo el programa
Acertar con una única entrada no arregla un esquema de numeración que deriva ni un intervalo de revisión que nadie rastrea: esa es la capa de gobierno de /es/guides/como-gestionar-las-revisiones-de-un-sop. Esta página trata de una entrada; esa otra trata del ritmo a través de todas ellas.
Construye el historial de revisiones de tu SOP
Toma el historial de revisiones como diagrama propio, fija los campos que registran tus entradas, y deja que el historial de versiones rastree cada edición automáticamente a partir de ahora.
Guías relacionadas
Preguntas frecuentes
¿Es «control de cambios» lo mismo que control de versiones para un SOP?
No exactamente. «Control de cambios» es lenguaje de editor de documentos para marcas de cambio y comentarios en línea dentro de un archivo. El control de versiones de un SOP es la práctica de dar a cada estado aprobado del procedimiento su propia versión identificada y mantener un registro de qué cambió entre ellas; una entrada de historial de revisiones es cómo se anota ese registro. Ver /es/guides/como-controlar-versiones-de-un-sop para la distinción completa.
¿Qué tiene que registrar una entrada de historial de revisiones?
Cinco cosas con independencia de quién la escriba: el SOP y el paso afectados, una descripción en lenguaje sencillo del cambio y su motivo, la fecha de vigencia, el autor y el número exacto de versión que sustituye la entrada. Omitir la versión sustituida es el hueco más habitual en un historial de revisiones.
¿Pasan todos los cambios de SOP por la misma revisión?
No. Un cambio a un paso crítico para la seguridad toma una vía de revisión acelerada en lugar de hacer cola detrás de los cambios rutinarios, mientras que todo lo demás pasa por el ciclo estándar. Las dos vías convergen en la misma comprobación de duplicados antes de redactar: ¿hay ya una entrada pendiente abierta contra este SOP?
¿En qué se diferencia esto de gestionar las revisiones de un SOP en general?
Esta página trata de la mecánica de una entrada: los campos que necesita, la bifurcación de revisión, la comprobación de duplicados. El esquema de numeración, el intervalo de revisión y quién es responsable del calendario en todos los SOP es la capa de gobierno, cubierta en /es/guides/como-gestionar-las-revisiones-de-un-sop.
¿Sustituye QueryChart al registro manual?
Para un SOP basado en un diagrama, sí en todo lo capturado en el propio diagrama: cada edición a nivel de campo se registra automáticamente en el historial de versiones, con una vista de comparar versiones y restauración en un clic (ver /features/version-control). Un registro manual sigue mereciendo la pena donde el contenido del SOP vive fuera del diagrama, o donde una norma nombra un historial de revisiones como su propio artefacto, como el ciclo de vida más completo en /es/templates/plantilla-sop-controlado.
