La Planificación y Soporte de la Transición es la encargada de coordinar los recursos de la organización TI para poner en marcha el servicio en el tiempo, calidad y coste definidos previamente.
Esto incluye la definición de los entregables (contenido, plazos, niveles de calidad), así como los flujos de trabajo y los actores involucrados en la prestación del servicio, los protocolos de control de la calidad, test de pruebas, mecanismos de monitorización, reportes, etc…
Interrelaciones del proceso: La Planificación y Soporte a la Transición: Al ser responsable de planificar y coordinar la fase de transición al completo, es un proceso transversal que ofrece entrada a todos los procesos de este ciclo. Ayuda a que todos los procesos optimicen su tiempo y esfuerzo. También mejora su adecuación a la estrategia de la organización TI y los requisitos del cliente.
Todo el proceso debe ser Monitorizado para asegurar que: La documentación (especialmente de la CMDB) está actualizada, se cumplen los requisitos internos y externos en costo, calidad y alcance y, se cumplen los plazos y se consumen los recursos previstos inicialmente.
Estrategia: En primer lugar se definen cuestiones claves que regirán todo el proceso de cambio: Políticas generales y metodologías, actores implicados (instituciones, proveedores etc…), requisitos internos y externos a tener en cuenta y tipos de entregas.
Preparación: Antes de planificar, se revisan todos los elementos implicados en el proceso de cambio: Documentación del Paquete de Diseño del Servicio SDP, RFCs a implementar, requisitos del cliente etc…Elementos de configuración CIs y criterios de evaluación y reporte.
Planificación: La actividad principal del proceso, que consiste en: Estructurar el cambio en etapas, tareas y actividades, asignar los recursos específicos para cada tarea, definir los criterios de aceptación aplicables para cada etapa y establecer plazos de entrega y prever futuras incidencias.
Una correcta Planificación de la Transición trae consigo importantes ventajas que aportan valor al negocio:
- Incrementa la capacidad de la organización para manejar de forma simultánea un gran volumen de cambios y versiones.
- El servicio prestado está mejor alineado con los requisitos del cliente y los proveedores, e incluso con la propia estrategia interna de la organización.
- Al existir un cronograma general del que todos los procesos tienen conocimiento, se minimizan los tiempos muertos y por tanto los retrasos.
Entre las dificultades que pueden obstaculizar la Planificación de la Transición encontramos:
- La relación entre los recursos disponibles para prestar el servicio y la calidad exigida en los requisitos está desequilibrada, ocasionando el incumplimiento de plazos o de acuerdos con el cliente.
- La información sobre los elementos de configuración relacionados con el cambio no está actualizada.
- La valoración de la RFC en cuanto a su impacto y los recursos que precisará es incompleta o errónea.
- Los elementos de configuración que intervienen en el cambio no están preparados llegado el momento, ocasionando retrasos en la planificación.
- Se monitoriza cada uno de los pasos de la transición, pero a menos que el cliente lo reclame no se hace una reflexión final sobre el rendimiento, la adecuación a los requisitos planteados inicialmente.
La Revisión Post-Implantación o PIR es una fase de soporte posterior a la implementación de los cambios en la que la Planificación y Soporte a la Transición asesora a todas las partes implicadas. Estas labores de soporte consisten principalmente en informar sobre los resultados de los cambios. En otras palabras, es también una lista de chequeo que realiza el ejecutor del cambio posterior a este, esta lista puede estar en el documento de solicitud de cambio RFC y permite llevar un control sobre el mismo.
Gestión de Cambios: Aporta a la planificación y soporte toda la información acerca de la RFC que se va a implementar. A cambio, recibe de ésta premisas estratégicas para orientar su labor, como por ejemplo los criterios de evaluación de cambios.
Gestión de la Configuración y Activos TI: Como responsable de los elementos de configuración de la infraestructura TI, debe garantizar que la CMDB está actualizada para que la planificación pueda elaborar el plan de transicion.
Gestión de Entregas y Despliegues: Es el destinatario principal del Plan de Transición, ya que a fin de cuentas es quien ejecuta los cambios. Las versiones generadas por la gestion de entregas y despliegues deben ceñirse a los criterios de calidad, los plazos y los recursos estipulados por la planificación.
Validación y Pruebas: La planificación y soporte proporciona tanto la estrategia general como los criterios que determinan el éxito / fracaso durante la validación y pruebas de las versiones.
Gestión del Conocimiento: Ofrece a la planificación una serie de criterios para registrar la documentación generada. Al mismo tiempo, ésta ayuda a optimizar tiempo y recursos al establecer el momento idóneo para que la Gestión de Conocimiento haga sus revisiones periódicas de la información registrada por los otros procesos.
El propietario de este proceso es el Jefe de Proyecto. En él recae la responsabilidad de controlar y medir los siguientes indicadores:
- Número de proyectos gestionados. Es decir, el número de versiones desplegadas que han sido objeto de planificación y soporte.
- Porcentaje de entregas (respecto al total de entregables) que se ajustaron a lo acordado con el cliente en cuanto a coste, calidad y alcance.
- Ajuste al presupuesto del proyecto, comparando el consumo de recursos humanos y financieros previstos con los que se usaron realmente.
- Retrasos en proyectos, comparando las fechas de entrega reales con las que en un principio se habían definido en la planificación.
Es frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: “si algo funciona, no lo toques”. Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas, y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias, puede resultar mucho más peligroso el estancamiento en servicios y tecnologías desactualizadas.
Las principales razones para la realización de cambios en la infraestructura TI son:
- Solución de errores conocidos.
- Desarrollo de nuevos servicios.
- Mejora de los servicios existentes.
- Imperativo legal.
El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI.
Interrelaciones del proceso: Debe existir una estrecha relación entre la Gestión de Cambios y otros procesos:
En la Gestión de Cambios, todo el proceso debe ser monitorizado: Asegurando que la CMDB se encuentra actualizada, emitiendo informes de rendimiento y elaborando métricas que permitan evaluar los cambios.
RFC: Cualquier cambio no estándar (normales y emergencia) requiere una “Petición de Cambio”. Los objetivos de una petición de cambio comprende: Corrección de errores, innovación y mejora de los servicios y, cumplimiento de nuevas normativas legales.
Registro: La RFC debe ser correctamente registrada para poder realizar el seguimiento de todo el proceso de cambio. El registro debe incluir: Identificador único de la RFC, descripción detallada del cambio propuesto y sus objetivos, un campo de estatus (aceptado, aprobado etc…)
Aceptado: El cambio debe ser aceptado en primera instancia por el Gestor de Cambios para su posterior tramitación.
Aceptado: Se pasa a determinar su impacto y categoría
Denegado: Se devuelve la RFC al solicitante para que presente modificaciones nuevas en la RFC propuestas en la retroalimentación.
Clasificación: Para el correcto procesamiento del cambio es necesario determinar su:
Prioridad: Importancia relativa de esta RFC. Determinará el calendario del cambio.
Categoría: Impacto y dificultad del cambio. Determinará la asignación de recursos y plazos previstos.
Urgencia: En ocasiones que el “cambio no puede esperar” debido a interrupciones de servicio críticos se deben aplicar protocolos de emergencia: Aprobación directa del cambio por el Gestor del Cambio o el Comité de Emergencia.
Aprobación y Planificación: El CAB debe decidir la aprobación definitiva del cambio. Si esta se produce es indispensable una correcta planificación: Elaboración de calendarios realistas de cambio, cumplimiento de los objetivos previstos y minimización de incidencias secundarias derivadas del cambio.
Roll-Out: Aunque la Gestión de Cambios no es la responsable directa de la implementación debe coordinar todo el proceso: Entorno de desarrollo, entorno de pruebas e implementación.
Back-Out: Los planes de Back-Out son imprescindibles para evitar interrupciones graves del servicio. Sus objetivos principales son: Volver en el menor tiempo posible a la última configuración estable anterior al cambio e impedir que se pierdan datos e información valiosa durante los procesos de implementación del cambio.
Cierre: Tras la implementación se debe evaluar el cambio: ¿Se cumplieron los objetivos previstos? ¿Cuál es la percepción de clientes y usuarios?
Si la valoración es positiva se termina de documentar y cerrar el cambio, en caso contrario se llevan a cabo los planes de back-out.
La Gestión de Cambios debe trabajar para asegurar que los cambios:
- Están justificados.
- Se llevan a cabo sin perjuicio de la calidad del servicio TI.
- Están convenientemente registrados, clasificados y documentados.
- Han sido cuidadosamente testeados en un entorno de prueba.
- Se ven reflejados en la CMDB.
- Pueden deshacerse mediante planes de “retirada del cambio” (back-outs) en caso de un incorrecto funcionamiento tras su implementación.