Cambios en producción sin sustos: solicitud, aprobación y ventana

Siete prácticas para que cada cambio llegue con las mismas preguntas respondidas: clasificación por riesgo, solicitud estándar, aprobación proporcional, ventanas, plan de regreso y verificación.

El cambio en producción es la causa más común de incidentes que nadie vio venir: un ajuste «pequeño» un viernes por la tarde, sin plan de regreso y sin que soporte supiera. La gestión de cambios no busca frenar al equipo; busca que cada cambio llegue con las mismas preguntas respondidas. Estas son siete prácticas que funcionan igual en un área de TI interna que en un despacho que opera la infraestructura de sus clientes.

1. Clasifica los cambios por riesgo, no por tamaño

Un marco como ITIL 4 distingue tres tipos: estándar (repetible, de bajo riesgo y preautorizado, como crear un usuario o renovar un certificado), normal (se evalúa y se autoriza antes) y de emergencia (para restaurar un servicio caído, con autorización acelerada). Define cuáles son estándar y buena parte del volumen deja de pasar por revisión.

2. Toda solicitud responde las mismas cinco preguntas

• ¿Qué cambia y por qué?
• ¿Qué servicios y qué usuarios toca?
• ¿Qué puede salir mal y cómo nos enteramos?
• ¿Cómo se regresa, y cuánto tarda?
• ¿Quién lo ejecuta y quién lo verifica?

Si la solicitud no las contesta, no se evalúa. Un formulario corto lo resuelve mejor que una reunión.

3. Una persona aprueba; el comité es para lo grande

Un comité de cambios que revisa cada ajuste se vuelve cuello de botella y la gente aprende a esquivarlo. Reserva el comité para los cambios de alto impacto y deja que el responsable del servicio apruebe los normales de riesgo bajo. Lo importante es que quede escrito quién autorizó y cuándo.

4. Ventanas de cambio y congelamientos publicados

Acuerda ventanas fijas (por ejemplo, martes y jueves en la noche) y calendarios de congelamiento: cierre contable, temporadas altas del cliente, fechas legales. Un cambio fuera de ventana es de emergencia, y las emergencias se revisan después.

5. Plan de regreso probado, no imaginado

«Regresamos al respaldo» no es un plan si nadie ha restaurado nunca ese respaldo. Para cada cambio normal anota el punto de decisión (a los 30 minutos sin verificación, se revierte) y, si es posible, ensáyalo en un ambiente de prueba.

6. Verifica y cierra con evidencia

Un cambio no termina al aplicarse, sino al verificarse: quien lo pidió confirma, se anota el resultado y se cierra con lo realmente ocurrido (fechas, tiempo, incidencias). Los cambios fallidos se revisan sin buscar culpables: ¿qué pregunta de la solicitud habría detectado el problema?

7. Mide dos números y revísalos cada mes

La proporción de cambios que causan un incidente y la de los que se ejecutan en emergencia. Si la segunda sube, el proceso normal es demasiado lento; si la primera sube, es demasiado laxo.

Cómo se ve en Iurefficient

Iurefficient no es una herramienta de gestión de cambios de infraestructura; lo que sí lleva es el control de cambios de un proyecto, útil cuando el cambio altera lo acordado con un cliente. En la pestaña «Cambios» de cada proyecto se guarda una línea base y cada orden de cambio declara su precio de venta, su costo y los días de calendario que mueve. Quien tiene la autoridad la autoriza o la rechaza, y al autorizarla el presupuesto se ajusta solo.

La captura usa datos de demostración. Para el trabajo operativo de un cambio —preparación, ejecución, verificación— cada paso puede llevarse como tarea del proyecto con responsable y fecha, y las ediciones masivas de tareas se pueden deshacer.

ti gestión de cambios itil operaciones mejores prácticas

← Volver al índice