Gestión del cambio en TI: una guía práctica para reducir el riesgo sin ralentizar el proceso

La gestión del cambio tiene un problema de reputación en el ámbito de las tecnologías de la información. Para muchos equipos, supone papeleo, aprobaciones lentas y procesos de gobernanza que parecen diseñados para obstaculizar el trabajo en lugar de protegerlo. Esa reputación no es del todo injusta. Una gestión del cambio mal aplicada realmente genera fricciones sin aportar un valor proporcional.

Pero una gestión del cambio bien implementada es algo totalmente distinto. Se trata de un enfoque estructurado para controlar el riesgo que conlleva cada modificación en un entorno de TI, de tal forma que se proteja la disponibilidad del servicio sin que cada ticket parezca un mero trámite de cumplimiento normativo. Según el informe «State of the MSP 2026» de Kaseya, el 18 % de los MSP señalan el uso ineficiente de sus soluciones de software como uno de los principales problemas operativos diarios, y los cambios no gestionados y no documentados son uno de los principales factores que contribuyen a ello.

La plataforma de Kaseya ayuda a los proveedores de servicios gestionados (MSP) y a los equipos de TI a gestionar miles de entornos de clientes cada día, lo que ofrece una visión clara de en qué casos los procesos de cambio tienen éxito y en cuáles provocan precisamente las incidencias que se pretendía evitar. Esta guía explica cómo funciona la gestión de cambios de TI, por qué es importante y cómo crear un proceso que mejore realmente el funcionamiento de tu entorno.

Documenta cada cambio. Recupera cualquier cambio.

IT Glue mantiene actualizados tus registros de cambios, configuraciones y guías de procedimientos, de modo que, cuando un cambio provoque una incidencia, tu equipo disponga de la información necesaria para resolverla rápidamente.

Explora IT Glue

Qué es la gestión del cambio en TI y qué no es

La gestión del cambio en TI es el proceso de gestionar las modificaciones en un entorno de TI —hardware, software, configuración, infraestructura y servicios— de manera que se minimice el riesgo de que dichas modificaciones provoquen interrupciones imprevistas.

Es un proceso, no una herramienta. El software puede facilitarlo, pero el valor reside en la disciplina: documentar qué se está modificando y por qué; evaluar los riesgos y el impacto antes de comenzar el trabajo; obtener las autorizaciones pertinentes; programar los cambios para minimizar las interrupciones; probar y validar el resultado; y tener preparado un plan de reversión por si algo sale mal.

Lo que no es, en cambio, es una razón para rechazar todas las solicitudes de cambio. ITIL 4, el marco más utilizado para la gestión de servicios de TI, cambió deliberadamente el nombre de esta práctica de «gestión del cambio» a «facilitación del cambio». Ese cambio de terminología refleja el objetivo real: facilitar cambios rápidos y seguros, en lugar de restringirlos. El arte de una buena gestión del cambio consiste en adaptar la gobernanza al nivel de riesgo, de modo que los cambios rutinarios se lleven a cabo con rapidez y los de mayor repercusión reciban el escrutinio que necesitan.

Por qué los cambios no controlados son la principal causa de incidencias

Los estudios del sector estiman sistemáticamente que la mayoría de las incidencias en los servicios de TI se deben directamente a cambios en el entorno. Un parche aplicado sin pruebas provoca un fallo en una aplicación. Un cambio de configuración realizado sin documentar el estado original no permite revertirlo. Una modificación en la red realizada por un ingeniero sin informar al resto del equipo crea un «agujero negro» a la hora de solucionar problemas cuando, tres días después, se produce un fallo.

Los daños derivados de los incidentes relacionados con los cambios se ven agravados por la falta de información. Cuando se produce un incidente y la primera pregunta es «¿qué ha cambiado recientemente?», un equipo que cuente con registros rigurosos de los cambios puede responder en cuestión de segundos. Un equipo que carezca de ellos se ve obligado a realizar un trabajo de investigación en medio de una interrupción del servicio, lo que ralentiza cada paso del diagnóstico y la resolución.

Para los MSP, esto supone una gran preocupación, ya que el alcance de un cambio mal gestionado puede extenderse a múltiples entornos de clientes a la vez. Un script implementado en el grupo de dispositivos equivocado. Un parche que provoca fallos en una aplicación de negocio que se ejecuta en varios clientes. Un cambio en la configuración de red que afecta a la infraestructura compartida. El carácter multicliente de las operaciones de los MSP hace que la disciplina en la gestión de cambios sea aún más importante, y no menos. Una práctica de gestión de cambios bien documentada se está convirtiendo cada vez más en un factor diferenciador a la hora de presentar ofertas a clientes del mercado medio que esperan controles demostrables.

Los tres tipos de cambios en el ámbito de las tecnologías de la información

ITIL y la mayoría de los marcos de gestión del cambio empresarial clasifican los cambios en tres tipos, cada uno de los cuales conlleva un riesgo diferente y requiere distintos niveles de proceso.

Los cambios estándar son modificaciones preaprobadas, rutinarias y de bajo riesgo que siguen un procedimiento establecido y documentado. Algunos ejemplos son las actualizaciones estándar de software, las tareas de mantenimiento programadas y las sustituciones rutinarias de hardware. Estos cambios pueden implementarse sin necesidad de seguir un ciclo completo de solicitud y aprobación de cambios. El propio procedimiento documentado sirve como aprobación. Los cambios estándar son candidatos idóneos para la automatización, lo que reduce tanto la carga de tiempo como la posibilidad de que se produzcan errores humanos.

Los cambios normales son aquellas modificaciones que no se consideran estándar. Requieren una solicitud de cambio, una evaluación de riesgos y una aprobación antes de su implementación. Entre ellos pueden figurar cambios en la infraestructura, actualizaciones de aplicaciones, modificaciones en la configuración de seguridad o implementaciones de nuevos servicios. El nivel de aprobación necesario —el responsable de TI, el Comité Asesor de Cambios (CAB) o la autorización del cliente en el caso de los MSP— depende del nivel de riesgo y del proceso definido por la organización.

Los cambios de emergencia son necesarios para resolver incidentes críticos o vulnerabilidades de seguridad en los que el plazo habitual de implementación de cambios provocaría una interrupción inaceptable. Los cambios de emergencia cuentan con un proceso de aprobación acelerado, en el que suele intervenir un único responsable de alto nivel en lugar de una revisión por parte de toda la junta, y se elaborará documentación tras la implementación para dejar constancia de lo que se ha hecho y por qué. La vía de emergencia existe para situaciones de crisis reales, no como un atajo para eludir unos procedimientos de gobernanza que resultan incómodos.

La capacidad de clasificar correctamente los cambios es lo que determina el éxito o el fracaso de la mayoría de los procesos de gestión del cambio. Considerar los cambios normales y con consecuencias como algo habitual es lo que da lugar a los incidentes. Tratar todo como una emergencia es lo que hace que el proceso de emergencia pierda todo su sentido.

El proceso de gestión del cambio en TI: paso a paso

Sea cual sea el marco que se siga, un proceso de gestión del cambio bien gestionado sigue un ciclo de vida coherente. El marco de las «7 R» es una herramienta útil para realizar una comprobación previa en la fase de solicitud. Antes de que se lleve a cabo cualquier cambio, hay que preguntarse: ¿Quién lo ha propuesto? ¿Cuál es el motivo? ¿Qué beneficios se esperan? ¿Qué riesgos conlleva? ¿Quién es el responsable de su implementación? ¿Qué recursos se necesitan? ¿Cuál es su relación con otros cambios en curso?

A partir de ahí, el proceso se desarrolla de la siguiente manera.

1. Envía una solicitud de cambio. Documenta el cambio propuesto, sus objetivos, su justificación, el impacto previsto y las dependencias. Este registro hace posible cada paso posterior y constituye la base de tu registro de auditoría.

2. Evalúa el riesgo y el impacto. Analiza las posibles interrupciones, las implicaciones en materia de seguridad, las dependencias del sistema y los recursos necesarios. Involucra a las personas que se verán afectadas, no solo a quien solicita el cambio.

3. Clasificar y priorizar. En función de la evaluación, clasificar el cambio como estándar, normal o de emergencia. Esto determina la vía de aprobación y el nivel de supervisión que se aplicará.

4. Obtén la autorización correspondiente. Los cambios normales y de emergencia se someten al proceso de revisión adecuado. Los cambios de alto riesgo se remiten al Comité de Aprobación de Cambios (CAB); los de menor riesgo se someten a un proceso de aprobación simplificado.

5. Planifica la implementación. Define los pasos exactos, el plazo previsto, el método de pruebas y el procedimiento de reversión antes de realizar ningún cambio en el entorno.

6. Implementar y supervisar. Llevar a cabo el cambio durante el plazo acordado, con un sistema de supervisión que permita detectar rápidamente cualquier efecto no deseado.

7. Revisar y documentar. ¿Se ha logrado con el cambio el resultado previsto? ¿Ha habido efectos inesperados? Actualizar la documentación para reflejar la nueva situación y recoger las lecciones aprendidas de cara a futuros cambios.

Cómo crear un proceso de gestión del cambio que funcione

Un proceso de gestión del cambio eficaz cuenta con varios componentes esenciales. La clave está en que cada uno de ellos sea proporcional al nivel de riesgo del cambio al que se aplica.

Una plantilla de solicitud de cambio que recoge lo esencial: descripción, motivo, sistemas afectados, plazo de implementación, evaluación de riesgos, plan de pruebas, procedimiento de reversión y autorizaciones necesarias. Un formulario estructurado que se rellena en cinco minutos se utilizará de forma sistemática; uno que lleve una hora, no.

Un marco de evaluación de riesgos. Definir criterios para que la evaluación de riesgos sea coherente en todo el equipo: impacto en los sistemas críticos, número de usuarios afectados, reversibilidad y dependencias. Las decisiones discrecionales que varían según cada persona constituyen una deficiencia del proceso, no una ventaja.

Un flujo de trabajo de aprobación que se adapte al nivel de riesgo. Los cambios estándar de bajo riesgo no deberían requerir el mismo proceso que un cambio en la infraestructura básica. Los umbrales de aprobación por niveles garantizan la eficiencia del proceso sin descuidar la supervisión donde es importante: autoaprobación para los cambios estándar, autorización del responsable para los de riesgo moderado y revisión del Comité de Aprobación de Cambios (CAB) para los cambios de gran impacto.

Un calendario de cambios. ¿Cuándo están programados los cambios? ¿Quién está al corriente de ellos? Los periodos de restricción —en torno a eventos empresariales importantes, el cierre del ejercicio fiscal y las ventanas de servicio críticas— deben ser visibles para todas las personas que puedan iniciar un cambio. Se pueden evitar los cambios inesperados durante los periodos de mayor presión en la empresa.

Revisión posterior a la implementación. ¿Se ha logrado con el cambio lo que se pretendía? ¿Ha habido efectos secundarios no deseados? En el caso de cambios significativos, una breve revisión estructurada mejora tanto el registro del cambio como la calidad de futuros cambios similares.

Una observación sobre los contextos de DevOps y ágil: los equipos que aplican la entrega continua necesitan controles ligeros para los cambios de bajo riesgo, no ciclos de aprobación pesados que bloqueen los flujos de implementación. La solución no consiste en prescindir de la gestión de cambios, sino en crear una lógica de aprobación acorde con el riesgo, en la que la captura automatizada de pruebas sustituya a la documentación manual cuando los cambios sean repetibles y estén preaprobados.

Explicación de los modelos de gestión del cambio

Existen varios marcos de referencia consolidados que determinan la forma en que las organizaciones abordan el cambio. Los más relevantes en el ámbito de las tecnologías de la información son:

La «facilitación del cambio» de ITIL 4 es el estándar para la gestión de servicios de TI. Ofrece un proceso estructurado para evaluar, aprobar e implementar modificaciones con una interrupción mínima del servicio. El cambio de ITIL 4 hacia la «facilitación del cambio» refleja un enfoque más adaptativo: el objetivo es facilitar rápidamente los cambios beneficiosos, no crear ciclos de revisión burocráticos. ITIL recomienda un Comité de Aprobación de Cambios (CAB) para revisar los cambios de alto riesgo, categorías de cambio claramente definidas y normas de documentación rigurosas en todo momento. Para conocer con más detalle cómo encaja ITIL en la gestión de servicios de TI, consulta nuestra guía sobre ITIL y la gestión de servicios de TI.

El modelo ADKAR (Concienciación, Deseo, Conocimiento, Capacidad, Refuerzo) se centra en la adopción del cambio a nivel individual. Resulta especialmente útil en el contexto de los equipos de MSP y de TI cuando es necesario que un equipo distribuido adopte de forma coherente nuevas herramientas o procesos. Cuando la implantación de un nuevo proceso de gestión del cambio se estanca continuamente, el modelo ADKAR ayuda a identificar exactamente en qué punto se está fallando la adopción a nivel individual.

El modelo de cambio de Lewin divide el cambio en tres etapas: «descongelación» (preparar al equipo abordando la resistencia), «cambio» (aplicar el nuevo enfoque) y «recongelación» (estabilizar la nueva situación para que se convierta en el modelo operativo habitual). Se trata de un marco útil para comprender por qué las mejoras en los procesos no se consolidan cuando se omite la etapa de estabilización.

El modelo de ocho pasos de Kotter, desarrollado en la Harvard Business School, resulta más aplicable a la transformación organizativa a gran escala que a las operaciones informáticas cotidianas. Resulta útil para los responsables de TI que gestionan migraciones importantes de plataformas o revisiones significativas de procesos, en las que el reto es tanto cultural y organizativo como técnico.

Gestión del cambio en « managed services »: consideraciones específicas para los MSP

Para los MSP que gestionan entornos informáticos en nombre de sus clientes, la gestión del cambio conlleva obligaciones adicionales: la comunicación con el cliente, el cumplimiento de los contratos y la complejidad derivada de la coexistencia de múltiples entornos descrita anteriormente.

Normas de comunicación con los clientes. La mayoría de los acuerdos de « managed services » exigen que se notifiquen los cambios previstos, sobre todo aquellos que afecten a la disponibilidad del servicio. Define qué se considera un cambio que debe notificarse, con cuánta antelación debe comunicarse y cómo es el proceso de comunicación. Los clientes que se ven sorprendidos por cambios que afectan a sus operaciones, incluso si dichos cambios salen bien, son los que cuestionan la calidad de tu gestión a la hora de renovar el contrato.

Ventanas de cambio específicas para cada cliente. Cada cliente tiene sus propios ritmos operativos. Un cliente del sector manufacturero puede tener ventanas de mantenimiento estrictas durante los fines de semana. Un cliente del sector minorista puede tener períodos de restricción en torno a las temporadas altas de ventas. Los MSP necesitan calendarios de cambio específicos para cada cliente, no una única política aplicada de forma uniforme a toda la cartera.

Documentación de los cambios a nivel de cliente. Los cambios realizados en los entornos de los clientes deben documentarse en la documentación informática del cliente, y no solo en un registro interno de cambios. Cuando un cliente pregunte qué cambios de configuración se han realizado en su entorno en los últimos 90 días, esa pregunta debe poder responderse en cuestión de segundos.

Así es como se desarrolla ese flujo de trabajo en la práctica en la plataforma Kaseya. Se crea una solicitud de cambio y se realiza su seguimiento en BMS | Autotask en forma de ticket. El registro vinculado de « IT Glue » (Configuración de Datto) recoge la configuración y la documentación pertinentes, de modo que el técnico dispone de una visión completa antes de intervenir. Una vez que el cambio se ha implementado y validado a través de Datto RMM, la documentación de « IT Glue » se actualiza para reflejar el nuevo estado, creando un registro permanente y auditable a nivel del cliente. Ese tipo de flujo de trabajo documentado es lo que los clientes del mercado medio esperan cada vez más de su MSP, y lo que distingue a los proveedores con los que siguen trabajando de aquellos a los que sustituyen.

Más información sobre la plataforma de Kaseya para proveedores de servicios de gestión (MSP).

El papel de la documentación en la gestión del cambio

La gestión del cambio sin documentación es una gestión del cambio que solo funciona hasta que la persona que ha realizado el cambio abandona el equipo.

La documentación y la gestión de cambios están estrechamente relacionadas. Antes de un cambio, la documentación te indica el estado actual: la línea de base que vas a modificar. Durante un cambio, documentar el procedimiento permite crear la ruta de reversión. Después de un cambio, actualizar la documentación para reflejar el nuevo estado garantiza que la siguiente persona que utilice ese sistema disponga de información precisa sobre la que basarse.

En la práctica, esto significa tratar la documentación informática como un sistema vivo que se actualiza con cada cambio, y no como un repositorio que existe al margen de las operaciones cotidianas. Las configuraciones, los diagramas de red, las credenciales y los manuales de procedimientos que no reflejan la realidad actual son peores que la ausencia de documentación. Inducen a error de forma activa a las personas que confían en ellos en situaciones de gran presión.

Para las organizaciones que desean mejorar la gestión del cambio, la calidad de la documentación suele ser la primera inversión que ofrece un mayor rendimiento. Una buena documentación hace que todas las demás actividades de gestión del cambio sean más rápidas, seguras y fiables.

Modos habituales de fallo en la gestión del cambio

«Lo documentaremos después». La documentación elaborada bajo presión de tiempo tras la implementación suele ser, sistemáticamente, menos precisa y completa que la que se prepara como parte del proceso de planificación del cambio. Haz que sea un requisito previo, no una tarea posterior.

Tratar todos los cambios normales como emergencias. El procedimiento de cambios de emergencia está pensado para situaciones de crisis reales. Los equipos que clasifican habitualmente los cambios como emergencias para eludir el proceso de aprobación están frustrando el propósito mismo de contar con dicho proceso. Si el proceso normal resulta demasiado lento para satisfacer necesidades operativas legítimas, la solución pasa por mejorar el proceso, no por recurrir a exenciones de emergencia como solución provisional.

No se han realizado pruebas de reversión. Un plan de reversión que no se ha probado es una suposición, no un plan. En el caso de cambios importantes, comprueba que el procedimiento de reversión funcione realmente antes de implementar el cambio definitivo.

La gestión de cambios como actividad individual. Un solo ingeniero que realice habitualmente cambios no documentados socava todo el sistema, tanto la seguridad que este ofrece como la confianza que genera entre los clientes y las partes interesadas. Hay que imponerla como norma de equipo, no como una decisión individual.

Puntos clave

• La mayoría de las incidencias en los servicios de TI se deben a cambios, lo que significa que la gestión del cambio es, en esencia, un programa de reducción de riesgos, y no un ejercicio de gobernanza.
• Los tres tipos de cambios —estándar, normal y de emergencia— deben contar con procesos proporcionales. Los cambios rutinarios no deberían requerir los mismos recursos administrativos que los de alto riesgo.
• Para los MSP, la gestión del cambio abarca la comunicación con los clientes, las ventanas de mantenimiento específicas para cada cliente y la documentación a nivel de cliente. Una práctica de gestión del cambio bien documentada constituye, además, un activo para la fidelización y la renovación de los clientes.
• La documentación es la infraestructura de la que depende una buena gestión del cambio. Disponer de registros actualizados y precisos es lo que permite realizar cambios seguros y revertirlos rápidamente.
• El giro de ITIL 4 hacia la «facilitación del cambio» refleja el objetivo adecuado: facilitar rápidamente los cambios beneficiosos, en lugar de obstaculizarlos con trabas burocráticas.