Gestión de cambios de TI: ejemplos reales de cambios normales en ITIL

ITSM normal change examples

Usualmente, las organizaciones sufren grandes cambios con el fin de aplicar mejoras importantes sobre sus productos y servicios. Sin embargo, esto requiere mucha planeación. Esto se debe a que deben traer a las partes interesadas indicadas y asegurarse de que están preparadas para todo tipo de contingencia. Adicionalmente, los usuarios finales deben aceptar el cambio. Si no lo hacen, el cambio puede terminar perjudicando a la corporación en vez de ofrecer los beneficios previstos.

Por medio de un ejemplo real, verá cómo puede implementar un cambio exitoso.

Caso de estudio: cómo desplegar un cambio de forma efectiva y ayudar a su compañía a abrazar el cambio

Normal IT change examples

Una PYME decide mover su infraestructura on-premise a la nube para sacar provecho de la velocidad, estabilidad y seguridad.

Best example of a normal IT change

He aquí lo que tiene inicialmente.

ITSM normal change implementation process

Tiene su Active Directory, AD FS, múltiples aplicaciones, datos y un servidor de correo Exchange on-premise. ¿Qué es lo que se propone? Por un lado, hacer la transición a Microsoft Entra ID. Por otro lado, hacer uso de Office 365 con sus aplicaciones SaaS. Como podrá suponer, esto es todo un reto. Implica desplazar una gran cantidad de aplicaciones, usuarios y datos. Desafortunadamente, la mayoría de organizaciones adoptan el siguiente aproximamiento a la hora de implementar estos cambios:

Whose approval is required in normal change request

"Cerremos los ojos y esperemos lo mejor". Lo que las corporaciones hacen es ir a ciegas sin un plan para diferentes contingencias esperando que todo salga bien.

Si lo que quiere es una implementación exitosa, este enfoque no servirá. Solo hará que todo se desmorone.

ITSM normal change template

Empecemos por que manejar diferentes tipos de cambios con el enfoque de que hay una solución única para todo crea obstáculos inesperados. Estos incluyen cortes del servicio y falta de recursos. Como estos problemas no son previstos, la incapacidad de comunicarlos genera oposición entre los usuarios finales. La falta de mecanismos de aprobación solo contribuye a los retrasos en el ciclo de vida de los cambios.

ITSM normal change process flow diagram

De nuevo, la planeación es crucial en una implementación exitosa. Supongamos que no tiene un plan de rollback. Una falla en la implementación de cambios conlleva a perdida de datos y completo caos. De esta forma, los obstáculos mencionados generan una pobre visibilidad y una inhabilidad para rastrear implementaciones de cambios.

Realizó este cambio para mejorar sus servicios, pero ha creado una catástrofe.

La PYME abraza el cambio con ServiceDesk Plus

ITSM normal change best practices

Para fortuna de esta PYME, ha abrazado el cambio con ServiceDesk Plus. Eso le ha permitido rectificar el curso siguiendo las mejores prácticas del flujo de trabajo.

ITSM normal change process flow

La PYME comenzó definiendo los diferentes tipos de cambios que iban a manejar. De esta forma, creó diferentes tipos de cambios, estableció flujos de trabajo de cambios sobre ellos y definió dichos flujos de trabajo dividiéndolos en seis etapas.

Stages of normal IT change

Al estar segmentados en piezas más pequeñas, el proceso es mucho más sencillo. Esto se debe a que la empresa crea planes de despliegue de impacto detallado, comunica efectivamente los tiempos de inactividad a los usuarios finales y gestiona la implementación de forma muy cuidadosa. No menos importante, hace una revisión posterior a la implementación y realiza mejoras continuas al servicio analizando métricas de cambio. Lo anterior puede parecer bastante, pero no hay que temer.

Le explicaremos lo simple que es lograrlo con una solución de mesa de servicio.

Cómo crear una solicitud de cambio

A través de su portal, el técnico puede hacer clic en Cambio y crear un nuevo ticket de cambio. Esto funciona de forma similar a la gestión de solicitudes de servicios. Claro, hay diferencias. Por ejemplo, hay un minicalendario en la parte izquierda. Este muestra el número de cambios programados, lo que ayuda a evitar colisiones de cambios. También hay diferentes campos que corresponden a los tipos de cambios.

Ya hemos mencionado cómo esta PYME ha definido diferentes tipos de cambios. Estos pueden ser clasificados con etiquetas como documentado, emergencia, crítico, normal y estándar. Se han creado diversos flujos de trabajo para gestionar estos tipos de cambios. También está la opción de modificar la solicitud o el propietario.

Más abajo están los roles. El cambio de roles en ServiceDesk Plus ayuda a establecer permisos de acceso para las diferentes partes interesadas involucradas en su implementación de cambios. Por ejemplo, puede establecer que el implementador solo pueda modificar la solicitud durante la fase de implementación. Esto ayuda a establecer silos dentro de los cuales las partes interesadas pueden operar. Lo anterior asegura que ninguna actividad no autorizada se lleve a cabo en su ticket de cambio.

Una vez llenados todos los campos, puede crear una solicitud de cambio.

Flujos de trabajo

Al hacer clic en el flujo de trabajo de emergencia, podrá ver diferentes etapas de cambio subdivididas en seis etapas. Dependiendo de las acciones realizadas sobre el ticket de cambio dentro de dichas etapas, ciertas transiciones se llevarán a cabo.

He aquí un ejemplo. Si el ticket de cambio es aceptado en la etapa de entrega, avanzará a la de implementación. Lo anterior se debe a que se trata de un cambio de emergencia. En dicho proceso, será capaz de notificar cambios de rol específicos. Estos incluyen el cambio de aprobador y administrador de cambios. Dichos flujos de trabajo garantizan la creación de flujos para cada tipo de cambio.

En las mejores prácticas del flujo de trabajo, la PYME ha creado diferentes tipos de cambios, cambios de roles y flujos de trabajo de cambios. Han reunido todas estas piezas de LEGO con una plantilla de cambio. Lo único que resta es desglosar el proceso de cambio en seis etapas y ejecutar los planes de despliegue de impacto detallados.

Etapa de entrega

En esta primera etapa, el que solicita el cambio debe proveer una buena razón para el mismo. Incluso puede crear adjuntos para justificarla. Más abajo, podrá encontrar los detalles de cambio y los roles asociados con este ticket de cambio. Una vez la etapa de entrega ha sido completada, el responsable de aprobar el cambio mira la solicitud.

De ser aprobada, el ticket avanzará a la etapa de planeación.

Etapa de planeación

Un análisis de impacto detallado da inicio. Los planes de despliegue son definidos, al igual que los de recuperación. En esta etapa se muestra el impacto detallado sobre diferentes servicios críticos. El plan de despliegue detallado describe la implementación. En el caso de que ocurra un fallo, está el plan de recuperación.

La implementación de una lista de chequeo ayuda al equipo de cambios a hacer seguimiento de todos los elementos esenciales para el cambio. Toda esta planeación le brindará información sobre qué servicios dejarán de funcionar. También le ayudará a crear tiempos de inactividad apropiados. Incluso podrá comunicarlos a sus usuarios finales. Al hacer clic en Acciones en la parte de arriba, puede realizar un anuncio desde el ticket de cambio e incluso mandar notificaciones a partes interesadas específicas.

Etapa de aprobación

Cuando la planeación haya concluido, el ticket de cambio pasa por un proceso de aprobación. En esta etapa, el Consejo Asesor de Cambios (CAB) se reúne. Usted puede añadir diferentes CAB y diferentes miembros del mismo para asegurar de que reseñen el plan. Si el ticket de cambio es aprobado, procederá a la etapa de implementación.

Etapa de implementación

En la etapa de implementación hay proyectos, tareas y cargas de trabajo, y planeación de tiempos de inactividad. “¿Pero por qué hay proyectos?”, preguntará.

Si fuera un cambio pequeño, habría bastado con definir tareas y hacer un seguimiento de las cargas de trabajo. Ya que este es un gran desafío, que involucra diversas tareas y técnicos, es necesario crear proyectos para hacer un seguimiento eficiente del progreso de la implementación. Con ese fin en mente, se define un hito y unas tareas asociadas. Dada la gran cantidad de tareas, no se pueden gestionar efectivamente desde un mismo ticket. Para eso se utiliza la integración con el módulo de gestión de proyectos.

El diagrama de Gantt en ServiceDesk Plus le ayuda a rastrear eficientemente la implementación de las tareas y los hitos. Esto le concede una vista de águila sobre lo que está ocurriendo con su implementación de cambios. Lo anterior facilita el proceso y garantiza que se complete de forma exitosa y sin interrupciones.

Etapa de revisión

Stages of normal IT change

Un plan detallado ha sido creado. Los tiempos de inactividad son públicos para los usuarios finales. Más importante, el cambio ha sido implementado a través de un proyecto. Solo resta realizar una revisión posterior a la implementación para garantizar que el cambio se realizó de forma exitosa. Aquí comienza la etapa de revisión.

En esta, los técnicos añaden comandos según lo que determine la revisión. No menos importante, se encargan de cualquier corrección que deba llevarse a cabo. Cuando el cambio haya sido implementado, el ticket se cierra definitivamente (etapa de cierre).

Todos los riesgos han sido prevenidos empleado la capacidad adecuada. Así de fácil es mejorar sus servicios utilizando una herramienta de ITSM adecuada. Solo resta analizar el resultado de los cambios realizados para garantizar una mejora continua del servicio.

¿Es el proceso de cambios efectivo?

Normal change metrics

Estas son las métricas esenciales que creemos que debe medir: número de incidentes provocados por el cambio, porcentaje de caídas del servicio no planeadas y porcentaje de cambios criticados. Estas métricas le ayudarán a proveer una imagen clara de qué tan efectiva ha sido la estrategia de gestión de cambios.

Resources for further reading

Recursos