3.1 Transición de los servicios (1/2) Flashcards

1
Q

¿Cuáles son los objetivos de la fase Transición del Servicio?

A

+ Supervisar y dar soporte a todo el proceso de cambio del nuevo (o modificado) servicio.
+ Garantizar que los nuevos servicios cumplen los requisitos y estándares de calidad estipulados en las fases de Estrategia y la de Diseño.
+ Minimizar los riesgos intrínsecos asociados al cambio reduciendo el posible impacto sobre los servicios ya existentes.
+ Mejorar la satisfacción del cliente respecto a los servicios prestados.
+ Comunicar el cambio a todos los agentes implicados.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

¿Cuáles son los procesos asociados a la fase de Transición del Servicio?

A
  1. Planificación y soporte a la Transición: responsable de planificar y coordinar todo el proceso de transición asociado a la creación o modificación de los servicios TI.
  2. Gestión de Cambios: responsable de supervisar y aprobar la introducción o modificación de los servicios prestados garantizando que todo el proceso ha sido convenientemente planificado, evaluado, probado, implementado y documentado.
  3. Gestión de la Configuración y Activos del Servicio: responsable del registro y gestión de los elementos de configuración (CIs) y activos del servicio. Este proceso da soporte a prácticamente todos los aspectos de la Gestión del Servicio.
  4. Gestión de Entregas y Despliegues: Responsable de desarrollar, probar e implementar las nuevas versiones de los servicios según las directrices marcadas en la fase de Diseño del Servicio.
  5. Validación y pruebas: responsable de garantizar que los servicios cumplen los requisitos preestablecidos antes de su paso al entorno de producción.
  6. Evaluación: responsable de evaluar la calidad general de los servicios, su rentabilidad, su utilización, la percepción de sus usuarios, etcétera.
  7. Gestión del Conocimiento: gestiona toda la información relevante a la prestación de los servicios asegurando que esté disponible para los agentes implicados en su concepción, diseño, desarrollo, implementación y operación.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

¿Cuáles son los aspectos generales de a Planificación y Soporte de la Transición?

A

Una vez definida una estrategia general y acordadas desde la fase de Diseño las especificaciones sobre cómo se van a prestar los servicios, hay que ponerse manos a la obra. 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.

Sin embargo, no podemos concebir estas tareas de coordinación como una “realidad paralela”, independiente del resto del Ciclo de Vida. La Planificación y Soporte de la Transición no podría ejercer su labor sin los inputs provenientes del resto de procesos:

+ Paquete de diseño del servicio (SDP). Contiene toda la información del servicio registrada en el Catálogo de Servicios, incluyendo los requisitos que éste debe cumplir (SLAs, SLRs, OLAs, etc.).
+ La Gestión de Cambios enviará toda la información relacionada con la propuesta de cambio (RFC) que se va a ejecutar durante la transición. Por supuesto, dichos cambios deben contar con la autorización formal del Gestor del Cambio o del Comité de Cambios (CAB).
+ Definición del paquete de entrega y otras especificaciones de diseño.

Por su parte, la Planificación también proporciona documentación de salida a otros procesos, especialmente a los de la fase de Transición:
+ Estrategia de transición y modelo de entregas.
+ Recopilación integral de planes de Transición del Servicio.
+ Información sobre riesgos y posibles impactos del cambio en la calidad del servicio.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

¿Cuál es el objetivo de la Planificación de la Transición?

A

El principal objetivo de este proceso consiste en coordinar y planificar los recursos necesarios para desplegar una nueva versión del servicio en el tiempo, coste y calidad requeridos en las especificaciones.

Para ello debe asegurarse de que todas las partes implicadas adoptan una metodología de trabajo común, proporcionando un plan de transición capaz de alinear el cambio con las necesidades del cliente.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

¿Qué ventajas trae consigo una correcta Planificación de la Transición?

A

+ 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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

¿Cuáles son las dificultades que pueden obstaculizar la Planificación de la Transición?

A

+ 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 SACs no están alineados con los requisitos de diseño.
+ 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, etc.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

¿Qué es una Petición de Cambio (RFC)?

A

Una Petición de Cambio o RFC es una petición formal para efectuar modificaciones en uno o más CIs.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

¿Qué es una Revisión Post-Implantación (PIR)?

A

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 procesos, sistemas y herramientas de apoyo a la Transición del Servicio.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

¿Cuáles son las principales actividades de la Planificación y Soporte a la Transición?

A
  1. Estrategia
    • Políticas generales.
    • Metodología.
    • Actores implicados (instituciones, proveedores, etc.).
    • Requisitos internos y externos a tener en cuenta.
    • Tipos de entregas.
  2. Preparación
    • Revisión de la documentación.
    • Comprobación de los elementos de configuración.
    • Identificación de los cambios de que consta la transición.
  3. Planificación
    • Definición de fases y plazos.
    • Asignación de recursos.
    • Establecimiento de SACs.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

¿Qué aspectos hay que tener en cuenta a la hora de definir la estrategia de transición?

A

En primer lugar, la organización debe definir la estrategia de transición para llevar a cabo los cambios previstos en el servicio nuevo o a modificar.

Los puntos clave que debe contemplar dicha estrategia incluyen:

+ Propósito, objetivos y metas.
+ Contexto de prestación del servicio.
+ Requisitos externos que deban tenerse en cuenta (estándares, legislación vigente, acuerdos contractuales, etc.). Requisitos particulares del servicio.
+ Organizaciones y terceros interesados (socios estratégicos, proveedores, etc.)
+ Marco de trabajo a adoptar (políticas, protocolos de autorización, etc.)
+ Roles y responsabilidades. Requisitos de formación de la plantilla involucrada.
+ Planificación de hitos y entregables. Frecuencia de entrega.
+ Convenios de nomenclatura que se han adoptado para denominar las entregas (p. ej. “versión 1.1.3.65”)
+ Criterios de evaluación y de aceptación de las RFCs.
+ Criterios para dar por concluido el soporte post-implantación (ELS).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

¿Cuáles son los tipos de entregas en la definición de la estrategia de la transición?

A
  1. Entrega mayor. Se consideran de esta clase los despliegues que incluyan la instalación de nuevo hardware y software, ya que suelen implicar un aumento de las funcionalidades.
  2. Entrega menor. Suelen consistir en paquetes de pequeñas mejoras, a menudo correspondientes a soluciones provisionales a problemas concretos.
  3. Entrega de emergencia. Se implementan de manera individual para resolver errores conocidos o problemas que no pueden esperar.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

¿Cuáles son los aspectos generales de la preparación de la transición?

A

La preparación consiste en una revisión general de toda la información recabada, así como de los elementos (recursos materiales, personal interno, proveedores, etc.) que intervendrán en la ejecución de los cambios.

+ Revisión y aceptación de los inputs procedentes del resto de procesos del Ciclo de Vida.
+ Revisión y comprobación del paquete de diseño del servicio (SDP) creado en la fase de Diseño.
+ Revisión de los SACs.
+ Identificación, desarrollo y planificación de las peticiones de cambio (RFCs).
+ Comprobación de que la Gestión de la Configuración está actualizada.
+ Comprobación de que la Transición está preparada para llevarse a cabo.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

¿Cuáles son los aspectos generales de la actividad Planificación de la transición?

A

Esta es la actividad principal del proceso, y consiste en la descripción pormenorizada del flujo de trabajo que hará posible la puesta en marcha del cambio. El plan ha de ser específico para cada nueva transición, ya que deben tomarse en cuenta aspectos concretos del servicio como el volumen de elementos de configuración (CIs) implicados en la prestación del mismo, los requisitos específicos acordados con el cliente, etc.

El desarrollo y despliegue de cada transición debe ser compartimentado en distintas etapas:

+ Adquisición y evaluación de los CIs y otros componentes.
+ Desarrollo de la entrega y evaluación preliminar.
+ Validación y pruebas de la entrega.
+ Comprobación de que el servicio está preparado para pasar a la fase de Operación.
+ Despliegue de la nueva versión.
+ Soporte post-implementación.
+ Revisión y cierre de la transición.

Para cada una de estas etapas deben definirse los siguientes aspectos:

+ Descripción de tareas y actividades.
+ Recursos específicos asignados a cada tarea.
+ Criterios de aceptación o SACs para determinar si se puede pasar a la siguiente etapa.
+ Incidencias que pueden presentarse y riesgos asociados.
+ Plazos previstos para cada fase.

Una buena Planificación y Soporte a la Transición tenderá a agrupar varias entregas y despliegues en una programación global, de tal manera que cada despliegue significativo será gestionado como un proyecto aparte.

Por último, debe hacerse una revisión exhaustiva de los planes estratégicos una vez terminados.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

¿Cuáles son los indicadores a controlar y medir en la Planificación y Soporte de la Transición?

A

+ Número de proyectos gestionados. Es decir, el número de versiones desplegadas (rollout) 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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

¿Cuáles son los aspectos generales a considerar en la gestión de los Cambios?

A

Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, y aunque esto no sea necesariamente así, es evidente que toda «evolución a mejor» requiere necesariamente de un cambio.

Sin embargo, 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 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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

¿Cuáles son los objetivos de la Gestión de los Cambios?

A

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.

17
Q

¿Cuáles son los principales beneficios derivados de una correcta gestión del cambio?

A

+ Se reduce 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 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.

18
Q

¿Cuáles son las dificultades que encuentra la implementación de una adecuada política de gestión de cambios?

A

+ Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambios sobre todo en lo que respecta al cambio, independientemente de que éste 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 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, lo que les incapacita para desarrollar correctamente su actividad.
+ Los Gestores del Cambio no disponen de las herramientas de software adecuadas para monitorizar y documentar el proceso de forma apropiada.
+ 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 que empobrece la calidad del servicio.

19
Q

¿Quien es el Gestor de Cambios?

A

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.

20
Q

¿Qué es el Comité Asesor del Cambio (CAB)?

A

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.

21
Q

¿Qué son los Modelos de Cambio?

A

Es una serie de grupos de cambios que han sido previamente clasificados, analizados y autorizados, de tal manera que se predefinen ciertos mecanismos y actividades a realizar para cada grupo. De esta manera se alcanza un control más efectivo y una implementación mucho más ágil de las RFCs.

22
Q

¿En qué consiste el Alcance de la Gestión de Cambios?

A

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 la Configuración y Activos TI: 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 la Configuración y Activos TI, se sugirió como medida simplificadora la creación de “configuraciones de referencia” o paquetes de hardware y software estándar (por ejemplo, un PC de referencia con todas sus componentes de hardware y software predefinidas), es importante crear procesos de cambio cuyos protocolos estén previamente definidos y autorizados para, por ejemplo, realizar los cambios asociados a las configuraciones de referencia antes citadas.

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.

23
Q

¿Cuáles son las principales actividades de la Gestión de Cambios?

A

+ Registrar, evaluar y aceptar o rechazar las RFCs recibidas.
+ Planificación e implementación del cambio.
+ Convocar reuniones del CAB, excepto en el caso de cambios menores, para la aprobación de las RFCs y la elaboración del FSC.
+ Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.

24
Q

¿Cuáles pueden ser los orígenes de una RFC?

A

+ 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, 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 (como, por ejemplo, la LOPD) 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. Para cambios de escasa importancia o que se repiten periódicamente pueden acordarse procedimientos estándar que no requieran la aprobación de la Gestión de Cambios para cada caso.

25
Q

¿Cuáles son los datos mínimos que requiere el registro inicial de una RFC?

A

+ Fecha de recepción.
+ Identificador único de la RFC.
+ Identificador del error conocido asociado (dado el caso).
+ Descripción del cambio propuesto:
- Motivación.
- Propósito.
- CIs involucrados.
- Estimación de recursos necesarios para la implementación.
- 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.

26
Q

¿Qué debe incluir la información de registro actualizada de una RFC?

A
\+ Estatus actualizado: "aceptado", "rechazado", "implementado", etc.
\+ 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.
27
Q

¿Cuáles son los aspectos generales de la Aceptación del Cambio?

A

Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Una RFC puede ser simplemente rechazada si se considera que el cambio no esta 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 solicitó 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 encontrado justificado su ulterior procesamiento.

28
Q

¿Cuáles son los aspectos generales a la hora de la Clasificación de los Cambios?

A

Tras su aceptación se debe 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.

La categoría determina la dificultad e impacto de la RFC y será el parámetro relevante para determinar la asignación de recursos necesarios, los plazos previstos y el nivel de autorización requerido para la implementación del cambio.

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:

  1. 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.
  2. Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca algún otro cambio de más alta prioridad. A su vez, los cambios de esta categoría se pueden dividir en menores, significativos y mayores.
  3. 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.
  4. 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. Los cambios de esta categoría pueden clasificarse a su vez en normales y de emergencia.

La determinación de la categoría se basa en el impacto sobre la organización y el esfuerzo requerido para su implementación. El abanico de posibilidades incluye desde cambios que apenas requieren la participación del personal TI y que apenas modifican la calidad del servicio hasta cambios que necesiten grandes recursos y requieran de la aprobación directa de la Dirección.

Los cambios menores pueden no necesitar la aprobación del CAB y ser implementados directamente. Cualquier otro cambio habrá de ser discutido en el CAB y se habrá de solicitar la colaboración de personal especializado para realizar tareas de asesoramiento.

29
Q

¿Qué aspectos hay que tener en cuenta a la hora de la Aprobación del Cambio?

A

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 provocar 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. Pero esto obviamente no es suficiente.

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 pues pueden entrar en consideración aspectos de carácter estratégico y de política general de la organización.

30
Q

¿Qué es un paquete de cambios?

A

Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe evaluarse si éste 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.

31
Q

¿Qué aspectos hay que tener en cuenta a la hora de la Implementación de Cambios?

A

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 Entregas y Despliegues, sí 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 (debe tenerse en cuenta la resistencia habitual al cambio por parte de cierto tipo de usuarios).

Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es función tanto de la Gestión de Cambios como del Centro de Servicios 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.

32
Q

¿Qué aspectos hay que tener en cuenta a la hora de la Evaluación del cambio?

A

Antes de proceder al cierre del cambio, es necesario verificar que ha sido positivo para el servicio, ya porque el nivel de calidad se ha visto aumentado o porque contribuye a mejorar la productividad de la organización. Aunque la Gestión de Cambios es la encargada de emitir el dictamen final, es la Evaluación del servicio la que ha de proporcionar a ésta los informes.

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.

33
Q

¿Qué aspectos hay que tener en cuenta a la hora de Cambios de emergencia?

A

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. Es frecuente que la solución al problema requiera un cambio y que éste haya de realizarse siguiendo un procedimiento de urgencia.

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 si esto fuera posible.
+ En ciertos casos en los que el número de integrantes o sus circunstancias hagan de ello algo inviable, puede ser necesario constituir un equipo específico, más reducido, que se denomina CAB de Emergencia (ECAB).
+ 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 CAB e incluso del ECAB).

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. Si esto no fuera así, se podrían provocar situaciones de cambios futuros incompatibles, configuraciones registradas incorrectas, etc. que serían fuente de nuevas incidencias y problemas.

34
Q

¿Cuáles son las métricas que se pueden utilizar en la realización de informes para evaluar el rendimiento de la Gestión de Cambios?

A

+ 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.

35
Q

¿Cuál es la misión de la fase de Transición del Servicio?

A

La misión de la fase de Transición del Servicio es hacer que los productos y servicios definidos en la fase de Diseño del Servicio se integren en el entorno de producción y sean accesibles a los clientes y usuario