Existe una frase que resume décadas de gestión de servicios: “no existe cambio sin riesgo; existe cambio sin control”. Actualizar un servidor, cambiar una regla de firewall, alterar un flujo del ERP — cada una de estas acciones puede tumbar un servicio. La gestión de cambios existe para que la modificación sea planificada, aprobada y reversible.

Esta guía recorre el módulo de Cambios del Portal Nyverra ITSM: el concepto de RFC, tipos y evaluación de riesgo, el papel del CAB, el flujo de aprobación (con la regla que impide la autoaprobación), la ventana de implementación y el plan de rollback, además de la vinculación con problemas, tickets y liberaciones.

Interfaz del módulo en el Portal Nyverra ITSM.

Cambio, RFC y su lugar en ITIL

Un cambio (código CHG) es una modificación planificada en servicios o infraestructura. Cada solicitud de cambio se registra como una RFC (Request for Change), que incluye descripción, tipo, riesgo, impacto, plan de implementación y plan de retorno.

Para no confundir las disciplinas ITIL:

Disciplina	Pregunta que responde
Incidente	“¿Cómo restauro el servicio ahora?”
Problema	“¿Por qué sucedió esto?”
Cambio	“¿Cómo cambio con seguridad?”
Liberación	“¿Qué se despliega junto en esta ventana?”

El cambio es el vínculo entre la causa raíz identificada (problema) y la entrega coordinada (liberación).

Tipos y riesgo: no todo cambio es igual

Tratar un cambio de disco como una actualización de ERP es receta para el caos. El Portal trabaja con tipos de cambio que definen el nivel de control:

Tipo	Característica	Control típico
Standard	Repetitivo, de bajo riesgo, preautorizado	Flujo ligero
Normal	Cambio planificado común	Aprobación y ventana
Emergency	Corrección urgente para restaurar el servicio	Flujo más rápido, aprobación retroactiva

El riesgo y el impacto informados en la RFC determinan quién aprueba y cuánto detalle exige el plan. Los cambios de alto riesgo solo deberían avanzar con un plan de rollback documentado.

El CAB (Comité de Asesoramiento de Cambios)

El CAB es el foro que evalúa los cambios de mayor impacto. En el Portal, esto se traduce en reuniones del CAB y en el registro de decisiones: quién evaluó, qué se decidió y por qué. Los cambios mayores pueden requerir esta deliberación antes de la aprobación; los cambios simples siguen con aprobación directa. El objetivo del CAB no es burocratizar, sino distribuir la responsabilidad de la decisión.

Quién lo usa

Perfil	Uso típico
Técnico / gestor de cambios	Crear, enviar, implementar
Aprobador / CAB	Aprobar o rechazar, con comentario
Representante del cliente	En cambios con cliente identificado, puede aprobar (perfil CUSTOMER)

El ciclo de vida de un cambio

1. Borrador: el solicitante prepara la RFC (título, descripción, tipo, riesgo, impacto, ventana, plan).
2. Envío para aprobación: la RFC entra en la cola de aprobación.
3. Aprobación / rechazo: el aprobador lee impacto y rollback y decide. El rechazo suele devolver la RFC para corrección.
4. Implementación: aprobada, el cambio se implementa en la ventana planificada.
5. Cierre: se registra el resultado y se vinculan los elementos resueltos.

La regla de la autoaprobación

Un principio de control interno, reforzado por el Portal: quien crea no aprueba su propio cambio (ni su propio ticket). Esta segregación de funciones evita que la autorización se convierta en una formalidad. Por eso, al enviar una RFC, esta no aparece en su cola de aprobaciones: va a otros aprobadores.

Ventana, rollback y evidencias

• Ventana de implementación: el período autorizado para ejecutar el cambio. Fuera de ella, la ejecución es indicio de un proceso laxo.
• Plan de rollback: cómo volver atrás si algo sale mal. En cambios de alto riesgo, es obligatorio.
• Vínculos: el cambio registra los tickets/problemas que resuelve y la liberación a la que pertenece, cerrando la pista de auditoría.

Reglas de negocio

Regla	Explicación
Los tipos importan	Emergency tiene flujo más rápido; Normal pasa por más controles.
CAB	Los cambios mayores pueden requerir reunión/registro de decisión, según la configuración.
Aprobación	Sin resolver la aprobación pendiente, no se avanza el estado indebidamente.
Rollback	Documentar el plan de retorno antes de la implementación en cambios de alto riesgo.
Autoaprobación	El creador no aprueba su propia RFC (ADR-015).

Cómo usar: paso a paso

1. Cree el cambio: Gestión de servicios → Cambios → Nuevo; indique título, descripción, tipo, riesgo, impacto, ventana y plan.
2. Guarde como borrador mientras ajusta, o envíe para aprobación.
3. Apruebe/rechace: en el detalle o en Aprobaciones pendientes; lea impacto y rollback y registre un comentario.
4. Implemente dentro de la ventana y registre el resultado.
5. Vincule tickets/problemas resueltos y la liberación correspondiente.

Buenas prácticas

• Nunca registre un cambio sin plan de rollback, sobre todo en riesgo alto.
• Use el cambio como cierre del problema: problema → RCA → cambio → liberación.
• Combine la ventana con el Downtime Manager para suprimir alertas de monitoreo durante la intervención.
• Para cambios de emergencia, registre la aprobación retroactiva y documente la decisión.
• Comunique a las partes afectadas antes de la ventana: cliente avisado es cliente satisfecho.

Errores comunes

Situación	Qué hacer
“Voy a editar el estado” sin aprobación	Respete el flujo; la aprobación existe por segregación de funciones.
Cambio sin ventana definida	Defina inicio/fin; la ejecución fuera de ventana rompe el control.
RFC sin vínculo con el problema	Vincule para mantener la trazabilidad de la causa raíz.

Preguntas frecuentes

¿Cuál es la diferencia entre cambio y liberación?
El cambio es la modificación individual; la liberación agrupa varios cambios que entran juntos en producción.

¿Puedo aprobar el cambio que yo creé?
No. El Portal aplica la regla de autoaprobación prohibida.

¿Emergency dispensa de aprobación?
Dispensa el proceso largo, no el control: la aprobación puede ser retroactiva, pero queda registrada.

Automatice vía API

El módulo está expuesto vía API (/api/mudancas, /api/cab-reunioes, vínculo /api/problema-mudanca-links), con transiciones de estado y aprobación controladas por RBAC (CHANGE_*). Referencia en developer.nyverra.com.

Escenarios de uso: tipos de cambio en la práctica

1. Cambio estándar (Standard). Reiniciar un servicio conocido, aplicar un parche aprobado, agregar un usuario a un grupo. Son operaciones repetitivas y de bajo riesgo, con flujo ligero: no deberían detenerse en el CAB. El valor está en registrar para mantener la pista, incluso cuando la ejecución es casi automática.

2. Cambio normal con ventana. Actualizar el ERP, cambiar un firewall, migrar una base de datos. Aquí entran evaluación de riesgo, aprobación, ventana de mantenimiento y plan de rollback. Es el cambio que más se beneficia del vínculo con el Downtime Manager y con la liberación.

3. Cambio de emergencia. Un incidente crítico exige una modificación inmediata. El flujo es acelerado; la aprobación es retroactiva, pero registrada. Sin esto, el “atajo” de producción se convierte en el incidente del mes siguiente sin que nadie sepa qué cambió.

KPIs de gestión de cambios

Indicador	Qué revela
Tasa de éxito (cambios sin incidente posterior)	Calidad de la planificación
% de cambios de emergencia	Cuánto sigue siendo reactiva la operación
Tiempo promedio de aprobación	Agilidad del CAB/flujo
Cambios con rollback ejecutado	Precisión de la evaluación de riesgo
Cambios fuera de la ventana	Disciplina de ejecución

Una caída en el porcentaje de cambios de emergencia suele indicar madurez: la organización pasó a planificar en lugar de apagar fuegos.

Automatización e integración

Gran parte del trabajo de cambio es predecible. Las reglas de Automatización pueden notificar a los afectados, abrir tareas estándar e iniciar el Downtime automáticamente al aprobar un cambio. Integrar monitoreo y CMDB permite prever el impacto antes de enviar la RFC: quién depende de lo que va a cambiar. Es la diferencia entre cambiar “a ciegas” y cambiar sabiendo exactamente el alcance.

Conclusión

La gestión de cambios es el arte de modificar sin sorprender. Con tipos y riesgo, CAB, aprobación segregada, ventana y rollback, el Portal Nyverra ITSM brinda a TI el control que la producción exige, y la tranquilidad que el negocio espera.