Esta guía lo ayudará a comprender los fundamentos de la gestión de cambios basada en IT y le proporcionará las herramientas necesarias para implementar cambios efectivos mediante un proceso de cambios bien definido.
- Introducción a la gestión de cambios de las mejores prácticas de TI
- El «qué»
- El «por qué»
- El «cómo»
Introducción a la gestión de cambios de TI
El panorama empresarial y las expectativas de los clientes cambian constantemente, y la transformación digital se ha convertido en un factor clave para el éxito de las empresas en todas las industrias. La transformación digital se trata de aprovechar la tecnología disponible para enfrentar los desafíos comerciales y aprovechar las oportunidades. Al examinarla en detalle, la transformación digital básicamente es una gestión de TI mejorada para eliminar las áreas problemáticas y equipar su infraestructura de TI para enfrentar los desafíos comerciales. Y esto implica implementar cambios de TI que ayuden a su organización a aplicar nuevas tecnologías a los procesos de negocio y de TI existentes.
Estos cambios pueden ser tan simples como migrar las aplicaciones colaborativas a la nube para mejorar la eficiencia operativa, o adoptar un enfoque móvil para mejorar la experiencia del consumidor. A pesar de su aparente simplicidad, estos cambios tienen sus propios desafíos logísticos. No implementar un cambio correctamente puede hacer que su organización dé un paso adelante y dos hacia atrás.
La actualización fallida de la aplicación móvil de un banco popular en diciembre de 2018 es un gran ejemplo de cómo no implementar un cambio. El plan del banco para introducir una nueva y mejorada aplicación de banca móvil fue una idea brillante y necesaria. Pero la nueva aplicación tuvo problemas desde su lanzamiento. El banco introdujo la nueva aplicación después de haber eliminado la antigua. Cuando falló la nueva aplicación, miles de clientes se quedaron sin poder acceder a sus cuentas bancarias a través de la aplicación. Para empeorar las cosas, hubo muy poca comunicación sobre una solución para la nueva aplicación, dejando a los clientes frustrados. La aplicación móvil estuvo inactiva durante cuatro días antes de que el banco decidiera recuperar la aplicación anterior.
Podemos ver que el banco falló en varias etapas de su cambio propuesto: lanzar la nueva aplicación cuando no estaba lista para implementarse, no ser transparente al no comunicar el tiempo de inactividad asociado con la actualización a los usuarios finales y no tener un plan alternativo en caso de falla. Definitivamente no es la forma como debería implementar su cambio.
Aquí es donde entra en juego la gestión de cambios; le ayuda a gestionar todos los diferentes cambios en su organización y le brinda un proceso para implementar los cambios de manera eficiente sin afectar al resto de su organización. La gestión de cambios reduce la posibilidad de que ocurran interrupciones similares a las que enfrentó el banco.
En esta guía, hablaremos sobre el «qué», el «por qué» y el «cómo» de la gestión de cambios. Aprenderá cómo ayudar a su organización a mantenerse al día con las tendencias de la industria con cambios efectivos.
¡Empecemos!
El «qué»
¿Qué es la gestión de cambios?
Se describe la gestión de cambios como el proceso de controlar y gestionar un cambio a lo largo de todo su ciclo de vida, desde el inicio hasta el cierre, con el objetivo de minimizar el riesgo.
Establecer un proceso sistemático de gestión de cambios ayuda a su organización a implementar los cambios sin incidentes y con una alta tasa de éxito.
¿Qué es un cambio?
Según las mejores prácticas de TI, un cambio es «la adición, modificación o eliminación de cualquier cosa que pueda afectar directa o indirectamente los servicios».
Básicamente, cualquier cambio en la infraestructura de TI de una organización que pueda afectar las operaciones de la organización se considera un cambio de TI. Esto incluye el reemplazo de impresoras, proyectores, servidores, entre otros.
¿Cuál es la diferencia entre un incidente, un problema y un cambio?
Incidente | Problema | Cambio | |
---|---|---|---|
Definición | Según las mejores prácticas de TI, «una interrupción no planificada de un servicio de TI o una reducción en la calidad de un servicio de TI». | Según las mejores prácticas de TI, un problema es «una causa o posible causa de uno o más incidentes». | Según las mejores prácticas de TI, un cambio es «la adición, modificación o eliminación de cualquier cosa que pueda afectar directa o indirectamente los servicios». |
Alcance | Restaurar las operaciones normales de servicio lo antes posible | Identificar la causa raíz de las interrupciones en las operaciones normales de servicio | Implementar un cambio que aborde la causa raíz para evitar futuras interrupciones en las operaciones normales de servicio |
Naturaleza | Reactivo | Reactivo y proactivo | Reactivo y proactivo |
Ejemplo | Los usuarios no pueden conectarse a la red. Se emite una solución alternativa para resolver el incidente y permitir a los usuarios acceder a la red. | Se crea un ticket de problema para realizar el análisis de causa raíz (RCA). Un switch de red no funciona correctamente, lo que genera al incidente. Se debe reemplazar el switch. | Se crea un ticket de cambio para reemplazar el switch defectuoso. |
El «por qué»
¿Por qué las organizaciones necesitan la gestión de cambios?
Ahora que sabemos qué es la gestión de cambios, veamos por qué las organizaciones la necesitan, comenzando con los objetivos de la gestión de cambios.
Objetivos de la gestión de cambios según las mejores prácticas de TI
Permitir a las organizaciones controlar y gestionar sus cambios:
La gestión de cambios le dará un mejor control sobre su proceso de cambios y lo ayudará a implementar los cambios con un riesgo mínimo. Al seguir los procesos estándar, la gestión de cambios garantiza que todos los aspectos de cada cambio (como la planificación, la evaluación de riesgos y el seguimiento de la implementación) se gestionen de manera efectiva. Usar una herramienta de mesa de servicio para controlar los cambios de principio a fin resulta de gran utilidad y permite a las organizaciones gestionar mejor su infraestructura de TI con cambios bien planificados y ejecutados.
Ayudar a las organizaciones a implementar mejor los cambios:
Al controlar todo el proceso de cambios, la gestión de cambios permite a las organizaciones mantenerse al tanto de todas las solicitudes de cambios. También facilita la identificación y reducción de los cambios no autorizados. Al permitir que los usuarios envíen una solicitud de cambio (RFC) solo a través de la herramienta de la mesa de servicio, las organizaciones pueden recopilar toda la información necesaria sobre el cambio desde el principio y luego decidir si realmente es necesario implementar el cambio. Un mecanismo de aprobación robusto garantiza que los cambios reciban todos los permisos necesarios antes de su implementación.
Permitir la mejora continua:
La gestión de cambios no es solo para los tiempos difíciles. Su objetivo es ayudar a las organizaciones a mejorar continuamente su infraestructura y procesos, así como a mantenerse al día con las tendencias de la industria al garantizar que puedan implementar sin problemas los cambios necesarios sin afectar las operaciones de servicio actuales.
Beneficios de la gestión de cambios
Para la organización:
- Menos conflictos entre los cambios gracias a la eficiencia en la gestión de cambios.
- La posibilidad de implementar actualizaciones sin afectar las operaciones.
- Menos cambios fallidos.
- Clasificación precisa de los cambios.
Para los usuarios finales:
- Mejor comunicación sobre el tiempo de inactividad y la falta de disponibilidad de los servicios debido a los cambios programados.
- Operaciones de servicio más fluidas con menos interrupciones causadas por los cambios mal planificados
El «cómo»
¿Cómo llevan a cabo las organizaciones la gestión de cambios?
Ahora veamos cómo puede implementar la gestión de cambios en su organización. Lo primero es establecer un proceso de cambios efectivo que le permita planificar los cambios, obtener la aprobación necesaria e implementar los cambios. A continuación se muestra un proceso de gestión de cambios que puede seguir para manejar los cambios de manera efectiva.
El proceso de gestión de cambios
Paso 1: Envío
En la primera etapa se inicia el cambio. Esto implica recopilar información básica sobre el ticket de cambio, como el tipo de cambio y la prioridad.
- Creación:: Los tickets de cambio se inician con la herramienta de la mesa de servicio. La información necesaria se recopila desde el principio utilizando un formulario de cambio que contiene campos obligatorios.
- Definición de los roles de cambio: Al usar los roles de cambio, las organizaciones pueden delegar las responsabilidades de cambio a diversas partes interesadas y controlar el nivel de acceso de cada rol para cada etapa de un cambio.
Paso 2: Planificación
En la siguiente etapa se planifica todo el cambio. Un cambio bien planificado es el secreto para lograr una implementación de cambios exitosa. También es esencial obtener las aprobaciones necesarias para implementar el cambio. Los detalles como el impacto, los planes de rollout, los planes de backout y el tiempo de inactividad asociado se documentan para presentar claramente el plan de cambio a las partes interesadas y convencerlas de que vale la pena hacer el cambio.
Paso 3: Aprobación
Luego, el plan de cambio debe ser aprobado por el comité asesor de cambios (CAB), el comité asesor de cambios de emergencia (ECAB) y cualquier otra autoridad que tenga interés en el cambio o en la infraestructura organizacional afectada por el cambio. Crear CAB personalizados ayuda a las organizaciones a agrupar el personal relevante para gestionar fácilmente las aprobaciones. Automatizar el proceso de aprobación acelera todo el cambio y garantiza que no se pasen por alto las solicitudes de aprobación.
Nota: El CAB incluye varios roles y equipos de trabajo. Puede incluir ejecutivos corporativos, gerentes de equipo, equipos técnicos, personal de finanzas y más, dependiendo de la gravedad y la escala del cambio.
Paso 4: Implementación
Una vez que se obtienen las aprobaciones necesarias, se puede implementar el cambio. Las organizaciones pueden controlar y gestionar la implementación de cambios creando tareas o usando un proyecto.
- Delegación de trabajo a través de tareas: Las tareas se crean y se asignan a diferentes técnicos de diferentes equipos para gestionar fácilmente el trabajo realizado por todos los individuos involucrados en la implementación del cambio. Las tareas primarias y secundarias se pueden usar para establecer dependencias entre las tareas y garantizar que las tareas se realicen en un orden particular y que no se omitan tareas.
- Aprovechamiento de la gestión de proyectos: Las organizaciones pueden usar proyectos para manejar los cambios a gran escala, como por ejemplo migrar toda la infraestructura de la organización a la nube. Los proyectos pueden abarcar un mayor alcance de implementación y pueden manejar mejor una mayor cantidad de tareas, personas e hitos. Integrar la gestión de cambios y la gestión de proyectos puede ser muy beneficioso para las organizaciones.
Paso 5: Revisión
A continuación, se realiza una revisión post-implementación para garantizar que no haya desviaciones en la implementación y para resolver cualquier problema antes de cerrar el cambio.
Paso 6: Cierre
Este es el último paso en el proceso de gestión de cambios. Aquí se registra la naturaleza del cambio completado como «exitoso», «fallido» o «incompleto». Registrar el código de cierre correcto hace que las métricas de una organización sean mucho más precisas y útiles.
Tipos de cambios según las mejores prácticas de TI
No todos los cambios son iguales, ya que algunos tienen requisitos diferentes. Algunos cambios se deben implementar lo antes posible, algunos necesitan la aprobación de los directivos de la organización, y algunos son cambios normales que se implementan semanalmente.
Según las mejores prácticas de TI, los cambios se pueden clasificar en tres tipos: cambios estándar, cambios normales y cambios de emergencia.
Cambios estándar:
Estos son cambios aprobados previamente que tienen bajo impacto, son reconocidos y están documentados. Los cambios estándar requieren una autorización y evaluación de riesgos cuando se implementan por primera vez, pero las implementaciones posteriores se pueden realizar sin ello siempre que el cambio no se haya modificado.
Ejemplo: reemplazar el cartucho de tinta de una impresora.
Cambios normales:
Un cambio normal debe seguir todo el proceso de cambios; se debe programar, evaluar su riesgo y estar autorizado. Los cambios normales incluyen los cambios menores (urgencia e impacto bajo a medio) y los cambios mayores (urgencia e impacto alto). Todos los cambios que no sean estándar o de emergencia deben tratarse como cambios normales y seguir el proceso de cambios.
Ejemplo: migrar los servicios on-premises a la nube.
Cambios de emergencia:
Los cambios de emergencia tienen un alto impacto y urgencia, y requieren de una rápida evaluación, aprobación e implementación para que los servicios vuelvan a funcionar lo antes posible. Las modificaciones a los componentes que afectan las operaciones comerciales y, por lo tanto, causan tiempos de inactividad, se tratan como cambios de emergencia.
Ejemplos: falla del servidor primario, interrupción del centro de datos, parche de emergencia para una vulnerabilidad de seguridad.
Roles y responsabilidades de la gestión de cambios
Propietario del cambio:
El propietario del cambio es responsable de todo el proceso de gestión de cambios, incluida la mejora. Ya que es responsable de la gestión de cambios en la organización, generalmente es un funcionario de alto rango.
Gestor del cambio:
El gestor del cambio maneja la implementación del cambio y las actividades relacionadas. También gestiona el CAB y los diversos equipos y partes interesadas involucrados, y coordina con ellos.
Iniciador del cambio:
El iniciador del cambio es quien inicia el cambio y agrega los planes de cambio, los planes de implementación y otros detalles necesarios. También organiza el plan de implementación del cambio. El iniciador del cambio puede ser un técnico o un usuario final.
CAB:
El CAB reúne a varios miembros de diferentes equipos y con diversas funciones de trabajo. Juntos analizan el cambio propuesto y dan su aprobación y recomendaciones con respecto al cambio y su implementación.
Roles adicionales
Algunas organizaciones usan roles personalizados además de estos cuatro roles principales para delegar el trabajo y asignar las responsabilidades. Los roles personalizados lo ayudan a adaptar el proceso de gestión de cambios a las necesidades de su organización. Estos son algunos de los roles adicionales más comunes:
- Aprobador del cambio
- Implementador del cambio
- Revisor del cambior
- Planificador del cambio
Proceso/roles | Gestor del cambio | Iniciador del cambio | CAB | Propietario del cambio |
---|---|---|---|---|
Envío | C | R | - | A |
Creación | C | R | - | A |
Definición de los roles de cambio | C | R | - | A |
Planificación | C | R | - | A |
Aprobación | R | I | C | A |
Implementación | C | R | - | A |
Delegación del trabajo a través de tareas | C | R | - | A |
Aprovechamiento de la gestión de proyectos | C | R | - | A |
Revisión | R | I | - | A |
Cierre | C | R | - | A |
* R - Responsable, A - Aprobador, C - Consultado, I - Informado
4 desafíos comunes de la gestión de cambios
Estos son cuatro desafíos comunes que pueden dificultar la gestión de cambios.
-
Cambios fallidos:
Los cambios requieren una gran cantidad de recursos, ya que se necesita mucho tiempo e investigación para planificar los cambios. Una gran cantidad de cambios fallidos pueden generar muchos costos si no se controlan. En el caso de cambios de infraestructura, una alta tasa de fallas puede generar problemas más grandes durante la implementación o al implementar los planes de retroceso. Muchos cambios fallidos también son un indicador de un proceso de gestión de cambios deficiente.
Ejemplo: Zylker planeó actualizar su infraestructura de red primaria, por lo que la compañía estableció una red alternativa con un proveedor de red externo; planeó implementar el cambio durante un fin de semana. Durante la implementación, Zylker recibió tickets por la caída de los servicios, lo cual fue una sorpresa dado que la compañía había establecido una red alternativa. Resulta que el proveedor de red alternativo también estaba realizando un mantenimiento ese fin de semana, lo que significaba que tanto las redes primarias como las redes alternativas de Zylker estaban caídas, lo que hacía que los servicios de Zylker no estuvieran disponibles. Como el cambio no se planificó correctamente, terminó siendo un fracaso.
-
Cambios no autorizados:
Los cambios no autorizados son el resultado de un mecanismo de aprobación mediocre y de no incluir a las partes interesadas correctas en la etapa de aprobación. Estos cambios omiten los permisos necesarios y pueden terminar siendo implementados si no se identifican a tiempo. Los cambios no autorizados pueden conducir a cambios que su organización no necesita o no está lista para implementar. El hecho es que los cambios no autorizados son un problema y un gasto innecesario.
-
Demasiados cambios de emergencia:
Como se explicó anteriormente, los cambios de emergencia requieren de una rápida aprobación para que puedan implementarse lo antes posible. Tratar demasiados cambios como si fuesen cambios de emergencia puede generar retrasos en caso de que se deba implementar un cambio de emergencia grave. Siempre es bueno tener precaución al clasificar un cambio como un cambio de emergencia.
Nota: La popular historia sobre «El pastorcito mentiroso» es una buena analogía de por qué tratar demasiados cambios como si fuesen cambios de emergencia puede ser contraproducente. En caso de que suceda una emergencia real, es posible que su organización no aborde el cambio con la debida seriedad, y es posible que no tenga los recursos necesarios para manejar la emergencia.
-
Conflictos entre los cambios:
La mala planificación puede conducir a un conflicto entre los cambios. Los conflictos entre los cambios se generan cuando se planea implementar dos o más cambios simultáneamente sin saberlo, interrumpiendo la implementación de cualquiera de los cambios. Utilizar un cronograma de cambios para planificar mejor los cambios puede ayudar a prevenir los conflictos entre los cambios.
10 mejores prácticas de la gestión de cambios
Estas son las mejores formas de abordar la gestión de cambios.
-
Identificar los tipos de cambios:
No todos los cambios son iguales. Los cambios tienen diferentes niveles de prioridad y diferentes requisitos, como se explicó en la sección sobre los tipos de cambios. Por lo tanto, es importante identificar primero los tipos de cambios que su organización podría realizar, y luego crear diferentes tipos de cambios para implementarlos de manera efectiva.
-
Diseñar procesos para los diferentes tipos de cambio:
Dado que los diferentes tipos de cambios tienen sus propios requisitos únicos, debe diseñar procesos únicos para satisfacer esas necesidades. Usar el mismo proceso de cambio para todos los tipos de cambios solo generará demoras innecesarias e implementaciones de cambio incompletas.
Nota: Puede crear diferentes flujos de trabajo de cambio para cada uno de sus tipos de cambio.
-
Definir los roles y las responsabilidades clave:
Los roles permiten al gestor de cambios delegar las actividades y responsabilidades a otras personas. Los roles facilitan la gestión de cambios y definen claramente las actividades que puede realizar cada persona.
-
Registrar, gestionar y priorizar las propuestas de cambio:
Es una buena práctica establecer una forma de registrar, gestionar y priorizar los cambios en un solo lugar de manera organizada. Si tiene una mejor visibilidad de los cambios de su organización, puede priorizar cuáles cambios se deben implementar primero.
-
Obtener información clara sobre los riesgos y el impacto de los cambios:
Todos los cambios se deben someter a un análisis de riesgo e impacto para comprender mejor el cambio y asignar los recursos necesarios. Los detalles sobre el riesgo y el impacto se deben agregar en la etapa de planificación para que el CAB tenga una idea clara del cambio y pueda dar su recomendación.
-
Implementar un mecanismo de aprobación efectivo:
Definir el proceso de aprobación facilita la obtención de los permisos necesarios para implementar un cambio. De esta forma se garantiza que todas las partes interesadas clave estén al tanto de los cambios y den su recomendación antes de implementar un cambio. Esto ayuda a evitar los cambios no autorizados.
-
Comunicar los horarios y cualquier tiempo de inactividad a las partes interesadas:
Mantener a las partes interesadas informadas respecto a los cambios planificados reduce la cantidad de incidentes causados por los cambios. Entregar la información de manera oportuna también ayuda a garantizar que los servicios no se vean afectados debido a los cambios, y que el cambio se puede implementar de manera efectiva. Además, los directivos prefieren estar informados durante todo el ciclo de vida del cambio.
-
Medir el progreso y la efectividad de las implementaciones de cambios:
Supervisar el cambio durante todo su ciclo de vida garantiza que nada salga mal y que el cambio se implemente de acuerdo con el plan de cambio. Medir las métricas clave le permite tener una idea clara de cuán efectivo es su proceso de cambio y también le permite identificar las áreas que puede mejorar.
-
Establecer planes de contingencia:
Nunca se está demasiado preparado, por lo que siempre es una buena idea planificar cuál es la peor situación posible y elaborar un plan de retroceso durante la etapa de planificación del cambio. Esta planificación detallada puede significar la diferencia entre un cambio fallido común y corriente o un daño irreversible en su infraestructura de TI.
-
Implementar la mejora continua del servicio:
Si bien las estrategias de contingencia son una parte crucial de la gestión de cambios, los cambios tienen un alcance más amplio en su organización. Los cambios pueden mejorar la tecnología y los procesos. Por lo tanto, el poder mejorar continuamente la capacidad de su organización para proporcionar mejores servicios se está convirtiendo en otro factor importante de la gestión de cambios.
Establezca su propio proceso de gestión de cambios basado en las mejores prácticas con ServiceDesk Plus
¿Cómo encaja la gestión de cambios en su proceso de gestión de servicios de TI?
La gestión de cambios no termina al completar un cambio. La efectividad de los cambios implementados se puede mejorar si la gestión de cambios aprovecha la información recopilada en otros procesos de ITSM y viceversa. La posibilidad de asociar los incidentes con los cambios causados o causantes, o actualizar la CMDB en función de los cambios de la infraestructura de TI, tan solo son el comienzo de crear una práctica de ITSM integral que funcione en conjunto para ayudar a gestionar mejor su organización.
Así es como la gestión de cambios puede trabajar junto con sus otros procesos de ITSM:
-
Gestión de incidentes:
Dar seguimiento a los incidentes que causan o que son causados por un cambio le permite comprender mejor cómo los cambios afectan a su organización. Por ejemplo, cuando se actualiza un router, es posible que reciba tickets de incidentes informando que Internet está caído. Asociar los cambios con los incidentes que causaron lo ayuda a identificar rápidamente la causa de un incidente y a evitar asignar recursos para solucionar ese incidente en particular, ya que se solucionará tan pronto como se complete el cambio.
-
Cumplimiento de solicitudes:
Es importante utilizar los cambios para las solicitudes de servicio de alto impacto a fin de mantener actualizada su infraestructura de TI. Sin cambios, una solicitud de servicio para actualizar el servidor o una solicitud para actualizar el espacio de almacenamiento de Azure finalizaría con la entrega del servicio. Pero si utiliza un cambio para implementar la solicitud de servicio, puede recopilar más información (como el motivo del cambio y el plan de implementación), obtener las aprobaciones necesarias de todas las partes interesadas y actualizar la CMDB con la nueva información.
Nota: Los cambios para el cumplimiento de la solicitud son más eficientes si se usan para las solicitudes de servicio de alto impacto y cualquier solicitud de servicio que requiera un cambio en la CMDB. Si se debe actualizar la CMDB, ¡entonces se necesita un cambio!
-
Gestión de problemas:
La gestión de problemas requiere crear un cambio para corregir la causa raíz de un problema. Poder crear una RFC directamente desde un ticket de problema facilita el control de los cambios y problemas asociados. También le da al CAB una mejor idea de por qué se requiere el cambio, y denota la gravedad del problema que inició el cambio.
-
Gestión de liberaciones e implementaciones:
Las actualizaciones de las liberaciones e implementaciones se benefician del enfoque estructurado que brinda el proceso de cambio. Puede controlar fácilmente los planes de implementación, los planes de rollout y la implementación real de las liberaciones y despliegues utilizando cambios. La transparencia y visibilidad que ofrecen los cambios también ayuda a mantener informados a todos los interesados.
-
CMDB:
Cualquier actualización en la CMDB se debe realizar con un cambio. Un cambio proporciona mucha información útil sobre por qué, cómo y cuándo se realizó la actualización. El análisis de impacto que se realiza junto con el cambio también garantiza que las actualizaciones de la CMDB se analicen correctamente y que la actualización no cree interrupciones en el resto de la organización. Puede usar los diversos tipos de cambio para registrar las actualizaciones de la CMDB que tienen distintas prioridades.
Garantice la integridad de su ITSM
KPI de la gestión de cambios
Estas son algunas métricas importantes para medir la efectividad de su proceso de gestión de cambios.
KPI | Fórmula | Comentarios |
---|---|---|
Número de cambios no autorizados | El número de cambios no autorizados identificados durante un período de tiempo específico | Si el número es bajo, esto indica que su proceso de aprobación es sólido y capaz de gestionar todos los cambios. |
Número de solicitudes de servicio de alto impacto cumplidas sin realizar cambios | El número de solicitudes de servicio de alto impacto cumplidas sin realizar un cambio durante un período de tiempo específico | Las solicitudes de servicio de alto impacto se deben cumplir mediante un cambio. Si el número es alto, esto indica que su infraestructura es vulnerable a los problemas, como los fallos en la actualización de la CMDB. |
Porcentaje de cambios revertidos | El porcentaje de cambios que usaron el plan de retroceso debido a problemas durante la implementación | Si el número es alto, esto indica que los cambios están mal planificados. |
Tasa de aceptación de cambios | El porcentaje de cambios que fueron aprobados por el CAB | Esto indica la efectividad de sus solicitudes de cambio y planes de cambio. Si el número es alto, esto indica que sus cambios y planificación son sólidos. |
Variación de cronograma | La desviación entre el tiempo empleado y el tiempo estimado | Esto indica si sus cambios se implementan a tiempo y de acuerdo con el plan de cambio. |
Número de incidentes causados por el cambio | El número de incidentes causados por un cambio particular | Esto indica si un cambio afecta a otras operaciones de servicio. Si el número es alto, esto indica que los cambios se deben comunicar mejor. |
Porcentaje de cambios completados a tiempo | El porcentaje de cambios completados a tiempo | Esto indica si el proceso de cambio está funcionando de manera óptima. Cuanto mayor sea el porcentaje, mejor será el proceso de gestión de cambios. |
Caso de uso
Analicemos un cambio en detalle para ver cómo puede mejorar su proceso de gestión de cambios.
Zylker, una empresa con una gran cantidad de usuarios remotos, decide migrar a la nube.
Actualmente, todas las aplicaciones y recursos de productividad de la compañía son internos, por lo que los usuarios remotos tienen acceso a la red a través de una VPN. Con el fin de agilizar el acceso a los datos, Zylker decide comenzar a usar aplicaciones en la nube. Decide utilizar Zoho One por su paquete de productividad y Office 365 por el correo electrónico. Parte de los recursos de la compañía, como sus servidores de archivos y bases de datos, todavía están en las instalaciones, por lo que los usuarios remotos también deben tener acceso a ellos.
Para cumplir con este requisito, el equipo de TI configura un entorno híbrido de Azure Active Directory (AD). Proporcionan un servidor federado para replicar su AD on-premises en el Azure AD basado en la nube. Ahora los usuarios finales, incluso los usuarios remotos, pueden acceder a los recursos de la nube con sus credenciales de AD.
Paso 1: Emitir la RFC
El primer paso es generar un ticket de cambio y recopilar la información necesaria sobre el cambio, como el tipo de cambio, el impacto del cambio y la urgencia, y establecer los roles de cambio. El iniciador del cambio puede emitir un ticket de cambio fácilmente utilizando su portal web y elegir la plantilla de cambio y el tipo de cambio relevantes. La plantilla de cambio recopila toda la información necesaria utilizando campos obligatorios. Luego, el iniciador del cambio establece el tipo de cambio como «normal», selecciona la plantilla de cambio apropiada, asigna los roles de cambio y describe por qué se requiere el cambio.
Paso 2: Planificar el cambio
A continuación, el iniciador del cambio agrega la información del cambio, como el motivo del cambio, información detallada sobre su impacto, los planes de rollout y backout, y el tiempo de inactividad programado. El iniciador de cambios también agrega todos los incidentes y problemas asociados para realizar un mejor seguimiento del cambio y su impacto. A continuación se detallan los diversos planes que ideó el iniciador del cambio.
Plan de rollout:
- Obtener cuentas de Azure AD y Office 365
- Configurar los servicios de federación de Active Directory (ADFS)
- Iniciar la sincronización entre AD on-premises y Azure AD
- Configurar el inicio de sesión único
- Sincronizar Exchange on-premises con Office 365
Plan de backout:
Dado que la configuración existente está intacta, revertir a la configuración anterior y reanudar los servicios.
Tiempo de inactividad planificado: 12 horas
Paso 3: Obtener las aprobaciones necesarias
El gestor del cambio establece los CAB para revisar el plan de cambios y dar una recomendación sobre si se debe implementar el cambio o modificar el plan. Como se trata de un cambio a gran escala, se requiere la aprobación de varios roles de trabajo con distintos cargos. A continuación se muestra una lista de los CAB y los miembros involucrados en el proceso de aprobación:
- CAB ejecutivo:
- Director de Información (CIO)
- Director de Tecnología (CTO)
- Director Financiero (CFO)
- Director General (CEO)
- CAB técnico:
- Gerente de Entrega de Servicios
- Gerente de Operaciones
- Gerente de Seguridad de la Información
- Delegado de Protección de Datos
- CAB empresarial:
- Gerente de Administración de Empresas
- Gerente de Recursos Humanos
- Gerente de Relaciones Comerciales
Paso 4: Implementar el cambio de la manera correcta
Zylker utiliza tareas para controlar la implementación. Las tareas se asignan a diferentes técnicos, y las dependencias establecen el orden en que se deben realizar las tareas. El propietario del cambio puede controlar fácilmente el progreso de la implementación del cambio y gestionar las tareas en un solo lugar.
Así es como Zylker organizó la implementación por tareas para facilitar el seguimiento y la gestión de la implementación del cambio:
- Preparar Office 365 y Azure AD
- Configurar un servidor de ingesta de video
- Iniciar la migración de datos
- Configurar proxies de Azure AD
- Verificar la integridad de los datos
Paso 5: Seguir el plan
Luego, el propietario / gestor del cambio revisa la implementación del cambio para verificar si hay alguna desviación del plan. Cualquier desviación identificada se reporta y corrige antes de que el cambio se considere exitoso.
Paso 6: Cerrar el ticket de cambio
Finalmente, el cambio se cierra y se asigna un código de cierre basado en la naturaleza del cierre del cambio.
Paso 7: Reunir las métricas
El gestor de cambios mide ciertos KPI para determinar qué tan eficiente es el proceso de cambio e identificar las áreas que se pueden mejorar.
Lista de verificación de funciones para la gestión de cambios
Aquí hay una lista de las funciones que debe tener en cuenta al elegir una herramienta de mesa de servicio. Estas funciones lo ayudarán a implementar un proceso de gestión de cambios efectivo en su organización.
Gestión de cambios
Creación y registro del cambio
- Cree cambios a partir de incidentes y problemas, y transfiera la información necesaria.
- Recopile la información requerida con plantillas de cambio personalizadas.
- Cree diferentes tipos de cambios y cree flujos de trabajo únicos para cada tipo.
- Involucre a las partes interesadas adecuadas, como el propietario del cambio, el aprobador, el gerente de línea, el revisor del cambio, usando los roles de cambio.
Planificación y evaluación del cambio
- Cree planes de cambio elaborados con análisis de impacto y planes de rollout, backout y tiempo de inactividad.
- Mantenga una lista de verificación con los pasos que se deben realizar.
Aprobación del cambio
- Forme varios CAB.
- Configure varios niveles de aprobación. Marque si la RFC debe ser aprobada por todos los miembros del CAB o por cualquier miembro.
- Permita que el gestor de cambios tenga la última palabra en la aprobación del cambio.
- Omita las aprobaciones del Gestor de Cambios y del Aprobador de Cambios al aprobar automáticamente el cambio cuando todos los miembros del CAB lo recomienden.
- Marque si los usuarios finales pueden aprobar las solicitudes de servicio.
Coordinar la implementación del cambio
- Desglose los cambios en tareas y use registros de trabajo para estimar cuánto tiempo le tomará al equipo de implementación de cambios completar las actividades.
- Agilice la implementación creando proyectos a partir de un cambio o asociando un cambio a los proyectos existentes.
- Rastree todos los incidentes y problemas asociados que causaron o fueron causados por el cambio.
- Programe el tiempo de inactividad e informe a las partes interesadas clave.
- Mantenga a los interesados informados con notificaciones periódicas.
Revisión y cierre del cambio
- Documente la revisión post-implementación (PIR)
Flujos de trabajo del cambio
- Cree distintos flujos de trabajo para diferentes tipos de cambios y procesos con diferentes niveles de complejidad y funciones.
- Configure varias acciones como condiciones, conmutaciones, notificaciones, actualizaciones de campo y aprobaciones durante las transiciones entre etapas.
- Trace los flujos de trabajo del cambio en un espacio gráfico de arrastrar y soltar.
Marque todas las casillas para lograr una gestión de cambios eficiente
Glosario
Cambio:
La adición, modificación o eliminación de cualquier cosa que pueda afectar directa o indirectamente los servicios.
Comité asesor de cambios (CAB):
Un equipo conformado por varias partes interesadas que dan recomendaciones sobre los cambios y aprueban el plan de cambio.
Conflicto entre los cambios:
Cuando se planea implementar dos o más cambios simultáneamente sin saberlo, interrumpiendo la implementación de cualquiera de los cambios.
Gestión de cambios:
El proceso que consiste en completar los cambios con interrupciones y conflictos mínimos.
Roles de cambio:
La delegación de responsabilidad sobre los diversos aspectos del cambio a diferentes miembros de la organización.
Código de cierre:
Se utiliza para registrar la naturaleza del cierre del cambio, es decir, fallido o exitoso.
Base de datos de gestión de la configuración (CMDB):
Un repositorio que recopila todos los elementos de configuración y sus relaciones.
Mejora continua del servicio:
El proceso que consiste en identificar y corregir las áreas que se pueden mejorar para mejorar los servicios.
Tiempo de inactividad:
El período de tiempo durante el cual un servicio en particular no está disponible.
Incidente:
Una interrupción no planificada de un servicio de TI o una reducción en la calidad de un servicio de TI. La falla de un elemento de configuración, incluso si aún no ha afectado un servicio, también es un incidente (por ejemplo, la falla de un disco de un conjunto de replicación).
Problema:
Una causa o posible causa de uno o más incidentes.
Revisión post-implementación:
El proceso que consiste en evaluar si se siguió el plan de cambio sin desviaciones, así como en examinar la implementación para ver si es necesario cambiar algo.
Solicitud de cambio (RFC):
El proceso que consiste en iniciar un cambio con un motivo válido.
Evaluación de riesgos:
El proceso que consiste en evaluar los posibles riesgos que conlleva un cambio.
Mesa de servicio:
El punto de comunicación entre los proveedores de servicios y los usuarios de la organización.