Gestión de Cambios 7.1 Introducción
7.3.9 Actividades de la Gestión de Cambios
La Gestión de Cambios utiliza las siguientes actividades para procesar los cambios:
- Registro - no incluida en las actividades de la Gestión de Cambios, pero con ayuda en este proceso,
porque la Gestión de Cambios es la responsable de garantizar que todos los cambios sean correctamente registrados.
- Aceptación - filtrar las RFCs y aceptarlas para mayor consideración.
- Clasificación - clasificar las RFCs por categoría y prioridad.
- Planificación - consolidar los cambios, planear su implementación y los recursos necesarios.
- Coordinación - coordinar la construcción, evaluación e implementación del cambio.
- Evaluación - determinar si cada cambio fue exitoso y sacar conclusiones para el próximo evento
(aprendizaje).
Gestión de Cambios
7.4 Actividades
7.4.1 Registro
Primero, se deben registrar o anotar todas las RFCs. Cuando se eleva una RFC para solucionar un problema, también se debe registrar el número de error conocido.
¿Qué constituye una RFC?
No todas las peticiones de modificación son tratadas como un cambio: algunas tareas administrativas rutinarias que se encuentran bien definidas y están cubiertas por procedimientos (estandarizados) pero que no precisan de modificaciones pueden ser tratadas como Peticiones de Servicio (p. ej. cambios "categoría 0", ver 7.1.1).
Esto da como resultado la siguiente clasificación de cambios:
- Cambios Estándar (en calidad de Peticiones de Servicio) - cambios bien definidos y aprobados, que
están registrados de manera individual, pero no fueron evaluados por la Gestión de Cambios. Estos cambios se realizan como rutina (Nota: no todos las Peticiones de Servicio son cambios).
- Cambios no Estándar - todos los otros pedidos de modificación de la infraestructura administrada. ¿Dónde se originan las RFCs?
Las RFCs conciernen a todos los aspectos de la infraestructura dentro del alcance de los procesos ITIL. Cualquier persona que trabaje dentro de la infraestructura puede elevar una RFC.
Se pueden identificar varias fuentes de RFCs, tales como:
- Gestión de Problemas - propone soluciones para eliminar errores a largo plazo para estabilizar la
provisión de los servicios.
- Clientes - pueden pedir más, menos u otros servicios. Estas peticiones pueden elevarse directamente
como RFCs, o se los puede canalizar a través de la Gestión de Niveles de Servicio o de la Gestión de Relaciones con el Cliente TI.
- Política - los procesos tácticos y estratégicos del Set de Aprovisionamiento de Servicios y del de
Gestores puede llevar a RFCs a cambiar los servicios. Por ejemplo, la Gestión de Niveles de Servicio, la Gestión de la Disponibilidad y la Gestión de la Capacidad producen planes anuales para mejorar los servicios, que después se elevarán en forma de RFCs.
- Legislación - si se imponen nuevos cambios regulatorios a las actividades del negocio, o si se introducen
nuevos requisitos por seguridad TI, Continuidad Del negocio o Gestión de Licencias. El proceso correspondiente controla esto.
- Abastecedores - los abastecedores ponen a la venta nuevas versiones y actualizaciones de sus productos
e identifican los errores que corrigieron. También pueden comunicar que ya no ofrecen soporte a ciertas versiones, o que no hay garantías sobre el desempeño de una versión (p. ej. por los problemas del Milenio). Por esta razón la Gestión de Problemas y la Gestión de la Disponibilidad pueden elaborar una RFC.
- Proyectos - un proyecto siempre provocará un número de cambios. La Gestión de Proyectos deberá
coordinar esto con la Gestión de Cambios a través de los procesos pertinentes, tales como Gestión de Niveles de Servicio, Gestión de la Capacidad, etc.
- El resto del personal TI - en principio todos pueden elevar propuestas para mejorar los servicios.
Específicamente, el personal TI puede contribuir al perfeccionamiento de los procedimientos y los manuales.
Registro de RFC
Aquí hay algunos ejemplos de la información que se puede incluir en una RFC: - Número de identificación de la RFC.
- Número de problema/error conocido asociado (si corresponde). - Descripción e identificación de los CIs correspondientes.
- Motivo del cambio incluyendo la justificación y el beneficio para el negocio. - Versión actual y nueva del CI a cambiar.
- Nombre, ubicación y número de teléfono de la persona que realiza la RFC, - Día de emisión.
- Recursos y tiempo estimados.
7.4.2 Aceptación
Después de registrar la RFC, la Gestión de Cambios hará una evaluación inicial para corroborar si alguna de las RFCs son poco claras, ilógicas, poco prácticas o innecesarias. Las que así resulten serán rechazadas, mencionando las razones. La persona que elevó el pedido siempre debe tener notificación de las decisiones tomadas y contar con la oportunidad de defender su petición.
Un cambio provoca la modificación de los datos de la CMDB, por ejemplo: - Un cambio en el estado de un CI existente.
- Un cambio en las relaciones entre un CI con otros CIs. - Un nuevo CI, o la variación de un CI existente. - Un nuevo propietario o ubicación del CI.
- Sí la RFC fuera aceptada, se incluye en un registro del cambio la información necesaria para el resto del procesamiento. Después se agregará la siguiente información al registro:
- Prioridad signada.
- Evaluación del impacto de la implementación y de la no implementación del Cambio y de los costes necesarios.
- Categoría.
- Recomendaciones del Gestor de Cambios. - Fecha y hora de la autorización.
- Fecha estimada para la implementación del cambio. - Planes de soporte.
- Planes de "marcha atrás". - Requisitos de soporte. - Plan de implementación.
- Información sobre el constructor y los que la ejecutan. - Fecha y hora real del cambio.
- Fecha de evaluación.
- Resultados de la evaluación y problemas observados. - Razones por las que se rechazó el pedido (si corresponde). - Información sobre el escenario y la evaluación.
7.4.3 Clasificación
Una vez que se acepta una RFC, se especifica su prioridad y su orden:
- La prioridad indica qué importancia tiene un cambio frente a las otras RFCs, y deriva de la urgencia y el impacto del cambio. Si un cambio se produce para corregir un error conocido, la Gestión de Problemas puede ya haber asignado un código de prioridad. Sin embargo, la Gestión de Cambios asigna el código de prioridad final después de considerar las otras RFCs en proceso.
- La Gestión de Cambios determina la categoría basándose en los impactos y recursos. Esta clasificación determina si se dará más consideración al pedido, e indica el significado del cambio.
Gestión de Cambios
Determinación de la prioridad
Aquí hay un ejemplo del sistema de prioridad de códigos:
- Baja prioridad - se necesita un cambio, pero puede esperar hasta un mejor momento (p. ej. El próximo
lanzamiento, o mantenimiento programado).
- Prioridad normal - no representa gran urgencia o no implica un impacto importante, pero no se debe
diferir el cambio. En la reunión de CAB se le da prioridad normal cuando se asignan los recursos. - Prioridad alta - un error grave que afecta a muchos usuarios, o un error poco conveniente que afecta a
un gran número de usuarios, o relacionados con otros temas urgentes. En la próxima reunión de CAB se le da la mayor prioridad a este cambio.
- Prioridad máxima - la RFC se produce por un problema que afecta seriamente el uso de servicios
esenciales de los usuarios, o que necesita de un cambio TI urgente (p. ej. nuevas funciones por razones del negocio, una legislación de emergencia o un arreglo rápido que no puede esperar). Los cambios con esta prioridad se clasifican como "cambios de emergencia". Los cambios de emergencia no siguen los procedimientos normales, ya que los recursos deben estar disponibles de inmediato. Se puede necesitar de una reunión de emergencia de CAB o del Comité de Conducción TI. Con tal fin en especial, se debe constituir un CAB/EC (Comité de Emergencia), con autoridad suficiente para tomar decisiones de emergencia. Todos los planes hechos con anterioridad pueden demorarse o interrumpirse.
Los códigos pueden asociarse con números, p. ej. bajo-l/máximo-4.
Determinación de la categoría
La Gestión de Cambios determina las categorías, si es necesario junto con el CAB, que indica el impacto del cambio y la demanda que tiene para la organización TI.
Algunos ejemplos de categorías:
- Impacto menor - un cambio que no necesita mucho trabajo. El Gestor de Cambios puede aprobar estos
cambios sin presentarlos ante la CAB.
- Impacto sustancial - un cambio que precisa bastante esfuerzo y que tendrá un impacto sustancial en los
servicios. Estos cambios se discuten en la reunión de CAB para determinar el esfuerzo necesario y el impacto potencial. Antes de la reunión, se hace circular la información entre los miembros de la CAB y posiblemente entre los especialistas y los encargados de desarrollo.
- Impacto mayor - un cambio para el que se necesitará mucho esfuerzo. El Gestor de Cambios necesita
autorización previa de la gestión TI o del Comité de Conducción TI, tras el que se envía el cambio a CAB.
Se puede asignar número a los códigos, p. ej. menor=l/mayor=3.
Muchos cambios caen dentro de las dos primeras categorías. Además también se deben especificar la clasificación, los grupos que trabajan en la solución, y los servicios afectados por el cambio.
7.4.4 Planes
La Gestión de Cambios planifica los cambios utilizando un calendario de cambio, o un Programa de Cambios a Futuro (FSC). El FSC contiene detalles de todos los cambios aprobados y su planificación.
Los miembros de CAB aconsejan sobre los cambios planificados, como la disponibilidad de personal, recursos, costes, aspectos de afectación del servicio, y el cliente; todo debe ser considerado. CAB actúa como un comité consejero.
La Gestión de Cambios tiene autoridad delegada ya que se pronuncia en representación de la Dirección de TI. Los cambios más importantes pueden necesitar de la aprobación de la Dirección de TI, antes de presentarlos ante CAB.
La aprobación del cambio puede constar de tres aspectos:
- Aprobación financiera - análisis coste/beneficio y presupuesto
- Aprobación técnica - impacto, necesidad y viabilidad
- Aprobación del negocio - aprobación de los usuarios de las funciones necesarias y el impacto
Para conseguir una planificación eficaz, la Gestión de Cambios debe estar en contacto con las oficinas de proyecto y con todas las otras oficinas de la organización que construyen e implementan los cambios. Es más, se debe prestar especial consideración a las comunicaciones eficaz de la planificación de cambios a nivel horizontal (interdepartamental), en lo posible a través de Programa de Cambios a Futuro (FSC).
Política de Cambios
Las RFCs pueden combinarse en un único lanzamiento. En ese caso, un solo back-out será suficiente por si algo sale mal. Esta clase de lanzamiento debe considerarse como un único cambio, aún sí incluye muchos cambios. Los lanzamientos pueden planearse con un objetivo funcional para el negocio. Pueden incluir hardware y software, y son implementados por la Gestión de Versiones.
Es aconsejable definir la política de esta sección y comunicarla a la organización TI y a los clientes (ver también Gestión de Versiones).
La política debe tener como objetivo evitar la ruptura innecesaria con el usuario. Al consultar a los departamentos TI afectados, el CAB puede especificar ventanas de tiempo regulares para implementar los cambios en un horario que minimice el impacto en el servicio.
Los horarios más aconsejables son los fines de semana o fuera del horario de oficina, pero siempre dependerá de los servicios afectados y de los niveles de servicio pactados para ellos.
De igual manera se pueden establecer horarios en los que no se permitan cambios o en los que se produzcan pocos, como durante las horas de oficina o a fines del año financiero cuando todos los usuarios de los departamentos están haciendo los deberes periódicos.
Reuniones del CAB
Se debe distribuir la información sobre la planificación de un cambio antes de la reunión CAB.
Antes de la reunión también se deben hacer circular los documentos y la información correspondiente sobre los puntos a tratar.
El CAB debe tener cierta cantidad de puntos fijos en la agenda de sus encuentros, incluyendo: - Cambios sin autorización.
- Cambios autorizados que no han sido remitidos a CAB. - RFCs que deben ser evaluadas por los miembros de CAB. - Cambios abiertos y cerrados.
- Evaluaciones de cambios pasados.
Análisis de impacto y los recursos
Cuando se estiman los recursos necesarios y el impacto del cambio, los miembros de CAB, el Gestor de Cambios y demás personas involucradas (identificados por CAB) deben tener en cuenta los siguientes aspectos:
- Capacidad y rendimiento de el/los servicio(s) afectados. - Fiabilidad y recuperación.
- Planes de la Gestión de Continuidad de Servicios T I . - Planes de back-out.
- Seguridad.
Gestión de Cambios
- Registro y aprobación.
- Recursos necesarios y costes (soporte y mantenimiento). - Cantidad y disponibilidad de los especialistas necesario. - Ciclo de tiempo necesario para el cambio.
- Nuevos recursos a comprar y evaluar. - Impacto sobre las operaciones.
- Cualquier conflicto con los otros cambios. - Impacto de la no implementación del cambio.
- Los miembros de CAB también pueden aconsejar sobre la prioridad.
7.4.5 Coordinación
Los cambios aprobados se comunican a los especialistas de producto que corresponde, quienes pueden luego construir e integrar los cambios. Se evalúan los cambios antes de ser implementados.
La Gestión de Versiones puede cumplir un rol importante en la construcción, evaluación, implementación y despliegue de los cambios aprobados. Se debe prestar especial atención a las comunicaciones de los cambios a los grupos de soporte.
Construcción
No todos los cambios tienen una fase de construcción específica. Por ejemplo, los cambios estándar como la reubicación de un PC pueden planificarse e implementarse de inmediato.
La construcción puede incluir la creación de una nueva versión de software, con nueva documentación, manuales, procedimientos de instalación, un plan de back-out, y cambios de hardware. La Gestión de Cambios controla y coordina, y cuenta con la ayuda de la Gestión de Versiones y la administración de línea, que debería trabajar para garantizar que existen los recursos necesarios para implementar los planes.
Se deberá redactar un procedimiento de back-out como parte de la entrega de un cambio para revertir el cambio si no ofrece los resultados esperados. La Gestión de Cambios no debe aprobar el cambio en caso de no existir un procedimiento de back-out. Si el cambio impacta en el ámbito del usuario, se debe redactar un plan de comunicaciones y posiblemente de formación. El plan de implementación también se escribe durante la fase de construcción.
Los indicadores de rendimiento muestran hasta qué punto el proceso de la Gestión de Cambios es exitoso al manejar los cambios de manera eficaz y eficiente, con el menor impacto adverso posible en el nivel de servicio acordado. Estos indicadores cubren temas tales como:
- La cantidad de cambios que se complete por tiempo, por categoría. - Tasa a la que se implementan los cambios.
- Número de cambios rechazados.
- Número de incidentes que resultaron de los cambios. - Número de back-outs relacionados con los cambios. - Coste de los cambios implementados.
- Correlación entre los recursos estimados y los tiempos contra los reales. - Número de cambios urgentes.
Examen
El procedimiento de back-out, la implementación de cambio, y los resultados esperados del cambio deben ser evaluados en detalle. Se debe considerar el criterio definido antes por el CAB. En muchos casos, una evaluación por separado del entorno o una evaluación de laboratorio (piloto o maqueta) serán necesarias para la evaluación. Las primeras etapas de la evaluación pueden ser llevadas a cabo por los constructores, pero el cambio no debe implementarse sin alguna clase de evaluación independiente.
Esto a menudo se hace de dos formas -evaluación de la aceptación del usuario donde la comunidad del negocio (a menudo el cliente del cambio) evalúa la funcionalidad del cambio, y la evaluación de la
aceptación operacional donde aquellos que soportan y mantienen la infraestructura cambiada realizan una
evaluación independiente.
Se incluirá a las áreas de soporte técnico y al Centro de Servicios que evaluarán la documentación de soporte,
backup y procedimientos de recuperación, etc. También son necesarias las instrucciones claras para monitorizar la calidad de la evaluación, y documentar los resultados de la evaluación.
Implementación
Se puede pedir a cualquier persona en el departamento correspondiente responsable de la gestión de la infraestructura TI que implemente un cambio en la infraestructura.
La Gestión de Cambios garantiza que el cambio se realice según lo programado. Debe haber un plan de comunicaciones que indique a quién se tiene que informar del cambio, por ejemplo los usuarios, el Centro de Servicios, la Administración de Redes, etc.
Si no se puede evaluar un cambio correctamente, es posible aplicar el cambio a un pequeño grupo de usuarios, y evaluar los resultados antes de su implementación a gran escala.
7.4.6 Evaluación
Se deben evaluar los cambios implementados con la posible excepción de los cambios estándar. Si es necesario, el CAB decide si se necesita de un seguimiento. Se deben tener en cuenta los siguientes puntos: • ¿El cambio produjo los objetivos necesarios?
• ¿Los usuarios están satisfechos con el resultado? • ¿Hubo efectos colaterales?
• ¿Se excedieron los costes y los esfuerzos estimados?
Si el cambio fue satisfactorio, se puede cerrar la RFC. Los resultados son incluidos en la Revisión Post Implementación (PIR) o evaluación del cambio. Si el cambio no fue exitoso, entonces se retoma el proceso desde donde surgió el problema, utilizando un planteamiento modificado. A veces es mejor volver atrás y crear una RFC nueva o modificada. Seguir adelante con un cambio infructuoso crea mayores problemas. Los procedimientos con un límite de tiempo automático pueden ayudar a garantizar que no se descuiden las evaluaciones de cambio. Según la naturaleza del cambio, se puede hacer una evaluación después de unos días, o después de meses. Por ejemplo, un cambio en un PC que se utiliza todos los días puede evaluarse pasado unos días, mientras que un cambio en un sistema que se usa solo una vez por semana se puede evaluar pasados los tres meses.