Академический Документы
Профессиональный Документы
Культура Документы
1. Definicin y Objetivos La misin de la fase de Transicin del Servicio es hacer que los productos y servicios definidos en la fase de Diseo del Servicio se integren en el entorno de produccin y sean accesibles a los clientes y usuarios autorizados. Sus principales objetivos se resumen en:
Supervisar y dar soporte a todo el proceso de cambio del nuevo (o modificado) servicio. Garantizar que los nuevos servicios cumplen los requisitos y estndares de calidad estipulados en las fases de Estrategia y la de Diseo. Minimizar los riesgos intrnsecos asociados al cambio reduciendo el posible impacto sobre los servicios ya existentes. Mejorar la satisfaccin del cliente respecto a los servicios prestados. Comunicar el cambio a todos los agentes implicados.
Para cumplir adecuadamente estos objetivos es necesario que durante la fase de Transicin del Servicio:
Se planifique todo el proceso de cambio. Se creen los entornos de pruebas y preproduccin necesarios. Se realicen todas las pruebas necesarias para asegurar la adecuacin del nuevo servicio a los requisitos predefinidos. Se establezcan planes de roll-out (despliegue) y roll-back (retorno a la ltima versin estable). Se cierre el proceso de cambio con una detallada revisin postimplementacin. Los clientes disponen de servicios mejor alineados con sus necesidades de negocio. La implementacin de nuevos servicios es ms eficiente. Los servicios responden mejor a los cambios del mercado y a los requisitos de los clientes. Se controlan los riesgos y se dispone de planes de contingencia que eviten una degradacin prolongada del servicio. Se mantienen correctamente actualizadas las bases de datos de configuracin y activos del servicio. Se dispone de una Base de Conocimiento actualizada a disposicin del personal responsable de la operacin del servicio y sus usuarios.
Pgina 1
Planificacin y soporte a la Transicin: responsable de planificar y coordinar todo el proceso de transicin asociado a la creacin o modificacin de los servicios TI. Gestin de Cambios: responsable de supervisar y aprobar la introduccin o modificacin de los servicios prestados garantizando que todo el proceso ha sido convenientemente planificado, evaluado, probado, implementado y documentado. Gestin de la Configuracin y Activos del Servicio: responsable del registro y gestin de los elementos de configuracin (CIs) y activos del servicio. Este proceso da soporte a prcticamente todos los aspectos de la Gestin del Servicio Gestin de Versiones y Despliegues: Responsable de desarrollar, probar e implementar las nuevas versiones de los servicios segn las directrices marcadas en la fase de Diseo del Servicio. Validacin y pruebas: responsable de garantizar que los servicios cumplen los requisitos preestablecidos antes de su paso al entorno de produccin. Evaluacin: responsable de evaluar la calidad general de los servicios, su rentabilidad, su utilizacin, la percepcin de sus usuarios, etctera Gestin del Conocimiento: gestiona toda la informacin relevante a la prestacin de los servicios asegurando que est disponible para los agentes implicados en su concepcin, diseo, desarrollo, implementacin y operacin.
Pgina 2
Paquete de diseo del servicio (SDP). Contiene toda la informacin del servicio registrada en el Catlogo de Servicios, incluyendo los requisitos que ste debe cumplir (SLAs, SLRs, OLAs, etc.). La Gestin de Cambios enviar toda la informacin relacionada con la propuesta de cambio (RFC) que se va a ejecutar durante la transicin. Por supuesto, dichos cambios deben contar con la autorizacin formal del Gestor del Cambio o del Comit de Cambios (CAB). Definicin del paquete de entrega y otras especificaciones de diseo.
Por su parte, la Planificacin tambin proporciona documentacin de salida a otros procesos, especialmente a los de la fase de Transicin:
Estrategia de transicin y modelo de entregas. Recopilacin integral de planes de Transicin del Servicio. Informacin sobre riesgos y posibles impactos del cambio en la calidad del servicio.
Pgina 3
Pgina 4
Pgina 5
Polticas generales. Metodologa. Actores implicados (instituciones, proveedores, etc.). Requisitos internos y externos a tener en cuenta. Tipos de entregas. Revisin de la documentacin. Comprobacin de los elementos de configuracin. Identificacin de los cambios de que consta la transicin. Definicin de fases y plazos. Asignacin de recursos. Establecimiento de SACs. Informacin a interesados. Gestin/administracin de cambios, pedidos, problemas, riesgos... Monitorizacin de actividades.
Soporte
o o o
Pgina 6
Propsito, objetivos y metas. Contexto de prestacin del servicio. Requisitos externos que deban tenerse en cuenta (estndares, legislacin vigente, acuerdos contractuales, etc.). Requisitos particulares del servicio. Organizaciones y terceros interesados (socios estratgicos, proveedores, etc.) Marco de trabajo a adoptar (polticas, protocolos de autorizacin, etc.) Roles y responsabilidades. Requisitos de formacin de la plantilla involucrada. Planificacin de hitos y entregables. Frecuencia de entrega. Convenios de nomenclatura que se han adoptado para denominar las entregas (p. ej. versin 1.1.3.65) Criterios de evaluacin y de aceptacin de las RFCs. Criterios para dar por concluido el soporte post-implantacin (ELS). Entrega mayor. Se consideran de esta clase los despliegues que incluyan la instalacin de nuevo hardware y software, ya que suelen implicar un aumento de las funcionalidades. Entrega menor. Suelen consistir en paquetes de pequeas mejoras, a menudo correspondientes a soluciones provisionales a problemas concretos. Entrega de emergencia. Se implementan de manera individual para resolver errores conocidos o problemas que no pueden esperar.
Pgina 7
Revisin y aceptacin de los inputs procedentes del resto de procesos del Ciclo de Vida. Revisin y comprobacin del paquete de diseo del servicio (SDP) creado en la fase de Diseo. Revisin de los SACs. Identificacin, desarrollo y planificacin de las peticiones de cambio (RFCs). Comprobacin de que la Gestin de la Configuracin est actualizada. Comprobacin de que la Transicin est preparada para llevarse a cabo.
Pgina 8
Adquisicin y evaluacin de los CIs y otros componentes. Desarrollo de la entrega y evaluacin preliminar. Validacin y pruebas de la entrega. Comprobacin de que el servicio est preparado para pasar a la fase de Operacin. Despliegue de la nueva versin. Soporte post-implementacin. Revisin y cierre de la transicin. Descripcin de tareas y actividades. Recursos especficos asignados a cada tarea. Criterios de aceptacin o SACs para determinar si se puede pasar a la siguiente etapa. Incidencias que pueden presentarse y riesgos asociados. Plazos previstos para cada fase.
Para cada una de estas etapas deben definirse los siguientes aspectos:
Una buena Planificacin y Soporte a la Transicin tender a agrupar varias entregas y despliegues en una programacin global, de tal manera que cada despliegue significativo ser gestionado como un proyecto aparte. Por ltimo, debe hacerse una revisin exhaustiva de los planes estratgicos una vez terminados.
Pgina 9
Pgina 10
RFCs autorizadas Paquete de Diseo del Servicio (SDP) Definicin del paquete de entrega y especificaciones de diseo Criterios de Aceptacin de Servicio (SAC) Estrategia de transicin Coleccin integral de planes de Transicin del Servicio
Salidas:
Pgina 11
El nmero de entregas implementadas que cumplen los requisitos acordados con el cliente. Un descenso en el nmero de desviaciones con respecto al mbito, la calidad, los costes y los recursos previos. Una mayor satisfaccin del cliente y los usuarios con los planes y la comunicacin. Un descenso en el nmero de problemas, riesgos y retrasos como consecuencia de una mejor planificacin.
Pgina 12
Solucin de errores conocidos. Desarrollo de nuevos servicios. Mejora de los servicios existentes. Imperativo legal.
El principal objetivo de la Gestin de Cambios es la evaluacin y planificacin del proceso de cambio para asegurar que, si ste se lleva a cabo, se haga de la forma ms eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI.
Pgina 13
Estn justificados. Se llevan a cabo sin perjuicio de la calidad del servicio TI. Estn 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" ( backouts) en caso de un incorrecto funcionamiento tras su implementacin
Pgina 14
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 Gestin de Cambios. En grandes organizaciones, el Gestor de Cambios puede disponer de un equipo de asesores especficos para cada una de las diferentes reas. Comit Asesor del Cambio (CAB): es un rgano interno, presidido por el Gestor de Cambios, formado principalmente por representantes de las principales reas de la gestin de servicios TI. Sin embargo, en algunos casos tambin puede incorporar:
o o o
Consultores externos. Representantes de los colectivos de usuarios. Representantes de los principales proveedores de software y hardware.
Modelos de Cambio: 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 ms efectivo y una implementacin mucho ms gil de las RFCs.
Pgina 15
Pgina 16
Registrar, evaluar y aceptar o rechazar las RFCs recibidas. Planificacin e implementacin del cambio Convocar reuniones del CAB, excepto en el caso de cambios menores, para la aprobacin de las RFCs y la elaboracin del FSC. Evaluar los resultados del cambio y proceder a su cierre en caso de xito
Pgina 17
Gestin de Problemas: se encarga de proponer soluciones a errores conocidos. En la mayora de los casos, esta solucin acarrea un cambio en la infraestructura TI. En este caso, el RFC debe ser registrado con informacin 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 direccin puede decidir una redireccin estratgica que puede afectar, por ejemplo, a los niveles de servicio ofrecidos o a la implantacin 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 actualizacin. Imperativo legal: un cambio de legislacin (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 peridicamente pueden acordarse procedimientos estndar que no requieran la aprobacin de la Gestin de Cambios para cada caso. Independientemente de su origen, el correcto registro inicial de una RFC requerir, cuando menos, de los siguientes datos:
Fecha de recepcin. Identificador nico de la RFC. Identificador del error conocido asociado (dado el caso). Descripcin del cambio propuesto:
o o o o o
Motivacin. Propsito. CIs involucrados. Estimacin de recursos necesarios para la implementacin. Tiempo estimado.
Pgina 18
Este registro deber ser actualizado con toda la informacin generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobacin hasta la evaluacin final y cierre. La informacin de registro debe ser actualizada durante todo el proceso y debe incluir al menos:
Estatus actualizado: "aceptado", "rechazado", "implementado", etc. Fecha de aceptacin (denegacin) del RFC. Evaluacin preliminar de la Gestin del Cambio. Prioridad y categora. Planes de back-out. Recursos asignados. Fecha de implementacin. Plan de implementacin. Cronograma. Revisin post-implementacin. Evaluacin final. Fecha de cierre.
Pgina 19
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 algn otro cambio de ms alta prioridad. A su vez, los cambios de esta categora se pueden dividir en menores, significativos y mayores. 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 prxima reunin y adoptar las medidas pertinentes que permitan una pronta solucin. Urgente: es necesario resolver un problema que est provocando una interrupcin 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 categora pueden clasificarse a su vez en normales y de emergencia.
La determinacin de la categora se basa en el impacto sobre la organizacin y el esfuerzo requerido para su implementacin. El abanico de posibilidades incluye desde cambios que apenas requieren la participacin del personal TI y Pgina 20
Pgina 21
Cules son los beneficios esperados del cambio propuesto? Justifican esos beneficios los costes asociados al proceso de cambio? Cules son los riesgos asociados? Disponemos de los recursos necesarios para llevar a cabo el cambio con garantas de xito? Puede demorarse el cambio? Cul 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 tambin consultarse a la direccin pues pueden entrar en consideracin aspectos de carcter estratgico y de poltica general de la organizacin. Una vez aprobado el cambio (en caso contrario se seguira el proceso ya descrito para el caso de no aceptacin) debe evaluarse si ste ha de ser implementado aisladamente o dentro de un "paquete de cambios", que formalmente equivaldran a un solo cambio. Esto tiene algunas ventajas:
Se optimizan los recursos necesarios. Se evitan posibles incompatibilidades entre diferentes cambios. Slo se necesita un plan de back-out. Se simplifica el proceso de actualizacin de la CMDB y la revisin postimplementacin.
Pgina 22
Tanto el software desarrollado como el hardware adquirido se ajustan a las especificaciones predeterminadas. Se cumplen los calendarios previstos y la asignacin de recursos es la adecuada. El entorno de pruebas es realista y simula adecuadamente el entorno de produccin. Los planes de back-out permitirn la rpida recuperacin de la ltima configuracin estable.
Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoracin preliminar de los nuevos sistemas en lo que respecta a su:
La opinin 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 funcin tanto de la Gestin de Cambios como del Centro de Servicios mantener informados a los usuarios de los futuros cambios y, dentro de lo posible, hacerles partcipes del mismo:
Escuchando sus sugerencias. Comunicando las ventajas asociadas. Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepcin de mejora debe ser compartida por usuarios y clientes.
Pgina 23
Se cumplieron los objetivos previstos? En qu medida se apart el proceso de las previsiones realizadas por la Gestin de Cambios? Provoc el cambio problemas o interrupciones del servicio imprevistas? Cul ha sido la percepcin de los usuarios respecto al cambio? Se pusieron en marcha los planes de back-out en alguna fase del proceso? Por qu?
Si la evaluacin final determina que el proceso y los resultados han sido satisfactorios, se proceder al cierre de la RFC y toda la informacin se incluir en la PIR asociada.
Pgina 24
La reunin urgente del CAB si esto fuera posible. En ciertos casos en los que el nmero de integrantes o sus circunstancias hagan de ello algo inviable, puede ser necesario constituir un equipo especfico, ms reducido, que se denomina CAB de Emergencia (ECAB). Una decisin del Gestor del Cambio si es imposible demorar la resolucin del problema o ste sucede durante un fin de semana o periodo vacacional (lo que puede dificultar la reunin del CAB e incluso delECAB).
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 documentacin asociada al cambio se realicen a posteriori. Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma informacin de la que dispondramos tras un cambio normal. Si esto no fuera as, se podran provocar situaciones de cambios futuros incompatibles, configuraciones registradas incorrectas, etc. que seran fuente de nuevas incidencias y problemas.
Pgina 25
Cambios estratgicos Cambios que afecten a uno o ms servicios Cambios operativos Cambios para mejora continua Polticas y estrategias de cambios y entregas RFCs Propuesta de cambio Planes de: cambio, transicin, entrega y despliegue, pruebas, evaluacin, regresin Programacin de Cambios (SC) y Paradas de Servicio Planificadas (PSOs) Activos y elementos de configuracin Resultados de pruebas, informes de pruebas y de evaluacin Solicitudes de cambio aprobadas o rechazadas Servicios, elementos de configuracin y activos, nuevos o modificados PSO ajustada Programacin de Cambios actualizada Decisiones, acciones, documentos, registros e informes de cambios Gestin de la Configuracin y Activos del Servicio: la informacin del Sistema de Gestin de la Configuracin (CMS) ayuda a determinar el impacto de los cambios propuestos y a seguir el flujo de trabajo de los cambios. Tambin indica si el cambio afecta a otros elementos de configuracin que no estn incluidos en la solicitud de cambio. Gestin de Problemas: es uno de los procesos que presenta ms solicitudes de cambio. Su contribucin es muy importante en las reuniones del CAB. Gestin de la Continuidad del Servicio de TI: incluye un gran nmero de planes y procedimientos que se actualizan con el proceso de Gestin de Cambios. Gestin de la Seguridad de la Informacin: todos los cambios relacionados con temas de seguridad se tratan con el proceso de Gestin de Cambios.
Entradas:
Salidas:
Pgina 26
Gestin de la Capacidad y Gestin de la Demanda: una demanda mal gestionada implica un mayor nmero de riesgos. La Gestin de la Capacidad desempea un papel importante en la evaluacin de cambios.
Pgina 27
Nmero de interrupciones, incidencias y problemas como consecuencia de cambios. Nmero de especificaciones incorrectas de cambios Nmero de anlisis de impacto incorrectos Reparaciones de servicios/aplicaciones como consecuencia de especificaciones incorrectas de cambios. Frecuencia de cambios Nmero de cambios Nivel de satisfaccin de las personas con la velocidad, claridad y facilidad de uso Nmero y porcentaje de cambios que siguen los procedimientos formales de gestin de cambios Tasa de solicitudes de cambio planificadas con respecto a las no planificadas Tasa de solicitudes de cambio aceptadas con respecto a las rechazadas Utilizacin de personal Comparacin de coste y presupuesto
Mtricas de proceso:
Pgina 28
Llevar el control de todos los elementos de configuracin de la infraestructura TI con el adecuado nivel de detalle y gestionar dicha informacin a travs de la Base de Datos de Configuracin (CMDB). Proporcionar informacin precisa sobre la configuracin TI a la Planificacin y Soporte a la Transicin en su papel de coordinacin del cambio para que sta pueda establecer las fases y plazos en que se articular la Transicin. Interactuar con la Gestin de Incidencias, Problemas, Cambios y Versiones y Despliegues de manera que stas puedan resolver ms eficientemente las incidencias, encontrar rpidamente la causa de los problemas, realizar los cambios necesarios para su resolucin y mantener actualizada en todo momento la CMDB. Monitorizar peridicamente la configuracin de los sistemas en el entorno de produccin y contrastarla con la almacenada en la CMDB para subsanar discrepancias.
Pgina 29
Proporcionar informacin precisa y fiable al resto de la organizacin de todos los elementos que configuran la infraestructura TI. Mantener actualizada la Base de Datos de Gestin de Configuracin y Activos TI:
o o o
Registro actualizado de todos los CIs: identificacin, tipo, ubicacin, estado... Interrelacin entre los CIs. Servicios que ofrecen los diferentes CIs.
Servir de apoyo a los otros procesos, en particular, a la Gestin de Incidencias, Problemas y Cambios.
Pgina 30
Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. as como sus componentes: tarjetas de red, teclados, lectores de CDs, etc. Software: sistemas operativos, aplicaciones, protocolos de red, etc. Documentacin: manuales, acuerdos de niveles de servicio, etc.
En resumen, todos los componentes que han de ser gestionados por la organizacin TI. Cada informacin registrada sobre un CI recibe el nombre de atributo. Son ejemplos de atributos: nmero de versin, nombre, localizacin, etc. Base de Datos de la Gestin de la Configuracin y Activos TI : esta base de datos debe incluir:
Informacin detallada de cada elemento de configuracin. Interrelaciones entre los diferentes elementos de configuracin, como, por ejemplo, relaciones "padre-hijo" o interdependencias tanto lgicas como fsicas.
La CMDB no se limita a una mera enumeracin del stock de piezas, sino que nos brinda una imagen global de la infraestructura TI de la organizacin. Sistema de Gestin de la Configuracin (CMS): es un sistema de apoyo diseado para infraestructuras de servicios TI de gran complejidad.
Pgina 31
Planificacin: determinar los objetivos y estrategias de la Gestin de la Configuracin y Activos TI. Clasificacin y Registro: los CIs deben ser registrados conforme al alcance, nivel de profundidad y nomenclatura predefinidos. Monitorizacin y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estn correctamente registrados y se conoce su estado actual. Realizacin de auditoras: para asegurar que la informacin registrada en la CMDB coincide con la configuracin real de la estructura TI de la organizacin. Elaboracin de informes: para evaluar el rendimiento de la Gestin de la Configuracin y Activos TI y aportar informacin de vital importancia a otras reas de la infraestructura TI.
Pgina 32
Designar un responsable: una descentralizacin excesiva puede generar descoordinacin y llevar al traste todo el proceso. Invertir en alguna herramienta de software adecuada a las actividades requeridas: una organizacin manual es impracticable. Realizar un cuidadoso anlisis de los recursos ya existentes: gestin de stocks, activos, etc. Establecer claramente:
o o o
Coordinar el proceso estrechamente con la Gestin de Cambios, Gestin de Entregas y Despliegues y los Departamentos de Compras y Suministros.
Una falta de planificacin conducir con total certeza a una Gestin de la Configuracin y Activos TI defectuosa con las graves consecuencias que esto supondr para el resto de los procesos.
Pgina 33
Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo a la organizacin y resultar, a la larga, en una dejacin de responsabilidades. La informacin sea suficiente: debe existir, al menos, un registro de todos los sistemas crticos para la infraestructura TI.
Alcance En primer lugar habremos de determinar qu sistemas y componentes TI van a ser incluidos en la CMDB:
Es esencial incluir al menos todos los sistemas de hardware y software implicados en los >servicios crticos. Se debe determinar qu CIs deben incluirse dependiendo del estado de su ciclo de vida. Por ejemplo, pueden obviarse componentes que ya han sido retirados. Es recomendable incorporar, al menos, la documentacin asociada a proyectos, SLAs y licencias.
En general, cualquier servicio o proceso es susceptible de ser incluido en la CMDB, pero unos objetivos en exceso ambiciosos pueden resultar contraproducentes. Nivel de detalle y Profundidad Una vez determinado el alcance de la CMDB, es imprescindible establecer el nivel de detalle y profundidad deseados:
Determinar los atributos que describen a un determinado CI. Tipo de relaciones lgicas y fsicas registradas entre los diferentes CIs. Subcomponentes registrados independientemente. Atributos: Fecha de compra, fabricante, procesador, sistema operativo, propietario, estado, coste, etc. Relaciones: conexin en red, impresoras conectadas, etc. Profundidad: tarjetas de red, discos duros, tarjetas grficas, etc.
Nomenclatura Aunque este sea un aspecto muy tcnico, es de vital importancia predefinir los cdigos de clasificacin de los CIs para que el sistema sea funcional:
La identificacin debe ser, por supuesto, nica y si es posible interpretable por los usuarios.
Pgina 34
Este cdigo debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir fsicamente unido al mismo (mediante una etiqueta de difcil eliminacin). Los cdigos no deben ser slo utilizados para componentes de hardware sino tambin para documentacin y software.
Pgina 35
Pgina 36
Asegurar que todos los componentes estn registrados en la CMDB. Monitorizar el estado de todos los componentes. Actualizar las interrelaciones entre los CIs. Informar sobre el estado de las licencias.
Pgina 37
Tras la implementacin de una nueva CMDB. Antes y despus de cambios mayores en la infraestructura. Si existen fundadas sospechas de que la informacin almacenada en la CMDB es incorrecta o incompleta. Uso correcto de la nomenclatura en los registros de los CIs. Comunicacin con la Gestin de Cambios: informacin sobre RFCs , cambios realizados, etc. Estado de los CIs actualizado. Cumplimiento de los niveles de alcance y detalle predeterminados. Adecuacin de la estructura de la CMDB con la de la estructura TI real
Pgina 38
Gestin de Cambios: anlisis de impactos. Gestin Financiera: informacin sobre costes, depreciaciones, mantenimiento y reparaciones Gestin de la Continuidad del Servicio de TI: para hacer que la organizacin conozca los activos de los que depende el negocio, y para el control de software y repuestos clave. Gestin de Incidencias y Problemas: para el diagnstico de problemas e incidencias. Gestin de la Disponibilidad: para la deteccin de puntos de fallo.
Pgina 39
Mayor calidad y precisin de la informacin sobre activos y elementos de configuracin Menos errores debidos a informacin obsoleta Menor duracin de las auditoras como resultado de u n mejor acceso a la informacin Tiempos de diagnstico y resolucin ms cortos para incidencias y problemas Menos discrepancias entre la situacin real y la reflejada en el CMS
Pgina 40
Determinar el nivel correcto de detalle y profundidad Implementar un enfoque vertical para la estructura de la configuracin Conseguir el nivel de precisin correcto Utilizar tecnologa para automatizar el CMS y aplicar las directrices de SACM Importancia excesiva de los aspectos tcnicos sobre los servicios y las operaciones Prdida de vigencia del CMS debido, por ejemplo, al traslado de activos hardware por personal no autorizado
Riesgos:
Pgina 41
Pgina 42
Establecer una poltica de implementacin de nuevas versiones de hardware y software. Implementar las nuevas versiones de software y hardware en el entorno de produccin despus de que la Validacin y Pruebas las haya verificado en un entorno realista. Garantizar que el proceso de cambio cumpla las especificaciones de la RFC correspondiente. Asegurar, en colaboracin con la Gestin de Cambios y la de Configuracin y Activos TI, que todos los cambios se ven correctamente reflejados en la CMDB. Archivar copias idnticas del software en produccin, as como de toda su documentacin asociada, en la DML. Mantener actualizado el DS.
Pgina 43
Versiones mayores: que representan importantes despliegues de software y hardware y que introducen modificaciones importantes en la funcionalidad, caractersticas tcnicas, etc. Versiones menores: que suelen implicar la correccin de varios errores conocidos puntuales y que a menudo son modificaciones que vienen a implementar de una manera correctamente documentada soluciones de emergencia. Versiones de emergencia: modificaciones que reparan de forma rpida un error conocido.
Como pueden llegar a existir mltiples versiones, es conveniente definir una referencia o cdigo que los identifique unvocamente. El sistema universalmente aceptado es:
Versiones mayores: 1.0, 2.0, etc. Versiones menores: 1.1, 1.2, 1.3, etc. Versiones de emergencia: 1.1.1, 1.1.2, etc.
Aunque en algunos casos esta clasificacin se refina an ms (vea, por ejemplo, en la ayuda la versin de su navegador). En su ciclo de vida, una versin puede encontrase en diversos estados: desarrollo, pruebas, produccin y archivado.
Pgina 44
Pgina 45
Cmo puede afectar la nueva versin a otras reas del entramado TI.
Qu CIs se vern directa o indirectamente implicados durante y tras el lanzamiento de la nueva versin. Cmo ha de construirse el entorno de pruebas para que ste sea fiel reflejo del entorno de produccin. Qu planes de back-out son necesarios. Cmo y cundo se deben implementar los planes de back-out para minimizar el posible impacto negativo sobre el servicio y la integridad del sistema TI. Cules son los recursos humanos y tcnicos necesarios para llevar a cabo la implementacin de la nueva versin con garantas de xito. Quines sern los responsables directos en las diferentes etapas del proceso Qu planes de comunicacin y/o formacin deben desarrollarse para que los usuarios estn puntualmente informados y puedan percibir la nueva versin como una mejora. Pgina 46
Qu tipo de despliegue es el ms adecuado: completo, delta, sincronizado en todos los emplazamientos, gradual... Cul es la vida media til esperada de la nueva versin. Qu impacto puede tener el proceso de lanzamiento de la nueva versin en la calidad del servicio. Si es posible establecer mtricas precisas que determinen el grado de xito del lanzamiento de la nueva versin.
Una herramienta clave para formular la planificacin de entregas es el Modelo en V, que sirve para identificar los diferentes niveles de test necesarios para aceptar una versin durante el proceso de Validacin y Pruebas. La metodologa del Modelo en V consiste en definir, en el brazo izquierdo de la V, las especificaciones del servicio que es necesario cumplir para aceptar una versin. En el brazo derecho se van indicando, de forma paralela, las pruebas mediante las cuales se van a comprobar cada una de las especificaciones de la izquierda.
Pgina 47
Back-up automtico de datos. Actualizaciones necesarias de las Bases de Datos asociadas. Instalacin de las nuevas versiones en diferentes sistemas o emplazamientos geogrficos. Creacin de logs asociados al proceso de instalacin.
Parte integrante del desarrollo lo componen los planes de back-out asociados. stos tendrn que tomar en cuenta la disponibilidad acordada con los clientes en los SLAs correspondientes.
Pgina 48
Completo y sincronizado: se realiza de manera integral y simultnea en todos los emplazamientos. Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo, introduciendo la nueva versin por grupos de trabajo o incrementando progresivamente la funcionalidad ofrecida.
El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sus tareas y responsabilidades especficas. En particular, los usuarios finales deben estar puntualmente informados del calendario de lanzamiento y de cmo ste puede afectar a sus actividades diarias. Es imprescindible determinar claramente:
Los CIs que deben borrarse e instalarse y en qu orden debe realizarse este proceso. Cundo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones geogrficas. Qu mtricas determinan la puesta en marcha de los planes de back-out y si stos deben ser completos o parciales.
Se incluya una copia de la versin en la DML. El DS incorpore repuestos funcionales de los nuevos CIs. La CMDB est correctamente actualizada. Los usuarios estn debidamente informados de las nuevas funcionalidades y han recibido la formacin necesaria para poder sacar el adecuado provecho de las mismas.
Tras la implementacin, la Gestin de Entregas y Despliegues debe ser puntualmente informada por el Centro de Servicios de los comentarios, quejas, incidentes, etc. que la nueva versin haya podido suscitar. Toda esta informacin deber ser analizada para asegurar que las prximas versiones incorporen las sugerencias recibidas y que se tomen las medidas correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios
Pgina 49
Los usuarios deben conocer el prximo lanzamiento de una nueva versin y conocer con anterioridad la nueva funcionalidad planificada o los errores que se pretenden resolver para participar, a su discrecin, en el proceso. Cuando se considere oportuno, se impartirn cursos presenciales o remotos mediante mdulos de e-learning sobre el funcionamiento de la nueva versin. Se desarrollar una pgina de FAQs donde los usuarios puedan aclarar las dudas ms habituales y puedan solicitar ayuda o soporte tcnico en el uso de la nueva versin.
Pgina 50
Solicitud de cambio aprobada Solicitud de cambio aprobadas, paquete del servicio, SLP, SDP, SAC y planes de continuidad Polticas, diseo y modelo de versiones Plan y modelo de construccin Planes y estndares de tecnologa, compras, Gestin del Servicio y operacin del Servicio Criterios de entrada y salida para cada fase de la gestin de versiones y despliegue Planes de versiones y despliegues, solicitud de cambio completa, notificaciones de servicio, catlogo de servicios actualizado y modelo de servicio Informes de servicio y documentacin de gestin del servicio nuevo o modificado Nuevo entorno y capacidades del servicio probados SLA, OLAs y contratos Informe de Transicin del Servicio y plan de capacidad del servicio Lista completa y precisa de CIs, con una traza de auditora para los CIs del paquete de entrega, y adems las configuraciones de servicio e infraestructuras, nuevas o modificadas
Entradas:
Salidas:
Pgina 51
Mejora del rendimiento del servicio Reduccin del nmero de incidencias Aumento de la satisfaccin del cliente y los usuarios Costes ms bajos para diagnosticar incidencias y problemas Reduccin del nmero de discrepancias en las auditoras de configuracin, en relacin a la situacin real
Pgina 52
El servicio nuevo (o modificado) se ejecuta en el entorno de destino y se prueba con respecto al Diseo de Servicio El servicio nuevo (o modificado) se ha probado en un piloto Los modelos de prueba se pueden reutilizar para pruebas de regresin de futuras entregas Falta de claridad en las expectativas y objetivos de los distintos interesados y mala definicin de roles, tareas y responsabilidades Gestin incompetente, recursos financieros insuficientes, falta de control y Gestin de Cambios defectuosa Relaciones deficientes con asociados y proveedores de servicio, as como falta de apoyo (compromiso) de los grupos de inters Riesgos relativos a la infraestructura tcnica y las aplicaciones
Riesgos:
Pgina 53
La Gestin del Catlogo de Servicios enva a la Validacin y Pruebas el Catlogo de Servicios Tcnico, que incluye informacin detallada sobre modelo de servicio (servicios suministrados, soporte, activos que lo conforman, etc.). La Gestin de Niveles de Servicio facilita los SLRs acordados con el cliente y las Hojas de Especificacin, que recogen, desde un punto de vista ms tcnico, el nivel de calidad que debe cumplir la versin. La Planificacin y Soporte de la Transicin y la Gestin de Cambios aportan tanto la estrategia general de Transicin en el servicio como toda la documentacin de la RFC particular (valoracin de riesgos, recursos asociados). La Gestin de Versiones y Despliegues proporciona la versin a testear propiamente dicha.
Una vez terminadas las sesiones de testeo, la Validacin y Pruebas del Servicio ha de entregar los resultados de las mismas a la Evaluacin para que elabore los informes de rendimiento que luego servirn a la Gestin de Cambios para tomar una decisin final.
Pgina 54
Disear y mantener un entorno de pruebas, es decir, una rplica exacta del escenario en el que el servicio desarrolla su actividad. Conocer a fondo las funcionalidades del servicio y mantener listados actualizados de todos los casos de uso para poder hacer chequeos completos. Conocer a fondo los requisitos de calidad del servicio acordados con el cliente para poder garantizar que las nuevas versiones los cumplen. Planificar y llevar a cabo un calendario de pruebas que cubra todas las funcionalidades registradas para el servicio.
Pgina 55
Pgina 56
Validacin de paquetes de servicios, ofertas y contratos. Definicin del modelo de pruebas, la planificacin y los protocolos de testeo. Construccin del escenario de pruebas y acceso a los elementos a probar. Pruebas de las nuevas versiones en un entorno idntico al entorno real de desarrollo del servicio nuevo o mejorado. Aceptacin de los datos y elaboracin de informes de resultados que registren los errores, de haberse producido. Limpieza del entorno de pruebas y cierre del proceso.
Pgina 57
El propio objeto de las pruebas, proporcionado por la Gestin de Entregas y Despliegues. Plan de Pruebas, que recoge la planificacin y la estimacin de plazos para cada una de las pruebas: tcnicas, funcionales, etc. Puede haber uno o varios, dependiendo de las circunstancias y magnitud de los cambios. Guiones de pruebas, que recogen el mtodo a emplear: cmo se va a testear cada elemento, qu datos se van a tomar como indicadores y los baremos de calidad que determinarn si la prueba ha sido un xito o un fracaso.
La Direccin y Validacin de Pruebas es la unidad encargada de supervisar el correcto desempeo de las tareas descritas en el Plan de Pruebas. Al final de todo el proceso, ser tambin la responsable de elaborar el registro final de todas las tareas realizadas y de verificar que la planificacin se cumpli punto por punto. Una vez planificado el proceso, el siguiente paso consiste en la validacin de los paquetes de servicios, las ofertas y los contratos (UCs). El objetivo ltimo es asegurar que el servicio TI se corresponde con la utilidad y garanta esperadas, y que el proveedor o proveedores correspondientes estn preparados para poner en funcionamiento el nuevo servicio a partir de su despliegue. Llegado este punto, tambin se repasan los diseos y planes de pruebas para verificar que todo est completo y que se ajusta a los perfiles de riesgo previstos (teniendo en cuenta, por ejemplo, los picos de demanda) y a todos los casos de uso (interfaces, perfil tecnolgico de los usuarios, roles, etc).
Pgina 58
Las mismas versiones de software que la plataforma en produccin. Los mismos dispositivos de hardware. Clones de las bases de datos. Slo si se utilizan las bases de datos reales pueden obtenerse informes precisos sobre, por ejemplo, el rendimiento de las consultas, con resultados que no apareceran de utilizar bases de datos de ejemplo con slo unas pocas entradas.
Antes de dar comienzo a las pruebas, todos estos componentes son pretesteados para garantizar que slo participarn en ellas aquellos que cumplen con los ms estrictos criterios de calidad.
Pgina 59
Pruebas del correcto funcionamiento de la versin. Pruebas de los procedimientos automticos o manuales de instalacin. Pruebas de los planes de back-out. Pruebas por grupo objetivo (roles), para medir la utilidad del servicio.
Siempre que sea posible, las pruebas de carcter funcional deben ser realizadas por un selecto grupo de usuarios finales. Durante este proceso de prueba se documentar y analizar:
La experiencia subjetiva del usuario. Los comentarios y sugerencias sobre usabilidad y funcionalidad o las dudas que hayan surgido durante el uso de la nueva versin. La claridad de la documentacin que se pondr a disposicin del usuario final.
Pgina 60
Reporte de actividades realizadas. Listas de bugs o errores detectados, si se diera el caso. Ideas de mejora, que se envan a la fase de CSI. Informacin y conocimiento para el SKMS.
Este documento es el que ms adelante servir a la Evaluacin para elaborar informes de rendimiento del servicio que a su vez sern tenidos en cuenta por la Gestin de Cambios a la hora de validar o no el cambio.
Pgina 61
Pgina 62
Paquete del servicio y paquete del nivel de servicio Definiciones de interfaces segn el proveedor de servicios Paquete de Diseo del Servicio Planes de versiones y despliegues Criterios de aceptacin y solicitudes de cambio Lneas bases de configuracin del entorno Pruebas realizadas Resultados de las pruebas Anlisis de los resultados Registros de incidencias, problemas y errores de pruebas Ideas de mejora para CSI Datos actualizados Informacin y conocimiento para el Sistema de Gestin del Conocimiento del Servicio
Salidas:
Pgina 63
Reduccin del impacto de incidencias y errores en produccin, que sean atribuibles a una nueva transicin de servicio Uso ms efectivo de los recursos e implicacin del cliente (por ejemplo, pruebas de aceptacin del usuario) Una mejor comprensin por parte de todos los interesados de los roles y responsabilidades relacionados con el servicio nuevo o modificado Reduccin del esfuerzo y los costes necesarios para preparar el entorno de pruebas Reduccin del esfuerzo necesario para detectar errores, y del nmero de "errores repetidos" Reutilizacin de datos de prueba Reduccin del porcentaje de incidencias relacionadas con erroes detectados durante las pruebas Nmero de errores conocidos documentados durante y antes de las fases de prueba
Pgina 64
Pgina 65
El Diseo del Servicio aportar el SDP, donde figuran las caractersticas del servicio nuevo o modificado. La Gestin de Cambios proporcionar la documentacin necesaria para llevar la evaluacin a cabo: registro de la RFC, informe de impacto y riesgos previstos, etc La Validacin y Pruebas del Servicio suministra, por su parte, el informe de resultados de las labores de testeo.
La Evaluacin, por su parte, toma los datos proporcionados por estos procesos y genera una serie de informes de evaluacin que servirn para que:
La Gestin de Cambios cuente con la informacin de contexto necesaria para aprobar o no cada solicitud de cambio. La Mejora Continua del Servicio detecte necesidades o carencias relacionadas con el rendimiento y proponga nuevas RFC.
Pgina 66
Pgina 67
Planificacin de la evaluacin, que consiste en analizar los efectos, tanto previstos como imprevistos, de la puesta en marcha de un cambio o nuevo servicio. Evaluacin del rendimiento previsto. Se realiza antes de implementar el cambio y consiste en predecir los efectos que ste tendr una vez est operativo.
Evaluacin del rendimiento real. Se realiza una vez el cambio ha sido ya implementado, y consiste en analizar los efectos que ha provocado su puesta en marcha.
Pgina 68
Capacidad del proveedor de Servicios (S). La capacidad de un proveedor o de una unidad de servicio para desempear su trabajo. Tolerancia (T). La capacidad que tiene el servicio para absorber cambios. Configuracin de la Organizacin (O). La capacidad que tiene la organizacin TI para absorber cambios. Recursos (R). Disponibilidad de la necesaria infraestructura, personal cualificado, fondos econmicos, etc. para llevar a cabo la transicin. Modelado y medidas (M). Grado en que las predicciones formuladas a partir del modelo de rendimiento coinciden con el comportamiento real del servicio modificado. Personas (P). Las personas dentro del sistema y el efecto del cambio en ellas. Uso (U). Grado en que el servicio cumple con las expectativas de uso (p.ej. disponibilidad, capacidad, seguridad, etc.) Propsito (P). Grado en que el servicio se ajusta al propsito inicial.
La mejor manera de garantizar que el impacto del cambio se ha comprendido en profundidad es examinarlo desde dos perspectivas:
Efectos deliberados. En general, son beneficiosos para el servicio y deben estar alineados con los SACs definidos por la Planificacin y Soporte a la Transicin. Algunos ejemplos: reduccin del coste del servicio, incremento del rendimiento, optimizacin de recursos, etc. Efectos imprevistos. Son muy difciles de predecir e incluso de detectar, ya que a menudo no se manifiestan hasta que se despliega el cambio en produccin.
Por lo general, suelen ser perjudiciales para el servicio y son difciles de medir: impacto en los clientes/usuarios, sobrecarga de la red
Pgina 69
Requisitos del cliente (SLRs, SLAs). Rendimiento esperado o rendimiento que est previsto que el servicio obtenga una vez implantado el cambio. Modelo de rendimiento, que no es sino una representacin de la utilidad y garanta del servicio.
Si la Evaluacin concluye que el rendimiento real no coincide con lo previsto, acarrea riesgos inaceptables o bien se desva de los criterios de aceptacin, entonces se interrumpen las actividades de evaluacin y se genera un Informe Intermedio de Valoracin, que ser enviado a la Gestin de Cambios y que contemplar:
Perfil de riesgos. Reporte de desviaciones (rendimiento esperado vs. real). Recomendaciones. Control de calidad.
Si, en cambio, la Evaluacin concluye que el rendimiento previsto coincide con lo esperado, se procede al despliegue del cambio y a la evaluacin del rendimiento real.
Pgina 70
Pgina 71
Una solicitud de evaluacin del gestor de la Transicin del Servicio o de la Gestin de Cambios. Una actividad de evaluacin en el plan de proyecto El Paquete de Diseo del Servicio (SDP) Criterios para la Aceptacin del Servicio (SAC) Informes de pruebas Resultados Informe de evaluacin
Entradas:
Salidas:
Pgina 72
Diferencias en el rendimiento del servicio (mnimas y en descenso) y el nmero de incidencias (bajo y en descenso) Nmero de diseos fallidos (cero) y el tiempo de evaluacin (corto y en descenso)
Pgina 73
Retrasos en el calendario de evaluaciones debido al incumplimiento en las fechas de entrega de proyectos y proveedores Desarrollo de mtodos estndares para medir el rendimiento y creacin de una "cultura de gestin del riesgo" Analizar el riesgo desde distintos puntos de vista y comprender el impacto de los riesgos sobre la Transicin del Servicio
Pgina 74
Los errores detectados y las soluciones aportadas en cada caso, principalmente desde la Gestin de Incidencias y Errores. De esta manera, puede confeccionarse un registro que recibe el nombre de KEDB y que ayuda a minimizar el tiempo de catalogacin y solucin de los mismos en el futuro. Asimismo, la Gestin de Problemas puede hacer un seguimiento del histrico de errores, establecer relaciones y determinar con mayor facilidad las causas de los mismos. La Gestin de Cambios aportar documentacin sobre las propuestas de cambio llegadas desde la fase de Mejora Continua del Servicio, tanto si han sido preaprobadas como si se han desechado. La informacin relativa a las posibles consecuencias del error, que puede proporcionar al Centro de Servicios la posibilidad de anticiparse al cliente.
La Gestin del Conocimiento es la encargada, por ltimo, de centralizar toda esta informacin en un repositorio denominado Sistema de Gestin del Conocimiento del Servicio (SKMS).
Pgina 75
Garantizar que el personal hace uso de las herramientas, tanto para registrar como para consultar los datos disponibles. Evaluar los datos recogidos, velando por que estn permanentemente actualizados. Analizar las necesidades de informacin de ciertos departamentos y coordinar la correcta transferencia de conocimiento desde aquellos que poseen los datos.
Estas funciones requieren, de quienes desempean las labores de Gestin del Conocimiento, un entendimiento profundo de los procesos que se desarrollan en la organizacin, as como una constante monitorizacin del registro, organizacin y aprovechamiento de los datos.
Pgina 76
Definir una estrategia de Gestin del Conocimiento y difundirla a toda la organizacin TI. Ayudar a la transferencia de conocimiento entre personas, equipos y departamentos. Gestionar la informacin y los datos para garantizar su calidad y utilidad. Uso del SKMS.
Pgina 77
Una serie de polticas generales referentes a los datos: qu registrar, cundo hacerlo, cmo estructurar los datos, etc. Las condiciones de administracin: qu clase de informacin es susceptible de ser corregida o eliminada. Los roles: quin registra la informacin, quin la revisa, quin la valida, quienes la pueden consultar libremente. Procedimientos de registro, revisin y validacin de la informacin.
Pgina 78
Detectar las necesidades de conocimiento existentes en la organizacin, tanto a nivel particular como grupal. Conocer en todo momento quin o quines poseen esa informacin. Establecer el canal adecuado para que los propietarios del conocimiento puedan transferirlo a quienes lo necesitan: seminarios, anuncios, boletn, peridico
Pgina 79
Iniciar y gestionar procesos de borrado de informacin. Determinar la periodicidad de las revisiones. Detectar y subsanar incoherencias en los datos registrados.
Pgina 80
Gobierno de TI: Cartera de Servicios, informes, CSI, Riesgos y otras cuestiones. Calidad: Polticas, procesos, procedimientos, formularios, plantillas, listas de comprobacin. Servicios: Catlogo de Servicios, SPs, informes del servicio. Activos y Configuracin: Activo financiero, informacin del CMS, informes de estado, datos de la CMDB, fuentes definitivas. Centro de Servicios / Soporte: Catlogo de Servicios, clientes, usuarios, grupos de inters, CIs, incidencias, problemas, cambios, entregas, rendimiento de las configuraciones.
Pgina 81
Implementacin satisfactoria de servicios, nuevos y modificados, sin un nmero considerable de errores relacionados con el conocimiento Aumento del conocimiento en el grupo objetivo Mayor nmero de preguntas con respuesta Menor dependencia del personal para el conocimiento Identificacin/localizacin ms rpida de informacin de diagnstico sobre incidencias y problemas Menor duracin del Soporte Post-Implantacin Tiempos ms cortos de resolucin de problemas Mejor experiencia de los usuarios Menos informes innecesarios de errores, debido a una mejor orientacin de la transferencia de conocimiento Uso de la base de conocimiento y nivel de reutilizacin de la documentacin Errores detectados por el personal o en una auditora Participacin del personal en foros de discusin y de preguntas y respuestas Grado de reutilizacin del material documentado Satisfaccin con los cursos, boletines, notas en la web, etc.
Pgina 82
Como apoyo a los procesos involucrados en la fase de transicin. Como requisito para la implementacin de los propios cambios.
La fase de transicin puede ser intrnsecamente compleja en organizaciones con una fuerte dependencia tecnolgica. La organizacin del workflow, las pruebas y la generacin de toda la documentacin asociada al cambio requieren por regla general disponer de herramientas de apoyo que permitan:
Gestionar adecuadamente la base de datos de configuracin y activos del servicio para asegurar que est refleja en todo momento una instantnea actualizada de la infraestructura TI. Gestionar el versionado de los servicios. Gestionar de forma gil y flexible toda la documentacin generada. Acceder rpidamente a todo el conocimiento necesario. Supervisar las pruebas realizadas sobre calidad y rendimiento de los nuevos servicios. Supervisar el despliegue de los nuevos servicios. Mantener puntualmente informados a todos los agentes participantes en esta fase de transicin.
Por otro lado es imprescindible que la infraestructura TI disponga de la tecnologa adecuada para la prestacin de los servicios nuevos o modificados. Aunque esto pueda parecer una verdad de perogrullo es habitual que organizaciones TI reactivas no afronten actualizaciones tecnolgicas necesarias hasta que stas se hacen imperativas por una clara degradacin del servicio. Habitualmente nuevos servicios requieren actualizaciones de hardware y software que impidan una degradacin de la calidad cuando estos se ven forzados a sus lmites de capacidad. Normalmente estas actualizaciones desembocan en procesos de cambio secundarios que es necesario analizar, planificar y supervisar de igual manera y con los mismos niveles de exigencia.
Pgina 83
Pgina 84
Pgina 85
A su vez la fase de Transicin debe asesorar al Diseo sobre los riesgos y posibles impactos del cambio en la calidad del servicio.
Pgina 86
El entorno de produccin El conocimiento asociado (incidencias, percepcin de clientes y usuarios) a servicios similares a los que se han de desplegar. Toda la documentacin necesaria asociada al uso y mantenimiento de los nuevos o actualizados servicios. La informacin relativa a los procesos de prueba y evaluacin.
Pgina 87
Pgina 88
Pregunta 1 El objetivo del proceso de Gestin del Cambio es descrito con mayor precisin como? Garantizar que todos los cambios se registran, gestionan, prueban y se aplican de una manera controlada Velar por que los cambios en la infraestructura de TI se gestionan de manera eficiente y eficaz Velar por que todos los cambios tienen planes adecuados de marcha atrs en caso de fall Proteger Servicios al no permitir que se hagan cambios
Pregunta 2 Considere las siguientes declaraciones: Cul es correcta? 1. Transicin del Servicio proporciona orientacin sobre los servicios nuevos y modificados en la produccin 2. Transicin del Servicio proporciona orientacin sobre las pruebas 3. Transicin del Servicio proporciona orientacin sobre la transferencia de servicios hacia o desde un proveedor de servicios externos Cul de las afirmaciones anteriores es correcta? 1 y 2 slo 1 solo Todas las anteriores 1 y 3 slo
Pregunta 3 Cul de los siguientes es objetivo del proceso de Gestin de la Versin y del Despliegue? 1. Garantizar que hay versiones claras y planes de despliegue 2. Garantizar que las habilidades y conocimientos se transfieren a las operaciones y personal de apoyo 3. Garantizar que existe un impacto de imprevistos mnimo en los servicios de produccin
Pgina 89
Pregunta 4 Cul de las siguientes afirmaciones describe completamente el objetivo de la Gestin de la versin y del Despliegue? Para crear, probar y ofrecer la capacidad de proporcionar los servicios especificados en el Diseo del Servicio y que cumplir los requisitos de los interesados y entregados conforme a los objetivos previstos A fin de garantizar que cada paquete de la versin especificada por el Diseo del Servicio consiste en un conjunto de activos y componentes de servicio que son compatibles entre s Asegurar que todos las versiones y paquetes desplegados puedan ser rastrear, instalados, probados, verificados y / o desinstalar o anulado en su caso Para grabar y gestionar las desviaciones, los riesgos y cuestiones relacionadas con los servicios nuevos o modificados
Pregunta 5 Cul de las siguientes afirmaciones es correcta? La Gestin de la Configuracin del Sistema (CMS) es parte de la BBDD de Errores Conocidos (KEDB) El Sistema de Gestin del Conocimiento del Servicio (SKMS) forma parte de la CMS El KEDB y la CMS forman parte de la ms grande SKMS El CMS es parte de la BBDD de Gestin de la Configuracin (CMDB)
Pregunta 6
Pgina 90
Las consecuencias del cambio como limitado, importante, significativo, etc La velocidad con la que se hace el cambio La secuencia en la que se hace el cambio El nmero de Solicitud de Cambio que se asigna al cambio
Pregunta 7 Qu representa el "Modelo de servicio V"? Una estrategia para la finalizacin con xito de todos los proyectos de gestin de servicios El camino de la Prestacin del Servicios y Apoyo(Soporte) del Servicio para el uso eficiente y eficaz de los recursos Los niveles de las pruebas necesarias para ofrecer una Capacidad del Servicio La perspectiva de negocio segn lo percibido por el cliente y el usuario de los servicios
Pregunta 8 Cul es el papel del Comit de Cambios de Emergencia (ECAB)? Asistir al Gestor de Cambios para asegurar que los cambios urgentes no se hacen durante los perodos de negocios particularmente voltiles Asistir al Gestor de Cambios en la implementacin de Cambios de Emergencia Asistir al Gestor de Cambios en la evaluacin de los Cambios de Emergencia y decidir si el cambio debe ser aprobado Asistir al Gestor de Cambios en la aceleracin del Proceso de Cambio de Emergencia para que no se producen retrasos inaceptables
Pgina 91
Pregunta 10 Cul es el uso del modelo RACI? Documentacin de los roles y las relaciones de los interesados en un proceso o actividad Definir los requisitos para un nuevo servicio o proceso Analizar el impacto empresarial de una Incidencia Creacin de un Cuadro de Mando Integral que muestra el estado global de la Gestin del Servicio
Pgina 92