Change Management: ventanas, RFCs, CAB ligero y rollback plans que funcionan

Como implementar gestion de cambios sin burocracia. Ventanas de mantenimiento, RFCs cortos, CAB que no consume horas y planes de rollback que el equipo entiende.

Change management es una de esas practicas que o se hace bien o se convierte en el enemigo de cualquier cambio util. La diferencia esta en el diseno del proceso.

Por que falla change management

Las implementaciones fallidas comparten sintomas:

CAB con 15 personas que nadie convoca
RFCs de 5 paginas que nadie lee
Cambios urgentes que se saltan el proceso siempre
Documentacion posterior al cambio como control unico
Rollback plans que dicen "revertir el cambio" sin detalle

El equipo empieza a ver change management como tramite, no como proteccion. Eso es el principio del fin.

Ventanas de mantenimiento

Dos tipos de ventana cubren el 90% de casos:

Ventana estandar: martes y jueves 7-9 PM. Para cambios pre-aprobados de bajo riesgo. No requiere CAB.

Ventana de mantenimiento mayor: sabado 11 PM - 3 AM, uno al mes. Para cambios de alto impacto. Requiere CAB ligero y notificacion a negocio.

Fuera de ventana solo se permite emergencia real (P1 activo o riesgo inminente). Y las emergencias se documentan despues.

RFCs cortos

Un RFC util cabe en una pantalla. Campos necesarios:

Descripcion del cambio (2-3 lineas)
Sistemas afectados
Riesgo: bajo / medio / alto
Impacto en usuarios: ninguno / parcial / total
Ventana propuesta
Plan de rollback (no "revertir", sino pasos concretos)
Responsable tecnico
Validacion post-cambio

Si un RFC necesita mas, el cambio probablemente necesita ser partido en varios.

CAB ligero

El CAB tradicional de 15 personas semanal es donde los cambios van a morir. La version ligera:

3 personas fijas: responsable de IT, responsable de operacion de negocio, security officer o equivalente
30 minutos semanales maximo
Solo revisa cambios de riesgo medio/alto
Los cambios de bajo riesgo son auto-aprobados si estan dentro de ventana estandar
Decisiones por mayoria simple, no consenso

Si un cambio es urgente entre sesiones de CAB, email con los 3 y decision en 2 horas.

Rollback plans que funcionan

Un plan de rollback util tiene:

Trigger definido. "Si el error rate pasa de 2% en 15 min, rollback." No "si algo sale mal".
Pasos ejecutables. "Ejecutar script X, validar con query Y, confirmar en dashboard Z." No "restaurar base de datos".
Tiempo estimado. "Rollback tarda 20 min desde decision." Para saber si hay tiempo en la ventana.
Responsable de ejecutar. Nombre especifico, no "el equipo".
Validacion post-rollback. Como confirmas que regresaste al estado previo.

Si el rollback no se puede ejecutar en la ventana, el cambio no deberia hacerse en esa ventana.

Cambios pre-aprobados

Lista de cambios que no requieren CAB cada vez:

Parches de seguridad ya probados en staging
Ajustes de configuracion reversibles
Updates menores de software con track record
Scaling de recursos cloud

Estos cambios siguen documentandose pero la aprobacion es automatica si cumplen criterios.

Metricas que importan

% de cambios exitosos (objetivo: >95%)
% de cambios con rollback ejecutado (objetivo: <5%)
% de cambios de emergencia (objetivo: <10% del total)
Tiempo promedio de RFC a aprobacion (objetivo: <48 horas riesgo bajo/medio)

Si el % de emergencia es alto, el proceso esta mal calibrado: las ventanas son muy restrictivas o el CAB es muy lento.

El balance

Change management funciona cuando el equipo prefiere usarlo que saltarlo. Eso solo pasa si es mas rapido hacer un RFC corto que justificar despues un cambio no documentado. El diseno del proceso determina el comportamiento, no los memos de direccion.