Documente Academic
Documente Profesional
Documente Cultură
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.
2 Procesos
Una vez definida una estrategia general y acordadas desde la fase de Diseo las
especificaciones sobre cmo se van a prestar los servicios, hay que ponerse manos a
la obra. La Planificacin y Soporte de la Transicin es la encargada de coordinar los
recursos de la organizacin TI para poner en marcha el servicio en el tiempo, calidad y
coste definidos previamente.
Sin embargo, no podemos concebir estas tareas de coordinacin como una realidad
paralela, independiente del resto del Ciclo de Vida. La Planificacin y Soporte de la
Transicin no podra ejercer su labor sin los inputs provenientes del resto de procesos:
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:
Para ello debe asegurarse de que todas las partes implicadas adoptan una metodologa
de trabajo comn, proporcionando un plan de transicin capaz de alinear el cambio con
las necesidades del cliente.
Una Peticin de Cambio o RFC es una peticin formal para efectuar modificaciones en
uno o ms CIs.
Revisin Post-Implantacin (PIR)
2.1.3 Procesos
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.
Para cada una de estas etapas deben definirse los siguientes aspectos:
Por ltimo, debe hacerse una revisin exhaustiva de los planes estratgicos una vez
terminados.
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
evolucin a mejor requiere necesariamente de un cambio.
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" (back-outs) en
caso de un incorrecto funcionamiento tras su implementacin.
Los principales beneficios derivados de una correcta gestin del cambio son:
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:
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.
Estos protocolos de cambio estndar deben ser cuidadosamente elaborados, pero una
vez definidos permiten una gestin ms rpida y eficiente de cambios menores o de bajo
impacto en la organizacin TI.
2.2.2 Procesos
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.
Fecha de recepcin.
Identificador nico de la RFC.
Identificador del error conocido asociado (dado el caso).
Descripcin del cambio propuesto:
Motivacin.
Propsito.
CIs involucrados.
Estimacin de recursos necesarios para la implementacin.
Tiempo estimado.
Estatus: que inicialmente ser el de "registrado".
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:
Aceptacin
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 modificacin si se considera que algunos aspectos de la misma
son susceptibles de mejora o mayor definicin. 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.
Clasificacin
Aunque el rango de posibles prioridades pueda ser tan amplio como se desee, se
debera considerar una clasificacin 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
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.
Los cambios menores pueden no necesitar la aprobacin del CAB y ser implementados
directamente. Cualquier otro cambio habr de ser discutido en el CAB y se habr de
solicitar la colaboracin de personal especializado para realizar tareas de
asesoramiento.
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:
En la fase de desarrollo del cambio se deber monitorizar el proceso para asegurar que:
Funcionalidad.
Usabilidad.
Accesibilidad.
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).
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 organizacin. Aunque la Gestin de Cambios es la
encargada de emitir el dictamen final, es la Evaluacin del servicio la que ha de
proporcionar a sta los informes.
Si la evaluacin final determina que el proceso y los resultados han sido satisfactorios,
se proceder al cierre de la y toda la informacin se incluir en la asociada.
Cualquier interrupcin del servicio de alto impacto, ya sea por el nmero de usuarios
afectados o porque se han visto involucrados sistemas o servicios crticos para la
organizacin, debe encontrar una respuesta inmediata. Es frecuente que la solucin 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 validacin de los cambios urgentes que pueden
requerir:
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 del ECAB).
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.
Para que estos informes ofrezcan una informacin precisa y de sencilla evaluacin, es
imprescindible elaborar mtricas de referencia que cubran aspectos tales como:
solicitados.
Porcentaje de aceptados y aprobados.
Nmero de cambios realizados clasificados por impacto y prioridad y filtrados
temporalmente.
Tiempo medio del cambio dependiendo del impacto y la prioridad.
Nmero de cambios de emergencia realizados.
Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.
Numero de back-outs con una detallada explicacin de los mismos.
Evaluaciones post-implementacin.
Porcentajes de cambios cerrados sin incidencias ulteriores.
Incidencias asociadas a cambios realizados.
Esto no es una labor sencilla y requiere la colaboracin de los Gestores de los otros
procesos, en particular, de la Gestin de Cambios y la de Entregables y Despliegues.
Las principales dificultades con las que topa la Gestin de la Configuracin y Activos TI
son:
A lo largo de este captulo hemos utilizado y utilizaremos con profusin conceptos tales
como elementos de configuracin (CI) y base de datos de Gestin de la Configuracin
y Activos TI (CMDB) es por lo tanto conveniente que nos detengamos para dar una
definicin precisa de ambos.
Elementos de configuracin: todos, tanto los componentes de los servicios TI como
los servicios que stos nos ofrecen, constituyen diferentes elementos de configuracin.
A modo de ejemplo citaremos:
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.
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.
2.3.2 Procesos
Alcance
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:
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.
2.3.2.3 Monitorizacin
Puede representar una ayuda para el anlisis el uso de herramientas de software que
ofrezcan representaciones visuales del ciclo de vida de los componentes, organizados
por diferentes filtros (tipo, fabricante, responsable, costes, etc.).
2.3.2.5 Auditoras
Existen herramientas que permiten una gestin remota, centralizada y automtica de los
elementos de configuracin de hardware y software. La informacin recopilada puede
ser utilizada para actualizar la CMDB.
Las complejas interrelaciones entre todos los elementos que componen una
infraestructura TI convierten en tarea delicada la implementacin de cualquier cambio.
Las principales dificultades con las que topa la Gestin de Entregas y Despliegues
son:
Una versin es un grupo de CIs de nueva creacin o modificados que han sido validados
para su instalacin en el entorno de produccin. Las especificaciones funcionales y
tcnicas de una versin estn determinadas en la RFC correspondiente.
Como pueden llegar a existir mltiples versiones, es conveniente definir una referencia
o cdigo que los identifique unvocamente. El sistema universalmente aceptado es:
Versin delta: slo se testean e instalan los elementos modificados. Esta opcin
tiene como ventaja su mayor simplicidad pero conlleva el peligro de que puedan
aparecer problemas e incompatibilidades en el entorno de produccin.
Versin completa: Se distribuyen todos los elementos afectados, ya hayan sido
modificados o no. Aunque esta opcin es obviamente ms trabajosa, es ms
improbable que se generen incidentes tras la instalacin si se han realizado las
pruebas pertinentes.
Paquete de Versiones: La Gestin de Cambios puede optar por distribuir de
forma sincronizada diferentes paquetes de versiones: de esta forma se ofrece
una mayor estabilidad al entorno TI. En algunos casos esta opcin es obligada
por incompatibilidades entre una nueva versin con software o hardware
previamente instalado. Pensemos, por ejemplo, en la migracin a un nuevo
sistema operativo que requiere hardware ms avanzado y/o nuevas versiones
de los programas ofimticos.
El almacn de Recambios Definitivos (DS) contiene piezas de repuesto para los CIs
en el entorno de produccin.
Los activos almacenados deben incorporarse a la CMDB en el caso de que los CIs
correspondientes se hallen registrados en la misma (esto puede depender del alcance
y nivel de detalle de la CMDB).
2.4.2 Procesos
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.
Qu tipo de despliegue es el ms adecuado: completo, delta, sincronizado en
todas 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.
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.
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.
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.
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.
Para que estos informes ofrezcan una informacin precisa y de sencilla evaluacin es
necesario elaborar mtricas de referencia que cubran aspectos tales como:
La Validacin y Pruebas del Servicio se relaciona con los siguientes procesos del Ciclo
de Vida:
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.
Para cumplir este cometido, la Validacin y Pruebas del Servicio se encarga de:
Los beneficios de una correcta Validacin y Pruebas del Servicio se resumen en:
2.5.1 Procesos
Es importante que las pruebas incluyan los planes de back-out para asegurarnos de que
se podr volver a la ltima versin estable de una forma rpida, ordenada y sin prdidas
de valiosa informacin.
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).
En esta etapa, la Validacin y Pruebas del Servicio se ocupa de recopilar todos los
componentes de la versin y de poner a punto el entorno de pruebas en las condiciones
necesarias para su correcto desarrollo.
La fiabilidad de las pruebas est condicionada al entorno en el que stas tienen lugar.
Si no es idntico al escenario real en que se desplegar el servicio nuevo o modificado,
los resultados de las pruebas se vern distorsionados y por tanto no servirn. De ah la
importancia de que el escenario de pruebas tenga:
Antes de dar comienzo a las pruebas, todos estos componentes son pre-testeados para
garantizar que slo participarn en ellas aquellos que cumplen con los ms estrictos
criterios de calidad.
En esta etapa del proceso se llevan a cabo las pruebas propiamente dichas: todos los
componentes, herramientas y mecanismos que participan en el despliegue, la migracin
y el back-out son examinados uno por uno. El desarrollo de las pruebas puede ser
automtico o manual.
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:
Por ltimo, se procede a la limpieza del entorno de pruebas, revirtiendo los cambios
incorporados durante los test (instalacin de aplicaciones, importacin de datos, etc.)
hasta la situacin inicial.
En esta ltima etapa, el equipo encargado de las pruebas revisa el planteamiento de las
mismas y verifica si la planificacin se cumpli conforme a los recursos, SACS y plazos
acordados. As, se detectan aspectos mejorables para perfeccionar el proceso.
2.6 Evaluacin
Sin embargo, a pesar de ser sta su funcin principal, la Evaluacin no debe concebirse
como una actividad puntual, sino como un proceso iterativo. Los informes preliminares
de rendimiento del servicio son tiles a la hora de planificar la transicin, pero han de
ser contrastados con informes posteriores una vez que stos han sido implantados.
La Evaluacin est estrechamente relacionada, por lo tanto, con otros procesos del Ciclo
de Vida, ya que de ellos recibe los inputs necesarios para elaborar sus informes:
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:
2.6.1 Procesos
Por lo general, suelen ser perjudiciales para el servicio y son difciles de medir: impacto
en los clientes/usuarios, sobrecarga de la red
Perfil de riesgos.
Reporte de desviaciones (rendimiento esperado vs. real).
Recomendaciones.
Control de calidad.
Una buena Gestin del Conocimiento ha de colaborar estrechamente con los procesos
de las otras fases del Ciclo de Vida para documentar y analizar:
Sin embargo, una organizacin puede tener las herramientas adecuadas para registrar
y organizar los datos, pero los buenos propsitos pueden no llegar a materializarse
nunca si no existe una unidad de Gestin del Conocimiento que impulse, coordine y
estructure el proceso para:
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.
Los beneficios obtenidos de una correcta Gestin del Conocimiento son numerosos:
Estructura DIKW
2.7.2 Procesos
Por otro lado, es tambin su labor instalar una cultura de aprendizaje constante entre
los miembros del personal. No slo se trata de hacer que los empleados registren los
datos, sino tambin motivarlos a que acudan a las fuentes de conocimiento para
completar aquello que no saben.
3 Puesta en marcha
3.1 Organizacin
Los cambios y los nuevos productos y servicios provocan con frecuencia los
consecuentes cambios organizativos.
Transferencia de personal
Reorganizaciones jerrquicas
Cambios procedimentales
Recapacitacin del personal
Todos estos cambios pueden ser percibidos positivamente por los miembros de la
organizacin TI o por el contrario pueden ser causa de tensiones internas y problemas
de carcter personal.
3.2 Tecnologa
Entre los factores de xito y retos a los que se debe confrontar la correcta
implementacin de la Fase de Transicin del Servicio se encuentran:
4 Glosario
5 Referencias
http://itilv3.osiatis.es
ITIL V3 Fundamentos