Mejores prácticas de gestión de cambios de ITIL que pueden reducir las interrupciones en las operaciones

Los equipos de cambio necesitan procesos claros para definir e identificar las amenazas a la estabilidad operativa, todo sin ralentizar la creación continua de nuevo valor. También deben permanecer flexibles para poder responder a los cambios continuos en el entorno empresarial, que pueden incluir cambios en la plataforma tecnológica.

Rápido, flexible y vigilante: Mejores prácticas de gestión de cambios de ITIL potenciar las operaciones de TI para hacer las tres. El uso de Análisis impulsados ​​por IA puede proteger aún más los entornos de operaciones de las interrupciones, preservando las funciones comerciales y mitigando el riesgo. Utilizando datos de todo el flujo de valor, junto con la IA, permite a los equipos mitigar los riesgos de interrupción, monitorear las amenazas a la estabilidad operativa y optimizar la toma de decisiones a la luz de los nuevos conocimientos derivados de los datos.

ITIL 4 proporciona orientación para las mejores prácticas de gestión de cambios, que puede reducir los riesgos comunes en la producción. Sin ser demasiado prescriptivo, las pautas de ITIL 4 proporcionan descripciones claras de las funciones y responsabilidades necesarias para mantener ciclos de gestión de cambios estables y predecibles.

Las siguientes mejores prácticas sugeridas por la guía ITIL 4 y los expertos en gestión de cambios pueden ayudar a las empresas que buscan mantener el rendimiento y abordar rápidamente las amenazas operativas.

Asegúrese de que cada cambio de TI tenga un valor comercial definido y un "por qué" claro

El primer paso con cualquier decisión relacionada con el cambio es comprender por qué se propone el cambio. Ya sea que el cambio haya sido instigado por una solicitud de cambio de los equipos de desarrollo o una propuesta de cambio dentro de las operaciones de TI, cada cambio debe considerarse desde la perspectiva del valor que ofrece a la organización. Adicionalmente, el cambio debe entenderse a la luz de los riesgos que presenta.

La definición de valor y riesgo puede, y debe, hacerse desde una perspectiva objetiva basada en métricas. Sin embargo, las organizaciones de TI primero deben estar preparadas para modelar los próximos cambios desde un punto de vista subjetivo para que puedan reconocer intrínsecamente el valor propuesto que aporta un cambio esperado.

El popular bloguero “Joe the IT Guy” define cuatro razones básicas generadoras de valor por las que se podría proponer un cambio:

1. Para corregir algo que ya falló o salió mal
2. Para evitar que algo falle o salga mal
3. Porque algo más ha cambiado, o va a cambiar, y necesitas hacer un cambio para seguir siendo compatible.
4. Porque necesita agregar, quitar o mejorar una capacidad

El primer tipo de cambio es reactivo a los problemas; dos y tres son proactivos/preventivos; y el número cuatro es el único de estos que ofrece directamente un nuevo valor.

Al considerar los cambios propuestos desde esta perspectiva, las organizaciones de TI pueden desarrollar métricas para cuantificar los tipos de cambios que están realizando. A los cambios se les puede asignar una categoría, por ejemplo, describiendo el propósito del cambio y si es una corrección o una nueva característica.

Si demasiados cambios se basan en necesidades reactivas, entonces la organización necesita mejores capacidades predictivas y de evaluación de riesgos. Los cambios relacionados con la compatibilidad y la prevención de fallas también tienden a consumir recursos y no crean un nuevo valor medible, sino que preservan el valor creado en otros lugares. Con esto en mente, la organización puede apuntar a una reducción en los cambios relacionados con la resolución o prevención de problemas.

Idealmente, a medida que la organización ajusta sus procesos y su enfoque para DevOps, una mayor proporción de cambios estará relacionada con la creación directa de valor. Si la organización busca continuamente cambios que provoquen la creación directa de valor, entonces puede evolucionar sus ofertas mientras se mantiene al día con los avances modernos.

Utilice métricas de cambio y KPI para comprender los riesgos de gestión de cambios asociados

Comprender el propósito al que sirven los cambios permite a las organizaciones cuantificar los cambios de manera más hábil utilizando métricas y KPI apropiados. El monitoreo de las métricas de cambio brinda retroalimentación para describir tendencias en curso, informar sobre la asignación de recursos e indicar cuándo las cosas van bien o mal.

Ejemplos de cambiar las métricas que pueden impulsar agility y la creación continua de valor incluyen:

• Cambiar tasa de éxito
• Cambios de emergencia implementados por período
• Volumen de incidentes/problemas relacionados con cambios

¿Qué métricas son las más importantes para predecir los riesgos de cambio? Los modelos de aprendizaje automático pueden responder esa pregunta en todas sus complejidades. Un algoritmo de ML examinará los datos de cambios históricos y los registros de fallas asociados para determinar qué métricas tienen la mejor capacidad para predecir futuros problemas, fallas e incidentes asociados con cambios. Los cambios propuestos pueden medirse luego en términos de los riesgos que plantean, incluida la probabilidad de los riesgos y cuán disruptivos podrían ser. Un modelo de puntuación puede facilitar una respuesta rápida a los riesgos de cambio identificados.

La medición de las métricas de cambio con estos métodos establece puntos de referencia para que TI visualice la estabilidad dentro de su entorno operativo actual, prediga qué cambios pueden ser inherentemente riesgosos y persiga objetivos de mejora continua para reducir las interrupciones del servicio mientras mantiene agility. El uso de modelos de puntuación también agiliza los enfoques necesarios para abordar el riesgo de cambio, reduciendo la cantidad de tiempo y energía que el CAB necesita para abordar cada cambio y mantener el canal de valor en movimiento.

Definir roles, responsabilidades y propiedad de las métricas de cambio

Definir roles y propiedad en TI tiene una forma única de producir resultados. Establecer responsabilidad en TI puede ayudar a los líderes a cumplir con los SLA, implementar iniciativas de CSI con éxito y reducir la cantidad de recursos necesarios para responder y prevenir interrupciones del servicio relacionadas con cambios.

Se pueden establecer diferentes roles y jerarquías. para diferentes contextos, lo que significa que una persona con propiedad sobre una métrica relacionada con el cambio puede ser el segundo al mando de otra.

Sin embargo, las funciones y responsabilidades siempre deben ser claras, documentadas y plenamente comprendidas para que TI funcione de manera eficiente. Este nivel de alto funcionamiento es especialmente importante durante las respuestas a incidentes mayores, donde los cambios de emergencia tienen una alta tasa de fallas que pueden crear, en lugar de resolver, nuevos problemas.

Los líderes de TI deben mapear las partes interesadas, los roles y las jerarquías para que se definan las responsabilidades y se comprenda la rendición de cuentas. Nada de esto necesita introducir procesos rígidos tampoco; en cambio, a los equipos se les puede dar autonomía con la comprensión final de que tienen el control del rendimiento de una métrica determinada, CI, o característica operativa.

Modele el impacto de los cambios operativos antes deploymento usando IA

Análisis predictivo de TI puede permitir a las organizaciones cuantificar los riesgos de cambio y comprender qué consecuencias puede tener un impulso de cambio dado. Luego pueden identificar la respuesta adecuada, que puede incluir aceptar el riesgo de cambio, mitigarlo modificando el cambio o evitar el riesgo deteniendo el cambio hasta que se pueda hacer menos riesgoso.

Los equipos de operaciones de TI también deben estar preparados en caso de que falle algún cambio de alto riesgo. Para fallas de cambio que resultan en una degradación del rendimiento, por ejemplo, los equipos pueden tener un plan de retroceso para restaurar el estado del entorno operativo anterior mientras se estudia el cambio con más detalle. Para una serie de cambios de alto riesgo que se prevé que, o ya han dado lugar, a un incidente o interrupciones del servicio, es posible que sea necesario congelar los cambios mientras se estabiliza el entorno operativo.

Los planes de contingencia permiten una acción rápida en caso de que un cambio propuesto no salga como se esperaba. También alientan a los equipos de TI a considerar opciones alternativas que pueden necesitar convertirse en parte del proceso regular o en una heurística de toma de decisiones, dado un patrón de cambios pasados ​​que han tenido resultados negativos. Los modelos predictivos de IA también pueden aprovechar el análisis de datos para alertar a los equipos de cambio cuando pueden tener un mayor riesgo de fallar en el cambio, lo que genera la necesidad de un plan de contingencia.

Asegúrese de que cada cambio tenga un cierre

Cada cambio debe ir acompañado de un proceso de cierre, ya sea que el cambio haya sido exitoso o no. Los impactos del cambio deben ser monitoreados y documentados. Los metadatos del cambio deben registrarse para que las métricas puedan identificar qué cambios afectan qué funciones y qué cambios conllevan ciertos riesgos. La CMDB debe actualizarse ya que ciertos cambios afectan la relación que tienen los CI entre sí.

Estas tareas pueden ser laboriosas, pero automatización parcial o total puede reducir los esfuerzos que necesitan los miembros individuales de TI al tiempo que mejora la eficiencia en general. Las etapas de un proceso de cierre de cambios son increíblemente importantes no solo para monitorear la presencia de riesgo de degradación/interrupción del servicio, sino también para cuantificar los riesgos de cambio con un modelado más preciso a lo largo del tiempo.

Las mejores prácticas de gestión de cambios de ITIL permiten la creación constante de valor frente a la incertidumbre

Ninguna de las mejores prácticas descritas anteriormente es sofocantemente prescriptiva, pero revelan el nivel de atención y responsabilidad de custodia que se requiere para que las operaciones de TI brinden un valor comercial continuo.

“Uno de los beneficios de usar un marco estandarizado de mejores prácticas es garantizar que los empleados comprendan sus roles y los procedimientos que deben seguir para brindar servicios y brindar un alto nivel de atención al cliente”. notas BMC blogs. Al mismo tiempo, BMC reconoce que “el marco de trabajo de ITIL también pretende dar a los proveedores de soporte de TI un papel más interactivo en las empresas. En lugar de brindar soporte en segundo plano, los departamentos de TI que utilizan este marco son parte de la estructura general de la empresa”, lo que significa que son una parte directa de la cadena de creación de valor dentro de su empresa.

Como menos cambios requieren supervisión e intervención directas y se habilitan cambios más directamente beneficiosos a través de la optimización y la automatización, las organizaciones de TI en su conjunto pueden contribuir más al resultado final de su organización al tiempo que dan a su talento un papel más importante en la creación de valor.

Conozca cómo el análisis empresarial de TI puede ayudarlo a evolucionar de ITSM reactivo a proactivo y Gestión de cambios en nuestro seminario web reciente: "Cómo adaptar su servicio de TI y gestión de cambios para una fuerza de trabajo distribuida"