Change Management (Control)

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.

Change Management (Emergencias)

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.

Change Management (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.

Change Management (Implementación)

Aunque la Gestión de Cambios NO es la encargada de implementar el cambio, algo de lo que se encarga habitualmente la Gestión de Versiones, si lo es de supervisar y coordinar todo el proceso.

En la fase de desarrollo del cambio se deberá monitorizar el proceso para asegurar que:

  • Tanto el software desarrollado como el hardware adquirido se ajustan a las especificaciones predeterminadas.
  • Se cumplen los calendarios previstos y la asignación de recursos es la adecuada.
  • El entorno de pruebas es realista y simula adecuadamente el entorno de producción.
  • Los planes de “back-out” permitirán la rápida recuperación de la última configuración estable.

Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoración preliminar de los nuevos sistemas en lo que respecta a su:

  • Funcionalidad.
  • Usabilidad.
  • Accesibilidad.

La opinión de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada en caso de que se encuentren objeciones justificadas al cambio (debe tenerse en cuenta la resistencia habitual al cambio por parte de cierto tipo de usuarios).

Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es función tanto de la Gestión de Cambios como del Service Desk mantener informados a los usuarios de los futuros cambios y, dentro de lo posible, hacerles participes del mismo:

  • Escuchando sus sugerencias.
  • Comunicando las ventajas asociadas.
  • Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepción de mejora debe ser compartida por usuarios y clientes.

Change Management (Planificación)

La planificación es esencial para una buena gestión del cambio.

Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede desencadenar una reacción en cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de “back out” que permitan la recuperación de la última configuración estable antes del cambio. Pero esto obviamente no es suficiente.

En primer lugar el CAB debe reunirse periódicamente para analizar y eventualmente aprobar los RFCs pendientes y elaborar el FSC o calendario del cambio correspondiente.

Para su aprobación el cambio se debe evaluar minuciosamente:

  • ¿Cuáles son los beneficios esperados del cambio propuesto?
  • ¿Justifican esos beneficios los costes asociados al proceso de cambio?
  • ¿Cuáles son los riesgos asociados?
  • ¿Disponemos de los recursos necesarios para llevar a cabo el cambio con garantías de éxito?
  • ¿Puede demorarse el cambio?
  • ¿Cuál será el impacto general sobre la infraestructura y la calidad de los servicios TI?
  • ¿Puede el cambio afectar los niveles establecidos de seguridad TI?

En el caso de cambios que tengan un alto impacto debe también consultarse a la dirección pues pueden entrar en consideración aspectos de carácter estratégico y de política general de la organización.

Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe evaluarse si este ha de ser implementado aisladamente o dentro de un “paquete de cambios” que formalmente equivaldrían a un solo cambio. Esto tiene algunas ventajas:

  • Se optimizan los recursos necesarios.
  • Se evitan posibles incompatibilidades entre diferentes cambios.
  • Sólo se necesita un plan de back-out.
  • Se simplifica el proceso de actualización de la CMDB y la revisión post-implementación.