Lecciones y ejemplos de mejores prácticas de ITSM:
Revisión de la gestión del cambio en un banco

Ver PDF

(Para descargar, haga clic con
el botón derecho y guárdelo)

Escenario

Un banco de tamaño medio de la India decidió gestionar sus operaciones de infraestructura y desarrollo de aplicaciones mediante la implementación de la gestión de servicios de TI (ITSM). Así pues, el equipo de TI del banco adoptó un enfoque por fases y se centró en tres procesos ITSM: gestión de incidentes, cumplimiento de solicitudes y gestión de cambios. En primer lugar, el equipo de TI diseñó un enfoque de mejores prácticas basado en el marco ITSM para los tres procesos, capacitó a otros empleados, documentó una RACI y una matriz para los procesos y llegó a unos indicadores clave de rendimiento (KPI) acordados para realizar un control del rendimiento. A continuación, el banco adquirió una herramienta de gestión de servicios para seguir flujos de trabajo o procesos basados en las mejores prácticas integradas en la herramienta ITSM.

En los tres meses siguientes, la herramienta marcó una gran diferencia en la organización. El responsable de procesos y cumplimiento revisó las métricas y los KPI e indicó que los incidentes y las solicitudes de servicio se gestionaban bien, pero no las solicitudes de cambio.

He aquí las instantáneas de los cambios registrados en el periodo de tres meses

Como se muestra en la Fig. A, los cambios estándar fueron escasos, mientras que los cambios normales y de emergencia siguieron aumentando. Además, se produjeron varios cambios fallidos y la empresa empezó a perder la esperanza en las TI.

El equipo central adopta el enfoque de gestión del cambio adecuado

Se formó un equipo central compuesto por el jefe de infraestructura, el jefe de desarrollo de aplicaciones, el director de cambios y el director de servicio al cliente para corregir la situación. Este equipo entrevistó a los equipos de asistencia y desarrollo, analizó los datos para comprender las razones de los cambios no exitosos, realizó un análisis de las deficiencias y sugirió soluciones prácticas.

¿Cuál fue la causa de tantos cambios insatisfactorios?

Los equipos de infraestructuras y aplicaciones estaban bajo presión para mejorar el rendimiento, actualizar los servidores y mejorar el tiempo de respuesta de todos los cambios que pasaban a producción. No tenían visibilidad de la relación ascendente y descendente de los componentes que estaban sufriendo cambios. Por ejemplo, cuando un Exchange Server se caía, el equipo de infraestructura no podía localizar la información en la herramienta ITSM. El equipo tuvo que recurrir a expertos en la materia (SME) o al equipo de Exchange Server. Y cuando los SME no estaban disponibles, el equipo siguió adelante con los cambios utilizando procedimientos independientes. Como resultado, los cambios no se analizaron y el equipo de revisión de cambios no pudo predecir de forma concluyente el impacto de los mismos.

¿Cómo lo abordó el equipo central?

El equipo central comprendió la necesidad de construir un sistema de gestión de la configuración (CMS) para registrar la topología completa de la infraestructura y las aplicaciones con atributos y relaciones.

El equipo enumeró los servicios críticos para el negocio y construyó una estructura de árbol de servicios que incluía atributos para varios dispositivos, junto con las relaciones principal y secundario asociadas, como se muestra en la Fig. D. El equipo identificó la topología completa y obtuvo el visto bueno de los SME de servidor, almacenamiento y red y la importó a la herramienta de gestión de servicios.

Además, los equipos no tenían visibilidad de los cambios planificados, programados e implementados. No existía un mecanismo adecuado para publicar el calendario previsto de cambios ni para realizar un control de los cambios previstos y sus fechas de publicación.

¿Qué hizo el equipo central para agilizar el flujo de trabajo de los cambios y garantizar la visibilidad?

El equipo central descubrió que los cambios se presentaban a menudo en el último minuto, sin tiempo suficiente para evaluarlos y ejecutarlos. Esto se debió a la falta de una disciplina y una gobernanza adecuadas para abordar la admisión y la ejecución de los cambios.

Definición de normas y estándares de gestión de cambios

Para evitar cambios de última hora, comunicaron las implicaciones, la justificación y el impacto en el negocio a los responsables de las empresas y obtuvieron la aprobación obligatoria con las siguientes condiciones:

• Todos los cambios normales deben pasar a producción una vez cada 15 días
• Todos los cambios deben incluirse en la liberación una vez cada 15 días, sin excepción para los cambios normales.
• Todas las solicitudes de cambio (RFC) deben presentarse con al menos dos semanas de antelación. Cualquier RFC que se solicite en el plazo de una semana será rechazada con el responsable del solicitante al corriente.
• Cualquier solicitud para acelerar los cambios normales, incluso en casos extremos, tenía que pasar por tres niveles de aprobación de la dirección. El equipo de TI realizó un control de las aprobaciones para regular los cambios que se planteaban.
• Los cambios de emergencia solo se contemplarían en dos supuestos:
• Para resolver una interrupción no planificada, una interrupción importante o un incidente.
• Una liberación completa no implementada por razones inevitables.

Definición de los distintos tipos de cambio

Cambio estándar y cambio normal

Los cambios estándar son cambios preaprobados de bajo riesgo que se producen con frecuencia y tienen un plazo de entrega rápido. Los cambios estándar pueden implementarse rápidamente y ayudan a gestionar los riesgos

Ejemplos de un cambio estándar:

• Movimiento de equipos desktop o autónomos.
• Un parche estándar que se aplica a los servidores una vez al mes durante la ventana de mantenimiento acordada

¿Qué es un cambio estándar?

Cuando un cambio normal se implementa con éxito unas cuantas veces, los procesos asociados como la planificación, la programación y la implementación se establecen y se vuelven predecibles y controlados. Es decir, el cambio se convierte en una tarea rutinaria y, por tanto, estándar.

Algunos ejemplos de cambios normales:

• Actualización de Exchange Server o de cualquier otro hardware
• Establecimiento de alta disponibilidad o clúster para funciones empresariales vitales (VBF)
• Rollout de una nueva liberación para solucionar los problemas comunicados

Acelerar o agilizar los cambios

Los cambios acelerados se plantean debido a una necesidad apremiante, como un requisito legal o empresarial. Estos cambios no están relacionados con el restablecimiento de un servicio.

Cambio de emergencia frente a cambio acelerado

El comité asesor de cambios (CAB) definió normas y reglamentos claros para calificar los cambios urgentes y acelerados y comunicó estas normas a toda la organización.

Calendario de cambios para una mejor visibilidad

El equipo central utilizó el calendario de cambios dentro de la herramienta de gestión de servicios para informar sobre el mantenimiento, los cambios y las liberaciones previstas y garantizar una mejor visibilidad a los equipos involucrados.

Definición de los indicadores clave de rendimiento

Para asimilar la eficiencia y la efectividad del proceso de gestión de cambios, el equipo central identificó los siguientes KPI.

• Número y porcentaje de cambios fallidos para cambios estándar, normales y de emergencia
• Número de incidentes y tiempo de inactividad del servicio causados por cambios normales y de emergencia
• Número o porcentaje de cambios no planificados o de emergencia
• Tiempo promedio de implementación de los cambios
• Número y porcentaje de cambios rechazados por el CAB
• Número y porcentaje de cambios no autorizados

Los cuatro primeros KPI se tomaron de la herramienta de gestión de servicios, mientras que el quinto y el sexto requirieron la intervención de expertos..

El comité asesor de cambios garantiza mejores revisiones de los cambios

El equipo central garantizó que el CAB se reuniera una vez a la semana, los jueves, entre las 7 P.M. y las 9 P.M., hora local. Representantes de los equipos de infraestructuras, aplicaciones, mesa de servicio y gestión de liberaciones revisaron todos los cambios previstos. Sin embargo, el director del cambio era la autoridad decisoria final.

El CAB rechazó los cambios principalmente debido al incumplimiento de los pasos y protocolos previstos de evaluación, revisión y BIA (análisis del impacto empresarial). Los propietarios del cambio fueron considerados responsables del fracaso. El equipo central se vio obligado a adoptar medidas estrictas para evitar que esto ocurriera en el futuro. Los cambios se evaluaron a partir de todos los escenarios posibles antes de la reunión del CAB.

Manejo de cambios no autorizados

Durante su discusión con las partes interesadas, el equipo central observó que alrededor del 20% de los cambios se realizaban sin autorización, principalmente porque el equipo de infraestructura estaba bajo presión para realizar los cambios rápidamente. Como resultado, muchos cambios se hicieron sin una solicitud de cambio o sin pasar por los procesos de revisión y aprobación.

Para hacer frente a esta situación, se nombraron guardianes de etapa para los equipos de infraestructura, aplicaciones y bases de datos con el fin de garantizar que no se omitieran los pasos cuando se realizara un cambio. Los guardianes de la etapa tenían una lista preparada que incluía los resultados de las pruebas, las aprobaciones, las firmas de todos los equipos involucrados y un plan de backout. En caso de infracción, los guardianes de la etapa asumían la responsabilidad que afectaba a su evaluación y a las medidas de rendimiento.

Otro motivo de los cambios no autorizados fue que los equipos de aplicación actualizaron la CMDB o el CMS después del rollout de la liberación.

El equipo central garantizó que se realizaran auditorías cada semana para comparar el estado actual del CMS con la RFC asociada y cualquier desviación se señalaba al propietario del CI y al propietario del servicio para que tomaran medidas inmediatas. A su vez, el propietario del servicio cerró el círculo y tomó medidas firmes. Este proceso duró de cuatro a seis semanas, y el equipo se acostumbró a seguir la norma sin excepciones.

Rollout de la comunicación y capacitación

Después de que el equipo central implementara los controles adecuados, se agilizó el proceso de comunicación para que los equipos implicados pudieran ser notificados del nuevo cambio. Así pues, los responsables de las empresas pusieron en marcha el proceso formal de gestión de cambios, al que siguieron sesiones de concienciación y programas de capacitación.

La ejecución en el siguiente periodo de tres meses mostró mejoras visibles, como se ve en la Fig. F.

Lecciones aprendidas (CSI)

• El equipo de TI del banco comprendió que la creación de un sólido sistema de gestión de la configuración con información actualizada de todos los componentes de TI es esencial para el éxito del proceso de gestión de cambios y liberaciones.
• El calendario previsto de cambios, la ventana de mantenimiento planificada y los planes de liberación son fundamentales para gestionar el volumen y la duración de los cambios y garantizar una implementación sin inconvenientes.
• Aplicar una política requiere sentido práctico, diligencia y aceptación. Las nuevas políticas eran menos numerosas pero importantes para el éxito del proceso de gestión de cambios (por ejemplo: CAB, cambios no autorizados y PIR).
• Unos KPI relevantes y prácticos ayudan a los equipos a ser eficientes y efectivos.
• El proceso y las herramientas tienen que funcionar en tándem y la ausencia de uno u otro afectará gravemente a la mejora continua del servicio (CSI).
• La revisión posterior a la implementación de los cambios clave y sus implicaciones proporcionó una valiosa información sobre las áreas potenciales de mejora y control de los cambios.

Conclusión:

El banco mejoró su eficiencia y efectividad general del proceso de gestión de cambios garantizando una buena gobernanza, implementando la alineación de procesos y herramientas, y ofreciendo un liderazgo sólido.

Este estudio de caso le proporciona las herramientas necesarias para estructurar, implementar y ejecutar cambios organizativos sin problemas. Si tiene alguna experiencia interesante con el proceso de gestión del cambio, compártala con nosotros en la sección de comentarios.