Lecciones de mejores prácticas de ITSM

Ver PDF

(Para descargar, haga clic derecho y guarde)

Guión

Un banco mediano de la India decidió administrar sus operaciones de infraestructura y el desarrollo de aplicaciones implementando la administración de servicios de TI (ITSM) . Por lo tanto, el equipo de TI del banco adoptó un enfoque por fases y se centró en tres procesos ITIL ^® : gestión de incidentes , cumplimiento de solicitudes y gestión de cambios . Primero, el equipo de TI diseñó un enfoque de mejores prácticas basado en el marco de ITIL para los tres procesos, capacitó a otros empleados, documentó un RACI y una matriz para los procesos y llegó a indicadores clave de rendimiento (KPI) acordados para realizar un seguimiento del desempeño. Luego, el banco compró una herramienta de gestión de servicios para seguir los flujos de trabajo o procesos basados ​​en las mejores prácticas integradas en la herramienta ITSM.

En los siguientes tres meses, la herramienta supuso una gran diferencia para la organización. El jefe de proceso y cumplimiento revisó las métricas y los KPI e indicó que los incidentes y las solicitudes de servicio se manejaron bien, pero no las solicitudes de cambio.

Aquí están las instantáneas de los cambios registrados en el período de tres meses

Como se muestra en la Figura A, los cambios estándar fueron pocos, mientras que los cambios normales y de emergencia continuaron aumentando. Además, hubo varios cambios fallidos y la empresa comenzó a perder la esperanza en TI.

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

Se formó un equipo central compuesto por el jefe de infraestructura, el jefe de desarrollo de aplicaciones, el administrador de cambios y el administrador de la mesa de servicio para corregir la situación. Este equipo entrevistó a los equipos de soporte y desarrollo, analizó los datos para comprender las razones de los cambios fallidos, realizó un análisis de brechas y sugirió soluciones prácticas.

¿Qué causó tantos cambios fallidos?

Los equipos de infraestructura y aplicaciones estaban bajo presión para mejorar el rendimiento, actualizar los servidores y mejorar el tiempo de respuesta de todos los cambios que se trasladaban a la producción. No tenían visibilidad de la relación ascendente y descendente de los componentes que estaban experimentando cambios. Por ejemplo, cuando un servidor de intercambio estaba inactivo, el equipo de infraestructura no podía ubicar la información en la herramienta ITSM . El equipo tuvo que depender de expertos en la materia (PYME) o del equipo del servidor de intercambio. Y cuando las pymes 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 manera concluyente el impacto de los cambios.

¿Cómo abordó esto el equipo central?

El equipo central entendió la necesidad de construir un sistema de gestión de la configuración (CMS) para capturar la infraestructura completa y la topología de la aplicación con atributos y relaciones.

El equipo enumeró los servicios comerciales críticos y construyó una estructura de árbol de servicios que incorporaba atributos para varios dispositivos, junto con las relaciones principales y secundarias asociadas, como se muestra en la Figura D. El equipo identificó la topología completa y la firmó en el servidor, almacenamiento, y pymes de la red y lo 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 de cambios futuros o realizar un seguimiento de los cambios planificados y sus fechas de publicación.

¿Qué hizo el equipo central para optimizar el flujo de trabajo del cambio y garantizar la visibilidad?

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

Definición de normas y estándares de gestión del cambio

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

• Todos los cambios normales deben entrar en producción una vez cada 15 días.
• Todos los cambios deben incluirse con el lanzamiento una vez cada 15 días, sin excepción de los cambios normales.
• Todas las solicitudes de cambio (RFC) deben enviarse con al menos dos semanas de anticipación. Cualquier RFC que se requiera dentro de una semana será rechazada con el gerente del solicitante en el ciclo.
• Cualquier solicitud para acelerar los cambios normales, incluso en casos extremos, tenía que pasar por tres niveles de aprobación por parte de la gerencia. El equipo de TI hizo un seguimiento de las aprobaciones para controlar los cambios que se plantean.
• Los cambios de emergencia solo se considerarían en dos escenarios:
• Para resolver una interrupción no planificada, una interrupción importante o un incidente.
• Una versión completa que no se implementó debido a razones inevitables.

Definición de los diferentes tipos de cambio

Cambio estándar y cambio normal

Los cambios estándar son cambios preaprobados de bajo riesgo que ocurren con frecuencia y tienen un tiempo de respuesta rápido. Los cambios estándar se pueden implementar rápidamente y ayudar a gestionar los riesgos

Ejemplos de un cambio estándar:

• Movimiento de equipos de escritorio o independientes.
• Un parche estándar que se aplica a los servidores una vez al mes durante el período de mantenimiento acordado.

¿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:

• Actualizar el servidor de Exchange o cualquier otro hardware
• Configuración de alta disponibilidad o clúster para funciones comerciales vitales (VBF)
• Lanzamiento de una nueva versión para abordar los problemas informados

Acelerar o acelerar los cambios

Los cambios acelerados se plantean debido a una necesidad urgente, como un requisito legal o comercial. Estos cambios no están relacionados con la restauración de un servicio.

Cambio de emergencia vs cambio acelerado

La junta asesora de cambios (CAB) definió reglas y regulaciones claras para calificar los cambios de emergencia y acelerados y comunicó estas reglas a toda la organización.

Cambiar calendario para una mejor visibilidad

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

Definición de los indicadores clave de desempeño

Para asimilar la eficiencia y la eficacia del proceso de gestión del cambio , 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 causado por cambios normales y de emergencia
• Número o porcentaje de cambios no planificados o de emergencia
• Tiempo promedio para implementar cambios
• Número y porcentaje de cambios rechazados por el CAB
• Número y porcentaje de cambios no autorizados

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

La junta asesora de cambios garantiza mejores revisiones de cambios

El equipo central se aseguró de que el CAB se reuniera una vez a la semana el jueves entre las 7 p.m. y las 9 p.m. hora local. Los representantes de la infraestructura, la aplicación, la mesa de servicio y los equipos de administración de versiones revisaron todos los cambios planificados. Sin embargo, el administrador de cambios fue la autoridad decisiva final.

El CAB rechazó los cambios principalmente debido al incumplimiento de los pasos y protocolos esperados de evaluación, revisión y BIA (Business Impact Analysis). Los propietarios del cambio fueron responsabilizados por la falla. El equipo central se vio obligado a adoptar medidas estrictas para evitar este tipo de sucesos en el futuro. Los cambios se evaluaron en 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 completaron sin autorización, principalmente porque el equipo de infraestructura estaba bajo presión para realizar los cambios rápidamente. Como resultado, muchos cambios se realizaron 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 designaron guardianes de la etapa para los equipos de infraestructura, aplicaciones y bases de datos para garantizar que los pasos no se omitieran cuando se realiza un cambio. Los encargados del escenario tenían una lista de listos que incluía los resultados de las pruebas, las aprobaciones, las firmas de todos los equipos interesados ​​y un plan de retirada. En caso de infracción, los guardianes del escenario asumieron la responsabilidad que afectó sus medidas de evaluación y desempeño.

Otro motivo de los cambios no autorizados fue que los equipos de aplicaciones actualizaron la CMDB o CMS después del lanzamiento de la versión.

El equipo central se aseguró de que se realizaran auditorías todas las semanas para comparar el estado actual de CMS con el RFC asociado y se destacó cualquier desviación al propietario del CI y al propietario del servicio para una acción inmediata. A su vez, el propietario del servicio cerró el círculo y tomó medidas firmes. Este proceso se prolongó durante cuatro a seis semanas y el equipo adoptó el hábito de seguir la regla sin excepciones.

Implementación y capacitación en comunicación

Después de que el equipo central implementó los controles apropiados, el proceso de comunicación se simplificó para que los equipos involucrados puedan ser notificados del nuevo cambio. Entonces, los jefes de negocio pusieron en marcha el proceso formal de gestión del cambio, al que siguieron sesiones de sensibilización y programas de formación.

La ejecución en el siguiente período de tres meses mostró mejoras visibles, como se ve en la Figura F.

Lecciones aprendidas (CSI)

• El equipo de TI del banco entendió que la construcción de un sistema de administración de configuración sólido con información actualizada de todos los componentes de TI es esencial para un proceso exitoso de administración de cambios y versiones.
• El cronograma anticipado de cambios, el período de mantenimiento planificado y los planes de lanzamiento son fundamentales para administrar el volumen y la duración de los cambios y garantizar una implementación sin problemas.
• Hacer cumplir una política requiere practicidad, diligencia y aceptación. Las nuevas políticas eran menos numerosas, pero eran importantes para el éxito del proceso de gestión de cambios (por ejemplo: CAB, cambios no autorizados y PIR).
• Los KPI relevantes y prácticos ayudan a los equipos a ser eficientes y eficaces.
• El proceso y las herramientas tienen que funcionar en conjunto y la ausencia de uno u otro afectará gravemente la mejora continua del servicio (CSI).
• La revisión posterior a la implementación de los cambios e implicaciones clave proporcionó información valiosa sobre áreas potenciales para mejorar y controlar los cambios.

Línea de fondo:

El banco mejoró su eficiencia y eficacia general del proceso de gestión del cambio asegurando un buen gobierno, implementando procesos y alineación de herramientas y ofreciendo un liderazgo sólido.

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