¿Qué es el control de versiones de documentos, SOP y procesos?
La mayoría de resultados sobre «qué es el control de versiones» dan por hecho Git y código fuente. Esta página lo define para documentos, SOP y procesos, y lo separa del control de revisiones, el control de cambios y el control documental.
El control de versiones es la práctica de mantener una única versión vigente y autorizada de un documento, SOP o proceso, junto con un historial completo de cada versión anterior y un registro de quién cambió qué.
En resumen
- Control de versiones = una versión vigente, un historial completo de cada versión anterior y un registro de quién cambió qué: la misma idea para documentos que para código.
- El control de revisiones es la misma práctica con otro nombre; el control de cambios y el control documental son procesos más amplios que lo usan como una de sus partes.
- QueryChart ya guarda este historial en todos los diagramas: un registro de cambios, una vista de comparar versiones y restauración en un clic. Ver /features/version-control.
- La versión menor de un borrador (0.1, 0.2…) avanza en cada ciclo de revisión; una versión mayor entera se asigna una sola vez, en la aprobación formal.
- ¿Versionas un objeto concreto? Consulta /es/guides/como-controlar-versiones-de-un-sop, /es/guides/como-controlar-versiones-de-un-documento o /es/guides/control-de-versiones-de-diagramas-de-flujo.
Una versión vigente, todo lo demás es historia
Busca «qué es el control de versiones» y casi todos los resultados dan por hecho que gestionas código fuente: commits, ramas, Git. Esta página trata el uso más antiguo y sencillo de la expresión: controlar versiones de documentos, procedimientos normalizados de trabajo (SOP) y procesos de negocio, no código. La idea de fondo no cambia entre los dos usos: una única versión vigente y autorizada; un historial completo de cada versión anterior; y un registro de quién cambió exactamente qué, y cuándo. Solo cambia el objeto que se versiona: papeleo en lugar de una base de código.
En la práctica eso significa que cada edición de un documento produce una versión nueva y numerada en lugar de sobrescribir la anterior, de modo que la versión previa siga siendo recuperable en vez de haber desaparecido. En QueryChart esto ya existe para todos los diagramas que construyes: un registro de cambios anota quién cambió cada campo y de qué valor a cuál, una vista de comparar versiones pone dos revisiones cualesquiera una junto a otra, y restaurar una antigua es una única acción y no un retecleo. Consulta /features/version-control para verlo completo. Nada de esto hay que activarlo: funciona en todos los diagramas desde el momento en que se crean.
Control de revisiones y control de versiones son la misma idea con dos nombres: los términos se usan indistintamente en casi todo este campo, y no hay nada relevante en la preferencia de una organización por uno u otro. El control de cambios y el control documental son cosa distinta: son procesos de gobierno más amplios que usan el versionado como uno de sus mecanismos, no sinónimos suyos. Un proceso de control de cambios (ver /es/guides/como-crear-un-proceso-de-control-de-cambios) decide si un cambio debe llegar a producirse siquiera (impacto, aprobación, reversión) y el control de versiones es sencillamente cómo se numera y se registra el resultado aprobado después. Un proceso de control documental (/es/templates/proceso-de-control-de-documentos, y el cómo hacerlo en /es/guides/como-crear-un-proceso-de-control-de-documentos) gobierna todo el ciclo de vida de un documento (borrador, revisión, aprobación, publicación y retirada de la copia sustituida de cada sitio donde vivía) con el control de versiones como una cláusula dentro de él, no como el conjunto. Las tres comparaciones tienen su propia página completa en /es/guides/control-de-versiones-frente-a-control-de-cambios, /es/guides/control-de-versiones-frente-a-gestion-documental y /es/guides/control-de-revisiones-frente-a-control-de-versiones; aquí solo hace falta que veas que no son cuatro palabras para lo mismo.
Si ya sabes cuál de esos objetos estás versionando, la respuesta general de arriba es menos útil que la específica: consulta /es/guides/como-controlar-versiones-de-un-sop para procedimientos normalizados de trabajo, /es/guides/como-controlar-versiones-de-un-documento para documentos controlados en general, o /es/guides/control-de-versiones-de-diagramas-de-flujo si lo que versionas es el propio mapa de proceso. Todo lo que sigue (la definición en miniatura, el recorrido guiado, el cómo hacerlo) es el caso general sobre el que se construyen esos tres.
Ver cómo se asigna un número de versión, etapa por etapa
Un documento pasa de un borrador decimal a la revisión, la aprobación y la publicación. Observa exactamente en qué punto cambia su número de versión, y en cuál no.
Un borrador empieza en 0.1, no en 1.0
El diagrama arranca en «Nuevo documento redactado» y pasa directamente a «Asignar versión de borrador inicial 0.1»: un decimal, porque nada anterior a la aprobación formal recibe nunca un número entero en este esquema.
El bucle de revisión hace avanzar la versión menor
«Circular el borrador para revisión interna» y «El revisor evalúa el borrador» alimentan «¿Se requieren cambios?». Un Sí enruta por «Incrementar la versión menor» (0.1 pasa a 0.2) hacia «Corregir el borrador según los comentarios», que vuelve atrás por una rama etiquetada «Nueva revisión» tantos ciclos como necesite el borrador.
Un número entero se gana, no se asume
«Enviar el borrador final para aprobación» y «El aprobador revisa el borrador final» llevan a «¿Aprobado para emisión?». Un rechazo vuelve a «Incrementar la versión menor»; una aprobación llega a «Asignar versión mayor 1.0» y a una fila de tipo File, «Actualizar el registro del historial de versiones», que lo deja registrado.
Publicar retira la versión antigua en la misma fila
«Publicar la versión aprobada» va seguido inmediatamente de «Marcar la versión anterior como obsoleta», así que la revisión anterior se retira en el momento en que la nueva entra en vigor. Un lector que solicita un cambio reentra en «Reabrir el documento en la siguiente versión»; todos los demás llegan a «La versión actual sigue en vigor».
Cómo funciona
Elige una única ubicación como versión autorizada
Cualquier otra copia (un PDF enviado por correo, una impresión, una página guardada en una unidad compartida) es una copia de esa única ubicación, no un segundo original. Si dos sitios pueden reclamar a la vez ser el vigente, todavía no tienes control de versiones, sea cual sea el aspecto de tu numeración.
Separa la numeración de borrador de la numeración publicada
Usa decimales para lo que sigue en revisión y reserva los números enteros para lo que ya está aprobado, del mismo modo que 0.1 a 0.3 llevan hasta 1.0 en el diagrama de ejemplo de arriba. Un revisor que cita «los comentarios de la 0.3» queda entonces sin ambigüedad sobre qué borrador quiere decir.
Registra quién cambió qué, no solo que algo cambió
Una fecha por sí sola no le dice a un lector nada sobre lo que realmente se movió. Registra el autor, el campo y el valor antes y después en cada edición, que es justo lo que hace automáticamente el registro de cambios de QueryChart en cualquier diagrama, sin ninguna configuración.
Haz que dos versiones sean comparables, no solo visibles
Poder abrir la versión 3 y abrir la versión 5 no es lo mismo que poder ver qué cambió entre ellas. La vista de comparar versiones de QueryChart pone dos revisiones cualesquiera una junto a otra para que la diferencia sea lo que estás viendo, no algo que tengas que adivinar.
Trata restaurar una versión antigua como algo rutinario, no una urgencia
Si revertir una mala edición significa pedirle a alguien con acceso a la base de datos que intervenga, tu control de versiones existe solo sobre el papel. Restaurar una versión anterior debería ser una acción que cualquier editor autorizado pueda hacer por sí mismo, en el momento en que detecta el problema.
Errores que debes evitar
Un nombre de archivo haciendo de número de versión
«SOP_v2_FINAL_revisado(1).docx» no es un esquema de versiones, es un nombre de archivo que casualmente contiene dígitos: nada garantiza que el número suba, ni que dos personas no produzcan cada una su propio «FINAL» a la vez. Una versión necesita vivir en un sistema que la asigne, no en lo que alguien teclee antes de guardar.
Un historial que solo registra el estado actual
Sobrescribir un documento en el sitio y llamar a la copia antigua «guardada en algún lado» no es un historial de versiones, es una esperanza. Un historial de verdad mantiene cada versión anterior recuperable y comparable, no solo rescatable por quien recuerde dónde la dejó.
Confundir «tiene número de versión» con «está controlado»
Un número en un documento te dice que se versionó una vez; no te dice que la copia antigua se retiró, que alguien aprobó el cambio, ni siquiera que el número signifique lo que crees. El control de versiones es la numeración y el registro. El control documental y el control de cambios son lo que gobierna el proceso a su alrededor.
Cambiar el vocabulario en lugar de arreglar la práctica
Estandarizar tu organización en «control de revisiones» en vez de «control de versiones», o al revés, no cambia nada sobre si los cambios se rastrean de verdad. Son la misma práctica con dos nombres; lo que importa arreglar es el registro, no la etiqueta.
Consulta el registro de cambios de tu diagrama en QueryChart
Todos los diagramas de QueryChart ya guardan este historial. Crea uno y abre su registro de cambios para comprobarlo tú mismo.
Consulta el registro de cambios de tu diagrama en QueryChart
Guías relacionadas
Preguntas frecuentes
¿Es el control de versiones lo mismo que el control de revisiones?
Sí, en la práctica. Los dos términos describen la misma idea de fondo (una versión vigente más un historial recuperable de cada versión anterior) y distintas organizaciones, herramientas y normas simplemente prefieren una palabra u otra. La mecánica no cambia en nada según el término que uses; consulta /es/guides/control-de-revisiones-frente-a-control-de-versiones para la comparación completa.
¿Cuál es la diferencia entre control de versiones y control de cambios?
El control de cambios decide si un cambio debe llegar a producirse siquiera (su impacto, quién lo aprueba, cómo revertirlo si sale mal). El control de versiones es lo que registra el resultado una vez tomada esa decisión: el número nuevo, la marca de tiempo, el autor. Un proceso de control de cambios puede existir sin control de versiones, aunque mal, y el control de versiones sin control de cambios solo significa que nadie decidió si el cambio era buena idea antes de numerarlo. Ver /es/guides/control-de-versiones-frente-a-control-de-cambios y /es/guides/como-crear-un-proceso-de-control-de-cambios para la mecánica del comité y de la reversión.
¿Funciona el control de versiones igual para documentos que para código?
La idea central es idéntica (una única versión vigente y autorizada, un historial completo de lo anterior, un registro de quién cambió qué) pero la mecánica difiere. El control de versiones de código, como Git, está construido en torno a ramificar y fusionar líneas de trabajo concurrentes; el control de versiones de documentos y procesos suele ser lineal, un borrador que avanza por revisión hasta una única versión aprobada, más cercano a lo que describen esta página y el diagrama de ejemplo.
¿Está activada por defecto la pista de auditoría de QueryChart?
El historial de versiones descrito en esta página (registro de cambios, comparar versiones, restaurar) es gratuito y funciona automáticamente en cualquier diagrama sin ninguna configuración. La pista de auditoría de cumplimiento de QueryChart, un registro encadenado por hash mapeado a controles de ISO 27001, SOC 2 y HIPAA, es una capacidad de pago independiente que una organización activa deliberadamente. No está activada por defecto ni es algo que ya tenga en marcha toda cuenta.
