Control de versiones frente a gestión documental

En resumen

• La gestión documental es la disciplina; el control de versiones es un mecanismo dentro de ella, no un sistema rival que elegir en su lugar.
• El control de versiones responde a «qué revisión es esta, y qué cambió». La gestión documental también responde a quién puede verla, dónde vive y cuándo le toca revisión.
• Una instalación de gestión documental típicamente envuelve control de acceso, metadatos y clasificación, calendarios de retención y enrutamiento de flujos de trabajo alrededor de un historial de versiones.
• El historial de versiones gratuito de QueryChart (registro de cambios con diferencias por campo, comparar versiones, restaurar) es la capa de control de versiones; no fija por sí solo permisos de acceso ni fechas de retención.
• «Control de versiones frente a gestión documental» es la pregunta equivocada. La pregunta real es si tu instalación de gestión documental tiene control de versiones real dentro.

Uno es todo el trabajo; el otro es una parte de él

Pídele a diez personas que definan gestión documental y control de versiones y varias asumirán en silencio que son alternativas (elige un sistema o el otro). No lo son. La gestión documental es la disciplina de gobernar un documento a lo largo de toda su vida: quién puede verlo, dónde vive la copia autorizada, cómo se clasifica y se recupera, cuánto tiempo se conserva y cómo un borrador avanza por la revisión hasta la aprobación. El control de versiones es una pieza de esa disciplina: la pieza que rastrea las versiones sucesivas del propio documento, para que puedas ver qué cambió, quién lo cambió y revertir si el cambio estaba mal. Para la definición sencilla de esa pieza por sí sola, ver /es/guides/que-es-el-control-de-versiones.

Pon las dos una junto a otra y la forma de la relación es evidente: toda instalación de gestión documental necesita control de versiones, pero casi nada de lo que se llama a sí mismo control de versiones hace por sí solo el resto del trabajo de la gestión documental. Un historial de versiones (entre ellos el registro de cambios gratuito y la vista de comparar versiones de QueryChart, ver /features/version-control) responde a «qué cambió entre la revisión 3 y la revisión 4, y quién hizo el cambio». No tiene opinión sobre quién puede abrir el archivo, qué carpeta es la autorizada, o cuándo le toca al documento su próxima revisión. Esas son preguntas de gestión documental, y un proceso de gestión documental real las enruta por pasos nombrados en lugar de dejarlas a quien se acuerde.

El diagrama de control documental de abajo hace concreto el límite. Veinte filas llevan un documento desde una solicitud de cambio pasando por la redacción, la revisión, la aprobación, la emisión y la baja, y exactamente una de ellas («Asignar versión y fecha de entrada en vigor») es donde ocurre el control de versiones. Las otras diecinueve son control de acceso, metadatos, distribución, formación y un calendario de retención: funciones de gestión documental que un número de versión por sí solo no puede cumplir. El ciclo de vida completo que recorren esas filas está cubierto de principio a fin en /es/guides/como-crear-un-proceso-de-control-de-documentos; esta página trata solo de qué partes de él son control de versiones y cuáles no.

Un proceso, y qué filas son control de versiones

Observa un único documento pasar por la solicitud, la redacción, el versionado y la retirada, y ve cuánto de esa cadena no es control de versiones en absoluto.

1. Se solicita un cambio, todavía no existe versión

   La fila de Inicio es un suceso, «Necesidad o cambio documental identificado», que fluye directamente hacia «Abrir una solicitud de cambio documental». Esto es enrutamiento de flujo de trabajo, la función de gestión documental de capturar por qué hace falta un cambio, y ocurre antes de que nada tenga un número de versión.

2. Una fila acuña la versión; el resto es enrutamiento de aprobación

   «Redactar o revisar el contenido» entra en un bucle de revisión («Realizar la revisión técnica», la decisión «¿Hay comentarios pendientes?», «Actualizar el borrador con los comentarios») y después la puerta «¿Se aprueba para emisión?» del Aprobador. Solo «Asignar versión y fecha de entrada en vigor» es control de versiones; el resto es enrutamiento de flujo de trabajo.

3. Registro, punto de acceso y retirada son gestión documental, no versionado

   «Actualizar el listado maestro de documentos» son metadatos y clasificación, escrito como fila de tipo File para que aparezca en el diagrama. «Publicar en la ubicación controlada» es control de acceso (un único sitio autorizado, no una copia). «Retirar del uso las copias obsoletas» es control de distribución, y ninguna de las tres se guarda en un número de versión.

4. Retención y revisión periódica sobreviven a cualquier versión individual

   La formación o «Leer y acusar recibo de la nueva versión» precede a «Usar la versión controlada vigente», y después «Lanzar la revisión periódica programada» reabre el registro con un temporizador. «¿El documento sigue vigente?» sale a «Registrar el resultado y la próxima revisión», de vuelta a la solicitud de cambio, o a «Documento retirado y dado de baja»: un calendario de retención, que el control de versiones por sí solo no ejecuta.

Cómo funciona

1. Nombra lo que realmente te falta

   Si nadie puede responder «quién cambió el párrafo 4 la semana pasada, y qué decía antes», te falta control de versiones en concreto. Si el hueco es en cambio «quién puede editar esto» o «cuál es la única copia en la que la gente debería confiar», eso es un hueco de gestión documental que un historial de versiones por sí solo no cerrará.

2. Comprueba qué devuelve en realidad un historial de versiones

   Uno real muestra un registro de cambios con diferencias por autor y por campo (no solo una fecha de modificación) más una forma de comparar dos versiones cualesquiera una junto a otra y restaurar una antigua. El registro de cambios y la vista de comparar versiones de QueryChart, en /features/version-control, son un ejemplo práctico de qué esperar antes de aceptar la afirmación de una herramienta de tener «historial de versiones».

3. Localiza las otras cuatro funciones por separado

   Control de acceso (quién puede ver o editar), metadatos y clasificación (cómo se encuentra el documento), calendario de retención (cuánto se conserva y cuándo se revisa) y enrutamiento de flujo de trabajo (cómo un borrador se convierte en un documento aprobado y emitido). Ninguna de estas vive dentro de un número de versión, así que audita cada una por separado en lugar de asumir que un historial de versiones ya las cubre.

4. No compres toda una disciplina para conseguir un solo mecanismo

   Un sistema pesado de gestión documental se justifica cuando necesitas las cuatro funciones de arriba aplicadas juntas. Si lo que realmente falta es la capacidad de ver qué cambió y revertirlo, ese es un problema mucho más pequeño, y una herramienta de diagramas con un registro de cambios real lo resuelve sin el resto del despliegue.

5. Traza la distinción sobre tu propio proceso

   Dibuja el ciclo de vida de tu documento como filas y marca cuál de ellas, una sola, acuña una versión, del modo en que el diagrama de abajo marca «Asignar versión y fecha de entrada en vigor». Todo lo demás del diagrama es gestión documental, y verlo así suele bastar para determinar de cuál de las dos anda escaso en realidad un equipo.

Errores que debes evitar

• Recurrir a «control de cambios» cuando se quiere decir «control de versiones»

  Un comité de cambios que aprueba un ticket de cambio y una vista de comparar versiones que diferencia dos revisiones de un documento resuelven problemas distintos, y los dos se confunden lo bastante a menudo como para merecer su propia página: ver /es/guides/control-de-versiones-frente-a-control-de-cambios para dónde divergen.

• Tratar «última modificación» como un historial de versiones

  Una única marca de tiempo en un archivo de unidad compartida te dice que el documento cambió, no qué cambió, quién lo cambió, ni cómo recuperar la redacción anterior. Eso no es control de versiones, es un rumor de que algo pasó.

• Dar por hecho que una compra de gestión documental incluye versionado real

  Muchos sistemas de gestión documental guardan archivos con metadatos ricos y reglas de acceso pero solo una lista de revisiones superficial, sin diferencia a nivel de campo ni restauración en un clic. Confirma el historial de versiones específicamente, en lugar de deducirlo del resto de la plataforma.

Ve el historial de versiones en acción

Abre el ejemplo de control documental como diagrama propio, y después comprueba su registro de cambios para ver la misma distinción: una versión estampada, un campo diferenciado, una revisión antigua restaurable.

Ve el historial de versiones en acción

Guías relacionadas

• Cómo registrar cambios en un SOP
• Cómo gestionar las revisiones de un SOP
• Buenas prácticas de control de versiones de SOP

Preguntas frecuentes

¿Es el control de versiones parte de la gestión documental, o algo separado de ella?

Parte de ella. La gestión documental es la disciplina que gobierna (acceso, clasificación, retención, flujo de trabajo y versionado juntos) y el control de versiones es el mecanismo dentro de ella que rastrea las revisiones sucesivas de un documento. Tratarlos como opciones separadas entre las que elegir es la idea equivocada que esta página existe para corregir: una instalación de gestión documental sin control de versiones le falta una función central, y un historial de versiones sin control de acceso ni política de retención alrededor todavía no es gestión documental.

¿Necesito un sistema completo de gestión documental solo para tener control de versiones?

No. El control de versiones es la capacidad más estrecha (un registro de cambios con diferencias por campo y por autor, una forma de comparar dos revisiones y una vía de restauración) y una herramienta de diagramas puede ofrecer eso por sí sola, gratis y siempre activo, como hace el historial de versiones de QueryChart; ver /features/version-control. Un sistema completo de gestión documental es la compra correcta cuando además necesitas permisos de acceso aplicados, clasificación formal y un calendario de retención corriendo sobre muchos documentos, no cuando lo que de verdad falta es simplemente ver qué cambió.

¿En qué se diferencia el control de versiones del control de cambios?

El control de versiones rastrea los estados sucesivos de un documento (qué cambió entre la revisión 3 y la revisión 4). El control de cambios gobierna la decisión de hacer un cambio siquiera, típicamente mediante un comité asesor, una evaluación de riesgo y un plan de reversión, casi siempre para sistemas de TI o procesos operativos más que para un único archivo. Un proceso de control documental usa los dos: puertas de aprobación al estilo del control de cambios antes de emitir una revisión, y control de versiones para registrar la propia revisión. /es/guides/control-de-versiones-frente-a-control-de-cambios cubre la distinción por completo.

¿Dónde se sitúa el control de versiones dentro de un proceso de control documental?

En un único punto: el paso que asigna un número de versión y una fecha de vigencia una vez aprobada una revisión. Todo lo anterior (la solicitud de cambio, la redacción, la revisión) y todo lo posterior (publicar en la ubicación controlada, retirar la copia sustituida, formación, revisión periódica) es gestión documental haciendo un trabajo que un número de versión por sí solo no puede hacer. /es/guides/como-crear-un-proceso-de-control-de-documentos recorre el proceso completo de veinte filas del que salen estas etapas.