Cómo mejorar tu flujo de trabajo de soporte de TI
La evolución de la gestión de los cambios de TI
La gestión de los cambios (o facilitación del cambio) es una práctica de TI diseñada para minimizar las interrupciones en los servicios de TI mientras se realizan cambios en sistemas y servicios críticos.
Un cambio es agregar, modificar o eliminar cualquier cosa que pueda repercutir directa o indirectamente en los servicios.
Las prácticas de gestión de los cambios están diseñadas para reducir incidentes y cumplir con la normativa. Con ellas se garantiza un manejo eficiente y rápido de los cambios en el código y la infraestructura de TI. Ya sea para implementar nuevos servicios, gestionar los existentes o resolver problemas en el código, las estrategias modernas de gestión de los cambios acaban con la segregación, proporcionan contexto y transparencia, evitan cuellos de botella y minimizan los riesgos.
La gestión de riesgos es una práctica relacionada con ITIL 4 y adoptada "para garantizar que la organización conoce los riesgos y los aborda de manera eficaz". Tanto la gestión de los cambios como la de riesgos requieren el seguimiento y la vinculación de los cambios para crear registros auditables. Si las organizaciones son capaces de aprovechar los datos sobre cambios anteriores y sus tasas de éxito, podrán adaptar sus prácticas de manera que equilibren el riesgo y la agilidad de forma inteligente.
Unas prácticas adaptativas y basadas en datos promueven la eficiencia, a diferencia de la gestión tradicional de los cambios que puede ser innecesariamente lenta, con exceso de procesos y carga de trabajo. La gestión de los cambios afronta desafíos relacionados con el riesgo y el cumplimiento, la verificabilidad y la coordinación entre equipos, por lo que muchas veces se hace compleja, burocrática y tediosa.
Pero no tiene por qué ser así. Imagina la gestión de los cambios como "las lentejas" de ITSM: no siempre apetecen, pero son buenas para la salud. Con las prácticas y la cultura adecuadas, la gestión de los cambios puede reducir los incidentes y el estrés de los equipos, y aumentar el tiempo dedicado a ofrecer valor a los clientes.
Definir la gestión de los cambios
Cuando pensamos en la gestión de los cambios, a menudo incluimos en la definición todos los aspectos relacionados con ellos, desde la tecnología, las personas y los procesos, hasta su impacto en clientes y sistemas. Para aclarar las cosas en el contexto de ITSM, ITIL 4 ha establecido una distinción entre la gestión de los cambios de TI y las prácticas de gestión de los cambios organizativos.
- La gestión de los cambios organizativos busca "garantizar que los cambios en una organización se implementen sin problemas y que se logren ventajas duraderas mediante la gestión de los aspectos humanos de los cambios".
A partir de ahí, ITIL 4 reacuñó el antiguo proceso de gestión de los cambios como la "práctica de control de los cambios".
- La práctica de control de los cambios garantiza "que los riesgos se evalúen adecuadamente, autorizando los cambios que pueden seguir adelante y gestionando un calendario de cambios con el fin de maximizar el número de cambios fructíferos en productos y servicios".
Este cambio de denominación fue controvertido, ya que muchos equipos de TI rechazaban la asociación con la idea de "control". Para algunas personas, es una palabra tóxica que evoca la burocracia, los cuellos de botella y los pasos innecesarios que la gestión tradicional de los cambios creó para mal.
Axelos prestó atención a estas críticas y se ocupó de atenderlas. "Tras la publicación de ITIL 4 Foundation, personas de todo el mundo señalaron que se había extendido la idea equivocada de que el objetivo de esta práctica era controlar a los equipos o los cambios, en lugar de su índice".
Para resolver este problema, ITIL pasó a hablar de "facilitación del cambio". El nuevo nombre evoca una práctica que ayuda a los equipos, al proporcionarles la capacidad (y la libertad) que necesitan para llevar los cambios adelante.
De todos modos, no creemos que el término sea lo más importante. (De hecho, en este artículo y en Atlassian, hablamos de "gestión de los cambios".) Lo realmente importante es el enfoque. Empieza por unos equipos sanos y con la cultura adecuada, para poner a tu organización en el buen camino para crear una práctica eficaz de gestión de los cambios.
La relación entre la gestión de los cambios y la gestión de publicaciones
La gestión de publicaciones también es una práctica importante a la hora de hablar de la gestión de los cambios. Según ITIL 4, el propósito de la "gestión de publicaciones… es asegurar la disponibilidad de los servicios y funciones nuevos o que se modifiquen". Las publicaciones pueden incluir cualquier cosa, desde cambios en la funcionalidad de software hasta correcciones en la documentación o la formación.
Históricamente, la gestión de publicaciones agrupaba cambios y los ofrecía a los clientes como un solo paquete. La gestión tradicional de publicaciones mantiene estándares rígidos de gestión de proyectos y puede crear fricción en el lanzamiento de actualizaciones de valor a los clientes, lo que lleva a la frustración entre los equipos que siguen los principios de la metodología ágil.
Podemos redefinir la gestión de publicaciones en el contexto de DevOps. Apartándose de su función tradicional de gestión de proyectos, la gestión de publicaciones debería centrarse en la integración y la automatización. El primer paso es reunir canalizaciones de código en un sistema seguro que incorpore revisión automatizada siempre que sea posible y que permita el seguimiento y la supervisión. Esto puede acabar con la segregación tradicional en unidades aisladas y ofrecer un camino sin fricciones hacia la producción. La gestión de publicaciones podría centrarse en facilitar la entrega continua de valor y en aplicar el principio "tú lo creas, tú lo gestionas".
¿Por qué es importante la gestión de los cambios de TI?
Las organizaciones modernas plantean dos demandas clave, pero enfrentadas, a los equipos de TI. Por un lado, esperan contar con servicios estables y fiables con los que la organización pueda ser productiva y cumplir las expectativas del usuario final. Por otro, el equipo de TI debe implementar actualizaciones periódicas de servicio para que la organización pueda adaptarse a unos requisitos empresariales, de costes y seguridad en cambio constante.
No cubrir cualquiera de estas dos expectativas puede tener consecuencias nefastas. La incapacidad de mantener un servicio de confianza puede causar daños enormes en la productividad y los costes. Para muchas organizaciones, la inactividad tiene un coste superior a 300 000 $ por hora, según Gartner. En algunos servicios basados en web, esa cifra incluso puede ser considerablemente superior.
Al mismo tiempo, las organizaciones que no se están adaptando para el futuro serán incapaces de mantener el ritmo del negocio y perderán puestos con respecto a la competencia. Con una implementación de cambios demasiado lenta, los empleados podrían buscar lugares de trabajo con sistemas más ágiles y los clientes podrían elegir a organizaciones que les proporcionen más valor.
Así las cosas, ¿cómo se puede lidiar con estas necesidades en conflicto? Con una práctica de gestión de los cambios, tu organización podrá lanzar actualizaciones, garantizando la estabilidad y mitigando el riesgo al mismo tiempo. La gestión de los cambios ayuda a implementar los cambios de las siguientes maneras:
- Estableciendo un marco para gestionar el proceso de cambio.
- Priorizando los cambios necesarios para una asignación correcta de los recursos.
- Incorporando información relevante para una toma de decisiones más inteligente.
- Integrando a las partes interesadas necesarias de desarrollo y TI en las aprobaciones.
- Incorporando pruebas a los cambios, para evitar incidentes.
- Optimizando y mejorando el procedimiento de cambios, para entregar valor más rápido.
Tipos de cambios
ITIL define tres tipos de cambios.
Cambios estándar
Los cambios estándar son habituales, suponen un riesgo bajo y están preaprobados. Se realizan con frecuencia y siguen un proceso documentado y aprobado.
Por ejemplo, ampliar memoria o almacenamiento es un cambio estándar. Reemplazar un router que falla por otro idéntico y operativo es un cambio estándar. Crear una nueva instancia de una base de datos es un cambio estándar.
Todos estos cambios son habituales y siguen un procedimiento bien definido. Además, es más que probable que ese procedimiento ya haya pasado por un proceso de aprobación y evaluación de riesgos de gestión de los cambios en alguna ocasión, por lo que no hará falta repetir todo el proceso cada vez que haya que cambiar un router.
Para muchas empresas, los cambios estándar son una oportunidad clave para la automatización. Algunas empresas señalan que se podría automatizar hasta el 70 % de los cambios estándar para que los equipos puedan centrarse en los cambios normales y urgentes.
Cambios normales
Los cambios normales son cambios que no son urgentes ni tienen un proceso definido y previamente aprobado.
Por ejemplo, mejorar a un nuevo sistema de gestión de contenido es un cambio normal. Migrar a un nuevo centro de datos es un cambio normal. Las mejoras del rendimiento también son cambios normales. No son estándar ni repetibles, e implican riesgos, pero no son ninguna urgencia. Esto significa que pueden entrar en la cola habitual de gestión de los cambios para la aprobación y evaluación del riesgo.
Algunos cambios normales, como un conmutador de centro de datos, son de alto riesgo y pueden requerir evaluación de riesgos y la aprobación de un comité asesor de cambios (CAC). Otros, como un cambio en el sitio web, pueden ser de bajo riesgo y podría aprobarlos más rápidamente una autoridad de cambio designada o mediante comprobaciones automatizadas y revisión por pares.
Cambios urgentes
Estos cambios surgen de un error o amenaza imprevistos y deben abordarse de forma inmediata, generalmente para que clientes o empleados puedan seguir utilizando un servicio, o para proteger los sistemas contra una amenaza.
Por ejemplo, implementar un parche de seguridad es un cambio urgente. Ocuparse de una interrupción del servicio del servidor es un cambio urgente. Resolver un incidente grave es un cambio urgente.
La urgencia de estos cambios significa que deben tratarse con plazos mucho más estrictos, ya que el riesgo que supone un proceso de revisión prolongado es mayor que los riesgos que implicaría resolver la incidencia rápidamente.
La forma en que clasifiques los cambios depende de factores como la organización, los procesos y la tolerancia al riesgo. Te recomendamos olvidar la idea de que existe una sola solución buena para todo y tratar cada cambio de manera diferente en función de la evaluación del riesgo. A medida que tu organización vaya aprendiendo sobre la base de incidentes anteriores y sistemas concretos e incorpore otros datos relevantes, cada vez más cambios deberían pasar a ser estándar y contar con preaprobaciones. La gestión moderna de los cambios debe simplificar al máximo las solicitudes de cambio.
¿Qué es un comité asesor de cambios (CAC)?
En la mayoría de las organizaciones de TI tradicionales, un comité asesor de cambios (CAC) se encarga de evaluar los riesgos y de aprobar (o no) cada cambio. Habitualmente, los CAC celebran reuniones programadas con regularidad para revisar los próximos cambios propuestos. Además, recurren a expertos según sea necesario para que aclaren, defiendan o evalúen el cambio.
Por un lado, los comités asesores de cambios pueden reducir el riesgo y alertar cuando un cambio no funcione en la empresa. Pero por otro, también pueden suponer un cuello de botella, especialmente cuando los integran personas que no están cerca de los cambios que se van a implementar. En muchas empresas, el proceso de aprobación del comité asesor de cambios es complejo y consume mucho tiempo, lo que ralentiza el proceso de cambio.
Muchos equipos de TI están abandonando las reuniones tradicionales de CAC o limitando el alcance de sus responsabilidades a los cambios más arriesgados y a las cuestiones más importantes desde el punto de vista organizativo. En este paradigma, los CAC pueden convertirse en asesores fiables, encargados de supervisar tendencias, asesorar sobre cómo pueden abordarlas las prácticas y coordinar equipos y necesidades.
ITIL 4 también promueve la descentralización de la autoridad del cambio y pasarla a las partes interesadas o los pares. En lugar de utilizar un comité independiente, incorpora la gestión de los cambios en los flujos de trabajo normales con las partes interesadas pertinentes. Para evitar cuellos de botella, apuesta por la automatización, las listas de comprobación virtuales y la revisión por pares como una alternativa más ágil y colaborativa.
El proceso de gestión de los cambios
En los equipos ágiles y rápidos, el proceso de gestión de los cambios se aleja de largos procesos de revisión y aprobaciones a cargo de partes interesadas no técnicas, para adoptar procesos automatizados y colaborativos entre TI y equipos de desarrollo que aumentan la agilidad y equilibran el riesgo.
Esta es una visión general básica de un proceso de gestión de los cambios, junto a algunas recomendaciones para aumentar la velocidad de entrega de valor.
| Paso | prácticas recomendadas |
| Solicitud de cambio - Alguien solicita un cambio e incluye notas sobre posibles riesgos, implementación esperada y sistemas afectados. | Configura un portal de autoservicio intuitivo para que las partes interesadas y el personal de TI puedan generar solicitudes de cambio estándar fácilmente. nAsegúrate de que los equipos de desarrollo y de TI puedan colaborar en la misma plataforma para tener contexto y transparencia durante todo el flujo de trabajo de solicitudes de cambio. |
| Revisión de una solicitud de cambio: Un gestor de cambios o revisor de pares revisa la solicitud inicial de cambio. ¿Qué probabilidad tiene de funcionar? ¿Los riesgos y recompensas son exactos? ¿Merece la pena? | Utiliza la automatización para aprobar automáticamente el cambio o poner en marcha un proceso de aprobación antes de implementarlo. |
| Plan de cambio: El equipo crea un plan estratégico para el cambio. Documentan los resultados esperados, los recursos, el cronograma, los requisitos de prueba y las formas de revertir el cambio, en caso necesario. | Asigna rápidamente a las partes interesadas con la puesta en marcha de una gestión de los cambios. nUnifica criterios entre equipos, con plantillas de base de conocimientos para documentar los planes de cambio. |
| Aprobación de los cambios: El gestor de cambios, el revisor de pares o el CAC revisan el plan y aprueban el cambio. | Optimiza las aprobaciones con revisiones por pares. Acaba con los silos mediante la documentación y el seguimiento del trabajo compartido para permitir la colaboración sencilla y asíncrona. |
| Implementación de los cambios: El equipo lanza el cambio, al tiempo que documenta procedimientos y resultados. | Utiliza la automatización para habilitar procesos y estándares. La automatización del flujo de trabajo puede enrutar y asignar solicitudes al siguiente autorizado de acuerdo con las reglas empresariales. |
| Cierre de los cambios: Cuando corresponda, el gestor de cambios revisa y cierra el cambio. Su informe debe señalar si el cambio ha sido efectivo y puntual, si la estimación era precisa, si se ajustó al presupuesto, etc. | Garantiza la disponibilidad de los tickets y los artículos de la base de conocimientos para que los equipos puedan aprender del trabajo anterior. Puede haber oportunidades para automatizar solicitudes de cambio similares en el futuro. |
Prácticas recomendadas para la gestión de los cambios
Como ya hemos visto, la gestión de los cambios despierta los mismos temores que muchos sentimos al ver un plato de lentejas. No siempre nos apetece comerlas, pero sabemos que es importante incorporarlas a la dieta. Además, podemos tomar medidas para que ambas cosas sean más apetitosas.
Estas son algunas prácticas recomendadas para la gestión moderna de los cambios:
- Conoce la tolerancia al riesgo de tu organización y las exigencias normativas.
- Simplifica y automatiza los procesos de gestión de los cambios siempre que sea posible.
- Da a los CAC un enfoque más estratégico.
- Adopta prácticas con las que los cambios estándar pasen a ser los cambios normales.
- Examina diferentes marcos como ITIL y DevOps, para encontrar unas pautas que funcionen bien en tu organización.
- Da prioridad a la colaboración.
- Reduce el riesgo con ingeniería del caos.
- Optimiza la recepción de solicitudes de cambio para los equipos de TI y desarrollo.
- Aprende a partir de KPI y métricas de cambio.
- Adopta un enfoque basado en DevOps para la gestión de publicaciones.
Cómo afrontar los desafíos de la gestión de los cambios
Los desarrolladores quieren implementar código rápidamente y sin dedicar tiempo ni esfuerzo adicionales a la documentación manual. Los equipos de operaciones de TI quieren reducir el riesgo, tener registros detallados para las auditorías y evitar incidentes. Si los desarrolladores tienen que añadir pasos extra a sus procedimientos, anotar todo tipo de cosas y fichar al entrar y salir, pueden sentirse apartados de los objetivos últimos de su trabajo. Por otro lado, pedir al equipo de operaciones que revise los procesos existentes, que prescinda de controles de aprobaciones y que ceda espacio a la automatización no es sencillo, ya que puede tener la sensación de que se está aumentando el riesgo.
Al mismo tiempo, cada vez hay más en juego. El aumento de los servicios basados en software ha elevado las expectativas de los clientes y la demanda de servicios siempre activos y de alto rendimiento. En un entorno cada vez más dinámico, el trabajo relacionado con la gestión de servicios no deja de crecer.
¿Cómo podemos abordar estos desafíos? Para empezar, hay que dejar atrás el mito de que unos procesos complejos reducen los riesgos. Una vez hecho eso, adopta una cultura, unas prácticas y unas herramientas que ayuden a los equipos a colaborar y a hacer lanzamientos. Por último, incorpora información de forma permanente que demuestre el valor de los pasos anteriores y permita seguir mejorando.
¿Quieres ver cómo puede Jira Service Management transformar tu proceso de gestión de cambios?
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
Lee el artículo técnicoBase de conocimientos: tu solución para mejorar la colaboración
Descubre las ventajas de disponer de una base de conocimientos para tu empresa. Aumenta la productividad, mejora el servicio de atención al cliente y optimiza la gestión de la información de forma eficaz.
Leer el artículo