Gestor de Cambios: es el responsable del proceso del cambio y como tal debe ser el último responsable de todas las tareas asignadas a la Gestión de Cambios. En grandes organizaciones el Gestor de Cambios puede disponer de un equipo de asesores específicos para cada una de las diferentes áreas.

Consejo Asesor de Cambios (CAB): es un órgano interno, presidido por el Gestor de Cambios, formado principalmente por representantes de las principales áreas de la gestión de servicios TI. Sin embargo, en algunos casos también puede incorporar:
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Evaluación.

Antes de proceder al cierre del cambio es necesario realizar una evaluación que permita valorar realmente el impacto del mismo en la calidad del servicio y en la productividad de la organización.
 

Los aspectos fundamentales a tener en cuenta son:

 

• ¿Se cumplieron los objetivos previstos?

• En que medida se aparto el proceso de las previsiones realizadas por la Gestión de Cambios.

• ¿Provocó el cambio problemas o interrupciones del servicio imprevistas?

• ¿Cuál ha sido la percepción de los usuarios respecto al cambio?

• ¿Se pusieron en marcha los planes de "back-out" en alguna fase del proceso?¿Por qué?

Si la evaluación final determina que el proceso y los resultados han sido satisfactorios se procederá al cierre de la RFC y toda la información se incluirá en la PIR asociada.

Cambios de Emergencia.

Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación deficiente a veces resultan inevitables.
 

Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios afectados o porque se han visto involucrados sistemas o servicios críticos para la organización, debe encontrar una respuesta inmediata. Es frecuente que la solución al problema requiera un cambio y que éste haya de realizarse siguiendo un procedimiento de urgencia.

El procedimiento a seguir en estos casos debe estar debidamente previsto. Por ejemplo, se deben establecer protocolos de validación de los cambios urgentes que pueden requerir:

 

• La reunión urgente del CAB y/o EC si esto fuera posible.

• Una decisión del Gestor del Cambio si es imposible demorar la resolución del problema o éste sucede durante un fin de semana o periodo vacacional (lo que puede dificultar la reunión del EC).

Como el objetivo prioritario en estos casos es restaurar el servicio es a menudo frecuente que los procesos asociados sigan un orden inverso al usual: tanto los registros en la CMDB como la documentación asociada al cambio se realicen a posteriori.

Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma información de la que dispondríamos tras un cambio normal. Si esto no fuera así se podrían provocar situaciones de cambios futuros incompatibles, configuraciones registradas incorrectas, etc. que serían fuente de nuevas incidencias y problemas.

Control del Proceso.

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios.
 

Para que estos informes ofrezcan una información precisa y de sencilla evaluación es imprescindible elaborar métricas de referencia que cubran aspectos tales como:

 

• RFCs solicitados.

• Porcentaje de RFCs aceptados y aprobados.

• Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente.

• Tiempo medio del cambio dependiendo del impacto y la prioridad

• Número de cambios de emergencia realizados.

• Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.

• Numero de back-outs con una detallada explicación de los mismos.

• Evaluaciones post-implementación.

• Porcentajes de cambios cerrados sin incidencias ulteriores.

• Incidencias asociadas a cambios realizados.

• Número de reuniones del CAB con información estadística asociada: número de asistentes, duración, nº de cambios aprobados por reunión, etc.

Caso Práctico.

Los clientes y proveedores de "Cater Matters" están utilizando cada vez más los servicios online de la empresa para gestionar tanto los pedidos como la cadena de suministro.
 

El sistema implantado en la actualidad, aunque cumple básicamente con los objetivos de negocio, no estaba diseñado para soportar un nivel de actividad elevado. Tanto la Gestión de Disponibilidad como la Gestión de la Capacidad han informado de deficiencias en el proceso y de futuros cuellos de botella si se sigue con el ritmo de crecimiento actual.
 

Por otro lado, la dirección de la empresa ha decidido reforzar su presencia online y ofrecer a sus clientes unos más elevados niveles de servicio para incrementar su cuota de mercado.
 

Todo ello requiere un cambio sustancial en la estructura de software y hardware de los servicios de Internet y su interconexión con el software de gestión interna de la organización (ERP).
 

Por todo ello ha sido la propia dirección de la empresa la que ha elevado una RFC a la Gestión de Cambios que tiene por objetivos:

 

• Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y capacidad de respuesta.

• Desarrollar una serie de WebServices que permitan:

 

• Integrar directamente el sistema de pedidos online en el ERP de la empresa.

• Realizar un seguimiento de todo el proceso de pedido.

• Gestionar remotamente junto a los proveedores toda la cadena de suministro.

• Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores.

Tras registrar adecuadamente la RFC:

 

• Se le otorga el estatus de "aceptado" y se le asigna provisionalmente una prioridad normal y un alto impacto.

• Se convoca una reunión del CAB para la cual se solicita la asistencia de los responsables de e-commerce y programación web.

• Se solicita una evaluación preliminar del proyecto a una consultora externa que supervisó todo el proceso de implementación del sistema actual.

Previamente a la reunión del CAB el Gestor del Cambio elabora, en estrecha colaboración con las Gestiones de la Capacidad, de la Disponibilidad, Financiera y de Niveles de Servicio, así como con la dirección y Gestión de Proyectos:

 

• Una evaluación inicial de costes y recursos necesarios.

• Una valoración del impacto de los cambios en la infraestructura TI.

• Un cronograma preliminar del proceso.

• Una encuesta para que el Service Desk sondee la opinión de los clientes respecto a los posibles cambios.

Sopesando la documentación aportada y la estrategia de negocio de la organización el CAB aprueba el cambio y:

 

• Determina el calendario definitivo del cambio.

• Asigna los recursos, internos y externos, necesarios.

• Desarrolla un plan que permita la convivencia temporal de ambos sistemas online para asegurar la continuidad del servicio:

 

• Duplicación de toda la estructura web: se compraran nuevos servidores para que los antiguos puedan prestar servicio permanentemente y estén dispuestos inmediatamente para el "back-out".

• Se desarrollarán aplicaciones de "traducción" que permitan mantener actualizadas las bases de datos antiguas para evitar la perdida de datos en caso de "back-out".

• Informa a la Gestión de Configuraciones sobre todos los CIs afectados por el cambio.

• Solicita la colaboración de la misma consultora que implanto el sistema actual para que realice una auditoria externa de todo el proceso.

• Elabora toda la información necesaria para que la Gestión de Versiones comience todo el proceso de pruebas e implementación.

Tras la implementación del cambio y en colaboración con el "Soporte al Servicio" y la "Provisión del Servicio" la Gestión de Cambios:

 

• Confirma el éxito del cambio:

 

• El nuevo sistema dispone de la capacidad suficiente para proporcionar los niveles de servicio y disponibilidad previstos.

• El nuevo sistema funciona sin errores aparentes.

• Los clientes y proveedores han percibido el cambio como una mejora en la prestación de servicios.

• Ha mejorado la productividad.

• Se asegura que todo el cambio ha sido correctamente registrado en la CMDB.

• Evalúa el proceso.

• Da por cerrado el cambio.