MODULO 02 Transicion de Servicios Service Transition V.1.0.0.A PDF

CURSO DE CERTIFICACION DE ITIL FOUNDATION
ITIL V3

T
TTr
rra
aan
nns
ssi
iic
cci
ii
n
nn d
dde
ee S
SSe
eer
rrv
vvi
iic
cci
iio
oos
ss
(
((S
SSe
eer
rrv
vvi
iic
cce
ee T
TTr
rra
aan
nns
ssi
iit
tti
iio
oon
nn)
))
MODULO
2

Fundamentos de ITIL Versin 3 - Transicin de Servicios

1
Transicin de Servicios (Service
Transition)

ontinuando con la formacin y ya establecidos los conceptos generales nos prestamos
a abordar la "Transicin de Servicios" o "Service Transition", comencemos.

C


2

4. Service Transition
4.1. Service Transition en el Ciclo de Vida de los Servicios
4.1.1. Metas

'La gestin y coordinacin de procesos, sistemas y funciones para
construir, armar paquetes, testear, instalar, liberar y poner en produccin el
servicio especificado en los requerimientos

Las Metas de Service Transition son:
Establecer las expectativas de los clientes sobre como puede ayudar al negocio
el uso de un servicio nuevo o modificado.
Habilitar la integracin de releases con los procesos de negocio.
Reducir las variaciones en la performance de los servicios que se encuentran en
un proceso de transicin.
Reducir los riesgos y errores durante la transicin.
Asegurar la usabilidad de los Servicios de acuerdo a los requerimientos y
limitaciones especificados.

4.1.2. Objetivos

Los Objetivos de Service Transition son:
Gestionar de los Recursos para llevar a produccin los servicios nuevos o
modificados en forma exitosa de acuerdo a los costos, tiempos y niveles de
calidad estimados.
Minimizar el impacto en el ambiente productivo.
Incrementar la satisfaccin de la experiencia de la transicin (instalacin,
comunicaciones, documentacin, capacitacin y transferencia de
conocimientos).
Enfatizar el uso correcto de los servicios, aplicaciones y tecnologas
subyacentes.
Alinear los cambios en los proyectos con los planes de transicin de los
servicios.


3


4
4.1.3. Valor para el Negocio

El valor para el Negocio de Service Transition es:
La habilidad para adaptarse rpidamente a los nuevos requerimientos y
cambios en el mercado. Adaptabilidad = ventaja competitiva
Facilita las fusiones, adquisiciones y transferencias de los servicios
Aumenta el porcentaje de cambios y releases exitosos
Mejora la Prediccin de los niveles de servicios y garantas
Da confianza respecto al Cumplimiento de todos los requerimientos
relacionados con las normas durante los cambios
Disminuye la variacin entre los recursos estimados, aprobados y actuales
Aumenta la productividad del personal del cliente y del negocio por el mejor
uso de los nuevos servicios
Ayuda a la Transicin de los contratos en el tiempo correcto
Mejora la Gestin de los Riesgos


5
4.2. Conceptos y Definiciones Generales
4.2.1. tem de Configuracin (CI, Configuration Item)

Un tem de configuracin es un activo, componente de un servicio u otro tem, el
cual est o estar bajo el control de la Gestin de la Configuracin.

4.2.2. Sistema para la Gestin de la Configuracin (CMS, Config. Mgmt
System)

El CMS administra toda la informacin de los CIs que se encuentran dentro del
alcance. Algunos de estos tems tendrn archivos o especificaciones relacionadas
que contendrn la informacin del tem, como ser software, documentos, fotos,
etc. Por ejemplo, un CI puede incluir detalles como ser:
Proveedor
Costo
Fecha de compra
Fecha de renovacin de licencias
Contratos de mantenimiento
Documentacin relacionada (SLAs, UCs, etc.).

La figura 4-1 muestra el tipo de informacin que un CMS administra para los
CI que almacena.


6

Figura 4-1
4.2.3. Librera Definitiva de Medios (DML, Definitive Media Library)

La DML es una librera segura que almacena y protege las versiones
definitivas autorizadas de todos los CIs.
Almacena copias maestras de las versiones que pasaron las revisiones de
seguridad y consiste una o ms libreras de software, reas de almacenamiento
de archivos, y dems, separadas de las reas de desarrollo, test y produccin.
Contiene copias maestras de todo el software controlado en la organizacin,
incluyendo copias definitivas del software controlado (con la documentacin y
licencias) como tambin del software desarrollado internamente.
Tambin se almacenan en la DML en formato electrnico las copias maestras
de los documentos controlados de los sistemas.

4.2.4. Cambios de Servicios

La adicin, modificacin, o retiro de un servicio o componente junto con su
documentacin asociada que se encuentra autorizado, planificado o
soportado.
Los cambios a los servicios se realizan por pedido de los procesos de Service
Design, Continual Service Improvement y Service Level Management.


7
Los cambios correctivos, que resuelven los errores detectados en los servicios,
son iniciados en Service Operations, y pueden ser solicitados va soporte o
proveedores externos a travs de un RFC formal.

4.2.5. Tipos de Cambios

NORMAL
Un cambio en un servicio que no se encuentra pre-aprobado.

ESTANDAR (Pre-Autorizado)
Un cambio a un servicio o a la infraestructura pre-autorizado por la Gestin de Cambios
con un procedimiento establecido y aceptado que genera un cambio especfico a un
requerimiento.

EMERGENCIA
Un cambio a un servicio destinado a reparar un error (Vulnerabilidad) en un servicio de TI
que puede llegar a afectar negativamente el negocio con consecuencias importantes.
o Los Cambios que introducen cambios requeridos en forma urgente por
el negocio, se deben manejar como cambios normales, a los cuales se les
debe asignar la mxima prioridad.
o Los cambios de Emergencia a veces son requeridos y deben ser
diseados y probados muy cuidadosamente antes de usarlos dado que el
impacto de estos cambios puede llegar a ser mayor que el del incidente
original.
o La cantidad de cambios de emergencia propuestos debiera de ser
mnima, porque generalmente son disruptivos y tienden a generar
nuevas fallas.
o Los cambios de emergencia generalmente se documentan luego de su
implementacin.

4.2.6. Unidad de Release

Una Unidad de Release describe las partes de un servicio o infraestructura de TI
que son normalmente liberadas conjuntamente de acuerdo a las polticas de
liberacin de la organizacin. La unidad puede variar, dependiendo del tipo o
tems de activos de servicios o componentes del servicio como ser software o
hardware.

La figura 4-2 muestra un ejemplo simplificado de un servicio de TI compuesto
por activos de servicios y sistemas, los cuales se forman a travs de los
componentes de servicio.


8

Figura 4-2

4.2.7. Gestin del Cambio: Las 7 Rs

Se deben contestar las siguientes preguntas para todos los cambios. Sin esta
informacin, la evaluacin de impacto no puede ser completada, y no se
comprender el balance entre los riesgos y beneficios del servicio, lo que puede
resultar en que el cambio no produzca todos los beneficios posibles o esperados
para el negocio, o que pueda haber efectos negativos o no deseados en el ambiente
productivo:
Who RAISED the change? (Quin elev el cambio?)
What is the REASON for the change? (Cul es la razn del cambio?)
What is the RETURN required from the change? (Cuales son los beneficios
requeridos por el cambio?)
What are the RISKS involved in the change? (cules son los riesgos
involucrados en el cambio?)
What resources are REQUIRED to deliver the change? (Qu recursos se
requieren para poder satisfacer el cambio?)
Who is RESPONSIBLE for the build, test and implementation of the change?
(Quin es responsable por la construccin, prueba e implementacin del
cambio?)
What is the RELATIONSHIP between this change and other changes? (Cul
es la relacin entre este cambio y otros cambios?)


9
4.3. Principios y Modelos Clave
4.3.1. El Modelo V de Servicios

De acuerdo al modelo V de servicios, la planificacin de la validacin y test de
aceptacin debiera de comenzar junto con la definicin de los requerimientos de
servicio: Los clientes que acuerden y firmen los requerimientos de servicio tambin
debern firmar los criterios de aceptacin y plan de testeo del servicio.

Figura 4-3

El enfoque del modelo V (Figura 4-3) tradicionalmente se asocia con el ciclo
de vida en cascada, pero es aplicable a otros ciclos de vida, incluyendo
aquellos iterativos, como el prototipado o RAD.
Lado izquierdo: La especificacin de los requerimientos de servicio
llevadas hasta el diseo detallado del servicio.
Lado derecho: Se focaliza en las actividades de validacin que se ejecutan
para las especificaciones definidas en el lado izquierdo.
A cada etapa de la izquierda le corresponde una equivalente de la derecha.

En cada uno de los ciclos del desarrollo iterativo, pueden aplicar los
conceptos del modelo V de establecer requerimientos de aceptacin para los
requerimientos y diseo, donde se considerar cada iteracin de acuerdo al
grado de integridad y competencia que puede justificar el liberar versiones
para el cliente a fin de realizar pruebas o evaluaciones.


10

Acrnimos usados en la figura 4-3

o SLP - Service Level Package: (Service Strategy) Un nivel definido de Utilidad y
Garanta para un Paquete de servicios particular. Cada SLP es diseado para
cumplir con las necesidades especficas del Modelo de la Actividad del Negocio
(PBA, Pattern of Business Activity)

o SDP - Service Design Package: (Service Design) Documenta todos los aspectos que
definen el servicio de TI y sus requerimientos a travs de cada etapa de su ciclo de
vida. Se produce un SDP para cada nuevo servicio de TI, para cada cambio
importante, o para cuando se retira un Servicio de TI

o SPI - Service Provider Interface: (Service Strategy) Una interfase entre el Proveedor de
Servicios de TI y el usuario, cliente, proceso del negocio, o proveedor. El anlisis de
estas interfases ayuda a coordinar la gestin completa de los servicios de TI.

o SLR - Service Level Requirement: (Service Design y Continual Service Improvement)
El requerimiento de un cliente sobre un aspecto de un servicio de TI. Los SLRs se
basan en los objetivos del negocio y se usan para negociar los objetivos de los acuerdos
de niveles de servicio.


11
4.4. Procesos de Service Transition
4.4.1. Gestin del Cambio (Change Management)

Objetivo

Garantizar que los cambios se registren, evalen, autoricen, prioricen, planifiquen,
testeen, implementen, documenten y revisen de una forma controlada.

Alcance

El alcance del proceso de Gestin del Cambio abarca los cambios a la lnea base de
Activos de Servicio (Cartera de Servicios) e tems de Configuracin (CMDB) a lo
largo de todo el Ciclo de Vida de los Servicios. La organizacin debiera definir los
cambios que se encuentren fuera del alcance de su proceso de gestin del cambio,
como ser:
Cambios con impactos mayores al de los cambios de servicios (organizacin
departamental, polticas, operaciones del negocio): pueden producir RFC que
generen los consecuentes cambios en los servicios.
Cambios a nivel operacional como ser la reparacin de impresoras y otras
rutinas de servicios de componentes.

La figura 4-3 muestra el alcance tpico para el proceso de gestin del cambio de
servicios dentro de un departamento de TI y las interfases con el negocio y los
proveedores a los niveles estratgico, tctico y operacional.

Figura 4-3

Conceptos Bsicos


12

Polticas y Estndares

Para definir a los proveedores internos y externos lo que se debe hacer,
incluyendo las consecuencias de la no adherencia a las polticas, performance,
estndares, etc. Son reglas que proveen una cultura y un ambiente que soporta
el proceso.

Requerimientos de cumplimiento estatutario

Adherencia a las leyes locales y nacionales, cdigos de prctica, estndares y
prcticas organizacionales.

Eliminar cambios no autorizados

Por razones de efectividad y eficiencia, pero tambin por razones legales

Convenciones de nombres y numeraciones para los Cambios

Define los criterios de identificacin y clasificacin respecto a:
o Identificadores de documentos de Cambios
o Tipos de documentos de Cambio, plantillas de documentacin de cambio,
y contenido esperado.
o Impacto, urgencia, prioridades

Organizacin, Roles y Responsabilidades

o Acontabilidad y Responsabilidades de todos los stakeholders
o Procedimientos de Testing evaluacin posterior
o Definicin de reglas de autorizacin para los Cambios (y su integracin
con las herramientas de trabajo correspondientes)
o Crear la Junta de Asesoramiento para los Cambios (CAB, Change
Advisory Board) y la de Emergencia (ECAB)

Stakeholders

o Involucrados en la planificacin y preparacin
o Se les da aviso va el Calendario de Cambios y los planes de Releases

Agrupamiento de Cambios

o Tratar de consolidar varios cambios en uno mayor referenciando varios


13
RFCs a un RFC maestro.
o Mayor eficiencia y una percepcin ms positiva del lado del cliente

Procedimientos
o Autorizacin de los cambios (polticas, reglas y procedimientos)
o Elevar el Pedido de Cambio (RFC, Request for Change)
o Realizar seguimiento del RFC
o Investigar y evaluar el RFC
o Identificar Dependencias e incompatibilidades entre los cambios
o Verificacin la implementacin del cambio
o Evaluacin de los Entregables
o Revisin del proceso de Cambio para identificar tendencias y
oportunidades de mejora

Incidentes relacionados con los cambios

o Mantener informado sobre los cambios al Service Desk (va la agenda de
cambios).
o Interfase entre la gestin de cambios, releases y configuracin con los
procesos de gestin de incidentes y problemas para medir y reducir los
incidentes relacionados con los cambios.

Nota: Los trminos Forward Schedule of Change de la versin 2 y
Change Schedule de la versin 3 son equivalentes.

Interfases con la Gestin de la Configuracin

o Provee informacin de calidad para hacer una evaluacin del Impacto y
reportes (comparando la configuracin actual con la planificada)
o Identificar CIs de alto riesgo y de alto impacto
o Para capturar lneas base de configuraciones de los CI, CIs y releases

Actividades del Proceso (Resumen)
En resumen, la Gestin de cambios involucra las siguientes actividades:
Planificacin y Control de Cambios
Agenda de Cambios y releases
Comunicaciones
Decisiones y autorizaciones de los Cambios
Asegurarse que existan Planes correctivos
Mediciones y control


14
Reportes de Gerencia
Comprensin del Impacto del Cambio
Mejora Continua

Actividades del Proceso (para gestionar cambios puntuales)

Las actividades tpicas que se desarrollan para gestionar un cambio se ilustran en la
figura 4-4

Figura 4-4

Los pasos se listan a continuacin:
Crear y registrar cambio
Revisar RFC y propuesta para el cambio
Filtrar los cambios (aquellos incompletos, mal enviados o inviables)


15
Valoracin y evaluacin del cambio
o Establecer el nivel apropiado de autoridad para el cambio
o Establecer las reas de inters relevantes (quien debiera de participar en
la reunin del CAB)
o Evaluar la justificacin del negocio, costos, impacto, beneficios y riesgo
del cambio.
o Requerir (en caso de ser necesario) una evaluacin independiente del
cambio.
Autorizacin
o Obtener la autorizacin o rechazo.
o Comunicar la decisin a todos los stakeholders, incluyendo al iniciador
del RFC.
Actualizacin de Planes
Coordinar la Implementacin del Cambio
Revisin y cierre
o Reunir toda la documentacin relacionada con el cambio.
o Revisar el cambio y la documentacin pertinente.
o Cerrar el cambio cuando se hayan completado todas las acciones.

Mtricas Clave

La mayor parte de las siguientes mtricas y medidas se pueden descomponer por
categora, divisin organizacional, geografa, proveedor, etc.

Medidas para las Salidas
o Cantidad de errores, problemas, incidentes e interrupciones causadas
por cambios incorrectos.
o Cantidad de especificaciones inadecuadas y Evaluaciones de impacto
incompletas
o Cambios no autorizados
o Porcentaje de reduccin (cambios no autorizados, o tiempos, esfuerzos
y costos de los cambios)
o Porcentaje de mejora (predicciones de tiempos, esfuerzos y costos)
o Retrabajo requerido por especificaciones de cambios inadecuadas.

Carga de Trabajo
o Frecuencia de los cambios (por servicio, rea de negocio, etc.)
o Cantidad de Cambios

Medidas del Proceso
o Satisfaccin de la gente con la velocidad, claridad o facilidad de uso
o Cantidad y porcentaje de cambios que usan el proceso formal de
cambios
o ndice: Planificados vs. no planificados (urgente, emergencia)


16
o ndice: Aceptados vs. rechazados (RFCs)
o Cantidad de RFCs registrados usando herramientas automticas
o Tiempo para completar un cambio (desde el inicio a la completitud)
o Utilizacin del personal
o Costos versus presupuesto

Desafos

Caso todos los procesos de negocio y servicios se basan en TI, por lo cual
existen grandes grupos de clientes y stakeholders involucrados por Service
Transition.
Hay muchas interfases y relaciones de contacto para ser administradas por
Service Transition (Clientes, usuarios, programas, proyectos, proveedores y
partners)
Hay muy poca integracin de procesos y disciplinas que impactan en Service
Transition (Gestin de finanzas, ingeniera, recursos humanos).
Las diferencias y dependencias desconocidas entre los sistemas legacy, la
nueva tecnologa y los elementos humanos pueden incrementar el riesgo de
los cambios.
Alcanzar un balance entre mantener un ambiente estable de produccin y
dar respuesta a las necesidades del negocio para modificar los servicios.
Alcanzar un balance entre el pragmatismo y la burocracia.
Crear un ambiente que fomente la estandarizacin, simplificacin y
compartir los conocimientos.
Ser un facilitador del cambio en el negocio, y por ende, un componente
integral de los programas de cambio del negocio.
Establecer lderes para manejar los cambios y mejoras.
Establecer quien esta haciendo que, cuando y donde y quien debera
estar haciendo que, cuando y donde.
Desarrollar una Cultura que anime a las personas a colaborar y trabajar
efectivamente en conjunto (una atmsfera que fomente los cambios
culturales requeridos para los cambios en las personas)
Desarrollar mtodos de mediciones estndar para todos los proyectos y
proveedores.
Garantizar que la calidad de las entregas y el soporte se condicen con el uso
de la nueva tecnologa por parte del negocio.
Garantizar que el tiempo de transicin de los servicios y su presupuesto no
se vea impactado por eventos tempranos del ciclo de vida de los servicios


17
(Ej.: recortes al presupuesto)
Entender las diferentes perspectivas de los stakeholders que soportan la
gestin efectiva de los riesgos dentro de una organizacin.
Entender y evaluar el balance entre gestionar y tomar riesgos, y su efecto en
la estrategia global de la organizacin.
Evaluar la efectividad del reporte en relacin con la gestin de riesgos y
gobernabilidad corporativa.

4.4.1.1 Roles

Change Manager

Las tareas principales del Change Manager, algunas de las cuales pueden ser delegadas, se
listan a continuacin:
RFCs: recibir, registrar y determinar prioridades (Rechazar los incompletos
y los impracticables)
RFCs: Administracin de las reuniones del CAB
CAB: Participante
Llama a reuniones urgentes del CAB o ECAB
Dirige las reuniones de CAB y ECAB
Luego de CAB o ECAB: autoriza o rechaza
Arma la Agenda de Cambios, que enva luego al SD
Coordina desarrollos, testeos e implementaciones
Actualiza el registro de cambios
Revisa los cambios implementados
Revisa los RFCs principales
Analiza los registros de cambios (tendencias / problemas)
Cierra RFCs
Genera reportes de Gestin

Autoridad para el Cambio

Se debe obtener una autorizacin formal para cada cambio desde la autoridad para
el cambio.
Los niveles de autorizacin se debieran juzgar de acuerdo al tipo, tamao o
riesgo del cambio.
La autoridad delegada puede existir con un nivel de autorizacin, por
ejemplo, delegando la autoridad al Change manager de acuerdo a un


18
conjunto preacordado de parmetros relacionados con:
o Riesgo para el Negocio.
o Implicancias financieras.
o Alcance del cambio.

La figura 4-5 muestra un ejemplo de jerarqua de autorizacin (CAM, Change
Authorization Model)

Figura 4-5

Change Advisory Board (CAB)
El CAB es un cuerpo de consejo que requiere trminos de referencia apropiados
(encuentros peridicos, alcance de la influencia, y conexiones con la Gestin de
Programas).

Es importante resaltar que el CAB:
Estar compuesto de acuerdo a los cambios que se consideran en la
reunin, y puede variar considerablemente incluso en el transcurso de una
misma reunin.
Debiera involucrar a los proveedores cuando sea til
Debiera reflejar tanto la mirada del usuario como la del cliente
Suele incluir a:
o Problem Manager
o Service Level Manager
o Personal de relaciones con el cliente


19

4.4.2. Gestin de los Activos de Servicio y Config. (Service Asset & Conf.
Mngmt)

Objetivo

Definir y controlar los componentes de Servicios e Infraestructura para mantener
los registros precisos de la configuracin existente.

Esto permite a la organizacin:
El cumplimiento de los requerimientos de Gobernabilidad corporativa
Controlar la Base de Activos
Optimizar costos
Permite realizar cambios y releases en forma efectiva
Ayuda a ser ms expeditivo en la resolucin de incidentes y problemas

Conceptos Bsicos

El modelo lgico
La gestin de la configuracin brinda un modelo lgico requerido de los
servicios, activos y de la infraestructura mediante el registro de las relaciones
entre los CI (ver Figura 4-6).

Figura 4-6

El poder del modelo lgico es que es EL modelo: una nica representacin
comn usada por todas las partes de ITSM.


20

Categoras de CI

Alguna documentacin definir las caractersticas de un CI mientras que
otra documentacin va a ser un CI propiamente dicho que debe ser
controlado. Existe una gran variedad de CIs: Por ejemplo:

o CIs del Ciclo de Vida del Servicio provee una imagen de los servicios
brindados por los proveedores de servicios, como se prestarn esos
servicios, cuales son los beneficios esperados, a que costo, cuando se
realizarn, e incluirn el caso de negocio, planes de gestin del servicio,
planes del ciclo de vida del servicio, SDP, planes de Cambios, releases,
testeo, etc.

o CIs de Servicios como ser:
- Activos de Capacidad de los Servicios: gestin, organizacin, procesos,
conocimiento, gente.
- Activos de los Recursos de los Servicios: capital para financiacin, sistemas,
aplicaciones, informacin, datos, infraestructura y ubicaciones, capital financiero,
gente.
- Modelo de Servicio
- Paquete de Servicio
- Paquete de Release
- Criterio de Aceptacin del Servicio

o CIs de la Organizacin como ser la estrategia de negocio de la
organizacin, otras polticas internas (independientes del proveedor de
servicio), requerimientos regulatorios o estatutarios aplicables.

o CIs Internos provistos por proyectos individuales, incluyendo activos
tangibles (como centros de cmputos) o intangibles (como el software)
requeridos para entregar y mantener el servicio y la infraestructura.

o CIs Externos como los requerimientos y acuerdos externos del cliente,
releases de los proveedores o subcontratistas y servicios externos.

Sistema de Gestin de la Configuracin (CMS, Configuration
Management System)
El CMS contiene toda la informacin relacionada con la Gestin de la
Configuracin y los Activos de Servicios para el alcance acordado.
(discutido previamente en el prrafo 1.6.8: ver la figura 4-7 como recordatorio)


21

Figura 4-7

Alguno de estos tems tendr especificaciones o archivos relacionados que
contendrn los contenidos de esos tems, por ejemplo software,
documentacin, fotografas (la figura 4-8 simplemente ilustra esas
relaciones).

Por ejemplo, un CI de Servicio incluir los detalles como ser el proveedor,
costo, fecha de compra y de renovacin de las licencias y del
mantenimiento, y la documentacin relacionada como ser SLAs y UCs.

Figura 4-8

Libreras Seguras

Un conjunto de CIs compuestos de software, documentos o electrnicos de
un tipo y estado comn usados para controlar y liberar componentes a lo
largo del Ciclo de Vida del Servicio (diseo, construccin, test, instalacin y
operacin). El acceso a la librera segura es restringido.


22
Depsitos Seguros

Una ubicacin fsica donde se almacenan los activos de TI y que juega un
papel importante en la provisin de seguridad y continuidad.

Librera Definitiva de Medios (DML, Definitive Media Library)

Librera segura en la cual se almacenan y protegen todas las versiones
definitivas autorizadas de todos los CIs electrnicos.

Piezas de repuesto (Spares) definitivas

Almacenamiento seguro de las piezas de repuesto de hardware
(componentes mantenidos al mismo nivel que el existente en los sistemas de
produccin)

Lnea base de Configuracin (Configuration Baseline)

La configuracin de un servicio, producto o infraestructura que ha sido
formalmente revisada y acordada, y que sirve como la base para actividades
futuras, que solamente puede cambiarse a travs de los procedimientos
formales de cambios.

Estado actual de Configuracin (Snapshot)

El estado actual de los tems de configuracin en un ambiente registrados
en el CMS como un registro histrico fijo.

La figura 4-9 muestra los conceptos de DML y Base de datos para la Gestin de
la Configuracin (CMDB, Configuration Management Database).


23

Figura 4-9
4.4.2.1 Roles

Service Asset Manager

Trabaja en pos de los objetivos generales acordados con el Gerente de Servicios de
TI; Implementa las polticas y estndares para la Gestin de Activos de Servicios,
que incluye:
Sistemas de Gestin de Activos: Evala los existentes, y disea,
implementa y gestiona los sistemas nuevos o mejorados para la efectividad y
eficiencia; incluyendo las tareas de planificacin de trabajo y recursos,
monitoreo y reportes de avance respecto a lo planificado, etc.
Establece los procesos, planes estndar y procedimientos para la
Gestin de Activos: Acuerda alcances, tems y funciones ser controladas, y
la informacin que se registrar.
Promueve el conocimiento: Realiza campaas para generar adherencia a
los nuevos procedimientos, asegurando que los cambios a los mtodos y
procesos se aprueben y comuniquen adecuadamente al personal antes de ser
implementados.
Staffing del Personal: Gestiona el reclutamiento y capacitacin del
personal.
Herramientas para la Gestin de Activos: Evala herramientas
propietarias y recomendaciones para cumplir con los requerimientos de
presupuesto, recursos, tiempos, y especificaciones tcnicas.
Administra e Implementa los procesos, principios y planes de Gestin
de Activos.


24
Convenciones de nombres y CIs: Acuerda que los activos (CIs) sean
identificados de manera nica mediante una convencin de nombres que
garantiza el cumplimiento de estndares para tipos de objetos, ambientes,
procesos, ciclos de vida, documentacin, versiones, formatos, lneas base,
releases y plantillas.
Define interfases: propone y/o acuerda las interfases con Change
Management, Problem Management, Network Management, Release
Management, logstica, finanzas y administracin.
Libreras, herramientas y bases de datos para los Activos: Planifica la
forma de llenar la base de datos de Activos, y la administra asegurando su
mantenimiento.
Reportes: Provee reportes del tipo gerencial, de anlisis de impacto, y del
estado de los activos.
Crecimiento y Cambios: Inicia las acciones necesarias para obtener los
fondos necesarios para permitir mejorar la infraestructura y niveles del
personal.
Gobernabilidad: Ayuda a los auditores para las actividades de auditora
correspondiente, y asegura que se ejecuten las acciones correctivas
recomendadas.

Configuration Manager

Trabaja en pos de los objetivos generales acordados con el Gerente de Servicios de
TI; Implementa las polticas y estndares para la Gestin de la Configuracin, lo
que incluye:
Sistemas de Gestin de la Configuracin: Evala los existentes, y disea,
implementa y gestiona los sistemas nuevos o mejorados para la efectividad y
eficiencia; incluyendo las tareas de planificacin de trabajo y recursos,
monitoreo y reportes de avance respecto a lo planificado, etc.
Establece los procesos, planes estndar y procedimientos para la
Gestin de la Configuracin: Acuerda alcances, tems y funciones ser
controladas, y la informacin que se registrar.
Promueve el conocimiento: Realiza campaas para generar adherencia a
los nuevos procedimientos para la Gestin de la Configuracin, asegurando
que los cambios a los mtodos y procesos se aprueben y comuniquen
adecuadamente al personal antes de ser implementados.
Staffing del Personal: Gestiona el reclutamiento y capacitacin del
personal.
Herramientas para la Gestin de la Configuracin: Evala herramientas
propietarias y recomendaciones para cumplir con los requerimientos de
presupuesto, recursos, tiempos, y especificaciones tcnicas.
Administra e Implementa los procesos, principios y planes de Gestin
de la Configuracin.


25
Define interfases: propone y/o acuerda las interfases con Change
Management, Problem Management, Network Management, Release
Management, logstica, finanzas y administracin.
Libreras, herramientas y bases de datos para la Gestin de la
Configuracin: Planifica la forma de llenar la base de datos del CMS, y la
administra asegurando su mantenimiento.
Reportes: Provee reportes del tipo gerencial, de anlisis de impacto, y del
estado de la configuracin.
Crecimiento y Cambios: Inicia las acciones necesarias para obtener los
fondos necesarios para permitir mejorar la infraestructura y niveles del
personal.
Gobernabilidad: Ayuda a los auditores para las actividades de auditora
correspondiente, y asegura que se ejecuten las acciones correctivas
recomendadas.

Configuration Analyst

Propone el Alcance de los procesos de Gestin de la Configuracin y
de los Activos, de las funciones, e tems que sern controlados; y la
informacin que ser registrada. Desarrolla los estndares, planes y
procedimientos para la Gestin de la Configuracin y los Activos.
Capacita: a especialistas en Gestin de la Configuracin y Activos y a otro
personal en cuanto a los principios, procesos y procedimientos relacionados
con la Gestin de Configuraciones y Activos.
Participa en la planificacin e implementacin de SACM
Participa en la definicin de procesos y procedimientos de SACM:
asegura que estn incluidos en los procedimientos y planes los roles y
responsabilidades correctas para la Gestin de Configuraciones y Activos.
Libreras, herramientas y bases de datos para la Gestin de la
Configuracin: Trabaja con el Configuration Administrator/Librarian para
llenar la base de datos del CMS, y la administra asegurando su
mantenimiento.
Interfase con la Gestin de Cambios: permite el acceso al CMS para


26
facilitar el anlisis de impacto de los RFCs, para asegurar que los cambios a
implementar se realicen de acuerdo a lo planificado. Crea registros de
cambios, lneas base de configuracin, y registros de paquetes de releases
para especificar el efecto de un cambio aprobado en los CIs. Garantiza que
CMS est actualizado despus de aplicar cualquier cambio.
Auditoras: Ejecuta auditoras de la configuracin para chequear que el
inventario fsico de TI es consistente con la informacin en el CMS e inicia
las acciones correctivas necesarias.
Crea y actualiza las libreras de los Proyectos y sistemas de CM:
Verifica los tems y grupos de tems en las herramientas de CM.
Lneas Base:
o Acepta productos de terceros
o Crea las lneas base internas para releases
Mantiene el estado de los proyectos y genera reportes
Monitorea (potenciales) problemas y mantiene la base de datos para
almacenamiento y extraccin de reportes de mtricas.

Configuration Administrator/Librarian

El Configuration Administrator/Librarian es el Custodio y guardin de las copias
maestras del software, activos y documentacin de los CIs, e informacin que se
encuentra registrada en el SACM. Las tareas principales son:
Controlar el ingreso, identificacin, almacenamiento, y retiro de todos los
CIs soportados.
Proveer informacin del estado de los CIs
Numerar, registrar, almacenar y distribuir los temas relacionados con la
Gestin de la Configuracin y Activos.

CMS / Tools Administrator

Evala herramientas para la Gestin de la Configuracin y Activos, y
recomienda aquella que mejor cumple con los requisitos de la organizacin
en cuanto a presupuesto, recursos, tiempos y especificaciones tcnicas. Una
vez adquirida, administra la herramienta de SACM en cuanto a la gestin de
la base de datos, customizacin, flujos de trabajo y reportes.
Monitorea la Performance y capacidad de los sistemas de SACM y
recomienda mejoras.
Realiza la administracin tcnica y soporte de la herramienta.
Garantiza la Integridad y operatividad de los sistemas de CM.


27

Configuration Control Board

El Configuration Control Board se requiere para garantizar que las polticas de
Gestin de la Configuracin se utilizan a lo largo de todo el Ciclo de Vida de la
Gestin de Servicios. Tiene las siguientes responsabilidades:
Define la lnea base de los servicios en trminos de aplicaciones,
informacin, servicios, infraestructura, que garantizarn que se cumplan con
los requerimientos establecidos en la fase de Service Design.
Revisa los cambios en la configuracin de los servicios para garantizar su
cumplimiento en cuanto a los requerimientos contractuales e internos.
Genera requerimientos de cambios para que la configuracin de los
servicios cumpla con los requerimientos de cambio a los contratos.

4.4.3. Release & Deployment Management

Objetivos

Establecer planes de liberacin e instalacin (release and deployment) claros y
completos para garantizar que los cambios que se generan en los proyectos del
negocio y los clientes estn alineados con estas actividades.
Permitir la construccin, instalacin, testeo y puesta en produccin del
paquete liberado en los tiempos acordados.
Brindar un nuevo servicio (o modificado) de acuerdo a los requerimientos
acordados.
Garantizar la Transferencia de conocimiento a los clientes y usuarios para
optimizar el uso del servicio para soportar las actividades de su negocio.
Garantizar la Transferencia de conocimiento y habilidades al personal de
soporte y operaciones para que ellos puedan mantener en forma efectiva y
eficiente el servicio de acuerdo a los niveles de servicio y garanta
requeridos.
Minimizar impactos negativos no planificados en los servicios en
produccin.
Mejorar el grado de Satisfaccin de los Stakeholders

Conceptos Bsicos


28
Big Bang versus fases

o Big-bang: El servicio nuevo o modificado se instala en todas las reas
en una sola operacin, esto se debe hacer cuando se necesita
consistencia del servicio a lo largo de toda la organizacin.

o Fases: El servicio se instala a un subconjunto de la base de usuarios, y
luego esta operacin se repite para los subsiguientes conjuntos de
usuarios de acuerdo a un plan de implementacin (roll out) establecido
previamente (Figura 4-10).

Figura 4-10

Push y Pull

Para implementar con el enfoque push, se debe contar con toda la
informacin de todos los usuarios. El enfoque pull no necesita esa
informacin, ya que ser el usuario quien comenzar la descarga. Dado que
algunos usuarios pueden llegar a no descargar nunca estos archivos, luego
de un tiempo especificado, se podra establecer una estrategia push para
todos esos usuarios que no hayan actualizado sus versiones.

o El enfoque PUSH es aquel en el cual el componente de servicio es
implementado desde un lugar central y enviado a todos los destinos
predefinidos. En trminos de implementacin de servicios, el envo de
una actualizacin a todos los usuarios (ya sea a travs de un big-bang o
por fases) es una estrategia push, ya que el usuario no elige cuando
actualizar el componente en su ambiente.

o El enfoque PULL se usa cuando el release de software se pone a
disposicin del usuario en una ubicacin especfica, pero es el usuario
quien decide cuando instalarlo, o bien, cuando se reinicia la estacin de


29
trabajo.

Automatizacin versus Manual

Los mecanismos para liberar e implementar componentes de servicio que
estn correctamente configurados debieran de estar establecidos en la fase
de diseo y testeados en las etapas de construccin y pruebas de los
servicios nuevos o modificados.

o La Automatizacin ayuda a garantizar la repetitividad y consistencia.
El tiempo requerido para proveer un mecanismo automtico eficiente y
bien diseado es largo y muchas veces no es viable.

o Si se usa un mecanismo Manual es importante verificar y medir el
impacto de repetir actividades manuales muchas veces, ya que esto lleva
a ineficiencias y a cometer errores. Muchas actividades manuales harn
bajar la productividad del equipo y crearn temas relacionados con la
capacidad y los recursos que afectarn los niveles de servicio.

Testing: Paquetes de Release y Release

o La figura 4-11 muestra las dependencias lgicas correspondientes al
proceso donde uno comienza la construccin y release basndose en la
arquitectura de la infraestructura, pasando por la arquitectura de la
aplicacin, y luego por la arquitectura de los servicios y el nivel de la
arquitectura del negocio.


30

Figura 4-11

o La figura 4-12 muestra donde aplica la fase LAB/Test en este flujo de
alto nivel.

Figura 4-12


31
4.4.3.1 Roles

Release and Deployment Manager

El Release and Deployment manager es responsable de la planificacin, diseo,
construccin, configuracin y testeo del software o hardware necesario para la
creacin de un paquete de release para la provisin de, o cambio a, un Servicio
especfico.
El Release and Deployment Manager reportar al Service Transition Manager
como tambin lo har el Service Test Manager; sin embargo, estos roles siempre
deben ser tomados por distintas personas, nunca combinados, para garantizar que
haya un testeo y una verificacin independiente.
Sus responsabilidades abarcan:
Gestionar el proceso de releases de punta a punta
Actualizar los sistemas SKMS y SACM/CMDB
Coordinar los equipos para construir, testear y liberar
Generar reportes de avance:
o Diseo, construccin y configuracin de los paquetes
o Aceptacin de los Releases
o Planificacin de la puesta en produccin (Rollout)
o Testeo de los Releases
o Firmas de Aceptacin
o Comunicacin y entrenamiento
o Auditora del Pre-release
o Instalacin del Hardware
o Almacenamiento del Software para su trazabilidad y auditora
o Release, distribucin e Instalacin

Release Packaging and Build Management

Release Packaging and Build management es el flujo de trabajo (establece los
requerimientos, diseos, construccin, testeo, implementacin, operacin y
optimizacin) para proveer aplicaciones e infraestructuras que cumplan con los
requerimientos de diseo de los Servicios.

Las responsabilidades principales del Release Packaging and Build Manager son:
Establece la configuracin final de los releases (Ej.: Conocimiento,
informacin, hardware, software e infraestructura).
Construye la versin final del release a entregar
Testea la versin final antes del testeo independiente
Establece y reporta los errores conocidos ms importantes y sus
workarounds
Brinda informacin para la firma de la aceptacin de la implementacin


32

Deployment
Deployment es responsable por las siguientes actividades:
Entrega fsica final
Coordina documentacin y comunicaciones incluyendo la capacitacin y las
notas finales para el usuario, gestin del servicio y administracin.
Brinda gua y soporte tcnico y de las aplicaciones
Provee Feedback
Registra las mtricas para los SLA


33

Esta pgina ha sido dejada en blanco intencionalmente


34

Piensa como trabajas, en el anlisis final, tu valor para la compaa
no solo viene de solucionar problemas, sino tambin de anticiparlos.

(Harold Ross)


35

Esta pgina ha sido dejada en blanco intencionalmente


36
ITIL es una marca registrada de Office of Government Commerce, y se encuentra registrada en la oficina de
marcas y patentes de Estados Unidos.

El Swirl logo es una marca registrada de Office of Government Commerce

MODULO 02 Transicion de Servicios Service Transition V.1.0.0.A PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

MODULO 02 Transicion de Servicios Service Transition V.1.0.0.A PDF

Cargado por

Copyright:

Formatos disponibles

CURSO DE CERTIFICACION DE ITIL FOUNDATION

También podría gustarte