Cómo implementar un proceso de solicitud de cambio

Con una secuencia de pasos clara, los cambios se evalúan, aprueban e implementan con total visibilidad y responsabilidad.

Con InvGate Service Management, puedes estandarizar la forma en que se solicitan y revisan los cambios, además de automatizar aprobaciones y asignaciones de tareas.

#1. Configura el proceso de solicitud de cambio

Configurar un proceso de Gestión de Cambios en InvGate Service Management es sencillo: selecciona la plantilla de Solicitud de cambios y adáptala a tus necesidades (puedes descargar la vista previa de la plantilla aquí).

1. Inicia sesión con rol de administrador y ve a: Configuración > Solicitudes > Procesos.
2. Selecciona Solicitud de cambios de la lista de plantillas.
3. Haz clic en Usar plantilla y se abrirá en el editor de diagramas, donde podrás ver y configurar el flujo y su secuencia de pasos.

Tip: Desde Configuración > Solicitudes > Procesos también puedes crear nuevos flujos de trabajo desde cero (haciendo clic en “Agregar”), importar procesos con extensión .sdw o ver y editar los existentes.

Si la plantilla cubre lo que necesitas, puedes usarla tal cual. Si quieres adaptarla, sigue leyendo.

#2. Edita la plantilla del proceso de solicitud de cambio

En el diagrama del flujo puedes definir cómo se comporta, quién lo gestiona y qué ve el usuario. Haz doble clic en cualquier bloque para abrir su configuración y modificar formularios, tareas, aprobaciones y más.

Esto es lo que hace cada bloque.

1. Formulario inicial

   El proceso comienza con un formulario inicial donde el solicitante ingresa la información necesaria para evaluar el cambio. Puedes agregar, quitar o modificar campos y decidir cuáles serán obligatorios.

   Campos por defecto:

   • Tipo de cambio (Emergencia, Estándar, Normal).
   • Descripción del cambio.
   • Motivo del cambio.
   • Elemento(s) de configuración involucrados.
   • Fecha y hora del cambio.
   • Plan de actividades (pasos para ejecutar el cambio).
   • Plan de rollback (acciones para volver atrás si es necesario).
   • Documentos (adjuntar archivos o documentación técnica).

   Tip: Incluye solo campos que realmente ayuden a tomar decisiones. Demasiados campos obligatorios pueden retrasar el proceso, sobre todo en solicitudes urgentes.

2. Categorizar el tipo de cambio

   Es un paso condicional que dirige el cambio al flujo de revisión y aprobación correcto:

   • ECAB (Emergency Change Advisory Board): Para cambios urgentes que deben implementarse rápidamente para evitar incidentes graves o resolver necesidades inmediatas.
   • CAB (Change Advisory Board): Para cambios estándar que requieren análisis detallado y planificación.
   • ELSE: Cambios de bajo riesgo que pueden aprobarse con mínima supervisión.
3. Evaluación de riesgo e impacto

   Los revisores evalúan el cambio según dos factores:

   • Riesgo: Alto / Medio / Bajo.
   • Impacto: Alto / Medio / Bajo.

   Estos valores permiten ubicar el cambio en una matriz de riesgo-impacto, priorizar esfuerzos de revisión y definir requisitos de aprobación.

4. Aprobación (CAB/ECAB)

   La solicitud se envía al grupo de aprobación correspondiente:

   • CAB para cambios estándar.
   • ECAB para cambios de emergencia.

   Resultados posibles:

   • Aceptado: El cambio pasa a la etapa de implementación.
   • Rechazado o cancelado: La solicitud se detiene, ya sea porque no cumple requisitos o por un cambio de prioridades. En este caso, se envía automáticamente un correo a los solicitantes y partes interesadas con la decisión. El flujo termina en un paso de “cancelado”.
5. Implementación

   Los cambios aprobados pasan a ejecución. Aquí se define una lista de tareas con nombre, descripción, fecha límite y responsable.

   Opciones adicionales:

   • Permitir nuevas tareas durante la ejecución – para manejar pasos imprevistos.
   • Tareas opcionales – permite avanzar sin completar todas las tareas.
6. Revisión

   Una vez implementado, el cambio se revisa para verificar resultados:

   • Se cumplieron las tareas.
   • Se completó en la fecha planificada.
   • No hubo efectos secundarios.
   • Se requiere reversión, sí/no.

   Incluye un campo de texto libre para documentar observaciones. Este registro sirve en auditorías y como referencia para futuros cambios.

7. Decisión de rollback

   Es un paso condicional que determina si se necesita un rollback:

   • Rollback si: si el cambio causa problemas o no cumple el objetivo.
   • Rollback no: si el cambio fue exitoso.

   Tip: Valida el plan de reversión en la etapa de aprobación para evitar sorpresas de último minuto.

8. Paso final

   Según la decisión anterior, el flujo continúa con:

   • Actividades de rollback: lista de tareas para restaurar el entorno al estado previo.
   • Notificación de cambio completado: correo automático a todos los interesados confirmando el cierre.

Publica tu proceso

Cuando tu proceso de solicitud de cambios esté listo:

1. Haz clic en el ícono de guardar y vuelve al menú de Procesos.
2. Haz clic en Publicar versión para activarlo.
3. Asígnalo a una categoría en el catálogo de servicios, en este caso “Solicitudes de cambio” bajo el departamento de IT.
4. Haz clic en Asignar ahora.

A partir de ese momento, cualquier solicitud de cambio seguirá el nuevo flujo configurado.

Personalización adicional para tu flujo de trabajo de solicitud de cambio

Como mencionamos, en InvGate Service Management, cada nodo de tu flujo de trabajo puede adaptarse a las políticas y estructura de aprobación de tu organización.

Al ajustar un flujo de trabajo de solicitud de cambio, no tienes que limitarte a la secuencia mostrada en una plantilla. Puedes:

1. Reordenar etapas – Por ejemplo, mover la evaluación de riesgos antes de la categorización si tu organización prefiere evaluar el alcance primero.
2. Ampliar formularios – Incluir campos obligatorios adicionales, como estimaciones de costos, participación de proveedores o enlaces a tickets relacionados de Incidentes o Problemas.
3. Agregar capas de aprobación adicionales – Por ejemplo, insertar un bloque de revisión extra para cambios que involucren CIs de alto impacto.
4. Insertar pasos condicionales – Crear ramas que omitan etapas innecesarias. Por ejemplo, saltar una revisión completa del CAB para cambios estándar previamente aprobados.
5. Correo electrónico – Añadir alertas automáticas por correo en puntos donde los interesados deban actuar o ser informados (ej.: pruebas finalizadas, inicio de rollback).
6. Incluir puntos de integración – Usar bloques de Web Service para actualizar tu CMDB, notificar a las herramientas de monitoreo o ejecutar scripts en los pipelines de despliegue.