6. Gestión de cambios (2015)

Resumen Español
Universidad Universidad Autónoma de Barcelona (UAB)
Grado Ingeniería Informática - 3º curso
Asignatura Models de qualitat en la Gestió de les TIC
Año del apunte 2015
Páginas 11
Fecha de subida 03/04/2016
Descargas 18
Subido por

Vista previa del texto

Gestión de cambios 1. Visión General Es moneda 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 desactualizados.
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.
2. Introducción y Objetivos El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar.
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… Las actividades principales de la Gestión de Cambios se resumen sucintamente en el siguiente diagrama: Los principales beneficios derivados de una correcta gestión del cambio son:        Reducir el número de incidentes y problemas potencialmente asociados a todo cambio.
Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga un impacto negativo en la estructura TI.
Se reduce el número de "back-outs" necesarios.
Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".
Se evalúan los verdaderos costes asociados al cambio y por lo tanto es más sencillo valorar el retorno real a la inversión.
La CMDB (Configuration Management Database) está correctamente actualizada, algo imprescindible para la correcta gestión del resto de procesos TI.
Se desarrollan procedimientos de cambio estándar que permiten la rápida actualización de sistemas no críticos.
La implementación de una adecuada política de gestión de cambios también se encuentra con algunas serias dificultades:       Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambios sobre todo en lo que respecta al cambio, independientemente de que este se realice para solucionar un problema, mejorar un servicio o adaptarse a requisitos legales.
No se siguen los procedimientos establecidos y, en particular, no se actualiza correctamente la información sobre los CIs (Configuration Item) en la CMDB.
Los encargados de la Gestión de Cambios no conocen a fondo las actividades, servicios, necesidades y estructura TI de la organización incapacitándoles para desarrollar correctamente su actividad.
Los Gestores del Cambio no disponen de las herramientas adecuadas de software para monitorizar y documentar adecuadamente el proceso.
No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados.
Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o por el contrario el proceso de cambio se trivializa provocando una falta de estabilidad necesaria para la calidad del servicio.
2.1 Conceptos básicos Gestor de Cambios: es el responsable del proceso del cambio y como tal debe ser el último responsable de todas las tareas asignadas a la Gestión de Cambios. En grandes organizaciones el Gestor de Cambios puede disponer de un equipo de asesores específicos para cada una de las diferentes áreas.
Consejo Asesor de Cambios (CAB): es un órgano interno, presidido por el Gestor de Cambios, formado principalmente por representantes de las principales áreas de la gestión de servicios TI. Sin embargo, en algunos casos también puede incorporar:    Consultores externos.
Representantes de los colectivos de usuarios.
Representantes de los principales proveedores de software y hardware.
En principio, todo cambio no estándar debe considerarse tarea de la Gestión de Cambios. Sin embargo es a veces impracticable gestionar todos los cambios mediante ésta.
El alcance de la Gestión de Cambios debe ir en paralelo con el de la Gestión de Configuraciones: todos los cambios de CIs inventariados en la CMDB deben ser correctamente supervisados y registrados.
Al igual que a la hora de implementar la Gestión de Configuraciones se sugirió como medida simplificadora la creación de "configuraciones de referencia" o paquetes de hardware y software estándar, es importante crear procesos de cambio cuyos protocolos están previamente definidos y autorizados.
Estos protocolos de cambio estándar deben ser cuidadosamente elaborados pero una vez definidos permiten una gestión más rápida y eficiente de cambios menores o de bajo impacto en la organización TI.
3. Proceso Las principales actividades de la Gestión de Cambios se resumen en:      Monitorizar y dirigir todo el proceso de cambio.
Registrar, evaluar y aceptar o rechazar las RFCs recibidas.
Convocar reuniones del CAB, excepto en el caso de cambios menores, para la aprobación de las RFCs y la elaboración del FSC.
Coordinar el desarrollo e implementación del cambio.
Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.
3.1 Registro El origen de una RFC (Request For Change) puede ser de muy distinta índole: Gestión de Problemas: se encarga de proponer soluciones a errores conocidos. En la mayoría de los casos esta solución acarrea un cambio en la infraestructura TI. En este caso el RFC debe ser registrado con información del error conocido asociado para que posteriormente pueda ser evaluada correctamente la pertinencia del proceso.
Nuevos Servicios: el desarrollo de nuevos servicios usualmente requiere cambios de la infraestructura TI. En este caso es importante coordinar todo el proceso con las Gestiones de Capacidad, Disponibilidad y Niveles de Servicio para asegurar que estos cambios cumplen las expectativas previstas y no deterioran la calidad de los otros servicios prestados.
Estrategia empresarial: la dirección puede decidir una redirección estratégica que puede afectar, por ejemplo, a los niveles de servicio ofrecidos o a la implantación de un nuevo CRM (Customer Relationship management), etc. y que por regla general requieren de cambios de hardware, software y/o procedimientos.
Actualizaciones de software de terceros: los proveedores pueden dejar de soportar versiones anteriores de paquetes de software o introducir nuevas versiones con grandes mejoras que recomienden la actualización.
Imperativo legal: un cambio de legislación puede exigir cambios en la infraestructura TI.
Otro: en principio cualquier empleado, cliente o proveedor puede sugerir mejoras en los servicios que pueden requerir cambios en la infraestructura.
No siempre un cambio implica una RFC. Independientemente de su origen el correcto registro inicial de una RFC requerirá, cuando menos, de los siguientes datos:      Fecha de recepción.
Identificador único de la RFC.
Identificador del error conocido asociado (dado el caso).
Descripción del cambio propuesto: o Motivación.
o Propósito.
o CIs involucrados.
o Estimación de recursos necesarios para la implementación.
o Tiempo estimado.
Estatus: que inicialmente será el de "registrado".
Este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobación hasta la evaluación final y cierre.
La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos:             Estatus actualizado: "aceptado", "rechazado", "implementado"...
Fecha de aceptación (denegación) del RFC.
Evaluación preliminar de la Gestión del Cambio.
Prioridad y categoría.
Planes de "back out".
Recursos asignados.
Fecha de implementación.
Plan de implementación.
Cronograma.
Revisión post-implementación.
Evaluación final.
Fecha de cierre.
3.2 Aceptación y clasificación Aceptación: Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Una RFC puede ser simplemente rechazada si se considera que el cambio no está justificado o se puede solicitar su modificación si se considera que algunos aspectos de la misma son susceptibles de mejora o mayor definición. En cualquiera de los casos la RFC debe ser devuelta al departamento o persona que la solicito con el objetivo de que se puedan realizar nuevas alegaciones a favor de dicha RFC o para que pueda ser consecuentemente modificada.
La aceptación del cambio no implica su posterior aprobación por el CAB y es sólo indicación de que se ha encontrada justificado su ulterior procesamiento.
Clasificación: Tras su aceptación se deben asignar a la RFC una prioridad y categoría dependiendo de la urgencia y el impacto de la misma.
La prioridad determinará la importancia relativa de esta RFC respecto a otras RFCs pendientes y será el dato relevante para establecer el calendario de cambios a realizar.
Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debería considerar una clasificación que incluyera, al menos, los siguientes niveles de prioridad:     Baja: puede ser conveniente realizar este cambio junto a otros cuando, por ejemplo, se decidan actualizar ciertos paquetes de software o se compre nuevo hardware, etc.
Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca algún otro cambio de más alta prioridad.
Alta: un cambio que debe realizarse sin demora pues está asociado a errores conocidos que deterioran apreciablemente la calidad del servicio. El CAB debe evaluar este cambio en su próxima reunión y adoptar las medidas pertinentes que permitan una pronta solución.
Urgente: es necesario resolver un problema que está provocando una interrupción o deterioro grave del servicio. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que trataremos de forma independiente.
La determinación de la categoría se basa en el impacto sobre la organización y el esfuerzo requerido para su implementación.
3.3 Aprobación y Planificación Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede desencadenar una reacción en cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de "back out" que permitan la recuperación de la última configuración estable antes del cambio En primer lugar el CAB debe reunirse periódicamente para analizar y eventualmente aprobar los RFCs pendientes y elaborar el FSC o calendario del cambio correspondiente.
Para su aprobación el cambio se debe evaluar minuciosamente:        ¿Cuáles son los beneficios esperados del cambio propuesto? ¿Justifican esos beneficios los costes asociados al proceso de cambio? ¿Cuáles son los riesgos asociados? ¿Disponemos de los recursos necesarios para llevar a cabo el cambio con garantías de éxito? ¿Puede demorarse el cambio? ¿Cuál será el impacto general sobre la infraestructura y la calidad de los servicios TI? ¿Puede el cambio afectar los niveles establecidos de seguridad TI? En el caso de cambios que tengan un alto impacto debe también consultarse a la dirección.
Una vez aprobado el cambio debe evaluarse si este ha de ser implementado aisladamente o dentro de un "paquete de cambios" que formalmente equivaldrían a un solo cambio. Esto tiene algunas ventajas:     Se optimizan los recursos necesarios.
Se evitan posibles incompatibilidades entre diferentes cambios.
Sólo se necesita un plan de back-out.
Se simplifica el proceso de actualización de la CMDB y la revisión post-implementación.
3.4 Implementación Aunque la Gestión de Cambios NO es la encargada de implementar el cambio, algo de lo que se encarga habitualmente la Gestión de Versiones, si lo es de supervisar y coordinar todo el proceso.
En la fase de desarrollo del cambio se deberá monitorizar el proceso para asegurar que:     Tanto el software desarrollado como el hardware adquirido se ajustan a las especificaciones predeterminadas.
Se cumplen los calendarios previstos y la asignación de recursos es la adecuada.
El entorno de pruebas es realista y simula adecuadamente el entorno de producción.
Los planes de "back-out" permitirán la rápida recuperación de la última configuración estable.
Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoración preliminar de los nuevos sistemas en lo que respecta a su:    Funcionalidad.
Usabilidad.
Accesibilidad.
La opinión de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada en caso de que se encuentren objeciones justificadas al cambio.
Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es función tanto de la Gestión de Cambios como del Service Desk mantener informados a los usuarios de los futuros cambios y, dentro de lo posible, hacerles partícipes del mismo:    Escuchando sus sugerencias.
Comunicando las ventajas asociadas.
Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepción de mejora debe ser compartida por usuarios y clientes.
3.5 Evaluación Antes de proceder al cierre del cambio es necesario realizar una evaluación que permita valorar realmente el impacto del mismo en la calidad del servicio y en la productividad de la organización.
Los aspectos fundamentales a tener en cuenta son:    ¿Se cumplieron los objetivos previstos? En qué medida se apartó el proceso de las previsiones realizadas por la Gestión de Cambios.
¿Provocó el cambio problemas o interrupciones del servicio imprevistas?   ¿Cuál ha sido la percepción de los usuarios respecto al cambio? ¿Se pusieron en marcha los planes de "back-out" en alguna fase del proceso? ¿Por qué? Si la evaluación final determina que el proceso y los resultados han sido satisfactorios se procederá al cierre de la RFC y toda la información se incluirá en la PIR asociada.
3.6 Emergencias Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación deficiente a veces resultan inevitables.
Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios afectados o porque se han visto involucrados sistemas o servicios críticos para la organización, debe encontrar una respuesta inmediata.
El procedimiento a seguir en estos casos debe estar debidamente previsto. Por ejemplo, se deben establecer protocolos de validación de los cambios urgentes que pueden requerir:   La reunión urgente del CAB y/o EC si esto fuera posible.
Una decisión del Gestor del Cambio si es imposible demorar la resolución del problema o éste sucede durante un fin de semana o periodo vacacional (lo que puede dificultar la reunión del EC).
Como el objetivo prioritario en estos casos es restaurar el servicio es a menudo frecuente que los procesos asociados sigan un orden inverso al usual: tanto los registros en la CMDB como la documentación asociada al cambio se realicen a posteriori.
Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma información de la que dispondríamos tras un cambio normal.
4. Control del Proceso Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios.
Para que estos informes ofrezcan una información precisa y de sencilla evaluación es imprescindible elaborar métricas de referencia que cubran aspectos tales como:        RFCs solicitados.
Porcentaje de RFCs aceptados y aprobados.
Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente.
Tiempo medio del cambio dependiendo del impacto y la prioridad Número de cambios de emergencia realizados.
Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.
Numero de back-outs con una detallada explicación de los mismos.
    Evaluaciones post-implementación.
Porcentajes de cambios cerrados sin incidencias ulteriores.
Incidencias asociadas a cambios realizados.
Número de reuniones del CAB con información estadística asociada: número de asistentes, duración, nº de cambios aprobados por reunión, etc.
5. Caso Práctico Los clientes y proveedores de "Cater Matters" están utilizando cada vez más los servicios online de la empresa para gestionar tanto los pedidos como la cadena de suministro.
El sistema implantado en la actualidad, aunque cumple básicamente con los objetivos de negocio, no estaba diseñado para soportar un nivel de actividad elevado. Tanto la Gestión de Disponibilidad como la Gestión de la Capacidad han informado de deficiencias en el proceso y de futuros cuellos de botella si se sigue con el ritmo de crecimiento actual.
Por otro lado, la dirección de la empresa ha decidido reforzar su presencia online y ofrecer a sus clientes unos más elevados niveles de servicio para incrementar su cuota de mercado.
Todo ello requiere un cambio sustancial en la estructura de software y hardware de los servicios de Internet y su interconexión con el software de gestión interna de la organización (ERP).
Por todo ello ha sido la propia dirección de la empresa la que ha elevado una RFC a la Gestión de Cambios que tiene por objetivos:    Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y capacidad de respuesta.
Desarrollar una serie de WebServices que permitan: o Integrar directamente el sistema de pedidos online en el ERP de la empresa.
o Realizar un seguimiento de todo el proceso de pedido.
o Gestionar remotamente junto a los proveedores toda la cadena de suministro.
Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores.
Tras registrar adecuadamente la RFC:    Se le otorga el estatus de "aceptado" y se le asigna provisionalmente una prioridad normal y un alto impacto.
Se convoca una reunión del CAB para la cual se solicita la asistencia de los responsables de e-commerce y programación web.
Se solicita una evaluación preliminar del proyecto a una consultora externa que supervisó todo el proceso de implementación del sistema actual.
Previamente a la reunión del CAB el Gestor del Cambio elabora, en estrecha colaboración con las Gestiones de la Capacidad, de la Disponibilidad, Financiera y de Niveles de Servicio, así como con la dirección y Gestión de Proyectos:     Una evaluación inicial de costes y recursos necesarios.
Una valoración del impacto de los cambios en la infraestructura TI.
Un cronograma preliminar del proceso.
Una encuesta para que el Service Desk sondee la opinión de los clientes respecto a los posibles cambios.
Sopesando la documentación aportada y la estrategia de negocio de la organización el CAB aprueba el cambio y:       Determina el calendario definitivo del cambio.
Asigna los recursos, internos y externos, necesarios.
Desarrolla un plan que permita la convivencia temporal de ambos sistemas online para asegurar la continuidad del servicio: o Duplicación de toda la estructura web: se compraran nuevos servidores para que los antiguos puedan prestar servicio permanentemente y estén dispuestos inmediatamente para el "back-out".
o Se desarrollarán aplicaciones de "traducción" que permitan mantener actualizadas las bases de datos antiguas para evitar la pérdida de datos en caso de "back-out".
Informa a la Gestión de Configuraciones sobre todos los CIs afectados por el cambio.
Solicita la colaboración de la misma consultora que implanto el sistema actual para que realice una auditoría externa de todo el proceso.
Elabora toda la información necesaria para que la Gestión de Versiones comience todo el proceso de pruebas e implementación.
Tras la implementación del cambio y en colaboración con el "Soporte al Servicio" y la "Provisión del Servicio" la Gestión de Cambios:     Confirma el éxito del cambio: o El nuevo sistema dispone de la capacidad suficiente para proporcionar los niveles de servicio y disponibilidad previstos.
o El nuevo sistema funciona sin errores aparentes.
o Los clientes y proveedores han percibido el cambio como una mejora en la prestación de servicios.
o Ha mejorado la productividad.
Se asegura que todo el cambio ha sido correctamente registrado en la CMDB.
Evalúa el proceso.
Da por cerrado el cambio.
...