You are on page 1of 37

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® Versión 3 - Transición de Servicios


1
Transición de Servicios (Service
Transition)

ontinuando con la formación y ya establecidos los conceptos generales nos prestamos
a abordar la "Transición de Servicios" o "Service Transition", comencemos.

C


Fundamentos de ITIL® Versión 3 - Transición de Servicios


2

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


'La gestión y coordinación de procesos, sistemas y funciones para
construir, armar paquetes, testear, instalar, liberar y poner en producción 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 integración de releases con los procesos de negocio.
• Reducir las variaciones en la performance de los servicios que se encuentran en
un proceso de transición.
• Reducir los riesgos y errores durante la transición.
• 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 producción 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 satisfacción de la experiencia de la transición (instalación,
comunicaciones, documentación, capacitación y transferencia de
conocimientos).
• Enfatizar el uso correcto de los servicios, aplicaciones y tecnologías
subyacentes.
• Alinear los cambios en los proyectos con los planes de transición de los
servicios.



Fundamentos de ITIL® Versión 3 - Transición de Servicios


3



Fundamentos de ITIL® Versión 3 - Transición de Servicios


4
4.1.3. Valor para el Negocio


El valor para el Negocio de Service Transition es:
• La habilidad para adaptarse rápidamente 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 Predicción de los niveles de servicios y garantías
• Da confianza respecto al Cumplimiento de todos los requerimientos
relacionados con las normas durante los cambios
• Disminuye la variación 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 Transición de los contratos en el tiempo correcto
• Mejora la Gestión de los Riesgos




Fundamentos de ITIL® Versión 3 - Transición de Servicios


5
4.2. Conceptos y Definiciones Generales
4.2.1. Ítem de Configuración (CI, Configuration Item)



Un ítem de configuración es un activo, componente de un servicio u otro ítem, el
cual está o estará bajo el control de la Gestión de la Configuración.







4.2.2. Sistema para la Gestión de la Configuración (CMS, Config. Mgmt
System)



El CMS administra toda la información de los CIs que se encuentran dentro del
alcance. Algunos de estos ítems tendrán archivos o especificaciones relacionadas
que contendrán la información del ítem, como ser software, documentos, fotos,
etc. Por ejemplo, un CI puede incluir detalles como ser:
• Proveedor
• Costo
• Fecha de compra
• Fecha de renovación de licencias
• Contratos de mantenimiento
• Documentación relacionada (SLAs, UCs, etc.).

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




Fundamentos de ITIL® Versión 3 - Transición de Servicios


6

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



La DML es una librería 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 más librerías de software, áreas de almacenamiento
de archivos, y demás, separadas de las áreas de desarrollo, test y producción.
• Contiene copias maestras de todo el software controlado en la organización,
incluyendo copias definitivas del software controlado (con la documentación y
licencias) como también del software desarrollado internamente.
• También se almacenan en la DML en formato electrónico las copias maestras
de los documentos controlados de los sistemas.



4.2.4. Cambios de Servicios



La adición, modificación, o retiro de un servicio o componente junto con su
documentación 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.



Fundamentos de ITIL® Versión 3 - Transición de Servicios


7
• Los cambios correctivos, que resuelven los errores detectados en los servicios,
son iniciados en Service Operations, y pueden ser solicitados vía soporte o
proveedores externos a través 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 Gestión de Cambios
con un procedimiento establecido y aceptado que genera un cambio específico 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 máxima prioridad.
o Los cambios de Emergencia a veces son requeridos y deben ser
diseñados 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
mínima, porque generalmente son disruptivos y tienden a generar
nuevas fallas.
o Los cambios de emergencia generalmente se documentan luego de su
implementación.

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 políticas de
liberación de la organización. 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 través de los
componentes de servicio.





Fundamentos de ITIL® Versión 3 - Transición de Servicios


8

Figura 4-2


4.2.7. Gestión del Cambio: Las 7 R’s



Se deben contestar las siguientes preguntas para todos los cambios. Sin esta
información, la evaluación 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? (¿Quién elevó el cambio?)
• What is the REASON for the change? (¿Cuál es la razón 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? (¿cuáles 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?
(¿Quién es responsable por la construcción, prueba e implementación del
cambio?)
• What is the RELATIONSHIP between this change and other changes? (¿Cuál
es la relación entre este cambio y otros cambios?)






Fundamentos de ITIL® Versión 3 - Transición de Servicios


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


De acuerdo al modelo V de servicios, la planificación de la validación y test de
aceptación debiera de comenzar junto con la definición de los requerimientos de
servicio: Los clientes que acuerden y firmen los requerimientos de servicio también
deberán firmar los criterios de aceptación 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 especificación de los requerimientos de servicio
llevadas hasta el diseño detallado del servicio.
• Lado derecho: Se focaliza en las actividades de validación 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 aceptación para los
requerimientos y diseño, donde se considerará cada iteración de acuerdo al
grado de integridad y competencia que puede justificar el liberar versiones
para el cliente a fin de realizar pruebas o evaluaciones.



Fundamentos de ITIL® Versión 3 - Transición de Servicios


10

Acrónimos usados en la figura 4-3

o SLP - Service Level Package: (Service Strategy) Un nivel definido de Utilidad y
Garantía para un Paquete de servicios particular. Cada SLP es diseñado para
cumplir con las necesidades específicas 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 través 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 análisis de
estas interfases ayuda a coordinar la gestión 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.




Fundamentos de ITIL® Versión 3 - Transición de Servicios


11
4.4. Procesos de Service Transition
4.4.1. Gestión del Cambio (Change Management)



Objetivo

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



Alcance

El alcance del proceso de Gestión del Cambio abarca los cambios a la línea base de
Activos de Servicio (Cartera de Servicios) e Ítems de Configuración (CMDB) a lo
largo de todo el Ciclo de Vida de los Servicios. La organización debiera definir los
cambios que se encuentren fuera del alcance de su proceso de gestión del cambio,
como ser:
• Cambios con impactos mayores al de los cambios de servicios (organización
departamental, políticas, operaciones del negocio): pueden producir RFC que
generen los consecuentes cambios en los servicios.
• Cambios a nivel operacional como ser la reparación de impresoras y otras
rutinas de servicios de componentes.

La figura 4-3 muestra el alcance típico para el proceso de gestión del cambio de
servicios dentro de un departamento de TI y las interfases con el negocio y los
proveedores a los niveles estratégico, táctico y operacional.



Figura 4-3


Conceptos Básicos




Fundamentos de ITIL® Versión 3 - Transición de Servicios


12

• Políticas y Estándares

Para definir a los proveedores internos y externos lo que se debe hacer,
incluyendo las consecuencias de la no adherencia a las políticas, performance,
estándares, 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, códigos de práctica, estándares y
prácticas organizacionales.


• Eliminar cambios no autorizados

Por razones de efectividad y eficiencia, pero también por razones legales


• Convenciones de nombres y numeraciones para los Cambios

Define los criterios de identificación y clasificación respecto a:
o Identificadores de documentos de Cambios
o Tipos de documentos de Cambio, plantillas de documentación de cambio,
y contenido esperado.
o Impacto, urgencia, prioridades

• Organización, Roles y Responsabilidades

o Acontabilidad y Responsabilidades de todos los stakeholders
o Procedimientos de Testing evaluación posterior
o Definición de reglas de autorización para los Cambios (y su integración
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 planificación y preparación
o Se les da aviso vía el Calendario de Cambios y los planes de Releases

• Agrupamiento de Cambios

o Tratar de consolidar varios cambios en uno mayor referenciando varios


Fundamentos de ITIL® Versión 3 - Transición de Servicios


13
RFCs a un RFC maestro.
o Mayor eficiencia y una percepción más positiva del lado del cliente

• Procedimientos
o Autorización de los cambios (políticas, 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 Verificación la implementación del cambio
o Evaluación de los Entregables
o Revisión 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 (vía la agenda de
cambios).
o Interfase entre la gestión de cambios, releases y configuración con los
procesos de gestión de incidentes y problemas para medir y reducir los
incidentes relacionados con los cambios.


Nota: Los términos “Forward Schedule of Change” de la versión 2 y
“Change Schedule” de la versión 3 son equivalentes.

• Interfases con la Gestión de la Configuración

o Provee información de calidad para hacer una evaluación del Impacto y
reportes (comparando la configuración actual con la planificada)
o Identificar CIs de alto riesgo y de alto impacto
o Para capturar líneas base de configuraciones de los CI, CIs y releases



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


Fundamentos de ITIL® Versión 3 - Transición de Servicios


14
• Reportes de Gerencia
• Comprensión del Impacto del Cambio
• Mejora Continua


Actividades del Proceso (para gestionar cambios puntuales)

Las actividades típicas que se desarrollan para gestionar un cambio se ilustran en la
figura 4-4


Figura 4-4

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


Fundamentos de ITIL® Versión 3 - Transición de Servicios


15
• Valoración y evaluación del cambio
o Establecer el nivel apropiado de autoridad para el cambio
o Establecer las áreas de interés relevantes (quien debiera de participar en
la reunión del CAB)
o Evaluar la justificación del negocio, costos, impacto, beneficios y riesgo
del cambio.
o Requerir (en caso de ser necesario) una evaluación independiente del
cambio.
• Autorización
o Obtener la autorización o rechazo.
o Comunicar la decisión a todos los stakeholders, incluyendo al iniciador
del RFC.
• Actualización de Planes
• Coordinar la Implementación del Cambio
• Revisión y cierre
o Reunir toda la documentación relacionada con el cambio.
o Revisar el cambio y la documentación pertinente.
o Cerrar el cambio cuando se hayan completado todas las acciones.



Métricas Clave

La mayor parte de las siguientes métricas y medidas se pueden descomponer por
categoría, división organizacional, geografía, 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 reducción (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 Satisfacción 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)


Fundamentos de ITIL® Versión 3 - Transición de Servicios


16
o Índice: Aceptados vs. rechazados (RFCs)
o Cantidad de RFCs registrados usando herramientas automáticas
o Tiempo para completar un cambio (desde el inicio a la completitud)
o Utilización del personal
o Costos versus presupuesto


Desafíos

• 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 integración de procesos y disciplinas que impactan en Service
Transition (Gestión de finanzas, ingeniería, recursos humanos).
• Las diferencias y dependencias desconocidas entre los sistemas legacy, la
nueva tecnología y los elementos humanos pueden incrementar el riesgo de
los cambios.
• Alcanzar un balance entre mantener un ambiente estable de producción 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 estandarización, simplificación 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 líderes para manejar los cambios y mejoras.
• Establecer “quien esta haciendo que, cuando y donde” y “quien debería
estar haciendo que, cuando y donde”.
• Desarrollar una Cultura que anime a las personas a colaborar y trabajar
efectivamente en conjunto (una atmósfera que fomente los cambios
culturales requeridos para los cambios en las personas)
• Desarrollar métodos de mediciones estándar para todos los proyectos y
proveedores.
• Garantizar que la calidad de las entregas y el soporte se condicen con el uso
de la nueva tecnología por parte del negocio.
• Garantizar que el tiempo de transición de los servicios y su presupuesto no
se vea impactado por eventos tempranos del ciclo de vida de los servicios


Fundamentos de ITIL® Versión 3 - Transición de Servicios


17
(Ej.: recortes al presupuesto)
• Entender las diferentes perspectivas de los stakeholders que soportan la
gestión efectiva de los riesgos dentro de una organización.
• Entender y evaluar el balance entre gestionar y tomar riesgos, y su efecto en
la estrategia global de la organización.
• Evaluar la efectividad del reporte en relación con la gestión 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 continuación:
• RFCs: recibir, registrar y determinar prioridades (Rechazar los incompletos
y los impracticables)
• RFCs: Administración 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 envía 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 Gestión



Autoridad para el Cambio

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



Fundamentos de ITIL® Versión 3 - Transición de Servicios


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

La figura 4-5 muestra un ejemplo de jerarquía de autorización (CAM, Change
Authorization Model)


Figura 4-5


Change Advisory Board (CAB)
El CAB es un cuerpo de consejo que requiere términos de referencia apropiados
(encuentros periódicos, alcance de la influencia, y conexiones con la Gestión de
Programas).

Es importante resaltar que el CAB:
• Estará compuesto de acuerdo a los cambios que se consideran en la
reunión, y puede variar considerablemente incluso en el transcurso de una
misma reunión.
• 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



Fundamentos de ITIL® Versión 3 - Transición de Servicios


19

4.4.2. Gestión 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 configuración existente.

Esto permite a la organización:
• 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 más expeditivo en la resolución de incidentes y problemas

Conceptos Básicos

• El modelo lógico
La gestión de la configuración brinda un modelo lógico 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 lógico es que es EL modelo: una única representación
común usada por todas las partes de ITSM.



Fundamentos de ITIL® Versión 3 - Transición de Servicios


20



• Categorías de CI

Alguna documentación definirá las características de un CI mientras que
otra documentación 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 prestarán esos
servicios, cuales son los beneficios esperados, a que costo, cuando se
realizarán, e incluirán el caso de negocio, planes de gestión 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: gestión, organización, procesos,
conocimiento, gente.
- Activos de los Recursos de los Servicios: capital para financiación, sistemas,
aplicaciones, información, datos, infraestructura y ubicaciones, capital financiero,
gente.
- Modelo de Servicio
- Paquete de Servicio
- Paquete de Release
- Criterio de Aceptación del Servicio

o CIs de la Organización como ser la estrategia de negocio de la
organización, otras políticas internas (independientes del proveedor de
servicio), requerimientos regulatorios o estatutarios aplicables.

o CIs Internos provistos por proyectos individuales, incluyendo activos
tangibles (como centros de cómputos) 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 Gestión de la Configuración (CMS, Configuration
Management System)
El CMS contiene toda la información relacionada con la Gestión de la
Configuración y los Activos de Servicios para el alcance acordado.
(discutido previamente en el párrafo 1.6.8: ver la figura 4-7 como recordatorio)



Fundamentos de ITIL® Versión 3 - Transición de Servicios


21

Figura 4-7

Alguno de estos ítems tendrá especificaciones o archivos relacionados que
contendrán los contenidos de esos ítems, por ejemplo software,
documentación, fotografías (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 renovación de las licencias y del
mantenimiento, y la documentación relacionada como ser SLAs y UCs.


Figura 4-8

• Librerías Seguras

Un conjunto de CIs compuestos de software, documentos o electrónicos de
un tipo y estado común usados para controlar y liberar componentes a lo
largo del Ciclo de Vida del Servicio (diseño, construcción, test, instalación y
operación). El acceso a la librería segura es restringido.




Fundamentos de ITIL® Versión 3 - Transición de Servicios


22
• Depósitos Seguros

Una ubicación física donde se almacenan los activos de TI y que juega un
papel importante en la provisión de seguridad y continuidad.


• Librería Definitiva de Medios (DML, Definitive Media Library)

Librería segura en la cual se almacenan y protegen todas las versiones
definitivas autorizadas de todos los CIs electrónicos.


• 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
producción)


• Línea base de Configuración (Configuration Baseline)

La configuración 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 través de los procedimientos
formales de cambios.


• Estado actual de Configuración (Snapshot)

El estado actual de los ítems de configuración en un ambiente registrados
en el CMS como un registro histórico fijo.

La figura 4-9 muestra los conceptos de DML y Base de datos para la Gestión de
la Configuración (CMDB, Configuration Management Database).



Fundamentos de ITIL® Versión 3 - Transición de Servicios


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 políticas y estándares para la Gestión de Activos de Servicios,
que incluye:
• Sistemas de Gestión de Activos: Evalúa los existentes, y diseña,
implementa y gestiona los sistemas nuevos o mejorados para la efectividad y
eficiencia; incluyendo las tareas de planificación de trabajo y recursos,
monitoreo y reportes de avance respecto a lo planificado, etc.
• Establece los procesos, planes estándar y procedimientos para la
Gestión de Activos: Acuerda alcances, ítems y funciones ser controladas, y
la información que se registrará.
• Promueve el conocimiento: Realiza campañas para generar adherencia a
los nuevos procedimientos, asegurando que los cambios a los métodos y
procesos se aprueben y comuniquen adecuadamente al personal antes de ser
implementados.
• Staffing del Personal: Gestiona el reclutamiento y capacitación del
personal.
• Herramientas para la Gestión de Activos: Evalúa herramientas
propietarias y recomendaciones para cumplir con los requerimientos de
presupuesto, recursos, tiempos, y especificaciones técnicas.
• Administra e Implementa los procesos, principios y planes de Gestión
de Activos.



Fundamentos de ITIL® Versión 3 - Transición de Servicios


24
• Convenciones de nombres y CIs: Acuerda que los activos (CIs) sean
identificados de manera única mediante una convención de nombres que
garantiza el cumplimiento de estándares para tipos de objetos, ambientes,
procesos, ciclos de vida, documentación, versiones, formatos, líneas base,
releases y plantillas.
• Define interfases: propone y/o acuerda las interfases con Change
Management, Problem Management, Network Management, Release
Management, logística, finanzas y administración.
• Librerías, 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 análisis 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 auditoría
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 políticas y estándares para la Gestión de la Configuración, lo
que incluye:
• Sistemas de Gestión de la Configuración: Evalúa los existentes, y diseña,
implementa y gestiona los sistemas nuevos o mejorados para la efectividad y
eficiencia; incluyendo las tareas de planificación de trabajo y recursos,
monitoreo y reportes de avance respecto a lo planificado, etc.
• Establece los procesos, planes estándar y procedimientos para la
Gestión de la Configuración: Acuerda alcances, ítems y funciones ser
controladas, y la información que se registrará.
• Promueve el conocimiento: Realiza campañas para generar adherencia a
los nuevos procedimientos para la Gestión de la Configuración, asegurando
que los cambios a los métodos y procesos se aprueben y comuniquen
adecuadamente al personal antes de ser implementados.
• Staffing del Personal: Gestiona el reclutamiento y capacitación del
personal.
• Herramientas para la Gestión de la Configuración: Evalúa herramientas
propietarias y recomendaciones para cumplir con los requerimientos de
presupuesto, recursos, tiempos, y especificaciones técnicas.
• Administra e Implementa los procesos, principios y planes de Gestión
de la Configuración.


Fundamentos de ITIL® Versión 3 - Transición de Servicios


25
• Convenciones de nombres y CIs: Acuerda que los activos (CIs) sean
identificados de manera única mediante una convención de nombres que
garantiza el cumplimiento de estándares para tipos de objetos, ambientes,
procesos, ciclos de vida, documentación, versiones, formatos, líneas base,
releases y plantillas.
• Define interfases: propone y/o acuerda las interfases con Change
Management, Problem Management, Network Management, Release
Management, logística, finanzas y administración.
• Librerías, herramientas y bases de datos para la Gestión de la
Configuración: Planifica la forma de llenar la base de datos del CMS, y la
administra asegurando su mantenimiento.
• Reportes: Provee reportes del tipo gerencial, de análisis de impacto, y del
estado de la configuración.
• 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 auditoría
correspondiente, y asegura que se ejecuten las acciones correctivas
recomendadas.



Configuration Analyst

• Propone el Alcance de los procesos de Gestión de la Configuración y
de los Activos, de las funciones, e ítems que serán controlados; y la
información que será registrada. Desarrolla los estándares, planes y
procedimientos para la Gestión de la Configuración y los Activos.
• Capacita: a especialistas en Gestión de la Configuración y Activos y a otro
personal en cuanto a los principios, procesos y procedimientos relacionados
con la Gestión de Configuraciones y Activos.
• Participa en la planificación e implementación de SACM
• Participa en la definición de procesos y procedimientos de SACM:
asegura que estén incluidos en los procedimientos y planes los roles y
responsabilidades correctas para la Gestión de Configuraciones y Activos.
• Convenciones de nombres y CIs: Acuerda que los activos (CIs) sean
identificados de manera única mediante una convención de nombres que
garantiza el cumplimiento de estándares para tipos de objetos, ambientes,
procesos, ciclos de vida, documentación, versiones, formatos, líneas base,
releases y plantillas.
• Librerías, herramientas y bases de datos para la Gestión de la
Configuración: Trabaja con el Configuration Administrator/Librarian para
llenar la base de datos del CMS, y la administra asegurando su
mantenimiento.
• Interfase con la Gestión de Cambios: permite el acceso al CMS para


Fundamentos de ITIL® Versión 3 - Transición de Servicios


26
facilitar el análisis de impacto de los RFCs, para asegurar que los cambios a
implementar se realicen de acuerdo a lo planificado. Crea registros de
cambios, líneas base de configuración, y registros de paquetes de releases
para especificar el efecto de un cambio aprobado en los CIs. Garantiza que
CMS esté actualizado después de aplicar cualquier cambio.
• Auditorías: Ejecuta auditorías de la configuración para chequear que el
inventario físico de TI es consistente con la información en el CMS e inicia
las acciones correctivas necesarias.
• Crea y actualiza las librerías de los Proyectos y sistemas de CM:
Verifica los ítems y grupos de ítems en las herramientas de CM.
• Líneas Base:
o Acepta productos de terceros
o Crea las líneas 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 extracción de reportes de métricas.



Configuration Administrator/Librarian

El Configuration Administrator/Librarian es el Custodio y guardián de las copias
maestras del software, activos y documentación de los CIs, e información que se
encuentra registrada en el SACM. Las tareas principales son:
• Controlar el ingreso, identificación, almacenamiento, y retiro de todos los
CIs soportados.
• Proveer información del estado de los CIs
• Numerar, registrar, almacenar y distribuir los temas relacionados con la
Gestión de la Configuración y Activos.



CMS / Tools Administrator

• Evalúa herramientas para la Gestión de la Configuración y Activos, y
recomienda aquella que mejor cumple con los requisitos de la organización
en cuanto a presupuesto, recursos, tiempos y especificaciones técnicas. Una
vez adquirida, administra la herramienta de SACM en cuanto a la gestión de
la base de datos, customización, flujos de trabajo y reportes.
• Monitorea la Performance y capacidad de los sistemas de SACM y
recomienda mejoras.
• Realiza la administración técnica y soporte de la herramienta.
• Garantiza la Integridad y operatividad de los sistemas de CM.




Fundamentos de ITIL® Versión 3 - Transición de Servicios


27

Configuration Control Board

El Configuration Control Board se requiere para garantizar que las políticas de
Gestión de la Configuración se utilizan a lo largo de todo el Ciclo de Vida de la
Gestión de Servicios. Tiene las siguientes responsabilidades:
• Define la línea base de los servicios en términos de aplicaciones,
información, servicios, infraestructura, que garantizarán que se cumplan con
los requerimientos establecidos en la fase de Service Design.
• Revisa los cambios en la configuración de los servicios para garantizar su
cumplimiento en cuanto a los requerimientos contractuales e internos.
• Genera requerimientos de cambios para que la configuración de los
servicios cumpla con los requerimientos de cambio a los contratos.



4.4.3. Release & Deployment Management


Objetivos

Establecer planes de liberación e instalación (release and deployment) claros y
completos para garantizar que los cambios que se generan en los proyectos del
negocio y los clientes estén alineados con estas actividades.
• Permitir la construcción, instalación, testeo y puesta en producción 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 garantía
requeridos.
• Minimizar impactos negativos no planificados en los servicios en
producción.
• Mejorar el grado de Satisfacción de los Stakeholders



Conceptos Básicos




Fundamentos de ITIL® Versión 3 - Transición de Servicios


28
• Big Bang versus fases

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

o Fases: El servicio se instala a un subconjunto de la base de usuarios, y
luego esta operación se repite para los subsiguientes conjuntos de
usuarios de acuerdo a un plan de implementación (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
información de todos los usuarios. El enfoque ‘pull’ no necesita esa
información, 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 podría 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 términos de implementación de servicios, el envío de
una actualización a todos los usuarios (ya sea a través 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
disposición del usuario en una ubicación específica, pero es el usuario
quien decide cuando instalarlo, o bien, cuando se reinicia la estación de


Fundamentos de ITIL® Versión 3 - Transición de Servicios


29
trabajo.



• Automatización versus Manual

Los mecanismos para liberar e implementar componentes de servicio que
estén correctamente configurados debieran de estar establecidos en la fase
de diseño y testeados en las etapas de construcción y pruebas de los
servicios nuevos o modificados.

o La Automatización ayuda a garantizar la repetitividad y consistencia.
El tiempo requerido para proveer un mecanismo automático eficiente y
bien diseñado 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 harán
bajar la productividad del equipo y crearán temas relacionados con la
capacidad y los recursos que afectarán los niveles de servicio.




• Testing: Paquetes de Release y Release

o La figura 4-11 muestra las dependencias lógicas correspondientes al
proceso donde uno comienza la construcción y release basándose en la
arquitectura de la infraestructura, pasando por la arquitectura de la
aplicación, y luego por la arquitectura de los servicios y el nivel de la
arquitectura del negocio.




Fundamentos de ITIL® Versión 3 - Transición de Servicios


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





Fundamentos de ITIL® Versión 3 - Transición de Servicios


31
4.4.3.1 Roles




Release and Deployment Manager

El Release and Deployment manager es responsable de la planificación, diseño,
construcción, configuración y testeo del software o hardware necesario para la
creación de un paquete de release para la provisión de, o cambio a, un Servicio
específico.
El Release and Deployment Manager reportará al Service Transition Manager
como también 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 verificación 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 Diseño, construcción y configuración de los paquetes
o Aceptación de los Releases
o Planificación de la puesta en producción (Rollout)
o Testeo de los Releases
o Firmas de Aceptación
o Comunicación y entrenamiento
o Auditoría del Pre-release
o Instalación del Hardware
o Almacenamiento del Software para su trazabilidad y auditoría
o Release, distribución e Instalación


Release Packaging and Build Management

Release Packaging and Build management es el flujo de trabajo (establece los
requerimientos, diseños, construcción, testeo, implementación, operación y
optimización) para proveer aplicaciones e infraestructuras que cumplan con los
requerimientos de diseño de los Servicios.

Las responsabilidades principales del Release Packaging and Build Manager son:
• Establece la configuración final de los releases (Ej.: Conocimiento,
información, hardware, software e infraestructura).
• Construye la versión final del release a entregar
• Testea la versión final antes del testeo independiente
• Establece y reporta los errores conocidos más importantes y sus
workarounds
• Brinda información para la firma de la aceptación de la implementación




Fundamentos de ITIL® Versión 3 - Transición de Servicios


32

Deployment
Deployment es responsable por las siguientes actividades:
• Entrega física final
• Coordina documentación y comunicaciones incluyendo la capacitación y las
notas finales para el usuario, gestión del servicio y administración.
• Brinda guía y soporte técnico y de las aplicaciones
• Provee Feedback
• Registra las métricas para los SLA


Fundamentos de ITIL® Versión 3 - Transición de Servicios


33




Esta página ha sido dejada en blanco intencionalmente



Fundamentos de ITIL® Versión 3 - Transición de Servicios


34
















“Piensa como trabajas, en el análisis final, tu valor para la compañía
no solo viene de solucionar problemas, sino también de anticiparlos.”

(Harold Ross)


Fundamentos de ITIL® Versión 3 - Transición de Servicios


35




Esta página ha sido dejada en blanco intencionalmente



Fundamentos de ITIL® Versión 3 - Transición de Servicios


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