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.
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.
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.
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.
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.
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:
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:
¿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:
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.
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.
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.
Para asimilar la eficiencia y la eficacia del proceso de gestión del cambio , el equipo central identificó los siguientes KPI.
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.
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.
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.
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.
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.
Lecciones de mejores prácticas de ITSM - Ver PDF .
ITIL ® es una marca registrada de AXELOS Limited. Todos los derechos reservados.