Diagrama de flujo del proceso de gestión de cambios (ITIL)

¿Qué es diagrama de flujo del proceso de gestión de cambios (itil)?

En esta plantilla, gestión de cambios significa gestión de cambios de servicios de TI: el proceso permanente por el que pasa todo cambio sobre un servicio en producción, desde que se crea una solicitud de cambio hasta que se cierra su registro. No es la gestión del cambio organizativo, la disciplina centrada en las personas que se asocia a modelos como ADKAR o los ocho pasos de Kotter, aunque a las dos se las llame habitualmente «el proceso de gestión de cambios». La versión dibujada aquí es la operativa, de estilo ITIL, que llevan de forma continua un gestor de cambios y un comité asesor de cambios (CAB).

Casi todo el valor está en una sola decisión, muy al principio: ¿de qué tipo es este cambio? Pasar todo por la misma evaluación completa y el mismo comité semanal crea una cola, y una cola es justo lo que empuja a la gente a hacer cambios fuera del proceso. Por eso el diagrama tría una vez y pronto. Los cambios estándar están preautorizados contra un modelo de cambio documentado y van directos a planificación. Los normales reciben evaluación de riesgo e impacto y van al CAB. Los de emergencia obtienen autorización acelerada de un ECAB y después vuelven exactamente al mismo camino de planificación, implantación y revisión, para que una corrección urgente no sea nunca una corrección sin registro.

Lo otro que resuelve un diagrama es la propiedad, y por eso este va con carriles: solicitante, gestor de cambios, CAB, equipo de implantación y propietario del servicio. El propietario del servicio tiene carril propio porque la verificación es el paso que más se salta. «Se ha desplegado» y «el servicio funciona» son afirmaciones distintas, y esa diferencia es la razón de ser del plan de reversión. Aquí una verificación fallida dispara la reversión, y tanto el cambio correcto como el revertido llegan igualmente a la revisión posterior a la implantación y al cierre.

Qué cubre este diagrama de flujo

En esta plantilla

• La entrada entre los carriles de solicitante y gestor de cambios: crear la solicitud de cambio (RFC), registrarla en el registro de cambios y un filtro de completitud en «¿Solicitud completa y en alcance?» que devuelve las peticiones pobres al solicitante para aportar lo que falta antes de volver a la misma comprobación.
• El triaje a tres bandas de «¿Tipo de cambio?», que manda los cambios estándar directos al calendario de cambios, los normales a la evaluación de riesgo e impacto y los de emergencia a la autorización del ECAB.
• Evaluación y aprobación: evaluar riesgo e impacto en el servicio, registrar la evaluación y el plan de reversión como un único documento en lugar de un hilo de comentarios, y después la revisión del CAB y su decisión de aprobar o rechazar, con los rechazados terminando en «Cambio rechazado y cerrado» en el carril del solicitante.
• La planificación, donde las vías aprobada, de emergencia y estándar convergen en el calendario de cambios y se topan con la comprobación «¿Choca con otro cambio programado?», que devuelve las colisiones a reprogramar.
• Construcción e implantación en el carril del equipo de implantación: construir y probar el cambio y después implantarlo dentro de la ventana aprobada.
• Verificación y cierre: el propietario del servicio verifica el servicio y responde a «¿Cambio exitoso?», un fallo ejecuta el plan de reversión, y ambos desenlaces convergen en la revisión posterior a la implantación y el cierre del registro de cambio.

Cuándo usar esta plantilla

• Estás escribiendo o actualizando un procedimiento de gestión de cambios estilo ITIL para una mesa de servicio o un equipo de plataforma o infraestructura que hoy funciona por costumbre y por hilos de chat.
• Necesitáis acordar qué es estándar, normal y de emergencia antes de configurar los tipos de cambio en ServiceNow, Jira Service Management o Freshservice, para que la herramienta recoja una decisión ya tomada en vez de inventarla.
• Vas a formar a nuevos gestores de cambios, miembros del CAB o técnicos de guardia que necesitan saber qué cambios requieren aprobación, quién la da y qué se hace fuera de horario.
• Tienes que documentar para un auditor o un cliente cómo se evalúan, autorizan, prueban y revierten los cambios, por ejemplo frente al criterio CC8.1 de SOC 2 o el control 8.32 del Anexo A de ISO/IEC 27001:2022. El diagrama documenta el procedimiento; la evidencia son los registros de cambio que produce.
• Queréis bajar la tasa de cambios fallidos después de un trimestre malo y necesitáis ver exactamente dónde encajan la verificación y la reversión y quién es dueño de cada una.

Cómo funciona

1. Renombra los carriles con los roles que de verdad tienes

   Sustituye solicitante, gestor de cambios, CAB, equipo de implantación y propietario del servicio por tus funciones reales. En muchas organizaciones una sola persona es a la vez gestor de cambios y presidente del CAB, y en las más pequeñas no hay un equipo de implantación separado. Funde esos carriles en lugar de dibujar una estructura que no tienes, y no pases de cinco carriles o el diagrama dejará de leerse de un vistazo.

2. Define tus tres tipos de cambio en la decisión de triaje

   Escribe junto a «¿Tipo de cambio?» qué cuenta como estándar, normal y de emergencia, y marca las fronteras por riesgo y alcance del impacto, no por esfuerzo o tamaño del ticket. Mantén la lista de cambios estándar preautorizados lo bastante corta como para que alguien la mantenga de verdad, y dale a cada uno un modelo de cambio documentado que deba seguir.

3. Nombra la autoridad de cambios, su ritmo y su equivalente de emergencia

   En el paso de revisión del CAB, anota quiénes son los aprobadores, cada cuánto se reúnen y el corte para entrar en el orden del día. Define el ECAB aparte: quien puede autorizar una corrección fuera de horario rara vez es el comité completo. La regla en la que acaba casi todo el mundo es autorizar de viva voz en minutos, escribir el registro el mismo día y revisarlo en el siguiente CAB.

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

   Convierte «Registrar la evaluación y el plan de reversión» en una lista real: servicios y usuarios afectados, nivel de riesgo, dependencias, ventana de indisponibilidad, enfoque de pruebas, pasos de reversión y quién los ejecuta. La decisión del CAB vale exactamente lo que valga ese registro, y es el documento que un auditor pedirá meses después.

5. Haz explícitas las reglas de calendario y de choques

   Indica tus periodos de congelación, los plazos mínimos de antelación y quién es dueño del calendario de cambios. La comprobación de choques es una decisión a propósito y no un trámite, porque la mayoría de las colisiones son dos equipos tocando una dependencia compartida, no el mismo sistema. Decide de antemano si un choque significa reprogramar o escalar.

6. Define qué es un cambio exitoso y después publica y versiona el procedimiento

   Di qué significa «¿Cambio exitoso?» para vosotros: qué pruebas de humo, cuánto tiempo vigila el propietario del servicio y qué dispara la decisión de revertir. Después comparte el diagrama donde ocurre el trabajo, junto al formulario de solicitud de cambio o en el manual de operación, recoge la aprobación de las personas que aparecen en él y conserva las versiones anteriores para poder mostrar cuándo cambió el procedimiento y por qué.

Preguntas frecuentes

¿Esto es gestión de cambios de TI o gestión del cambio organizativo?

Gestión de cambios de TI. Las dos comparten nombre y casi nada más. Este diagrama es el proceso operativo estilo ITIL para cambios sobre servicios en producción: se crea una RFC, se tría, se evalúa, se autoriza, se planifica, se implanta, se verifica y se cierra. La gestión del cambio organizativo es la disciplina centrada en las personas para que la plantilla adopte una nueva forma de trabajar, normalmente estructurada con modelos como ADKAR o los ocho pasos de Kotter, y no tiene CAB, ni calendario de cambios, ni plan de reversión. Si buscas análisis de partes interesadas y plan de comunicación, este no es el diagrama.

¿Cuál es la diferencia entre un cambio estándar, uno normal y uno de emergencia?

Un cambio estándar es de riesgo bajo, se hace a menudo y está preautorizado contra un modelo de cambio documentado, así que no necesita aprobación individual y pasa directo a planificación. Un cambio normal es todo lo que hay que evaluar y aprobar por sus propios méritos, que es el camino de la evaluación de riesgo e impacto hasta el CAB. Un cambio de emergencia es aquel en el que esperar al siguiente CAB haría más daño que el propio cambio, así que recibe autorización acelerada de un comité de emergencia. En este diagrama los tres convergen en el mismo calendario, la misma implantación y la misma revisión, porque la categoría cambia la vía de aprobación, no el registro.

¿Todos los cambios tienen que pasar por el CAB?

No, y mandarlo todo allí es la forma más rápida de que la gente se salte el proceso. El CAB existe para revisar los cambios cuyo riesgo todavía no se entiende. En cuanto un tipo de cambio se ha hecho las veces suficientes como para tener un procedimiento fiable y un modo de fallo conocido, promuévelo a cambio estándar con su modelo documentado y sácalo del orden del día. Un CAB que dedica la reunión a firmar trabajo rutinario no está revisando nada, y la cola que genera empuja los cambios realmente arriesgados hacia la vía de emergencia.

¿Qué debe pasar cuando un cambio falla?

Sigue el mismo camino hasta el cierre que uno correcto. En este diagrama, una verificación fallida en «¿Cambio exitoso?» dispara el plan de reversión en el carril del equipo de implantación, y el cambio revertido pasa después a la revisión posterior a la implantación y al cierre igual que uno exitoso. Dos cosas hacen que eso funcione en la práctica: que el plan de reversión estuviera escrito y aprobado antes de ejecutar el cambio y no improvisado durante la incidencia, y que la revisión pregunte si el tipo de cambio era el correcto y no solo si el cambio funcionó. Un segundo intento es una RFC nueva, así el intento fallido conserva su propio registro.