Categorías de cambio ITIL: estándar, normal y de emergencia (con ejemplos)

Las cuatro categorías de cambio ITIL se organizan de acuerdo a los niveles de complejidad y/o alcance de los cambios.

Únete al IT Pulse

Recibe las últimas noticias del mundo de IT una vez por semana.

No todos los cambios de IT siguen el mismo proceso de aprobación: instalar una actualización de software, migrar una base de datos de producción o aplicar un parche de seguridad implican distintos niveles de supervisión, urgencia y riesgo. La Gestión de Cambios ITIL contempla estas diferencias mediante las tres categorías de cambio ITIL: estándar, normal y de emergencia.

Esta clasificación ayuda a las organizaciones a determinar quién debe autorizar cada cambio, con qué rapidez puede avanzar y qué medidas tomar para reducir las posibilidades de interrupción del servicio.

En definitiva, se trata de implementar cambios en servicios, infraestructura y aplicaciones de forma controlada, equilibrando la velocidad con la estabilidad operativa.

En este artículo explicamos los tres tipos de cambio ITIL junto con ejemplos, quién aprueba cada uno, cuánto tardan, cómo decidir a qué categoría pertenecen y cómo los maneja InvGate Service Management.

 

¿Cuáles son las categorías de cambio en ITIL?

Las categorías de cambio ITIL son estándar, normal y de emergencia, que detallamos a continuación:

Categoría Nivel de riesgo Quién lo aprueba Ejemplos
Estándar Bajo Usualmente preautorizado Mantenimiento de rutina, instalación de software aprobado, actualización de políticas de contraseñas, reemplazo de hardware idéntico
Normal De bajo a alto, según el caso Responsable del cambio o autoridad de cambios designada; los cambios de mayor riesgo pueden requerir revisión del CAB Actualización de aplicaciones, cambios en infraestructura, migraciones a la nube, modificación de configuraciones, implementación de nuevos servicios
Emergencia Alto Proceso de aprobación acelerado, generalmente con la autoridad de cambios correspondiente o un ECAB cuando sea necesario Corrección de vulnerabilidades de seguridad, restauración de servicios de producción que dejaron de funcionar, correcciones urgentes para incidentes críticos

Cabe aclarar que el “cambio mayor” no se encuentra dentro de las categorías de cambio ITIL, sino que pertenece a un cambio normal, pero es de alto riesgo.

Cambio estándar

Un cambio estándar es un ajuste de bajo riesgo y repetible que se encuentra preautorizado. Esto significa que sigue un procedimiento documentado que ya fue evaluado y aprobado. De hecho, muchos están completamente automatizados.

Sin embargo, la primera vez que un cambio se convierte en estándar pasa por una evaluación completa de riesgos, con su correspondiente proceso de autorización. A partir de ese momento, el procedimiento se aplica cada vez que se repite, siempre que no se modifique ningún aspecto.

Quién lo aprueba: la autoridad responsable de los cambios lo autoriza una sola vez. No pasa por el CAB (Change Advisory Board - Comité Asesor de Cambios).

Cuánto tarda: de minutos a horas.

Ejemplos: restablecimiento de contraseñas, actualización de definiciones del antivirus, creación de una cuenta de usuario a partir de una plantilla aprobada, provisión de una configuración estándar de la laptop y aplicación de un parche de rutina preaprobado.

Cambio normal

Un cambio normal es aquel que está planificado, pero no es estándar ni de emergencia. El proceso completo incluye una Solicitud de Cambio (RFC - Request for Change), una evaluación de los riesgos y del impacto, la autorización correspondiente y la programación de dicha modificación.

Esta categoría abarca una amplia variedad de situaciones: desde un pequeño ajuste en la configuración en un servidor hasta el reemplazo de un sistema central del que dependen cientos de personas.

ITIL gestiona esta variedad mediante la evaluación de los riesgos, en lugar de crear subcategorías adicionales. Así, el responsable de los cambios analiza las dependencias y el impacto potencial y, a partir de ello, determina si el cambio requiere una revisión completa del CAB o puede avanzar con un proceso de autorización más simple.

Cabe aclarar que los cambios que afectan servicios críticos, varios equipos o sistemas regulados requieren una revisión completa.

Quién lo aprueba: el responsable de los cambios, cuando se trata de ajustes de riesgo bajo o medio; o el CAB, cuando son de alto riesgo o se consideran cambios mayores.

Cuánto tarda: de días a semanas.

Ejemplos: actualizar una base de datos de producción, migrar el correo electrónico a una nueva plataforma, implementar una nueva aplicación o reconfigurar un segmento de la red.

Cambio de emergencia

Un cambio de emergencia es de alta urgencia y gran impacto, por lo cual debe realizarse lo antes posible -dentro de los límites que permita el nivel de riesgo- para resolver un incidente grave o contener una amenaza de seguridad activa.

El proceso del cambio de emergencia es acelerado, ya que la evaluación, la autorización y la implementación se realizan en un plazo más reducido.

Un ECAB (Emergency Change Advisory Board - Comité Asesor de Cambios de Emergencia) o una autoridad responsable de los cambios con la jerarquía necesaria otorga la aprobación.

Como no siempre puede reconstruirse con precisión después de los hechos, la documentación -pasos ejecutados, comandos utilizados y valores modificados- se registra en tiempo real mientras se realiza el trabajo, ya que es fundamental para la revisión posterior. Dicha revisión es obligatoria una vez que el servicio vuelve a estar estable.

Quién lo aprueba: el ECAB o la autoridad responsable de los cambios para situaciones de emergencia, mediante un proceso acelerado.

Cuánto tarda: de inmediato, dentro de unas horas.

Ejemplos: aplicar un parche a una vulnerabilidad que está siendo explotada activamente, restaurar un servicio crítico que no funciona, implementar una regla de firewall de emergencia para detener un ataque en curso o recuperar una prestación tras una falla del servidor principal.

herramientas-de-gestion-del-cambio
Lectura recomendada
Leer artículo

¿Cómo decidir a qué categoría pertenece un cambio?

Para clasificar cada Solicitud de Cambio dentro de las categorías de cambio ITIL, es fundamental responder estas tres preguntas:

  1. ¿Existe un procedimiento documentado y preautorizado para este cambio específico? Si la respuesta es sí, se trata de un cambio estándar.
  2. ¿Es necesario realizarlo de inmediato para resolver o prevenir un incidente grave o una amenaza de seguridad activa? Si la respuesta es sí, se trata de un cambio de emergencia.
  3. Todos los demás casos corresponden a cambios normales.

El orden de estas preguntas es importante: comprobar primero si existe un procedimiento estándar evita que los cambios de rutina lleguen al CAB innecesariamente. Mientras que hay que reservar la vía de emergencia para situaciones que realmente lo requieran para mantener su carácter excepcional. Y determinar la autoridad para los cambios normales según el nivel de riesgo ayuda a que la supervisión sea proporcional a su impacto.

Esta clasificación se realiza al momento de recibir la solicitud y debe estar contemplada en la política de cambios de la organización. La documentación de las reglas del proceso de Gestión de Cambios ITIL permite que una misma solicitud se clasifique siempre de la misma manera, independientemente de quién la registre.

Errores comunes al clasificar cambios y qué cuestan

La mayoría de las clasificaciones incorrectas se producen por razones prácticas: los equipos necesitan avanzar más rápido, los procedimientos establecidos no se revisan desde hace años o existen dudas sobre cómo debería gestionarse un cambio. Aunque estas decisiones parecen poco relevantes en el momento, suelen provocar demoras, implementaciones fallidas o problemas de cumplimiento.

Estos son algunos de los errores más frecuentes y sus consecuencias:

Derivar los cambios estándar al CAB

ITIL 4 considera una práctica inadecuada enviar todos los cambios estándar al CAB, porque estos ya fueron evaluados, documentados y preautorizados.

Los resultados suelen ser predecible:

  • Mayor tiempo de ejecución para las tareas de rutina.
  • Dedicación del CAB en solicitudes de bajo riesgo en lugar de abocarse a las discusiones relevantes.
  • Menor tiempo para evaluar cambios complejos o de alto riesgo.

En lugar de mejorar la gobernanza, este enfoque suele ralentizar la entrega sin reducir el riesgo.

Marcar un cambio normal como de emergencia

Los equipos clasifican un cambio planificado como de emergencia simplemente para evitar esperar una autorización o la próxima ventana de mantenimiento. Aunque esto puede acelerar la implementación a corto plazo, también pasa por alto las revisiones para identificar riesgos técnicos y del negocio.

Entre sus consecuencias más habituales se encuentran:

  • Aumentos de los cambios fallidos o revertidos.
  • Pruebas o planes de reversión incompletos.
  • Documentación insuficiente.
  • Uso de los cambios de emergencia como práctica habitual en lugar de mantenerlos como una excepción.

En definitiva, cuando todos los cambios se consideran urgentes, el proceso de emergencia pierde su propósito.

Tratar un cambio de alto riesgo como estándar

Un cambio no debería considerarse estándar simplemente porque ya se realizó anteriormente. Si las circunstancias se modificaron o si la implementación afecta sistemas de producción, dependencias críticas o entornos regulados es necesario realizar una nueva evaluación.

La clasificación incorrecta de estos cambios suele provocar:

  • Análisis de riesgos insuficientes.
  • Falta de una autorización formal.
  • Ausencia de procedimientos de reversión.
  • Interrupciones del servicio que podrían haberse evitado.

Un cambio estándar es aquel que es repetible, está bien documentado, es de bajo riesgo y cuenta con una preautorización formal; no simplemente uno que resulta familiar.

Documentar de forma insuficiente los cambios de emergencia

Si bien los cambios de emergencia deben ejecutarse rápidamente, eso no significa que puedan prescindir de la documentación. Para garantizar la trazabilidad y mejorar la gestión en el futuro, hay que registrar qué se modificó, quién lo autorizó y por qué fue necesario utilizar el proceso de emergencia.

Una documentación deficiente dificulta:

  • Realizar revisiones posteriores a la implementación.
  • Identificar problemas recurrentes.
  • Demostrar el cumplimiento durante las auditorías.
  • Mejorar los procedimientos de respuesta ante futuras emergencias.

Cuanto más rápido se implementa un cambio, más valor adquiere contar con una buena documentación posterior.

El punto en común de todos estos casos es que las categorías de cambio ITIL permiten adaptar el nivel de supervisión al riesgo, y no acelerar o ralentizar el trabajo de manera arbitraria.

proceso-de-gestion-del-cambio
Lectura recomendada
Leer artículo

¿Cómo maneja InvGate Service Management los tres tipos de cambio ITIL?

La clasificación correcta de los cambios constituye una decisión política, pero su aplicación de forma consistente depende del uso de una plataforma eficaz.

InvGate Service Management admite los tres tipos de cambio ITIL mediante un único flujo de trabajo de Habilitación de Cambios:

  • Un editor de flujos de trabajo sin código que ofrece el método de arrastrar y soltar permite modelar el recorrido que puede seguir cada tipo de cambio: un flujo automatizado para los estándar, uno completo de evaluación y aprobación para los normales y una ruta acelerada para los de emergencia.
  • La evaluación de los riesgos asistida por IA analiza el alcance del impacto, las dependencias entre los servicios y los patrones históricos para generar un nivel de riesgo y las recomendaciones correspondientes antes de la aprobación. Esto ayuda a asignar cada cambio normal a la autoridad apropiada.
  • Toda solicitud de cambio puede avanzar desde el registro y la evaluación -incluyendo el CAB cuando sea necesario- hasta la autorización y la implementación, con la información requerida y visible en cada etapa.
  • Los aprobadores no requieren una licencia, por lo cual ampliar un CAB o una cadena de aprobaciones no implica costos adicionales.
  • La Gestión de Cambios, la Gestión de Incidentes y la Gestión de Problemas funcionan en una misma plataforma. En consecuencia, un cambio de emergencia asociado a un incidente grave mantiene todo el contexto entre los distintos módulos.
  • Los análisis de la Gestión de Cambios y los registros de auditoría cubren las necesidades de gobernanza y control de cambios, entre otras funciones. Esto incluye el manejo de los períodos de congelamiento de los cambios, en los que se restringen las modificaciones para reducir los riesgos operativos.

Otro aspecto fundamental es que InvGate Service Management está acreditado por PeopleCert para la práctica de Gestión de Cambios ITIL, por lo cual el proceso sigue estándares reconocidos.

Preguntas frecuentes

¿Cuáles son las tres categorías de cambio ITIL? Son los cambios estándar, normales y de emergencia. Cada uno se define según su riesgo, impacto y urgencia, además de seguir un proceso de aprobación diferente.

¿Cuál es la diferencia entre un cambio estándar y un cambio normal? Un cambio estándar está preautorizado y se ejecuta mediante un procedimiento documentado y repetible, por lo cual no requiere una aprobación en cada instancia. Un cambio normal está planificado, pero no cuenta con una aprobación previa: cada vez que se lleva adelante, requiere una Solicitud de Cambio, una evaluación de los riesgos, la autorización correspondiente y la programación de su implementación.

¿Un cambio mayor es una categoría independiente de ITIL? No. En ITIL 4, un cambio mayor es un cambio normal de alto riesgo. La antigua distinción entre cambios mayores y menores se aborda mediante la evaluación de los riesgos, que determina si uno normal debe pasar por el CAB o requiere un proceso de aprobación más simple.

¿Quién aprueba un cambio de emergencia? Un ECAB o una única autoridad responsable de los cambios de alto nivel, mediante un proceso acelerado. Una vez que el servicio se estabiliza, se realiza una revisión posterior a la implementación.

Prueba InvGate como tu solución ITSM

Pruébalo 30 días sin costo - Sin tarjeta de crédito

Precios claros

Sin sorpresas ni cargos ocultos: solo precios claros que se adaptan a tus necesidades.

Ver Precios

Migración sencilla

Nuestro equipo garantiza que tu transición a InvGate sea rápida, fluida y sin complicaciones.

Ver Customer Experience