Cómo registrar cambios en un proceso
Cómo registrar cambios en un proceso: el registro de cambios de QueryChart nombra a quién editó una regla de decisión o un umbral, el valor anterior del campo y su valor vigente, para que nadie reconstruya una edición de memoria.
Registrar cambios en un proceso significa mantener un registro de exactamente qué campo cambió, quién lo cambió y qué valor sustituyó, no simplemente que existe una versión nueva.
En resumen
- Una edición al umbral de una fila de decisión (segundo aprobador requerido por encima de 5.000 $ subido a por encima de 10.000 $) se convierte en una entrada del registro de cambios que nombra quién lo cambió y qué valor sustituyó.
- Cada edición queda atribuida: autor, campo, valor anterior, valor actual y una marca de tiempo, no solo «diagrama actualizado».
- Comparar versiones da la diferencia más completa cuando se ha movido más entre dos revisiones de lo que cubre una sola entrada del registro de cambios.
- Restaurar una versión antigua deshace la edición sin más, en lugar de pedirle a alguien que recuerde y reteclee la regla anterior.
- Registrar un cambio es distinto de controlarlo: esto es el registro que deja una edición, no la puerta de aprobación sobre si debía producirse.
Quién movió el umbral, y cuándo
Un responsable de proceso sube la cifra en dólares de una fila de decisión de 5.000 $ a 10.000 $: un campo, una edición, guardada en segundos. Tres semanas después una factura de 7.000 $ pasa sin un segundo aprobador, y la pregunta no es si la regla cambió, sino quién la cambió, cuándo y cuál era en realidad el número antiguo. Nadie lo anotó en ningún sitio fuera del propio diagrama, porque el diagrama es donde vive la regla.
QueryChart guarda ese registro automáticamente. Cada edición de un diagrama (una decisión reetiquetada, una rama movida, un umbral cambiado) anota una entrada que nombra a la persona que la hizo, el campo que tocó, su valor anterior y su valor actual. Abre el registro de cambios sobre la edición de arriba y dice exactamente eso: umbral cambiado por una persona con nombre, de 5.000 $ a 10.000 $, en un momento registrado. Nadie mantiene un registro de cambios aparte a mano, y nadie tiene que confiar en un recuerdo de lo que decía antes la regla. El mecanismo está cubierto por completo en /features/version-control.
Registrar un cambio no es lo mismo que controlarlo. Esta página trata del registro que guarda QueryChart una vez que un proceso se ha editado: un hecho, después del hecho. El control de cambios es el proceso de decisión que gobierna si una edición debe llegar a producirse siquiera, normalmente con una solicitud y un paso de revisión; esa mecánica se construye en /es/guides/como-crear-un-proceso-de-control-de-cambios. Y si el documento del que se habla es un procedimiento escrito en lugar de un árbol de decisión, se aplica el mismo registro de cambios pero el recorrido se lee distinto. Ver /es/guides/como-registrar-cambios-en-un-sop para esa versión.
El árbol de aprobación, editado y registrado
Un árbol de decisión de aprobación de documentos de veinte filas, por etapas desde la recepción hasta la publicación, con el umbral de segundo aprobador en su centro: la regla exacta que edita el ejemplo trabajado de arriba.
Dónde empieza una edición
El diagrama arranca en «Documento enviado a aprobación», después pregunta «¿Documento nuevo o revisión?» y, para una revisión, «¿Cambio editorial o sustantivo?» antes de bifurcarse en «Registrar la corrección editorial» o una comprobación completa de «¿Tipo de documento regulado?»: la rama que decide cuánto escrutinio recibe un cambio antes de que nadie lo revise.
El bucle de revisión que saca a la luz el desacuerdo
Las filas seis a nueve ejecutan la revisión propiamente: «Añadir revisores de calidad y regulatorio», «Recoger los comentarios de los revisores», y después «¿Todos los comentarios resueltos?», que, si no, pregunta «¿Puede resolverlos el autor ahora?» antes de volver atrás o salir a retrabajo. Cada pasada por este bucle se guarda como su propia versión.
El umbral que edita el ejemplo de esta guía
«El aprobador revisa el borrador final» lleva a «¿Aprobar para publicación?», y después a la fila de la que trata el ejemplo trabajado de arriba: «¿Se requiere un segundo aprobador?», que enruta a «Obtener la segunda aprobación» cuando la respuesta es sí. Sube el umbral de esa fila y el registro de cambios anota exactamente esa edición.
Publicación, y el registro que deja
El carril de Publicación cierra el árbol de tres formas: «Publicado como cambio editorial menor», «Publicado tras la aprobación completa» o «Publicado con formación asignada» tras «¿Requiere leído y entendido?», además de «Devuelto al autor para su revisión» y «Rechazado y cerrado». Cada regla que enrutó un documento hacia uno de estos está en una versión que Comparar versiones puede abrir.
Cómo funciona
Abre el registro de cambios después de una edición
Cada guardado escribe una versión nueva, y el registro de cambios las lista en orden. Ábrelo desde el panel de historial del diagrama para ver qué versión cambió y quién la guardó. No necesitas saber de antemano que se movió un umbral.
Lee la entrada: autor, campo, valor anterior, valor actual
Entra en una versión y su entrada nombra a la persona que la editó, el campo que tocó (la etiqueta de una fila, la condición de una rama, la asignación de un carril) y el valor que tenía antes frente al valor que tiene ahora. Esa es toda la respuesta a quién cambió el umbral del segundo aprobador y qué decía antes, sin abrir un solo hilo de correo.
Usa Comparar versiones cuando una entrada no cuenta toda la historia
La entrada de una sola edición es precisa pero estrecha. Cuando varias filas se han movido entre la versión en la que confías y la que tienes delante, abre Comparar versiones en su lugar y lee las dos una junto a otra: el mismo mecanismo, ampliado a cada campo que difiere.
Restaura la versión anterior si la edición hay que deshacerla
Si un umbral subido resulta ser un error en lugar de intencionado, restaura la versión que lo precedió. Restaurar sustituye el diagrama actual por esa revisión sin más, en lugar de pedirle a alguien que reteclee de memoria la regla antigua.
Nombra la regla, no solo la rama, para que la diferencia siga siendo legible
Escribe la etiqueta de una fila de decisión y las etiquetas de sus ramas en torno al disparador real («¿Se requiere un segundo aprobador?» respondido «Requerido» o «No requerido») en lugar de un simple sí o no. Una entrada del registro de cambios que nombra un campo etiquetado es mucho más útil que una que dice que se movió una caja sin etiquetar.
Errores que debes evitar
Perseguir una regla cambiada por chat y memoria
Sin un registro de cambios, un umbral subido se reconstruye a partir de mensajes de Slack y del recuerdo de alguien sobre el número antiguo, y los dos rara vez coinciden. Cada edición a nivel de campo ya está atribuida y fechada: la reconstrucción que QueryChart está construido para hacer innecesaria.
Confundir una edición registrada con una aprobada
Una entrada del registro de cambios prueba que un umbral cambió y quién lo cambió, pero no prueba que alguien diera el visto bueno al número nuevo. Si una regla como esta debe pasar por revisión antes de entrar en vigor, esa puerta pertenece al propio proceso, del tipo que se construye en /es/templates/proceso-de-control-de-cambios, no solo al historial de versiones.
Dar por hecho que la pista de auditoría ya está activada
El historial de versiones integrado de QueryChart (el registro de cambios, Comparar versiones y restaurar) es gratuito y está activo en cualquier diagrama sin configuración. Una pista de auditoría encadenada por hash mapeada a controles de ISO 27001, SOC 2 o HIPAA es una capacidad de pago independiente que una organización activa deliberadamente; no es algo que lleve por defecto todo diagrama solo porque las ediciones se rastreen.
Registra tus propios cambios de proceso
Parte del ejemplo de aprobación de documentos, edita el umbral de una fila de decisión y observa cómo el registro de cambios nombra exactamente qué cambió.
Guías relacionadas
Preguntas frecuentes
¿Qué registra exactamente el registro de cambios cuando cambia un proceso?
Para cada edición, una entrada que nombra a la persona que la hizo, el campo que cambió (la etiqueta de una fila, la condición de una rama, una asignación de carril) y el valor de ese campo antes de la edición frente a su valor después. Subir un umbral de segundo aprobador de 5.000 $ a 10.000 $ produce una entrada que dice exactamente eso, atribuida y con marca de tiempo, sin que nadie mantenga un registro aparte. El mecanismo está cubierto por completo en /features/version-control.
¿Es registrar cambios de proceso lo mismo que control de cambios?
No. Registrar un cambio es el registro que guarda QueryChart automáticamente después de que ocurre una edición (quién, qué campo, valor antiguo, valor nuevo). El control de cambios es el proceso de decisión que gobierna si una edición debe llegar a producirse siquiera, normalmente con una solicitud, un paso de revisión y una vía de reversión. Los dos importan, pero responden a preguntas distintas; la mecánica del segundo está en /es/guides/como-crear-un-proceso-de-control-de-cambios.
¿En qué se diferencia esto de registrar cambios en un SOP?
El registro de cambios en sí es idéntico (mismo autor, campo y valores antes/después) porque un árbol de decisión y un procedimiento escrito son ambos diagramas bajo el mismo historial de versiones. La diferencia está en lo que suele editarse: un proceso como este cambia condiciones de rama y enrutamiento, mientras que un SOP cambia más a menudo texto de pasos y responsabilidad. Ver /es/guides/como-registrar-cambios-en-un-sop para esa versión de la misma función.
¿Puedo ver todo lo que cambió entre dos versiones, no solo una edición?
Sí: abre Comparar versiones en lugar de una sola entrada del registro de cambios, y pone dos revisiones una junto a otra con cada campo que difiere marcado. Esa es la herramienta para una regla que ha ido derivando a lo largo de varias ediciones pequeñas en lugar de una obvia.
¿Restaurar una versión antigua elimina la edición que cambió el umbral?
No. Restaurar hace que una versión anterior vuelva a ser la actual, pero la versión en la que cambió el umbral sigue existiendo en el historial del diagrama: su entrada del registro de cambios no se borra, así que el registro de quién lo subió y cuándo sobrevive a la restauración.
