Cómo crear un historial de revisiones de un documento
Cómo construir un historial de revisiones: las columnas que necesita, por qué el registro es un artefacto separado y de solo añadido respecto al documento que describe, y el paso de verificación que casi toda tabla se salta.
Un historial de revisiones de un documento es el artefacto (una tabla de versión, fecha, autor, descripción y verificador) que produce y mantiene exacto una práctica de control de versiones.
En resumen
- El historial de revisiones es el artefacto (una tabla); el control de versiones es la práctica que lo mantiene exacto.
- Columnas mínimas: versión, fecha, autor, descripción, referencia a la versión anterior, verificado por.
- Solo añadido: corrige una entrada equivocada con una fila nueva, nunca editando la antigua.
- Una entrada que nadie comprobó contra la edición real es una afirmación, no un registro.
- QueryChart genera esto automáticamente mediante su registro de cambios. Ver /features/version-control.
La tabla es un registro, no la disciplina
Un historial de revisiones es la tabla que la mayoría de lectores se imagina de inmediato: un número de versión, una fecha, el nombre de quien hizo el cambio, una breve descripción de qué cambió y a menudo el nombre de quien lo revisó. Es un artefacto: filas en una tabla, normalmente en la propia portada del documento. El control de versiones es la cosa distinta que produce esas filas: la práctica de no editar nunca un documento controlado sin escribir una, no reescribir nunca una entrada después de los hechos, y hacer que alguien distinto de quien edita compruebe la entrada contra la edición. Un documento puede llevar un historial de revisiones de aspecto completo y no tener ningún control de versiones real detrás, si nadie ha comprobado jamás una sola fila contra lo que realmente cambió.
Trata el historial de revisiones como un objeto separado del documento que describe, no como una sección dentro de él. El documento cambia; el registro solo puede crecer. Cada entrada necesita un número de versión, una fecha, un autor, una descripción sencilla de qué cambió y por qué, una referencia a la versión que sustituye y (la columna que más tablas hechas a mano omiten) quién verificó la entrada contra la edición real. Salta esa última columna y el registro es un conjunto de afirmaciones sin verificar: el relato de un autor sobre su propio cambio, archivado por la misma persona que lo hizo.
El diagrama de abajo recorre un proceso genérico de entrada de registro de revisiones (dieciséis filas en cinco carriles) donde lo que se mueve por el proceso es la propia entrada del registro, no el documento. Una solicitud abre una entrada pendiente, un autor implementa el cambio y archiva una descripción de antes y después, un revisor compara esa descripción contra la edición real antes de cerrar nada, y un auditor muestrea entradas cerradas más tarde. Ese paso de comparación es lo que casi nunca tiene una hoja de cálculo hecha a mano, porque no hay nadie cuyo trabajo sea explícitamente ejecutarlo. QueryChart sustituye por completo la tabla hecha a mano: cada edición de un diagrama queda capturada en un registro de cambios con valores de antes y después por campo y el nombre de quien edita, visible en una pantalla de comparar versiones, en /features/version-control. Nadie tiene que teclear la entrada, porque es el registro de lo que realmente se editó, no un autoinforme.
Dieciséis filas, cinco carriles, una entrada de registro
Observa una única entrada de registro de revisiones moverse desde la solicitud hasta un cierre verificado y muestreado por auditoría: las columnas que una tabla hecha a mano suele saltarse, dispuestas como un proceso.
Una solicitud, todavía no una entrada
La fila de inicio es «Se solicita un cambio sobre un documento controlado» (un suceso, no una tarea) seguida de «Enviar la solicitud de cambio con el motivo y el documento objetivo», que nombra el documento exacto y el motivo antes de que se registre nada. «¿Cambio aprobado para registro?» decide si llega a abrirse siquiera una entrada pendiente.
La entrada se abre antes que la edición
Solo tras la aprobación aparece «Abrir una entrada de registro pendiente», como una fila de tipo File y no como una nota en la bandeja de entrada de alguien. «Asignar número de entrada y vincular el documento» y «Asignar el cambio a un autor» ocurren las dos en el carril del Propietario del registro, antes de que empiece el carril del Autor: la entrada existe como registro antes de que cambie una sola palabra del documento.
Verificación, no solo una descripción
«Implementar el cambio en el documento» traslada el trabajo al carril del Autor, y «Registrar descripción de antes y después, autor y fecha» se archiva como su propia fila en lugar de fundirse con la edición. «Comparar la entrada del registro con el cambio implementado» y «¿Verificado contra el documento?» exigen entonces que el Revisor contraste las palabras de la entrada con la edición real antes de que nadie confíe en ninguna de las dos.
Un desajuste, y después el cierre y la auditoría
«¿Discrepancia en el documento o en la entrada del registro?» devuelve una comprobación fallida a «Implementar el cambio en el documento» o a «Registrar descripción de antes y después, autor y fecha», la que estuviera mal. Una entrada verificada llega a «Cerrar la entrada del registro», «Notificar al solicitante que el cambio está completo» y «Muestrear entradas cerradas en auditoría periódica» antes del Fin, «Entrada del registro cerrada y lista para auditoría», con «Solicitud rechazada, sin registrar» como la otra salida, de vuelta arriba.
Cómo funciona
Separa el registro del documento
Pon el historial de revisiones en su propio artefacto (una tabla en la portada o un registro independiente), nunca como un párrafo enterrado en el cuerpo. El documento cambia; el registro es el único de los dos al que se le permite solo crecer.
Fija las columnas antes de la primera entrada
Número de versión, fecha, autor, una descripción sencilla de qué cambió y por qué, una referencia a la versión que sustituye, y quién verificó la entrada. Omite cualquiera de las dos últimas y no hay forma de distinguir un registro comprobado de un autoinforme.
Abre la entrada antes de la edición, no después
Registra una entrada pendiente (número, enlace al documento, autor asignado) en el momento en que se aprueba un cambio, antes de que nadie abra el archivo. Una entrada escrita después de los hechos se reconstruye de memoria, que es justo el modo de fallo que un registro existe para prevenir.
Anota qué cambió, no que algo cambió
«Se actualizó la sección 4» no es una descripción; «se cambió el umbral de aprobación de 500 $ a 2.000 $ en la sección 4» sí lo es. Registra el antes y el después en términos sencillos, el nombre del autor y la fecha, para que un lector pueda reconstruir el cambio sin abrir el propio historial de versiones del documento.
Verifica la entrada contra la edición real
Haz que alguien distinto del autor compare la descripción registrada con lo que realmente cambió en el documento antes de cerrar la entrada. Si no coinciden, averigua si el documento o la entrada están equivocados: corregir la entrada no siempre es un retroceso para el autor.
Muestrea entradas cerradas, no revises todas
Construye una auditoría periódica que compruebe una muestra de entradas cerradas contra sus documentos, en un calendario que pertenezca al programa de auditoría en lugar de a una comprobación improvisada. Esto es lo que hace que el registro sea algo en lo que puedes confiar sin volver a verificarlo tú mismo.
Errores que debes evitar
El registro como prueba de memoria
Escribir la entrada días después de la edición convierte un registro en una reconstrucción. Abre la entrada pendiente cuando se aprueba el cambio, y archiva la descripción de antes y después el mismo día en que se hace la edición, no a partir de lo que alguien recuerde semanas después.
Editar el historial en el sitio
Corregir la fila tres de una hoja de cálculo para arreglar una descripción equivocada destruye lo mismo para lo que existe un historial de revisiones: la prueba de qué se registró y cuándo. Añade una fila nueva en su lugar; /es/guides/como-registrar-cambios-en-un-sop y /es/guides/como-gestionar-las-revisiones-de-un-sop cubren esta disciplina de solo añadido específicamente para SOP.
Un registro que nadie contrasta con el documento
Una tabla con columnas de Versión y Descripción pero sin paso de verificación es un conjunto de afirmaciones, no un registro. Dale a la comparación su propia fila con su propio responsable, como hace «Comparar la entrada del registro con el cambio implementado» en el diagrama de arriba, o el registro solo es tan fiable como la memoria del autor.
Confundir el registro con el proceso que lo produce
Un historial de revisiones registra qué cambió; no decide quién puede aprobar un cambio ni dónde viven las copias sustituidas: eso es control documental, cubierto por completo en /es/templates/proceso-de-control-de-documentos. Construye los dos, pero mantenlos como artefactos separados.
Construye tu propio registro de revisiones
Abre el diagrama de entrada de registro de revisiones como plantilla propia, pon tus propios tipos de documento en los carriles, y deja que el registro de cambios de QueryChart mantenga el historial verificado en lugar de una hoja de cálculo.
Guías relacionadas
Preguntas frecuentes
¿Cuál es la diferencia entre un historial de revisiones y el control de versiones?
Un historial de revisiones es el artefacto: la tabla de versión, fecha, autor, descripción y verificador. El control de versiones es la práctica que mantiene honesta esa tabla: la regla de que nada se edita sin una entrada, de que las entradas nunca se reescriben después de los hechos, y de que alguien distinto del autor comprueba una contra la otra. Puedes tener un historial de revisiones con un control de versiones débil detrás: la tabla existe, pero nadie verifica jamás una fila contra la edición real.
¿Qué columnas necesita una tabla de historial de revisiones?
Número de versión, fecha, autor, una descripción sencilla de qué cambió y por qué, una referencia a la versión que sustituye y (la que más tablas hechas a mano se saltan) quién verificó la entrada contra la edición real. Una fila sin la última columna es el autoinforme de un autor, no un registro comprobado.
¿Debería editarse un historial de revisiones para corregir un error en una entrada antigua?
No. Añade una fila nueva que corrija el registro en lugar de reescribir la antigua; el registro solo es tan fiable como esté intacto su historial de solo añadido. Si lo equivocado fue el documento y no la entrada, la corrección pertenece a una nueva revisión del documento, no a una fila de registro reescrita.
¿Basta una hoja de cálculo llevada a mano para un historial de revisiones, o hace falta software?
Una hoja de cálculo funciona hasta que alguien edita una fila en lugar de añadir una, lo cual es difícil de prevenir y fácil de pasar por alto. El historial de versiones de QueryChart escribe automáticamente el registro equivalente: un registro de cambios con valores de antes y después por campo y el nombre de quien edita en cada revisión, visible en una pantalla de comparar versiones y restaurable en cualquier punto, en /features/version-control. El diagrama de arriba muestra la versión manual de la misma disciplina (una solicitud, una descripción archivada, un paso de verificación) sea cual sea la herramienta que la ejecute.
