Diagrama de flujo del proceso de gestión de cambios (ITIL)
Diagrama de flujo de gestión de cambios ITIL: registro de la RFC, triaje de cambios estándar, normales y de emergencia, aprobación del CAB, planificación, implantación y reversión.
Cómo funciona
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.
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.
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.
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.
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.
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.