Cuando se planifica un nuevo servicio, los equipos de IT tienen que coordinar procesos, herramientas y personas para evitar que su implementación afecte aquello que ya funciona. La transición del servicio ITIL guía el procedimiento para comprobar que un servicio nuevo o actualizado esté listo para ponerse en producción sin interrumpir las operaciones existentes.
Cuando se gestiona correctamente, la transición permite que un servicio pase de la planificación a estar disponible y preparado para su uso y soporte. En cambio, una mal gestionada, puede provocar interrupciones, sobrecarga en los equipos y retrasos en los despliegues.
En este artículo, profundizamos sobre la transición del servicio en ITIL, cuáles son los ocho procesos que lo componen, quién es responsable de cada fase y por qué muchas fallan.
¿Qué es la transición del servicio en ITIL?
La transición del servicio ITIL consiste en tomar esos servicios definidos durante las etapas de estrategia y diseño, dentro del ciclo de vida del servicio ITIL, llevarlos a la operación, modificar o trasladar los que están funcionando, y retirar aquellos que ya no son necesarios: todo este proceso busca minimizar las interrupciones para el negocio. La Gestión de Cambios, Release Management (liberación), Gestión de la Configuración y Gestión del Conocimiento son las disciplinas centrales que hacen posible este procedimiento.
Los principios fundamentales de la etapa de transición del servicio ITIL son:
- Definir una política de transición clara para que todas las actividades estén establecidas y sigan los estándares y las prácticas de gobernanza de la organización.
- Asegurar que los servicios se implementen con los requisitos adecuados de utilidad y garantía.
- Seguir un enfoque estandarizado, con la ayuda de modelos y plantillas, para que todas las actividades se realicen de manera consistente.
- Mejorar y optimizar los procesos y sistemas.
- Planificar el release (conjunto de cambios, funcionalidades o componentes que se agrupan, prueban y preparan para su puesta en operaciones en un entorno determinado, generalmente producción).
- Supervisar el servicio y tomar medidas proactivas para mejorarlo durante el ciclo de lanzamiento.
- Captar el conocimiento de forma precisa, garantizando que sea de fácil acceso y uso.
La transición del servicio en ITIL 4 (y qué cambia en ITIL 5)
A medida que evolucionó, ITIL planteó la transición del servicio de distintas maneras: como parte de una actividad combinada “diseño y transición” en ITIL 4 y nuevamente como una fase independiente en ITIL 5.
Publicado en 2019, ITIL 4 organiza la gestión de servicios en torno al Sistema de Valor del Servicio (SVS - Service Value System), en cuyo centro se encuentra la cadena de valor, un modelo operativo compuesto por seis actividades: planificar, mejorar, involucrar, diseñar y transicionar, obtener/construir y entregar y soportar.
La actividad de diseñar y transicionar consiste en desarrollar, probar y llevar los servicios nuevos o modificados al entorno productivo para que cumplan con los requisitos acordados y estén preparados para su operación y soporte.
En ITIL 5 la transición pasa a ser una actividad independiente dentro del Modelo de Ciclo de Vida de Productos y Servicios, que lleva un producto o servicio nuevo o modificado desde la etapa de construcción hasta la operación. Es el último punto de control antes de la puesta en producción: el momento en que el equipo confirma que el servicio está preparado, lo implementa de forma segura y lo entrega a las personas que estarán a cargo de operarlo y brindarle soporte.
Como el ciclo de vida del servicio ITIL es iterativo, se ejecuta cada vez que se lanza algo nuevo, lo cual permite que conviva con la entrega continua sin convertirse en un obstáculo.
Los 8 procesos de la transición del servicio
La transición del servicio ITIL requiere coordinar distintas actividades para llevar un servicio nuevo o modificado a producción de forma controlada. En ITIL, estas actividades se organizan en procesos que detallamos a continuación.
1. Habilitación del Cambio
La Habilitación o Gestión del Cambio (depende la versión de ITIL) es el proceso que controla las actividades relacionadas con los cambios, con el objetivo de que se realicen con el menor impacto e interrupciones posibles en los servicios de IT.
Entre los KPIs asociados se encuentran las cantidades de cambios exitosos, los que provocaron incidentes y los cambios de emergencia.
2. Evaluación del cambio
La Evaluación del Cambio se utiliza para examinar los ajustes significativos, aquellos de mayor impacto que suelen realizarse una o dos veces por trimestre. Algunos ejemplos son la incorporación de un servicio clave para el negocio o una modificación importante de un servicio crítico existente.
Los KPIs relacionados son: cantidad de cambios evaluados y aquellos que avanzaron a la siguiente etapa.
3. Gestión de Proyectos (planificación y soporte de la transición)
La Gestión de Proyectos tiene como objetivo coordinar y planificar los recursos necesarios para implementar un release importante dentro de los plazos, costos y niveles de calidad acordados.
Aquí los KPIs incluyen el número de releases que requiere este nivel de coordinación y sus resultados.
4. Desarrollo de aplicaciones
El desarrollo de aplicaciones se orienta a la creación de aplicaciones y sistemas que proporcionen las funcionalidades indispensables para los servicios de IT. Esto contempla el mantenimiento y desarrollo de apps personalizadas, así como la adaptación de los productos de los proveedores de software.
Entre los KPIs se encuentra la cantidad de aplicaciones gestionadas mediante este proceso.
5. Gestión de Releases y despliegue
El Release Management y la Gestión de Despliegue abarcan la planificación, programación y control de los releases que se implementan en los entornos de prueba y producción.
El objetivo del proceso es garantizar la protección del entorno productivo y la puesta en marcha de los componentes correctos, preferentemente desde una biblioteca definitiva de medios (DML - definitely media library), de acuerdo con la política de releases.
Los KPIs son el número de releases, las implementaciones exitosas y las que utilizaron la DML.
6. Validación y pruebas
El objetivo de este proceso es asegurar que los releases implementados y los servicios asociados cumplan con las expectativas de los clientes, a la vez de verificar que las operaciones de IT puedan brindar soporte al nuevo servicio.
Para ello, las actividades de prueba se realizan mediante un modelo en V, que contempla validaciones previas al lanzamiento y posteriores a la implementación. De esta manera, se comprueba el cumplimiento de todos los resultados acordados y el funcionamiento adecuado, tanto desde el punto de vista técnico como desde la experiencia del cliente.
7. Gestión de Activos y Configuración
El proceso permite mantener información sobre los Elementos de Configuración (CIs - Configuration Items) necesarios para prestar un servicio de IT, incluidas sus relaciones y dependencias. Esto se almacena en una Base de Datos de Gestión de la Configuración (CMDB - Configuration Management Database) o en un Sistema de Gestión de la Configuración (CMS - Configuration Management System).
Entre los KPIs asociados con el proceso de Gestión de la Configuración se encuentran la cantidad de CIs bajo el control de la Gestión de la Configuración y el número de CIs cuya información es precisa.
8. Gestión del Conocimiento
La Gestión del Conocimiento es la práctica o proceso de recopilar, analizar, compartir y almacenar información dentro de una organización. Su objetivo es mejorar la eficiencia al evitar volver a descubrir conocimientos ya existentes.
Este proceso es responsable de administrar y actualizar el Sistema de Gestión del Conocimiento del Servicio (SKMS - Service Knowledge Management System).
En cuanto a los KPIs de esta instancia, figura el número de artículos de conocimiento revisados y verificados para comprobar su exactitud.
Ejemplo de un plan de transición del servicio
Si bien la implementación de las actividades de transición del servicio ITIL varía en cada organización, aquí presentamos un ejemplo con algunas tareas habituales que pueden resultar útiles en diferentes contextos.
Supongamos que una empresa está desarrollando un nuevo sistema de RR.HH. para gestionar las solicitudes de vacaciones anuales. Algunas actividades de transición útiles serán:
- Crear artículos de conocimiento tanto para los equipos técnicos como para los usuarios finales para utilizar y brindar soporte al nuevo sistema.
- Validar y realizar pruebas para garantizar que el servicio haya sido probado de forma exhaustiva.
- Aplicar las prácticas de Gestión de Cambios para procurar una implementación evaluada y programada adecuadamente.
- Ejecutar el Release Management para asegurar que la ejecución en el entorno productivo se realice sin inconvenientes.
- Garantizar la Gestión de Activos y Configuración del Servicio para registrar los componentes que conforman la nueva prestación e identificar cualquier dependencia, facilitando así el soporte continuo.
¿Quién es responsable de cada fase?
ITIL 4 describe la asignación de responsabilidades a través de prácticas, en lugar de establecer un organigrama fijo. Esta tabla relaciona cada una de las fases de la transición del servicio con roles y responsabilidades.
| Fase | Rol | Responsabilidad |
| Planificación y coordinación | Gerente de Transición o de Proyecto | Definir el orden de las tareas, asignar recursos y mantener el cronograma coordinado entre los distintos equipos |
| Autorización de los cambios | Gerente de Cambios y Autoridad de Cambios | Evaluar los riesgos, autorizar los cambios y programarlos en el calendario |
| Definición del release | Release Manager | Definir y gestionar los paquetes de release, y determinar qué componentes se implementarán juntos |
| Implementación | Responsable de Implementación o de Construcción | Trasladar los componentes a los entornos de prueba, staging y producción |
| Validación | Gerente de Pruebas | Definir la estrategia de pruebas, los criterios de aceptación y las verificaciones previas y posteriores a la implementación |
| Control de la configuración | Gerente de Configuración | Mantener actualizados los registros de los elementos de configuración (CIs), sus relaciones y la información de configuración |
| Transferencia de conocimiento | Gerente de Conocimiento | Crear y mantener la documentación necesaria para que los equipos técnicos y usuarios puedan utilizar y dar soporte al servicio |
La autorización de los cambios suele compartirse con una autoridad de cambios. En ITIL v3, esta función correspondía al Comité Asesor de Cambios (CAB - Change Advisory Board), que evalúa y aprueba aquellos que requieren ese nivel de revisión; y al Comité Asesor de Cambios de Emergencia (Emergency Change Advisory Board - ECAB), que se convoca con poca antelación para gestionar los que son urgentes, durante la resolución de incidentes e incidentes mayores, siguiendo un proceso abreviado.
En los equipos pequeños, una misma persona suele desempeñar varios de estos roles. Aun así, la responsabilidad debe estar asignada, incluso cuando recae en un único individuo.
¿Dónde fallan las transiciones y cómo evitarlo?
La mayoría de las transiciones fallidas se deben a un pequeño número de problemas recurrentes. Sin embargo, una atención adecuada desde las primeras etapas del trabajo puede ayudar a prevenirlos.
Aquí las fallas típicas de la transición del servicio ITIL:
- Datos incorrectos de la configuración. Cuando la CMDB está desactualizada, la evaluación del impacto se realiza sobre información que no se encuentra vigente. En consecuencia, los cambios que parecen de bajo riesgo pueden dejar fuera de servicio a sistemas que dependen de una relación sin documentar. La precisión de los datos de la configuración constituye la base sobre la que se sustenta el resto de la transición.
- Omisión de la transferencia de conocimientos. Un servicio se implementa sin un solo error y, aun así, sobrecarga la mesa de ayuda si los equipos de soporte no recibieron la documentación ni la capacitación correspondientes. Así, aumentan los escalamientos, se extienden los tiempos de resolución y disminuye el valor del nuevo servicio.
- Diferencias entre los entornos de prueba y de producción. Las validaciones pueden ser exitosas en un entorno de prueba que no refleja las condiciones reales, por lo cual los errores aparecen después de la implementación. La equivalencia entre los entornos permite que un resultado satisfactorio en las pruebas sea realmente significativo.
- Tratar el release y la implementación como un único paso. Combinar la decisión de realizar un release con la ejecución de la implementación elimina el punto de control donde es posible detenerse o realizar el proceso de forma gradual. Ambas instancias separadas permiten que la autorización sea independiente de la ejecución.
- No contar con planes de reversión. Una implementación sin un procedimiento de reversión probado deja al equipo sin una forma segura de recuperar el servicio ante una falla. El plan de reversión debe estar documentado y verificado antes de ejecutar el cambio, y no improvisarse durante un incidente.
- No brindar soporte en las primeras etapas de operación. El éxito técnico de una puesta en producción no significa que el servicio sea estable. Sin un período definido de soporte reforzado inmediatamente después de la implementación, los problemas pequeños pueden acumularse si las responsabilidades todavía no están claras.
InvGate Service Management facilita la gestión e implementación de los cambios a través de los flujos de trabajo sin código y capacidades de automatización. Además, permite evaluar el impacto, el riesgo y la urgencia; priorizar y aprobar los cambios, y coordinar el proceso de punta a punta.
Si quieres saber más, puedes agendar una llamada con un miembro de nuestro equipo.