El nuevo papel de los consejos asesores de cambio en un mundo automatizado

En un mundo en constante cambio, los procesos que funcionaban bien hace poco tiempo ya no funcionan como se esperaba. Un ejemplo de ello es el funcionamiento de su Comité Asesor de Cambios (CAB).

El propósito de adoptar marcos como DevOps consistía en acelerar el valor al permitir Integración continua y entrega continua (CI/CD)). Pero al exigir que cada cambio pase por el CAB para su revisión y aprobación, se desvirtúa la intención ágil del proceso.

Utilizar el CAB para evaluar cada cambio también consume valiosos recursos de los empleados. Los miembros del CAB suelen ser los líderes de TI y tecnología de más alto nivel de la organización, y su tiempo y talento son muy valiosos.

Las organizaciones pueden aliviar la presión sobre sus miembros al modificar el rol del Comité Asesor de Cambio (CAB) en el proceso de cambio. En lugar de evaluar cada cambio, el CAB puede reunirse de forma puntual, según sea necesario. Ciertos cambios estándar pueden designarse para su revisión por miembros individuales del CAB y marcarse para su preaprobación o posterior análisis antes de la etapa de implementación. Este cambio de enfoque del CAB permite una creación de valor más rápida y un uso eficiente de los recursos, sin dejar de garantizar que el CAB funcione según sea necesario.

Estos 4 pasos reducirán aún más la dependencia de CAB y acelerarán la creación de valor en las operaciones de TI.

1. Desarrollar un modelo para cambios estándar que no requieran aprobación manual
2. Identificar y monitorear las métricas clave que revelan el riesgo de cambio a través de Análisis respaldado por inteligencia artificial (IA) y aprendizaje automático (ML)
3. Identificar oportunidades para automatizar las aprobaciones de cambios siempre que sea posible y contar con un gestor de habilitación de cambios para gestionar los riesgos de bajo nivel.
4. Llame al CAB solo para situaciones de alto riesgo o decisiones estratégicas de alto nivel, y procure que el equipo se reúna virtualmente en lugar de presencialmente.

Estas acciones liberan tiempo a los miembros del CAB, aceleran la creación de valor e influyen positivamente en los objetivos de CI/CD dentro de la organización.

Desarrollar modelos de cambio para lograr más cambios estándar

Dentro del ITIL v3 y v4 Existen tres tipos principales de cambios. Estos son:

1. Cambios estándar, que son de bajo riesgo y están preautorizados, con un procedimiento bien conocido para su resolución.
2. Cambios de emergencia que deben implementarse de inmediato, como en caso de un incidente grave.
3. Cambios normales, o cualquier cambio no cubierto por las categorías de cambios estándar o de emergencia.

Los cambios con bajo riesgo de fallo deben gestionarse como cambios estándar. La mayoría de los cambios en una organización deben ser estándar, con procedimientos de resolución y reversión establecidos para casos de problemas. Los cambios estándar que siguen un procedimiento conocido pueden aprobarse previamente y resolverse sin la intervención del Comité Asesor de Cambios (CAB). Esto permite que el CAB dedique su tiempo a cambios urgentes y otras tareas.

Los cambios normales no deberían ser frecuentes. Cuando surgen, no necesariamente requieren la revisión del Comité Asesor de Cambios (CAB) para su resolución. Deben evaluarse y modelarse para que puedan funcionar como cambios estándar en el futuro. A veces, dividir el cambio en componentes más pequeños puede facilitar el proceso. De esta manera, la mayor cantidad posible de componentes del cambio se ajustan a un modelo estándar, mientras que los componentes verdaderamente novedosos pueden considerarse de forma aislada.

El objetivo es cambios en el modelo De esta forma, se pueden preaprobar e implementar con mayor rapidez. A medida que aumenta el volumen de cambios estándar, surge la oportunidad de automatizar aún más los cambios y reducir la necesidad de la participación del Comité Asesor de Cambios (CAB).

Aunque el CAB haya revisado inicialmente cada cambio en su organización, no tiene por qué seguir funcionando de esa manera.

“En el pasado, puede que la única forma que la organización conocía para cumplir con el requisito de auditoría fuera que el CAB aprobara cada solicitud de cambio”, dice DevOps consultor Kaimar Karu“Definitivamente, este no era el consejo que se incluía en la guía de ITIL.”

Utilizar la analítica para monitorizar el riesgo de cambio

Las organizaciones pueden aprovechar los datos para analizar los cambios e identificar fuentes de riesgo. El desarrollo de un modelo de riesgo de cambio permite a los líderes de operaciones de TI crear y monitorear métricas que permiten “tomar el pulso” a los cambios. El liderazgo puede evaluar rápidamente los riesgos, eliminar las demoras en la evaluación y resolución de los cambios, y crear una gestión de riesgos de cambios de TI más intuitiva en la organización.

Algunas métricas se pueden derivar directamente de los datos, mientras que otras son el resultado de modelos de aprendizaje automático complejos. El aprendizaje automático puede evaluar el poder predictivo de los factores de riesgo de cambio, desarrollando gradualmente modelos de causalidad que se centran en los mejores predictores. Con el tiempo, el modelado de aprendizaje automático puede correlacionar incidentes y problemas con los factores de riesgo, generando resultados más precisos y construyendo una narrativa que permite identificar qué factores y prácticas de desarrollo dan lugar a riesgos de cambio.

Un cliente de Numerify logró este objetivo asignando un “riesgo de cambio en la puntuación crediticiaSe asignó una puntuación numérica a cada gestor del cambio en la organización. Esta puntuación se derivó de diversos factores de riesgo y podía mejorarse mediante las acciones y los resultados del gestor. Este indicador clave de rendimiento (KPI) conductual reveló relaciones de causa y efecto, lo que permitió resoluciones más rápidas con menor inversión de tiempo, dinero y esfuerzo en la resolución de problemas relacionados con el cambio.

Las organizaciones pueden desarrollar modelos predictivos e indicadores clave de rendimiento (KPI) adicionales mediante aprendizaje automático e inteligencia artificial para optimizar el proceso. Asignar una puntuación de riesgo objetiva basada en los factores de riesgo modelados agiliza las respuestas y permite que la gestión del cambio tome decisiones sin demora. En este escenario:

• Se pueden aceptar riesgos bajos o medios
• Los riesgos elevados pueden ser revisados ​​por el CAB, congelados, desmantelados o abordados mediante otras estrategias, según corresponda.

El modelo de riesgo de cambio Debe ser accesible para su evaluación mediante visualizaciones claras, con un panel de control de autoservicio para investigaciones posteriores. Esto reducirá la extracción y el análisis manuales de datos, que requieren mucha mano de obra y pueden provocar retrasos en la toma de decisiones de días, o incluso semanas.

Reducir la necesidad de una reunión del CAB para obtener aprobaciones de cambios

Es importante recordar que CAB significa cambio asesor Junta, no junta de aprobación de cambios. El propósito de la Junta de Aprobación de Cambios (CAB) nunca fue someter a revisión todos los cambios, ni utilizarla para cambios estándar.

La gestión de riesgos puede optimizarse mediante el uso de análisis, el seguimiento de métricas y un sistema de puntuación, así como la automatización de cambios menores. El CAB solo debe convocarse para actualizaciones estratégicas periódicas, y sus reuniones deben celebrarse virtualmente.

Este cambio también reduce la necesidad de reuniones de emergencia del Comité Asesor de Cambios (CAB). En su lugar, los responsables de la gestión del cambio pueden supervisar los cambios de forma proactiva. Los cambios de alto riesgo pueden contar con medidas de reversión al momento de su implementación, con expertos en TI disponibles para una posible respuesta.

Asignar un rol estratégico al CAB en las organizaciones de TI

Este nuevo papel del CAB es estratégico, ya que Google sugiere: “Al delegar la revisión detallada del código a profesionales y métodos automatizados, se libera el tiempo y la atención de quienes ocupan puestos de liderazgo y gestión para que se centren en tareas más estratégicas. Esta transición, de guardián del código a arquitecto de procesos y fuente de información, es coherente con las prácticas de las organizaciones que destacan por su excelente desempeño en la entrega de software.”

Este enfoque estratégico reduce la presión sobre los valiosos recursos humanos, al tiempo que permite el flujo constante de CI/CD. Esto ha cobrado especial importancia durante una crisis global, cuando la mayoría de los equipos de las organizaciones trabajan de forma remota.

Las organizaciones pueden emplear un pensamiento estratégico guiado por análisis de TI y procesos basados ​​en éxitos pasados, creando un modelo de revisión CAB sencillo en lugar de complejo. Al usarlo solo cuando sea necesario, preservarán el valor y acelerarán su creación mediante actualizaciones constantes que mejoran el producto y la satisfacción del cliente.