Gestión de cambios de TI: Aprende eliminar los cuellos de botella
September 3, 2026
Si le preguntas a cualquier equipo de TI por qué una corrección de configuración de dos líneas tardó once días en implementarse la respuesta rara vez será técnica. Se quedó en una cola de aprobación, esperando la misma reunión semanal de asesoramiento sobre cambios que también revisa migraciones de servidores y reescrituras de firewalls, porque el proceso trata cada cambio como si tuviera el mismo riesgo. La corrección en sí tomó veinte minutos una vez que alguien finalmente la autorizó.
Este es el costo silencioso de una gestión de cambios basada en la costumbre en lugar del riesgo. El proceso existe para prevenir interrupciones y proteger el tiempo de actividad, lo cual es un objetivo real y necesario, pero cuando cada cambio pasa por la misma revisión sin importar su tamaño, el equipo aprende a evitarlo. Los ingenieros agrupan pequeñas correcciones en lanzamientos más grandes solo para evitar pasar por la cola una segunda vez, o tratan silenciosamente algunos cambios como "no realmente un cambio" para saltarse el proceso por completo, lo que anula el propósito mismo de tener uno.
Este artículo presenta un modelo de aprobación basado en riesgos con tres vías diferenciadas: estándar, normal y de emergencia, y cómo configurar ese modelo dentro de Freshservice para que el trabajo de bajo riesgo avance rápidamente mientras que los cambios genuinamente arriesgados reciben el escrutinio que merecen. También exploraremos cómo clasificar un cambio sin depender de suposiciones, en qué debería dedicar su tiempo el comité de asesoramiento sobre cambios y cómo mantener los lanzamientos de desarrollo avanzando bajo el mismo principio fundamental.
El primer antipatrón común es utilizar el correo electrónico como sistema de registro para las aprobaciones. Se envía una solicitud, las respuestas llegan a cuentagotas durante días y, para cuando todos han opinado, nadie puede decir con certeza qué se aprobó realmente, bajo qué condiciones o por quién. No hay un registro consistente, ni una secuencia de firmas aplicada, ni visibilidad para nadie fuera del hilo, lo que significa que la misma solicitud a menudo es realizada dos veces por diferentes personas que nunca fueron incluidas.
El segundo antipatrón es tratar la reunión semanal del comité de asesoramiento sobre cambios como el único mecanismo de aprobación existente. Cada cambio, independientemente de su tamaño, espera a esa única reunión, lo que significa que un equipo que realiza cinco cambios a la semana pero se reúne una vez crea un retraso estructural, incluso cuando cada cambio individual es trivial. Las organizaciones que han adoptado transiciones de TI más fluidas descubren constantemente que la reunión en sí nunca fue el problema. El problema era dirigir cambios que nunca necesitaron una reunión hacia la única cola que tenía una.
Las categorías de cambio de ITIL se ajustan perfectamente a la solución que este artículo propone: tres vías, cada una con su propio camino de aprobación, de modo que el nivel de riesgo de un cambio determine su proceso en lugar de que lo haga el calendario. Las categorías no son un invento nuevo, lo que la mayoría de las organizaciones omiten es la creación de flujos de trabajo distintos para cada una, en lugar de procesar cada solicitud a través del mismo formulario genérico, sin importar a qué categoría pertenezca.
Los cambios estándar son de bajo riesgo, repetibles y están preaprobados como categoría, como una actualización rutinaria de la política de contraseñas o un cambio de configuración conocido como seguro que se ha ejecutado con éxito muchas veces antes. Estos aún requieren un procedimiento documentado y un registro de quién los ejecutó, pero no necesitan un ciclo de aprobación nuevo cada vez, porque la evaluación de riesgos ya se realizó una vez cuando se definió la categoría.
Los cambios normales conllevan un impacto potencial real y necesitan una revisión formal: un aprobador definido, una evaluación de riesgos documentada y una ventana de implementación acordada. Esta es la vía que aún debería llegar a un CAB o a un aprobador designado, pero solo los cambios que realmente justifican ese nivel de escrutinio llegan aquí, en lugar de cada solicitud sin importar su tamaño.
Los cambios de emergencia son urgentes por naturaleza, pero nunca deben estar fuera de control. Un comité de asesoramiento sobre cambios de emergencia más pequeño, un subconjunto del CAB completo, puede reunirse rápidamente para autorizar correcciones urgentes sin perder el registro de lo que se aprobó y por qué, lo que evita que la velocidad y la responsabilidad sean mutuamente excluyentes, incluso cuando la corrección debe realizarse en menos de una hora en lugar del siguiente ciclo programado.
La decisión de clasificación es donde reside la mayor parte del trabajo de diseño real, ya que equivocarse en cualquier dirección socava todo el modelo. Si la clasificación es demasiado laxa, los cambios genuinamente arriesgados se cuelan como si fueran rutinarios. Si es demasiado estricta, el modelo recrea exactamente el cuello de botella que se creó para eliminar. Una evaluación de riesgos útil sopesa un pequeño conjunto de factores concretos en lugar de una percepción subjetiva de cómo se siente el cambio:
Aplicar estos factores de manera coherente, en lugar de permitir que quien envía la solicitud elija su propia categoría, es lo que mantiene la integridad del modelo. Un equipo que permite a los solicitantes elegir "estándar" siempre que quieren un cambio rápido verá, con el tiempo, cómo la categoría estándar absorbe cambios para los que nunca fue diseñada. En pocos meses, la vía rápida se parecerá exactamente a la lenta que reemplazó, con cada solicitud reclamando la etiqueta que le permite pasar más rápido.
Freshservice respalda este modelo directamente mediante formularios de cambio personalizados y flujos de trabajo vinculados al tipo de cambio y a los campos de riesgo, en lugar de forzar cada solicitud a través de un formulario genérico. Una plantilla de cambio estándar puede preaprobarse automáticamente una vez que se cumplen las condiciones documentadas, un formulario de cambio normal puede dirigirse al aprobador correcto según los sistemas afectados, y un formulario de cambio de emergencia puede notificar a los miembros del ECAB de inmediato en lugar de esperar a la próxima revisión programada. Freddy, la capa de IA de Freshservice, también puede señalar cuando la descripción de un cambio enviado sugiere una categoría de riesgo superior a la seleccionada, detectando el problema de mala categorización antes de que llegue a un aprobador, en lugar de después de que un cambio fallido lo revele.
Un CAB que revisa cada cambio, incluidos los rutinarios, dedica su limitada atención a solicitudes que nunca necesitaron un comité, que es exactamente el patrón que este modelo está diseñado para romper. Una vez que los cambios estándar están preaprobados por categoría y los cambios de emergencia tienen su propia vía rápida, la agenda restante del CAB se limita a los cambios normales con un impacto real entre sistemas, lo cual es una lista mucho más corta que el comité puede analizar a fondo en lugar de aprobar mecánicamente por agotamiento.
Los equipos de software que realizan lanzamientos frecuentes se enfrentan a una versión del mismo cuello de botella cuando cada despliegue debe superar el mismo proceso de cambio diseñado para el trabajo de infraestructura. Las integraciones de Freshservice con herramientas de CI/CD permiten que un lanzamiento que ya ha superado las pruebas automatizadas y una canalización definida califique para una ruta de cambio estándar o normal acelerada, en lugar de esperar detrás de solicitudes de infraestructura no relacionadas. Ese tipo de colaboración de desarrollo sin fricciones depende del mismo principio subyacente que el resto de este modelo: el proceso debe coincidir con el riesgo real del cambio específico, no con el departamento que casualmente lo solicita.
El modelo es tan bueno como sus resultados, por lo que la implementación requiere un pequeño conjunto de métricas rastreadas desde la primera semana: tiempo promedio desde la presentación hasta la aprobación por tipo de cambio, el porcentaje de cambios categorizados correctamente en la primera presentación y la tasa de éxito de los cambios desglosada por vía. Los informes de Freshservice pueden mostrar los tres sin necesidad de una herramienta de análisis independiente, convirtiendo lo que solía ser una intuición sobre si el proceso ayuda o perjudica en decisiones de TI basadas en datos sobre dónde el modelo aún necesita ajustes. Una vía que supera constantemente su ventana objetivo es una señal de que los criterios de riesgo para esa categoría necesitan una revisión, no una señal de que el equipo se mueve demasiado lento.
Lograr una aprobación de cambios adecuada tiene menos que ver con añadir más puntos de control y más con colocar el punto de control correcto frente al cambio correcto. Un modelo que trata un restablecimiento de contraseña y una migración de base de datos de la misma manera siempre frustrará a alguien, ya sea al equipo que espera una solución trivial o al revisor que debería haber tenido más tiempo para el cambio arriesgado. Los equipos que reconstruyen su flujo de aprobación en torno al riesgo en lugar de al hábito a menudo encuentran útil trabajar en las reglas de categorización con un socio que haya diseñado este tipo de flujo de trabajo anteriormente.
