Diagrama de flujo del proceso de control de cambios

¿Qué es diagrama de flujo del proceso de control de cambios?

El control de cambios es el conjunto de puertas que hay entre «alguien quiere cambiar algo» y «el cambio ya está en producción». Cada puerta deja un registro: qué se solicitó, qué encontró la evaluación de impacto, quién lo autorizó, cuándo se ejecutó, si la verificación se superó y qué concluyó la revisión posterior. En equipos de TI e ingeniería esto se lleva como una gestión de cambios al estilo ITIL con un CAB; en un sistema de calidad regulado es el procedimiento de cambio controlado que impide que un proceso validado se desvíe. La forma del proceso es la misma en los dos casos.

La mayoría de los fallos del control de cambios son fallos de traspaso, no fallos de proceso. El solicitante no sabe qué nivel de detalle necesita la evaluación, el CAB acaba revisando un hilo de tickets en lugar de un registro de evaluación, quien implementa monta un plan sin reversión y después nadie cierra el registro. Por eso esta plantilla está dibujada en carriles: Solicitante, Gestor de cambios, Comité de cambios, Implementador y QA son dueños de pasos concretos, y el diagrama deja a la vista dónde cambia de manos el trabajo.

Las dos ramas que los equipos dejan sin documentar con más frecuencia son también las dos que más discusiones provocan después: la vía de emergencia y qué ocurre con un cambio rechazado. Este diagrama incluye las dos. Los cambios de emergencia reciben una autorización acelerada del presidente del CAB y vuelven a la misma ruta de implementación y revisión, de modo que nunca quedan sin registrar. Los cambios rechazados regresan al solicitante con el dictamen del CAB y un punto de decisión que, o bien reabre la evaluación, o bien cierra la solicitud como cambio aplazado.

Qué cubre este diagrama de flujo

En esta plantilla

• Entrada y triaje entre los carriles Solicitante y Gestor de cambios: crear la solicitud de cambio, registrarla en el registro de cambios y una decisión de triaje a tres bandas, «¿Tipo de cambio?», que manda los cambios estándar directamente a la planificación, los normales a la evaluación de impacto y a la revisión del CAB, y los de emergencia al presidente del CAB
• Evaluación: evaluar impacto y riesgo, confirmar el alcance y la ventana de parada con el solicitante y dejarlo todo en un único registro de evaluación con su nivel de riesgo, para que el comité revise un documento y no un hilo de comentarios
• El punto de decisión del comité de cambios: el CAB revisa la solicitud y después la aprueba hacia la planificación de la implementación o la rechaza y la devuelve al gestor de cambios
• La rama de rechazo y aplazamiento: el dictamen del CAB vuelve al solicitante, que decide en «¿Revisar y volver a enviar?» entre corregir y reenviar (volviendo a la evaluación de impacto) o cerrar la solicitud como cambio aplazado
• La rama de emergencia: los cambios urgentes se saltan la agenda ordinaria del CAB mediante la autorización de emergencia del presidente y se reincorporan a la misma ruta de planificación, implementación y revisión
• Implementación y verificación: planificar implementación y reversión, programar la ventana de cambio, ejecutar el cambio y, en el carril de QA, probar y verificar. Una verificación fallida dispara el plan de reversión y vuelve a la planificación; una verificación superada pasa a la revisión posterior a la implementación y al cierre del registro del cambio

Cuándo usar esta plantilla

• Estás documentando un procedimiento de gestión de cambios al estilo ITIL para un equipo de operaciones de TI o de plataforma, incluyendo quién se sienta en el CAB y qué ve antes de decidir
• Estás redactando un procedimiento de cambio controlado para un sistema de calidad, donde los cambios sobre un proceso o un producto validado exigen una evaluación de impacto documentada y un aprobador con nombre y apellidos
• Estás incorporando nuevos gestores de cambios, miembros del CAB o técnicos de guardia que necesitan saber qué cambios requieren aprobación y cuáles no
• Queréis cerrar quién autoriza qué antes de configurarlo como flujo de trabajo en Jira, ServiceNow o un QMS, para que la herramienta refleje un proceso acordado en lugar de inventarse uno
• Un cliente o un auditor os ha preguntado cómo se aprueban, se prueban y se revierten los cambios

Cómo funciona

1. Renombra los carriles con tus roles reales

   Sustituye Solicitante, Gestor de cambios, Comité de cambios, Implementador y QA por los roles y equipos que realmente tienes. Si una misma persona es gestor de cambios y presidente del CAB, fusiona esos carriles en lugar de fingir que están separados. Mantén el número de carriles en cinco o menos para que el diagrama siga siendo legible.

2. Define tus categorías de cambio en la decisión de triaje

   La decisión de triaje ya separa estándar, normal y emergencia. Escribe qué cumple cada categoría en tu organización y pon esos umbrales junto al nodo de decisión. Fíjalos por riesgo y por radio de impacto, no por tamaño del ticket, y mantén la lista de cambios estándar preaprobados lo bastante corta como para que alguien la mantenga de verdad.

3. Nombra a la autoridad de cambio y su cadencia

   En el paso de revisión del CAB, anota quiénes son los aprobadores, cada cuánto se reúnen y cuál es el corte para entrar en el orden del día. Añade aparte la autoridad de emergencia, porque quien puede aprobar una corrección fuera de horario casi nunca es el comité entero.

4. Especifica qué debe contener el registro de evaluación

   Convierte el paso de evaluación en una lista de comprobación real: servicios y usuarios afectados, ventana de parada, nivel de riesgo, dependencias, enfoque de pruebas y enfoque de reversión. La decisión del CAB solo vale lo que valga ese registro, y es además la pista de auditoría del cambio.

5. Fija las reglas de reversión y de verificación

   Decide quién ejecuta una reversión, cuánto tarda y qué dispara la llamada. Después define qué significa verificar en vuestro caso: prueba de humo, batería de regresión o visto bueno del responsable del servicio. Ajusta el bucle de verificación fallida si vuestra política es revertir de inmediato en lugar de replanificar.

6. Publícalo y mantenlo versionado

   Comparte el diagrama donde ocurre el trabajo: junto al formulario de solicitud de cambio o dentro del runbook. Revísalo después de cualquier cambio que haya salido mal y conserva las versiones anteriores, para poder demostrar cuándo cambió el procedimiento y por qué.

Preguntas frecuentes

¿Qué diferencia hay entre control de cambios y gestión de cambios?

El control de cambios es la parte estrecha y procedimental: cómo se solicita, se evalúa, se autoriza, se implementa, se verifica y se cierra un cambio concreto, dejando un registro en cada paso. La gestión de cambios es más amplia e incluye la estrategia, las categorías, los roles, la comunicación y la mejora continua del propio proceso. Este diagrama es el procedimiento de control de cambios, que suele ser lo primero que se documenta porque es lo que la gente sigue cada día.

¿Quién debe aprobar un cambio? ¿Todo tiene que pasar por el CAB completo?

No. Llevar cada cambio al comité entero crea una cola y empuja a la gente a rodear el proceso. La mayoría de los equipos usan tres niveles: cambios estándar preaprobados con un procedimiento documentado que no necesitan revisión, cambios normales que van al CAB, y cambios de emergencia autorizados por una única autoridad con nombre, como el presidente del CAB o el responsable de guardia. Fija los umbrales por riesgo y radio de impacto, no por tamaño del ticket, y escríbelos junto a la decisión de triaje.

¿Cómo encajan los cambios de emergencia sin cargarse el proceso?

Un cambio de emergencia comprime la aprobación, no la elimina. En este diagrama la rama de emergencia se salta la agenda ordinaria del CAB, pero sigue recibiendo una autorización explícita, sigue pasando por la planificación de la implementación con su plan de reversión y sigue terminando en la revisión posterior y el cierre. La regla práctica que adoptan casi todos los equipos: autoriza verbalmente en minutos, pero escribe el registro del cambio el mismo día y revisa cada emergencia en el siguiente CAB para comprobar que la categoría estaba justificada.

¿Qué pasa con los cambios que el CAB rechaza o aplaza?

Necesitan un final explícito; si no, reaparecen como trabajo sin registrar. En esta plantilla el gestor de cambios devuelve al solicitante el razonamiento del CAB, y este llega a una decisión: corregir y reenviar, lo que devuelve el caso a la evaluación de impacto y a una segunda revisión, o aceptar el resultado y cerrar la solicitud como aplazada. Registrar el motivo importa tanto como la decisión, porque los cambios aplazados suelen volver en cuanto se libera la dependencia que los bloqueaba.

¿Esto es distinto del control de cambios de un documento o de un SOP?

Sí. Esta es la versión genérica del control de cambios, al estilo de operaciones de TI: un CAB, un plan de reversión, un paso de implementación y verificación, pensada para cambios en sistemas y servicios. /es/templates/flujo-de-control-de-cambios-de-documentos y /es/templates/proceso-de-control-de-cambios-de-sop son variantes más estrechas de la misma forma, construidas para un tipo de documento concreto, en las que el CAB se sustituye por revisores y aprobadores del documento y el plan de reversión se sustituye por la retirada de la versión sustituida. Si lo que en realidad buscas es la distinción conceptual entre control de versiones y control de cambios, y no un diagrama, consulta /guides/version-control-vs-change-control.