Gestión del Cambio en IT: Estrategias, Procesos y Mejores Prácticas

Heráclito dijo que nunca te bañas dos veces en el mismo río, dejando claro que el cambio es lo único que existe… Y lo que más sudores fríos provoca en tecnología. La diferencia entre que esas transformaciones nos acerquen a nuestros objetivos, o nos arrastren como un caballo sin riendas, es una adecuada gestión del cambio en IT. Por eso, he aquí una guía completa.
En ella veremos el ciclo de vida de esa gestión, metodologías, ejemplos y herramientas para navegar un río lleno de rápidos y rocas.

Qué es la gestión del cambio en IT

¿Qué es más veloz, la luz o los cambios en tecnología? Ya sea por seguridad o competitividad, el cambio en IT es constante y vertiginoso. Y su gestión se refiere a cómo las organizaciones planifican, implementan y controlan dichos cambios en sus sistemas, procesos, tecnologías o infraestructuras de TI.
El objetivo es minimizar riesgos y asegurar que los cambios se realicen de manera eficiente, sin afectar negativamente a los SLAs.
Dicho de otra manera, es un proceso estructurado que asegura que cualquier modificación tecnológica (nuevo software, actualizaciones, cambios de configuración, etc.) se haga de manera controlada y documentada para que:

• No produzca alteraciones de servicios o un error en las mil piezas móviles de la infraestructura IT de una organización.
• No comprometa la seguridad ante nuevas amenazas, vulnerabilidades o cambios legislativos.
• Nos permita estar a la vanguardia. Quien gestiona e implementa mejor los cambios adquiere ventajas que marcan la diferencia entre volar o caer en entornos cada vez más competitivos, donde el ganador se lleva todo, sin dejar nada al resto.

La diferencia entre la gestión del cambio y el Release Management

Un inciso para matizar la diferencia entre IT Change Management y Release Management.
El Release Management se enfoca en planificar, programar y controlar el despliegue de nuevas versiones de software, hardware o servicios. Por tanto, es solo una parte de la gestión del cambio en IT.
Este se enfoca en controlar y supervisar cualquier modificación en los sistemas, procesos o infraestructuras de IT, no solamente nuevas versiones.

¿Cómo funciona la gestión del cambio en IT?

El cambio en IT es un concepto amplio que abarca:

• Cambios tecnológicos en sí: como actualizaciones de software o hardware, migraciones a la nube, implementación de nuevas herramientas…
• Cambios en procesos: modificaciones en los flujos de trabajo, mejoras en gestión de tickets o incidentes, adaptación a nuevas metodologías (como Agile o DevOps)…
• Cambios en la infraestructura: configuración de servidores o bases de datos, cambios en la seguridad de la red (firewalls, políticas de acceso, etc.).
• Cambios organizacionales: las reestructuraciones de equipos, o formación de personal en nuevas tecnologías y procesos forman parte de la gestión del cambio organizacional.

Así los gestores del cambio se enfrentan a dos aspectos muy diferentes.

• Una tecnología que cambia cada segundo.
• Las personas que, contradiciendo a Heráclito, somos lo único que apenas cambia con el tiempo.

Como vemos, estamos abriendo un abanico más complejo de lo que parece. Por eso, mejor que lo hagamos metódicamente.

El ciclo de vida de la gestión del cambio en IT

El 1 agosto de 2012 amaneció como cualquier otro día perezoso de verano. Knight Capital, el mayor trader de valores estadounidenses, se preparaba para mover sus más 21.000 millones de dólares diarios en los mercados…
Pero todo cambió con un clic.
Aquella mañana implementaron un cambio en el software de compraventa, aplicándolo en sus 8 servidores. Sin embargo, no había plan, proceso escrito o gestión de cambios en IT. El despliegue fue a mano y el ingeniero encargado no copió el nuevo código en uno de los servidores.
Tampoco había un segundo ingeniero que revisara lo hecho, ni un sistema de alertas que hubiera detectado la discrepancia entre servidores. Y cuando abrieron los mercados, también lo hicieron las puertas del desastre.
El software comenzó a realizar compras y ventas frenéticas que causaban pérdidas millonarias cada segundo.
Un clic, una mañana, un cambio que terminó con la compra de Knight Capital a precio de saldo por un competidor.
Esas son las consecuencias de no gestionar los cambios en IT siguiendo las mejores prácticas. Y aunque existen varios marcos de trabajo, que veremos más adelante, este es el ciclo de vida natural de un cambio.

Solicitud del cambio

Todo empieza por un motivo, como la mejora continua de procesos y que, por ejemplo, el equipo de desarrollo pida migrar a la nube. O que se produzca un requerimiento externo, como cumplir la ISO 27001 de ciberseguridad.

Evaluación del cambio y sus alternativas

Aquí entran en juego conceptos clave de la gestión del cambio en IT como es el CAB (Change Advisory Board), el comité asesor en la gestión del cambio en IT, que evalúa, prioriza y aprueba esos cambios y está formado por:

• El Change Manager o responsable último del cambio.
• Técnicos relacionados con el cambio: administradores de redes, equipo de ciberseguridad, si tiene que ver con ellos…
• Responsables directos del servicio o departamento. Por ejemplo, si queremos implantar un nuevo CRM en la empresa, dentro del CAB estaría el responsable de gestión de clientes, aportando perspectiva de usuario (que procederá a ser ignorada por los técnicos).
• Otros implicados clave. En el ejemplo del CRM, el director comercial podría sentarse también en el CAB, teniendo en cuenta el posible impacto en el proceso de venta general que tendría cambiar la gestión de clientes.

Así, el CAB identifica riesgos (latencia, costos, procesos afectados…) y metas deseadas.

Aprobación o rechazo del cambio

Si se aprueba, este cambio puede ser total, parcial y/o con condiciones (como que se hagan una serie de pruebas previas y en ellas se alcancen determinados objetivos, por ejemplo).

Planificación del cambio

Esta detalla las tareas a realizar, fechas y responsables, así como las mejores prácticas para asegurar la menor disrupción de los procesos de la empresa.
Por ejemplo, aquí se establecería la ventana de cambio, como un sábado a la una de la madrugada, porque es cuando menos se visita la web a modificar. O bien, si se trata de algo que afecta a áreas críticas, se planean pruebas en un entorno de staging o se usan otras prácticas emergentes en gestión de cambios, como un gemelo virtual.
Así, construiríamos un gemelo de nuestros sistemas de manera virtual, implementando primero el cambio en él y comprobando qué ocurre. Del mismo modo, planteamos un plan de rollback para que, si sale mal, «pulsemos Ctrl+Z».
La metodología ITIL engloba estas fases de evaluación, aprobación y planificación en una sola (llamada «Evaluación y planificación»). Aunque sigo este marco de referencia, he desglosado sus tres principales componentes para verlos más claramente.

Implementación del cambio

Que no es más que llevar lo planificado a la realidad.

Revisión del cambio

Cuando Napoleón dijo que ningún plan aguantaba el contacto con la realidad, no hablaba de IT, pero podría haberlo hecho, de ahí la necesidad de:

• Comprobar que el cambio no produce efectos indeseados.
• Comprobar que consigue los objetivos planteados que deseábamos con él, con métricas adecuadas, que veremos más adelante.

Documentación

Si ha salido bien, documentamos y, por ejemplo, si hemos trasladado servicios a la nube, actualizamos la CMDB (Configuration Management Database) con la información pertinente.

Las dos vertientes del cambio en IT

Visto el ciclo de vida, debemos tener en cuenta que gran parte de la vertiente «externa» de cambios vendrá de los usuarios, mediante incidencias y peticiones.
Por otro lado, gran parte de la vertiente «interna» vendrá del desarrollo de nuestros propios proyectos.
Por eso, es fundamental integrar y automatizar en lo posible ambas cosas. Ahí es donde entran el Service Desk, que traerá muchos cambios externos, y las herramientas de gestión de proyectos y procesos empresariales, que motivarán buena parte de los internos.
Veamos estos dos aspectos más a fondo.

Gestión del cambio en ITSM y Service Desk

La gestión del cambio en IT es un core process del ITSM (Gestión de Servicios de TI), además de jugar un papel crítico en el Service Desk, el punto de contacto con el usuario y puerta de entrada de muchos cambios, motivados por subsanaciones de errores o peticiones de mejora de procesos.
Según la metodología ITIL, los cambios pueden ser:

• Estándar: de bajo riesgo y habituales, como renovar un certificado SSL.
• Normales: un cambio previsto, pero de mayor envergadura con consecuencias importantes, que debe ser revisado y gestionado por el CAB.
• De emergencia: imprevistos y urgentes, como mitigar una vulnerabilidad descubierta.

Dado que muchos cambios provendrán de los usuarios, es fundamental automatizar en lo posible, integrando con herramientas de gestión de tickets, que agilicen y tracen esos cambios.

Gestión del cambio en Project Management

El avance de nuestros proyectos IT también motivará cambios. De ahí la importancia de integrar también un control de cambios en gestión de proyectos
El manifiesto Agile establece que: «Los cambios en requerimientos son bienvenidos» (no sé si ese es el sentimiento real en el día a día, pero bueno), y en Scrum, el backlog de producto define esos cambios, que deben priorizarse por importancia y dividirse en cambios más pequeños cuando este es muy grande.
Sin embargo, en la gestión ágil del cambio también existe el principio de «proteger el sprint», de modo que, cuando en el backlog del sprint aparece un cambio, no corremos a implementarlo. Analizamos y, muchas veces, solo implementaremos cambios de emergencia, especialmente cuando los no urgentes comprometen el sprint actual, integrándolos ya en el siguiente.
En este contexto, DevOps y la automatización son aliados clave. Los pipelines de CI/CD (como Jenkins o GitLab CI) permiten implementar cambios en código de forma ágil. Mientras, herramientas de infraestructura como código (Terraform, Ansible) garantizan que cada modificación en servidores o redes sea trazable y reversible. Así, incluso cambios complejos se gestionan con la agilidad que exigen metodologías como Scrum.
Al final, proyectos de TI y reformas en casa se parecen demasiado. Esas «pequeñas modificaciones» que surgen multiplican tiempos y presupuestos. Si no queremos que el cronograma se estire más allá del universo conocido, debemos controlar bien ese flujo de cambios.

Seguridad, cumplimiento y desafíos en la gestión del cambio en IT

En tecnología, tenemos que atender a muchos amos. Por eso, la gestión del cambio no tiene en cuenta solo lo que surge de usuarios, proyectos o motivos externos (nueva legislación, por ejemplo), sino que también es necesario considerar estos desafíos adicionales:

• Que esos cambios no alteren el cumplimiento de normativas (RGPD, ISOs…). Estos son los márgenes que marcan nuestros límites.
• Que no comprometan la seguridad, lo que implica que el departamento de ciberseguridad debe sentarse en el CAB.
• Que la documentación refleje adecuadamente esos cambios, tanto internamente (en la base de conocimiento) como externamente (ante posibles revisiones o auditorías, como las de la NIS2). Igual que todo software tiene su changelog y es una de sus referencias más útiles, nuestros cambios deben estar igualmente documentados. Para ello, herramientas como Pandora ITSM nos harán la vida más fácil.
• Que las personas implicadas reciban formación en el cambio y este se adopte correctamente.
• Que se cumplan los objetivos, lo que significa establecer y comprobar KPIs.
• Que se minimicen riesgos, analizándolos y con una política de rollback en caso de desastre.

KPIs y métricas para evaluar la efectividad de los cambios

Estas métricas variarán según el cambio concreto, pero abarcan dos ámbitos.

• Métricas de la mejora deseada. Si hemos migrado a la nube para un mayor rendimiento, debemos medirlo y corroborar que sea así. Los SLAs y la satisfacción del usuario son también KPIs clave en cualquier cambio no trivial, porque son nuestro objetivo último: optimizar experiencia y servicio, no cambiar por capricho o moda.
• Métricas de nuestra capacidad de cambio. Como pueden ser:
  • Porcentaje de cambios exitosos.
  • Tiempo medio de implementación.
  • Impacto en la disponibilidad.
  • Costos asociados, etc.

Nosotros queríamos ser tecnólogos y acabamos siendo malabaristas, con demasiadas cosas en el aire que parecen a punto de caer. Esa sensación es habitual en la gestión de cambios, por eso la importancia de aplicar metodologías probadas.

Metodologías para gestión del cambio IT

Estas recogen las mejores prácticas de gestión del cambio en IT y las principales son:

ITIL

Es decir, Information Technology Infrastructure Library o Biblioteca de Infraestructura de Tecnologías de Información.
Es el marco de trabajo de referencia y el que permea toda esta guía. Contiene un conjunto de mejores prácticas para la gestión de servicios de TI, definiendo procesos estandarizados para evaluar, aprobar e implementar cambios.

ADKAR

Un modelo desarrollado por Prosci y centrado en el factor humano. De ahí que el acrónimo haga referencia a las 5 etapas que define para la adopción del cambio: Awareness, Desire, Knowledge, Ability, Reinforcement (Conciencia, Deseo, Conocimiento, Habilidad, Refuerzo).
Cuando se trata de cambios que requieren adopción de nuevas tecnologías o formas de trabajo, puede ser el más adecuado.

Kotter

Desarrollado por John P. Kotter, propone 8 pasos para un cambio exitoso, desde establecer un sentido de urgencia, hasta la comunicación y el empoderamiento.
De nuevo, es un marco de trabajo que enfatiza la importancia de las personas, el factor más complejo en muchas ocasiones.

Lewin

Creado por Kurt Lewin, solo tiene 3 etapas: Descongelación (preparar cambio), el cambio en sí y la Recongelación o estabilización del cambio.

La gestión del cambio en entornos IT modernos

La tecnología hace que los cambios sean complejos, pero también viene en nuestra ayuda. Por eso, la implementación de procesos estructurados de cambio dentro de un marco de gobernanza IT precisa herramientas especializadas, como Pandora ITSM.
La herramienta entiende que los cambios son un core process crítico en ITSM y aplica las mejores prácticas para crear, aprobar, implementar y auditar dichos cambios en IT de manera estructurada y automatizada.
Así no seremos el siguiente Knight Capital que alguien cite de ejemplo sobre cómo no gestionar el cambio en IT.

El flujo del proceso de cambio en Pandora ITSM

Pandora ITSM permite un control total del cambio durante todo su ciclo de vida, pudiendo gestionar:

• El registro inicial del cambio.
• Su evaluación por el CAB y el Change Manager, con la autorización si procede (o bien el rechazo y/o la petición de más información).
• La planificación y asignación de tareas, responsables y plazos para hacer realidad ese cambio.
• El registro de observaciones, imprevistos y la vinculación con tickets ITSM.
• La revisión del cambio y cierre del mismo.
• El registro y documentación final.

Las mejores herramientas son reflejo de las mejores prácticas, y Pandora ITSM recoge los métodos probados más exitosos en cada paso.
Del mismo modo, integra la capacidad de definir esos cambios como estándar, normal y de emergencia (siguiendo el marco ITIL) y controlarlos.
Los cambios son como niños pequeños, los pierdes de vista un instante y enseguida huele a quemado. La trazabilidad con Pandora ITSM permite saber siempre en qué punto están y recoger toda la información para posibles auditorías internas o externas.
Además, implementa características que hacen la gestión y el control de cambios en ITSM lo más fácil e indoloro posible, como:

• Automatización, notificaciones y alertas.
• Flujos predefinidos para no salirnos de las mejores prácticas.
• Plantillas para que cambios rutinarios y repetitivos sean un suspiro.
• Control de accesos y roles para una seguridad adecuada.
• Logs detallados para el cumplimiento de normativas y revisiones externas o internas, etc.

En definitiva, levanta el peso pesado de la gestión de cambios en TI, nos guía por la mejor manera de hacerlo y reduce errores, al seguir el flujo estructurado más eficiente.
El cambio no se puede evitar, pero el caos sí. Para eso, debemos familiarizarnos con las metodologías óptimas y las herramientas que las implementan, como Pandora ITSM. Cualquier otra cosa será invocar a Loki correteando por ahí con un mechero en cuanto surja la necesidad de un cambio, algo que en tecnología sucede cada minuto.