Comprender el proceso de gestión de cambios de ITIL 4 (y cómo la automatización puede mejorar las TI)

¿Qué es la gestión del cambio?

La gestión de cambios de ITIL 4 se refiere a un conjunto de directrices establecidas por la Fundación ITIL. Estas directrices ayudan a las organizaciones a gestionar los cambios en los productos digitales con fricción o riesgos mínimos.

ITIL 4 es la cuarta revisión de estas directrices, cuya primera versión se publicó en 1989. A diferencia de ITIL 3, que establecía un conjunto de procesos específicos que las organizaciones debían seguir, ITIL 4 ofrece una guía flexible. Es importante destacar que las organizaciones pueden adoptar los procesos específicos descritos en ITIL 3 sin dejar de ser totalmente compatibles con las directrices de ITIL 4.

Las recomendaciones de gestión del cambio de ITIL 4 proporcionan principalmente definiciones específicas para conceptos y roles clave en las operaciones de TI. Estos conceptos se generalizan para que sean aplicables universalmente, independientemente de la estructura de la empresa. El objetivo es que las organizaciones desarrollen sus propios procesos y prácticas teniendo en cuenta el marco de gestión del cambio establecido por ITIL 4.

Utilizar las recomendaciones de ITIL 4 junto con análisis de predicción de riesgos de cambio Puede acelerar considerablemente la velocidad de lanzamiento y, al mismo tiempo, guiar a los equipos de producto para que comiencen a realizar cambios de menor riesgo en general. Anticípese a los riesgos con Digital.ai Intelligence.

¿Por qué utilizar ITIL 4 para la gestión del cambio?

Los cambios son parte fundamental de las operaciones diarias de TI, independientemente de la categoría a la que pertenezcan. Hace décadas, los cambios se limitaban a actualizaciones de parches o de configuración poco frecuentes, que ocurrían solo unas pocas veces al año, o incluso con menos frecuencia. Pero ahora, algunas de las aplicaciones, servicios y plataformas más populares del mundo reciben miles de actualizaciones al año. Google informó en 2018 que… Ese mismo año realizó más de 3,000 cambios en sus algoritmos de búsqueda., con un promedio de aproximadamente 9 por día.

Ante la vertiginosa cantidad de cambios que se producen, las organizaciones de TI necesitan una forma estructurada de integrar e implementar dichos cambios para minimizar el riesgo de interrupciones del servicio. Al mismo tiempo, los responsables de operaciones de TI deben eliminar cualquier obstáculo que frene la velocidad del cambio. Cualquier retraso o control innecesario perjudica la cadena de valor.

Esto plantea una paradoja: debemos implementar cambios en un safe y a una velocidad mucho mayor que nunca.

El proceso de gestión de cambios de ITIL, recientemente actualizado, busca resolver este dilema. El objetivo principal de la gestión de cambios de ITIL 4 es eliminar todas las barreras a la implementación del cambio, manteniendo un control eficiente sobre las métricas operativas y otros objetivos de gestión de riesgos del cambio. En este sentido, ITIL 4 propone un marco de habilitación del cambio en lugar de definir rígidamente un conjunto prescriptivo de procesos de gestión del cambio.

Al adoptar los ideales de ITIL 4 y adaptarlos para que se ajusten mejor al entorno organizativo en cuestión, los equipos de operaciones de TI pueden acelerar el ritmo del cambio y, al mismo tiempo, minimizar las ineficiencias —y las amenazas disruptivas— en el proceso.

ITIL 4 pretende hacer que la gestión del cambio sea menos engorrosa.

Las versiones originales de ITIL —la primera publicada a finales de la década de 1980— definían con precisión los procesos que aportaban previsibilidad y estructura a las actividades de TI de una organización. Esta guía era fundamental para las empresas cuyos requisitos de TI eran desconocidos o generaban incertidumbre. Fue un producto de un mundo poco familiarizado con las tecnologías emergentes, y tanto las empresas como las organizaciones gubernamentales ansiaban este nivel de orientación específica.

Sin embargo, a principios de la década de 2000 se produjo un cambio importante en las metodologías de desarrollo de software: Agile. Con Agile, las metodologías rígidas…waterfallSe eliminaron los procesos de desarrollo preexistentes. Esto otorgó a los equipos de desarrollo individuales mayor autonomía y control sobre sus resultados finales, lo que permitió alcanzarlos en un período de tiempo significativamente más corto.

La metodología Agile popularizó la idea de que las aplicaciones y las plataformas tecnológicas podían evolucionar continuamente, siempre y cuando se trabajara para asegurar que cada nuevo cambio añadiera valor a los usuarios finales.

En respuesta al auge de la metodología Agile (y DevOps Tras ello, ITIL se vio obligado a adaptarse. ITIL v3 se basó en los procesos de cambio de ITIL existentes y desarrolló un modelo para la implementación del cambio continuo que muchas organizaciones siguieron con los siguientes pasos:

1. Crear una solicitud de cambio (RFC)
2. Revisión de RFC
3. Que un Comité Asesor de Cambios (CAB) evalúe la RFC.
4. Autorizar cambios según el RFC
5. Actualizaciones de planes
6. Implementación coordinada
7. Deploy/integrar nuevos cambios
8. Revisa los cambios y cierra el registro de cambios.

Esta versión del proceso de gestión de cambios de ITIL era fiable, repetible y permitía un gran control sobre el resultado de las propuestas de cambio. Sin embargo, para algunas organizaciones seguía siendo bastante engorrosa.

La necesidad de una revisión constante por parte del CAB retrasa los cambios y podría generar ineficiencias significativas. En consecuencia, el valor producido por cada cambio individual se ve mermado.

En respuesta a estas deficiencias, el nuevo marco ITIL 4 sugirió que el modelo rígido de gestión de cambios (propuesta > aprobación > implementación > cierre) se reservara para ciertos cambios considerados no estándar. Así, si bien el marco ITIL 4 mantiene la posibilidad de un proceso de gestión de cambios "normal" similar al de versiones anteriores, anima a los responsables de operaciones de TI a migrar la mayor cantidad posible de cambios a una categoría diferente: cambios estándar.

Acelerar la velocidad del cambio utilizando los modelos de cambio estándar de ITIL

ITIL v3 tenía una categoría de cambios propuestos descritos como “cambios estándar”. Estos se consideraban de bajo riesgo y ocurrirían con frecuencia en el entorno de TI dado. Ejemplos ofrecidos Incluía cambios de contraseña, procedimientos para nuevas contrataciones y la reubicación de equipos físicos.

Con ITIL 4, los líderes de ITSM reconocen que las organizaciones podrían aspirar a que los cambios estándar sean la norma, no una excepción especial a los “cambios normales”. Propone que, al modelar categorías de cambios o tipos de cambios específicos, la supervisión formalizada y la aprobación del CAB ya no son necesarias en muchos contextos.

Determinar qué cambios son realmente «normales» (es decir, de «bajo riesgo») puede, por lo tanto, eliminar la mayoría de los obstáculos que dificultan la agilidad. Cuando se introducen cambios de mayor riesgo en el proceso formal de RFC, los responsables de operaciones de TI también pueden empezar a trabajar para aceptar, mitigar o rechazar el riesgo.

El proceso de implementación de un cambio normal ahora puede automatizarse en gran medida, lo que significa que tan pronto como el equipo de desarrollo propone el cambio (a menudo en respuesta a los datos de retroalimentación de operaciones de TI), este puede probarse, integrarse e implementarse en el entorno de producción, y luego cerrarse con poca o ninguna intervención humana.

Así pues, aunque los cambios estándar reflejan el proceso de cambio normal, la RFC se revisa y autoriza mediante un proceso de baja latencia en lugar de una revisión formalizada por parte del CAB.

Adaptar el proceso de gestión de cambios de ITIL para acelerar los cambios gestionando el riesgo.

En esencia, cada paso del proceso original de gestión de cambios de ITIL 3 puede conservarse sin sacrificar la velocidad ni la flexibilidad.

Propuestas sugeridas por el marco actualizado de ITIL 4 Para adaptar el proceso de gestión del cambio de una organización se incluyen:

• Creación de modelos de cambio para cambios recurrentes
• Descentralización de la aprobación de cambios para cambios estándar
• Dividir los grandes cambios en partes más pequeñas que conlleven menos riesgo
• Utilizando comprobaciones, pruebas y despliegue automatizados

Así es como podrían reflejarse las adaptaciones en referencia a cada paso de un proceso de gestión de cambios ITIL más formal:

Solicitud de cambio

Las propuestas de cambios "normales" individuales deben considerarse primero en relación con un modelo de cambio estándar para determinar si pueden evitar el proceso de aprobación. Los cambios de "bajo riesgo" que incluyan algunas características de cambios premodelados pueden dividirse de modo que solo se considere formalmente la propuesta novedosa, mientras que los componentes estándar se preautorizan.

Cuando sea posible, las RFC pueden generarse automáticamente en respuesta directa a la necesidad de un cambio, basándose en la información recopilada de las operaciones de TI. Estas RFC autogeneradas pueden incorporarse al portafolio de cambios/funcionalidades propuesto. La generación automática de RFC reduce la necesidad de cambios de emergencia, ya que identifica proactivamente los riesgos y busca mitigarlos, preferiblemente ajustándose lo más posible a los cambios estándar predefinidos.

evaluación del cambio
Según ITIL 4, las reuniones del CAB deben convocarse para abordar circunstancias especiales, en lugar de programarse con una periodicidad preestablecida o como parte de un procedimiento de cambio estándar. Un único gestor de cambios suele ser suficiente para evaluar el riesgo o el impacto de un cambio si su criterio se complementa con el de otros. Análisis impulsados ​​por IALos cambios estándar pueden evaluarse, en su mayor parte o en su totalidad, mediante un proceso automatizado, lo que evita la acumulación de consideraciones pendientes y reduce considerablemente la latencia. Los cambios habituales que requieren aprobación formal pueden servir de base para un nuevo modelo de cambio estándar o bien pueden contribuir a actualizar los modelos existentes para abarcar un ámbito más amplio.

Autorización de cambio
Un objetivo principal del marco de habilitación de cambios de ITIL 4, centrado en la agilidad, es reducir al máximo la necesidad de autorizaciones de cambios. El modelado de cambios permite que la autorización sea instantánea, en la mayoría de los casos, y el uso de análisis para evaluar los riesgos del cambio puede hacer que la autorización de cambios normales guiada por humanos sea menos engorrosa y requiera menos investigación.

Cambios de plan
La planificación de cambios y la autorización de compilaciones pueden optimizarse drásticamente mediante el análisis de cambios, hasta lograr una automatización casi completa. La planificación manual de cambios y la programación de compilaciones deben reducirse al máximo. Asimismo, el modelado de cambios permite eliminar la incertidumbre al distinguir entre los cambios que requieren atención especial y aquellos que pueden planificarse e integrarse rápidamente en una futura versión.

Deploy/Integrar nuevos cambios
Gracias a Release Herramientas administrativasEn muchas empresas, la implementación e integración de cambios se han automatizado en gran medida. Se debe priorizar la implementación de cambios "normales" y de bajo riesgo, lo que significa que la mayoría no requieren implementación ni integración manual. Aquellos que sí requieren atención pueden supervisarse tras su implementación, lo que reduce la necesidad de supervisión humana directa para un pequeño subconjunto de cambios riesgosos.

Revisa los cambios y cierra el registro de cambios.
No debe subestimarse la importancia de un cierre de cambios exhaustivo. Se ha demostrado que reduce eficazmente los problemas e interrupciones imprevistos. Sin embargo, esto no significa que las organizaciones de TI deban implementar engorrosos procesos de revisión manual para garantizar que cada cambio sea estable y se refleje con precisión en la documentación necesaria.

El cierre de cambios es uno de los pasos de los procesos de gestión de cambios más susceptibles de automatización, incluso en organizaciones más pequeñas. Pruebas y revisión automatizadas Desempeñan una función de control de calidad, mientras que las actualizaciones automatizadas de la CMDB y otras tareas de cierre de cambios reducen la necesidad de cierre manual. Estas prácticas garantizan registros más completos y disminuyen el riesgo de que errores organizativos afecten la integridad de los datos de la CMDB y otros sistemas de registro importantes.

Acelere la implementación del cambio con análisis de TI en cada paso del proceso.

Los seres humanos somos creativos y excelentes solucionadores de problemas, pero no estamos tan capacitados como las computadoras para revisar rápidamente miles de líneas de código o millones de entradas de datos. El análisis de datos proporciona esta funcionalidad y puede mejorar drásticamente la productividad del departamento de TI, a la vez que aporta agilidad al proceso de revisión e implementación de cambios.
La incorporación de modelos de IA y ML mejora aún más las capacidades de TI al descubrir automáticamente patrones en los datos que el ojo humano podría no ser capaz de ver, como los factores de riesgo del cambio o la probabilidad de que un cambio determinado produzca un efecto disruptivo en el rendimiento.

Estas funcionalidades ilustran el papel fundamental que desempeña la tecnología para ayudarnos a gestionar la tecnología que creamos y modificamos a diario. Si bien la automatización de cambios no es intrínsecamente necesaria para las prácticas modernas de gestión de cambios, las directrices de ITIL la consideran una buena práctica, esencial en un mundo donde la velocidad se mide en milisegundos, no en meses.