ITIL v3

Fundamentos
ITIL como una Buena Práctica
• ITIL (Information Technology Infraestructure Library) es un conjunto
de mejores prácticas para la gestión de servicios de TI.
• Las buenas prácticas son las mejores prácticas que han ganado
una amplia aceptación y adopción
• No es un estándar como ISO 20000
• Permite alinear los servicios TI con la estrategia del negocio.
• Componentes:
– Núcleo ITIL (5 publicaciones).
– Publicaciones complementarías (guía para sectores
específicos).
– Servicio Web de Soporte
– Guía de Bolsillo
Organizaciones que integran ITIL
• ITIL®ha sido desarrollada y es mantenida por la OGC (The Office
of Government Commerce) que es un organismo independiente
del gobierno de Gran Bretaña.
• La TSO (The Stationery Office) es quien publica oficialmente la
documentación ITIL®.
• El APM Group (APMG) es el acreditador oficial de ITIL®.
• El desarrollador oficial de los exámenes de acreditación ITIL®es el
Examination Institute for Information Science (EXIN)
Evolución de ITIL
• ITIL v3 se enfoca en el ciclo de vida del servicio
Ciclo de Vida del Servicio
• 5 fases:
– Estrategia del Servicio.
– Diseño del Servicio.
– Transición del Servicio.
– Operación del Servicio.
– Mejora Continua del Servicio

Fuente: marlonmolina.tecnofor.es/p/2008-2009.html
Fases del Ciclo de Vida del Servicio

Fase Objetivo
Crear servicios que se conviertan en activos estratégicos
Estrategia del
para la organización, y que acompañen los objetivos de la
Servicio
empresa, de esta forma entrega valor a la organización.
Diseñar el servicio cumpliendo con las especificaciones de
la Estrategia y con las posibilidades de la organización,
Diseño del
basándose en las plataformas disponibles y creando un
Servicio
paquete de diseño con las especificaciones para su
construcción (o modificación).
Construir servicios nuevos o modificar servicios existentes,
Transición del
tomando como entrada el paquete de diseño, y llevando los
Servicio
servicios hasta producción.
En esta fase se realizan las actividades del día a día para
Operación del
asegurar que los servicios se entregan con utilidad y
Servicio
garantía al cliente (usuario).
Es la fase donde se mide lo que tenemos y se descubren
Mejora Continua
las brechas que se pueden cubrir para mejorar el servicio y
del Servicio
los resultados del servicio
Servicio y Gestión del Servicio
• Servicio es un medio para entregar valor a los clientes
facilitándoles un resultado deseado sin la necesidad de que estos
asuman los costes y riesgos específicos asociados.
• Gestión de Servicios es un conjunto de capacidades organizativas
especializadas para la provisión de valor a los clientes en forma de
servicios.
• La gestión de servicios transforman recursos utilizando
capacidades en servicios de alto valor para el negocio a través de
procesos.
• Los servicios son soportados por procesos.
Funciones, Procesos y Roles
• ITIL diferencia cada una de estas definiciones:

– Función: Área o unidad de negocio especializada en la

realización de una uno o mas procesos o actividades.
– Proceso: Conjuntos de actividades para lograr un objetivo. Crean
valor. Son sistemas cerrados (retroalimentación)
Incluyen: Roles, responsabilidades, herramientas y controles de
gestión (medidas y métricas)
– Rol: Conjunto de responsabilidades y autoridades definidas en un
proceso y asignadas a una persona o equipo. Una persona o
equipo puede tener varios roles.

• Las funciones ejecutan procesos. Dentro de los procesos se definen

roles.
Característic. y Element. Proceso
• Características:
– Medible.
– Entrega resultado especifico.
– Entrega resultado a un cliente clave.
– Responde a un evento (disparador).

• Elementos:
 Control del
proceso
 Procesos
 Habilitadores
del proceso.
Roles Genéricos
• Dentro de los Roles genéricos, tenemos:
– Propietario/dueño del Servicio: Responsable ante el cliente
que el servicio cumpla su objetivo. Responsable de la calidad
del servicio,
– Propietario/dueño del Proceso: Responsable ante la
organización que el proceso cumpla su objetivo. Responsable
de la calidad del proceso.
– Gestor del proceso: Responsable de la gestión operacional del
proceso. Ejecuta actividades.
RACI
• RACI es una matriz de autoridad que asigna
responsabilidades entre roles y actividades.

• R – Responsible:
Responsable de la
ejecución. Usualmente
uno (pueden ser mas)
• A – Accountable:
Responsable del proceso
en conjunto. Toma
decisiones. Solo uno.
• C – Consulted: Da
algún tipo de entrada. Se
le pide consejo u opinión.
Varios.
• I – Informed: Recibe
alguna salida. Se informa
de los avances. Varios
RACI aplicado a ITIL
Procesos y Funciones del Ciclo de Vida

Procesos
22 procesos y 4 funciones Centro Servicios

G. Técnica
Funciones
G. Portafolio Planificación y
G. Aplicaciones
Servicios Soporte (*)
Validación y Pruebas
G. Nivel Servicios G. Operaciones
(*)

G. Disponibilidad Evaluación (*) G. Eventos

G. Capacidad G. Conocimiento (*) G. Incidentes

G. Cartera Servicios G. Seg. Información G. Cambio G. Peticiones

Activos Servicio y G.
G. Demanda G. Continuidad G. Problemas
Configurac.
G. Liberación y
G. Financiera G. Proveedores G. Accesos
Despliegue

Transición Del
Estrategia del Servicio Diseño del Servicio Operación del Servicio
Servicio

Mejora Continua del Servicio

7 Pasos de Proceso de Mejora Continua
Ciclo Deming
(*) Procesos no cubiertos como parte del examen de Fundamentos de ITIL v3
Estrategia del Servicio
Objetivo Estrategia del Servicio
• Su principal objetivo es convertir la Gestión del Servicio en
un activo estratégico.
• Debe determinar en primera instancia qué servicios deben
ser prestados y por qué han de ser prestados desde la
perspectiva del cliente y el mercado.
• Una correcta Estrategia del Servicio debe:
– Conocer el mercado y los servicios de la competencia.
– Armonizar la oferta con la demanda de servicios.
– Alinear los servicios ofrecidos con la estrategia de negocio.
– Crear casos de negocio para justificar inversiones estratégicas.
Creación de Valor
• El valor para el cliente está en el resultado del servicio y el
impacto que éste tiene en su negocio y no en el servicio en
sí mismo.
• Dos conceptos son claves para entender el valor del
servicio desde la perspectiva del cliente:
– Utilidad (funcionalidad) que debe adaptarse a las necesidades
reales del cliente.
– Garantía que asegura que el servicio se prestará de forma
continuada preservando los niveles de calidad acordados,

Ajuste a la Ajuste al
intención uso

Fuente: itilv3.osiatis.es/itil.php
Activos del Servicio
• Los activos del servicio son:
– Recursos: “materia prima” necesaria para la prestación del
servicio . Son activos tangibles y son más fáciles de adquirir.
– Capacidades: habilidades desarrolladas a lo largo del tiempo para
transformar los recursos en valor. Son activos intangibles y no
pueden producir valor por sí mismos.

Fuente: itilv3.osiatis.es/itil.php
Proveedores de servicios
• ITIL considera tres tipos diferentes de proveedores de servicios:
– Proveedores de Servicios Interno (Tipo I)
Esta opción sólo es recomendable cuando los servicios prestados
forman parte esencial en el posicionamiento estratégico de la
organización.

– Unidades de Servicio Compartidas (Tipo II)

Este tipo de proveedor presta servicio a diferentes unidades de
negocio que operan bajo un paraguas común.

– Proveedores de Servicios Externo (Tipo III)

Estos proveedores ofrecen sus servicios en el mercado a diferentes
clientes que frecuentemente serán competidores entre sí.
Tipos Proveedores de Servicios

Fuente: Long O., John (2008) p. 7.

Portafolio de Servicios
• También llamada Cartera de
Servicios, es una descripción
detallada de todos los
servicios que se prestan y los
recursos asignados para ello.
• Incluye tres categorías:
– Canal de entrada de servicios
(Pipeline): Planeados o en
desarrollo.
– Catalogo de servicios: Activos o
disponibles para despliegue.
– Servicios retirados: Ya no
disponibles.

Fuente: Long O., John (2008) p. 10.

Catalogo de Servicios
• Proporciona información de todos los servicios de TI activos,
incluyendo aquellos disponibles para su puesta en funcionamiento
operativo.
• El Catálogo de Servicios ofrece dos perspectivas:
– Catálogo de Servicios de Negocio: contiene los detalles de todos
los servicios entregados al cliente, junto sus relaciones a las
unidades de negocio y procesos de negocio que dependen de los
servicios de TI. Se trata de la perspectiva que tiene el cliente del
Catálogo de Servicios.
– Catálogo Técnico de Servicios: contiene los detalles de todos los
servicios de TI prestados al cliente, junto con las relaciones de los
servicios de soporte, servicios compartidos, componentes y
elementos de configuración (CIs) necesarios para apoyar la
provisión de los servicios al negocio. Se trata de una perspectiva
interna del Catálogo de Servicios no accesible por los clientes
Cat. Serv. Técnicos y de Negocio
¿Qué es un caso de negocio?
• Un Caso de Negocio (Business Case):
– Es una justificación de un elemento significativo en el gasto. Es
la justificación para un servicio.
– Incluye información sobre los Costos, los beneficios, las
opciones, cuestiones, Riesgos, y posibles problemas.
– Es una herramienta gerencial para toma de decisiones, que
proyecta las posibles consecuencias de una acción de
negocios.
– Es un análisis detallado del impacto o beneficios del negocio. El
impacto del negocio esta, a su vez, ligado a los objetivos del
negocio.
– Debe enfocarse en el análisis financiero y en los impactos no
financieros.
Modelo de Caso de Negocio

Fuente: www.tbs-sct.gc.ca/emf-cag/business-rentabilisation/bcg-gar/bcg-gar02-eng.asp
Análisis y Gestión del Riesgo
• Riesgo es definido como una
incertidumbre respecto al
resultado del servicio, si es
una oportunidad positiva o una
amenaza para el negocio.
• Un riesgo es medido por la
probabilidad de una amenaza,
la vulnerabilidad de un activo a
esa amenaza y el impacto que
tendría si ocurriera.
• Dos fases: Análisis del riesgo y
Gestión del riesgo.
Procesos Estrategia de Servicios

Proceso Responsabilidad
G. Portafolio de Inversión en servicios nuevos y actualizados que
Servicios ofrezcan el máximo valor al cliente minimizando a
su vez los riesgos y costes asociados.
G. Demanda Armonización de la oferta de los servicios ofrecidos
con las demandas del mercado.
G. Financiera Garantizar la prestación de servicios con unos
costes controlados y una correcta relación calidad-
precio.
1.- Gestión Portafolio de Servicio
• La SPM (Service Portfolio Management) decide la estrategia a seguir
para dar servicio a los clientes y desarrollar las ofertas y capacidades
del proveedor de servicios.
• Desempeña las siguientes tareas:
– Conocer y analizar el mercado en el que el servicio desarrollará su
actividad, detectando oportunidades, competencia, etc.
– Plantear unas líneas estratégicas sólidas que sirvan para orientar todas las
actividades del negocio hacia una serie de objetivos claros.
– Definir de forma detallada los servicios que se ofrecerán a los clientes.
Elige de entre todos los servicios posibles que puede ofertar la
organización TI, cuáles se ajustan mejor a los objetivos planteados, ofrecen
mejores perspectivas de negocio, aportan mayor valor a los clientes, etc.
• Es responsable de la gestión del portafolio de servicios, que describen
los servicios en términos de valor del negocio
Activid. de G. Portafolio Servicios
• Las principales actividades son:
– Definición del negocio: Evaluación de la situación actual, Inventario de
servicios ofertados, análisis de mercado y de las necesidades del
cliente, oferta de servicios de otros proveedores, casos de negocio.
– Análisis de los servicios: Maximizar el valor de la cartera; alinear,
priorizar y balancear la oferta con la demanda
– Aprobación de Servicios: Autorizar los servicios y asignar los recursos
para el desarrollo de lo mismos.
– Planificación y actualización del Portafolio: Definición de las tareas y
plazos de entrega en un Plan de Estrategia del Servicio. Registrar
toda la información disponible (descripción, requisitos, casos de
negocio, prioridades, riesgos, costos, paquetes de servicio) para que
pueda ser utilizada por otros procesos en el Portfolio o Cartera de
Servicios.
Activid. de G. Portafolio Servicios
Estrategia del
Servicio

Inventario de
Definir Servicio
Casos de Negocio

Priorización de
Analizar propuestas de valor

Autorización de
Aprobar cartera de servicios

Asignación de
Instituir recursos
Comunicación
2.- Gestión de la Demanda
• La DM (Demand Management) tiene por objetivo principal es optimizar y
racionalizar el uso de los recursos TI. Especialmente cuando existen
problemas de capacidad en la infraestructura TI, tanto por exceso como
por defecto.
• Incluye actividades para entender e influenciar la demanda de servicios
del cliente y la provisión de capacidad para cumplir las demandas.
• En un nivel estratégico implica el análisis de Patrones de Actividad del
Negocio y de los Perfiles de Usuarios (tipos de usuarios). En un nivel
Táctico implica el uso de Cobros Diferenciados para incentivar a los
Clientes a usar los Servicios de TI en momentos en que haya menos
ocupación.

Fuente. Van Bon, Jan y otros (2008) p. 196.

Análisis Demanda basado Actividades
• Analiza los Patrones de la Actividad del Negocio (PBA - Pattern
of Business Activity) y predice la demanda tomando como
referencia los activos del servicio que soportan estas actividades.
• Los PBAs definen el perfil de la carga de trabajo (recursos
requeridos) de una o mas actividades que son parte de un servicio.
• Los PBAs definen como servicios son utilizados por los usuarios
en términos de frecuencia, volumen, ubicación, duración.

Fuente: tilv3.osiatis.es/itil.php
Paquete de Servicio (SP)
• El SP es una descripción completa de un servicio TI que ya está
disponible para ser entregado a los clientes.
• Comprenden un Paquete de Nivel de Servicio (SLP), uno o más
servicios esenciales y uno o más servicios de soporte.
– Paquete de Nivel de Servicio (SLP)
Consiste en la definición de un nivel de utilidad y garantía específicos para un
Paquete de Servicio concreto. Los SLP se diseñan conforme a las necesidades
de un Patrón de Actividad de Negocio (PBA) particular.
– Paquete de Servicio Esencial (CSP)
Descripción detallada de un servicio básico, sin los que el negocio no puede
satisfacer las necesidades del cliente. Representan el valor que el cliente desea
y por tanto, por lo que está dispuesto a pagar. Puede ser compartido por dos o
más Paquetes de Nivel de Servicio.
– Paquete de Servicio de soporte
Están orientados a dar continuidad al servicio o a mejorar su propuesta de valor
(p.ej. Centro de Atención al Usuario). Representan aquellas características que
diferencian nuestro producto de otros similares ofrecidos por la competencia.
Paquete de Servicio (SP)

Fuente: tilv3.osiatis.es/itil.php
Línea de Servicio (LOS)

Línea de Servicio
(LOS): Servicio esencial o
de soporte común a varios
Paquetes de Nivel de
Servicio (SLP).

Fuente: Long O., John (2008) p. 9.

Actividades de G. Demanda
• Las principales actividades de la Gestión de la Demanda
se resumen en:
– Análisis de la actividad del negocio: Para determinar patrones
de demanda y segmentaciones de clientes.
– Desarrollo de la oferta: Con distintas opciones para cada
segmento del mercado de acuerdo a sus necesidades,
empaquetando de manera distinta los servicios esenciales y los de
soporte.

Fuente: itilv3.osiatis.es/itil.php
3.- Gestión Financiera
• El principal objetivo es el de evaluar y controlar los costes
asociados a los servicios TI de forma que se ofrezca un servicio de
calidad a los clientes con un uso eficiente de los recursos TI
necesarios.
• La Gestión Financiera asegura los fondos apropiados para la
entrega y uso de los servicios.
Clasificación de Costes
• Costes atribuibles a la prestación del servicio o elaboración del producto:
– Costes directos: son los costes relacionados específica y exclusivamente con un
producto o servicio.
– Costes indirectos: aquellos que no son específicos y exclusivos de un servicio. Estos
costes son más difíciles de determinar y, por lo general, son prorrateados entre los
diferentes servicios y productos.
• Costes que dependen o no del volumen de producción:
– Costes fijos: son independientes del volumen de producción y están normalmente
relacionados con gastos en inmovilizado material.
– Costes variables: incluyen aquellos costes que dependen del volumen de producción y
engloban.
• Costes que dependen del horizonte temporal:
– Costes de capital: que proviene de la amortización del inmovilizado material o
inversiones a largo plazo.
– Costes de operación: son los costes asociados al funcionamiento diario de la
organización TI.
Tipos de Coste
• Los tipos de coste son gastos de alto nivel, como
hardware, software, personal, administración, ubicaciones
físicas, servicios externos y costes de transferencia
interdepartamentales.
• Es imprescindible distinguir entre los diferentes tipos de
coste para diseñar una política de precios clara y
consistente. El número de tipos de costes varía
dependiendo del tamaño de la organización TI y sus
necesidades.
• Los tipos de coste se subdividen a su vez en elementos
de coste. Elementos de coste del hardware, por ejemplo,
serían servidores, ordenadores de sobremesa, etc.
Clasificación y Tipos de Costes

Clasificación Tipos de Costes

Fuente: itilv3.osiatis.es/itil.php
Actividades de G. Financiera

• Las principales actividades se

resumen en:
– Presupuestos:
• Análisis de la situación financiera.
• Fijación de políticas financieras.
• Elaboración de presupuestos.
– Contabilidad:
• Identificación de los costes.
• Definición de elementos de coste.
• Monitorización de los costes.
Fuente: http: itilv3.osiatis.es/itil.php
– Fijación de precios:
• Elaboración de una política de
fijación de precios.
• Establecimiento de tarifas por los
servicios prestados o productos
ofrecidos.
Diseño del Servicio
Objetivo del Diseño del Servicio
• La principal misión es la de diseñar nuevos servicios o modificar
los ya existentes para su incorporación al catálogo de servicios y
su paso al entorno de producción.
• El Diseño del Servicio debe tener en cuenta tanto los requisitos del
servicio como los recursos y capacidades disponibles en la
organización TI. Un desequilibrio entre ambos lados de la balanza
puede resultar en servicios donde se vean comprometidas bien la
funcionalidad o bien la garantía
Elementos del Diseño del Servicio
• Los elementos o componentes que intervienen en el diseño del
servicio son:
– Personas (People): La gente, habilidades y competencias
involucradas en la provisión de servicios de IT
– Productos (Products): La tecnología y sistemas de gestión
usados en la entrega de servicios IT
– Procesos (Processes): Procesos, roles y actividades incluidas
en la provisión de IT
– Socios (Partners): Vendedores, fabricantes y proveedores
usados para asistir a la provisión de servicios IT
Cinco Aspectos Esenciales
1. Identificación de los Requerimientos del Negocio y del
Servicio.
– Nuevas facilidades y requerimientos de funcionabilidad.
– Cambios en los proceso de negocio.
– Incremento de niveles de servicio.
2. Cartera de Servicios
– La cartera de servicios es una de las principales herramientas
para la gestión del servicio a través de todas las fases del ciclo
de vida.
– La fase de Diseño del Servicio es responsable de determinar su
contenido específico (SLAs, capacidades y recursos, costes,
ROI, etc.) así como sus permisos de acceso.
Cinco Aspectos Esenciales
3. Diseño de la arquitectura del servicio
– Debe tener en cuenta todos los elementos necesarios para la
Gestión del Servicio así como la interrelación entre ellos y el
mercado: Arquitectura Infraestructura TI, De Aplicaciones, De
Datos/Información, etc.
4. Diseño de procesos
– Se han de definir los procesos involucrados con una descripción
detallada de sus actividades, funciones, organización, entradas
y salidas.
– Se deben establecerse los procesos de control para asegurar
que los procesos se realizan de forma eficiente y cumplen los
objetivos establecidos.
– Se deben definir en términos medibles y deben ser expresados
en términos de beneficio del negocio.
Cinco Aspectos Esenciales
5. Diseño de métricas
– Se debe diseñar sistemas de medición y seguimiento que
permitan evaluar tanto la calidad de los servicios prestados
como la eficiencia de los procesos involucrados.
– Los resultados recopilados mediante estos sistemas de
seguimiento y su análisis posterior, basado en métricas y
métodos preestablecidos, deben de ser la principal entrada para
la fase de Mejora del Servicio.
Estrategias Entrega de Servicios
• ITIL define las siguientes estrategías de entrega de servicios:
– Insourcing: Utiliza recursos internos
– Outsourcing: Utiliza recursos de una organización externa.
– Co-sourcing: Es una combinación de Insourcing y Outsourcing.
– Partnership o Multisourcing: Acuerdo formal entre dos o mas
organizaciones para trabajar juntos para proveer un servicio.
– Business Partner Outsourcing (BPO): Provee la totalidad de los
procesos de negocio o funciones en una locación de bajo costo, como
por ejemplo la contabilidad o el centro de llamadas.
– Application Service Provider (ASP): Provee servicios electrónicos
compartidos a las organizaciones. Las aplicaciones ofrecidas son
llamadas on-demand software/applications.
– Knowledge Partner Outsourcing (KPO): Provee procesos basados en
la experiencia en negocios.
Ventajas/Desvent. Estrateg. Entrega
Delivery strategy Advantages Disadvantages
Insourcing Direct control Scale limitations
Freedom of choice Cost and time to market for services readily available
Rapid prototyping of leading-edge services outside
Familiar policies and processes Dependent on internal resources and their skills and
Company-specific knowledge competencies
Outsourcing Economies of scale Less direct control
Purchased expertise c
Supports focus on company core competencies Solvency risk of suppliers
Support for transient needs Unknown supplier skills and competencies
Test drive/trial of new services More challenging business process integration
Increased governance and verification
Co-sourcing Time to market Project complexity
Leveraged expertise Intellectual property and copyright protection
Control Culture clash between companies
Use of specialized providers
Partnership or multi-sourcing Time to market Project complexity
Market expansion/entrance Intellectual property and copyright protection
Competitive response Culture clash between companies
Leveraged expertise
Trust, alignment and mutual benefit
‘Risk and reward’ agreements
Business Process Outsourcing (BPO) Single point of responsibility ‘One-stop shop’ Culture clash between companies
Access to specialist skills Loss of business knowledge
Risk transferred to the outsourcer Loss of relationship with the business
Low-cost location
Application Service Provision (ASP) Access to expensive and complex solutions Culture clash between companies
Low-cost location Access to facilities only, not knowledge
Support and upgrades included Often usage-based charging models
Security and ITSCM options included
Knowledge Process Outsourcing (KPO) Access to specialist skills, knowledge and expertise Culture clash between companies
Low-cost location Loss of internal expertise
Significant cost savings Loss of relationship with the business

Fuente: http://www.itservicestrategy.com/comparison-itil-sourcing-and-delivery-strategy
Procesos Diseño del Servicio
Proceso Responsabilidad
Crear y mantener un catálogo de servicios de la organización TI
G. Catálogo de
que incluya toda la información relevante: gestores, estatus,
Servicios proveedores, etcétera.
G. Niveles de Acordar y garantizar los niveles de calidad de los servicios TI
Servicio prestados.
Garantizar que se cumplen los niveles de disponibilidad acordados
G. Disponibilidad
en los SLA.
Garantizar que la organización TI dispone de la capacidad
G. Capacidad suficiente para prestar los servicios acordados.

G. Seguridad de la Establecer políticas de integridad, confidencialidad y disponibilidad

Información de la información.
Establecer planes de contingencia que aseguren la continuidad
G. Continuidad del servicio en un tiempo predeterminado con el menor impacto
posible en los servicios de carácter crítico.

G. Proveedores Relación con los proveedores y el cumplimiento de los UCs.

Procesos Diseño del Servicio
1.- Gestión Catalogo de Servicios
• El objetivo principal es compendiar toda la información referente a
los servicios que los clientes deben conocer para asegurar un
buen entendimiento entre éstos y la organización TI. El Catálogo
prescinde de aquellos servicios retirados o inactivos y se centra en
los que pueden interesar a los clientes.
• Para cumplir ese cometido, el Catálogo de Servicios debe:
– Describir los servicios ofrecidos de manera comprensible para personal no
especializado, poniendo especial cuidado en evitar el lenguaje técnico.
– Ser utilizado como guía para orientar y dirigir a los clientes.
– Incluir, en líneas generales, los Acuerdos de Niveles de Servicio y los
precios en vigor. Ha de recoger también otras políticas y condiciones de
prestación de los servicios, así como las responsabilidades asociadas a
cada uno de éstos.
– Registrar los clientes actuales de cada servicio.
– Encontrarse a disposición del Centro de Servicios y de todo el personal que
se halle en contacto directo con los clientes.
Actividades G. Catálogo de Servicios
• Las principales actividades se resumen en:
– Definición de las familias principales de servicios a prestar, registro
de los servicios en activo y de la documentación asociada a los mismos.
– Mantenimiento y actualización del Catálogo de Servicios

Fuente: itilv3.osiatis.es/itil.php
2.- Gestión Nivel de Servicios
• La SLM (Service Level Management) define, negocia y supervisa
la calidad de los servicios TI ofrecidos
• Busca un compromiso real entre las necesidades y expectativas
del cliente y los costes.
• Produce y acuerda los requerimientos del nivel de Servicio (SLR –
Service Level Requirements)
• Establece y mantiene los acuerdos de nivel de servicio (SLA -
Service Level Agrement)
Conceptos Básicos
• Requisitos de Nivel de Servicio (SLR): Recogen información detallada sobre las
necesidades del cliente y sus expectativas de rendimiento y nivel de servicios.
Constituye el elemento base para desarrollar los SLA y posibles OLAs.
• Hojas de Especificación: Evalúan los recursos necesarios para ofrecer el
servicio requerido con un nivel de calidad suficiente y determinar si es necesario
el outsourcing de determinados procesos, sirviendo de documento de base para la
elaboración de los OLAs y UCs correspondientes.
• Plan de Calidad del Servicio (SQP): Incorpora toda la información necesaria
para posibilitar una gestión eficiente de los niveles de calidad del servicio:
Objetivos de cada servicio, Estimación de recursos, Indicadores clave de
rendimiento, Procedimientos de monitorización de proveedores.
• Acuerdo de Nivel de Servicio (SLA): Recoge en un lenguaje no técnico, todos
los detalles de los servicios brindados. Debe considerarse el documento de
referencia para la relación con el cliente en todo lo que respecta a la provisión de
los servicios acordados, por tanto, es imprescindible que contenga claramente
definidos los aspectos esenciales del servicio tales como su descripción,
disponibilidad, niveles de calidad, tiempos de recuperación, etc.
Conceptos Básicos
• Acuerdo de Nivel de Operación (OLA): Es un documento interno de la
organización donde se especifican las responsabilidades y compromisos de
los diferentes departamentos de la organización TI en la prestación de un
determinado servicio.
• Contrato de Soporte (UC): Es un acuerdo con un proveedor externo para
la prestación de servicios no cubiertos por la propia organización TI.
• Programa de Mejora del Servicio (SIP): Recoge tanto medidas correctivas
a fallos detectados en los niveles de servicio como propuestas de mejora
basadas en el avance de la tecnología. El SIP debe formar parte de la
documentación de base para la renovación de los SLAs.
Acuerdos SLA, OLA y UC
Estructuras SLA
• Se tienen las siguientes opciones:
– SLAs basados en el Servicio: Cubre un único servicio para todos los clientes de tal
servicio. Esta estructura puede causar dificultades en el caso de que un cliente tenga
requisitos particulares para el mismo servicio.
– SLAs basados en el cliente: Cubre todos los servicios que un cliente usa. El cliente
suele preferir este tipo de SLA, ya que recoge todos sus requisitos en un solo documento.
– SLA Multinivel: Una combinación, que por ejemplo, tenga la siguiente estructura:
• Nivel Corporativo: Cubre todos los aspectos genéricos de SLM.
• Nivel de Cliente: Cubre todo los aspectos relevantes para un grupo específico de
clientes o unidades de negocio.
• Nivel de Servicio: Cubre todo los aspectos relevantes para un servicio concreto
relacionado con un cliente específico.
Actividades G. Niveles de Servicio
• Las principales actividades se resumen en:
– Planificación:
• Asignación de recursos.
• Elaboración de un catálogo de servicios.
• Desarrollo de SLAs tipo.
• Herramientas para la monitorización de la calidad del servicio.
• Análisis e identificación de las necesidades del cliente.
• Elaboración del los Requisitos de Nivel de servicio (SLR), Hojas de Especificación
del Servicio y Plan de Calidad del Servicio (SQP).
– Implementación de los Acuerdos de Niveles de Servicio:
• Negociación.
• Acuerdos de Nivel de Operación.
• Contratos de Soporte.
– Supervisión y revisión de los Acuerdos de Nivel de Servicio:
• Elaboración de informes de rendimiento.
• Control de los proveedores externos.
• Elaboración de Programas de Mejora del Servicio (SIP).
Actividades G. Niveles de Servicio

Fuente: itilv3.osiatis.es/itil.php
3.- Gestión de la Disponibilidad
• La Gestión de la Disponibilidad es responsable de optimizar y
monitorizar los servicios TI para que estos funcionen
ininterrumpidamente y de manera fiable, cumpliendo los SLAs y todo ello
a un coste razonable.
• El objetivo primordial es asegurar que los servicios TI estén disponibles y
funcionen correctamente siempre que los clientes y usuarios deseen
hacer uso de ellos en el marco de los SLAs en vigor.
• Las responsabilidades de la Gestión de la Disponibilidad incluyen:
– Determinar los requisitos de disponibilidad en estrecha colaboración con los
clientes.
– Garantizar el nivel de disponibilidad establecido para los servicios TI.
– Monitorizar la disponibilidad de los sistemas TI.
– Proponer mejoras en la infraestructura y servicios TI con el objetivo de
aumentar los niveles de disponibilidad.
– Supervisar el cumplimiento de los OLAs y UCs acordados con proveedores
internos y externos.
Actividades G. Disponibilidad
• Entre las actividades se encuentran:
– Determinar cuáles son los requisitos de disponibilidad reales del
negocio.
– Desarrollar un plan de disponibilidad donde se estimen las futuras a
corto y medio plazo.
– Mantenimiento del servicio en operación y recuperación del mismo en
caso de fallo.
– Realizar diagnósticos periódicos sobre la disponibilidad de los sistemas y
servicios.
– Evaluar la capacidad de servicio de los proveedores internos y externos.
– Monitorizar la disponibilidad de los servicios TI.
– Elaborar informes de seguimiento sobre disponibilidad, fiabilidad,
capacidad de mantenimiento y cumplimiento de OLAs y UCs.
– Evaluar el impacto de las políticas de seguridad en la disponibilidad.
– Asesorar a la Gestión de Cambios sobre el posible impacto de un cambio
en la disponibilidad.
Actividades G. Disponibilidad

Fuente: itilv3.osiatis.es/itil.php
Calculo de la Disponibilidad
• Es habitual definir la disponibilidad en tanto por ciento de la
siguiente manera:

% Disponibilidad = (AST – DT) * 100

AST

• Donde:
– AST (Agreed Service Time) se corresponde con el tiempo acordado de
servicio y DT (Down Time) es el tiempo de interrupción del servicio durante
las franjas horarias de disponibilidad acordadas.
Métricas de Disponibilidad
• Algunas métricas que suele utilizar la Gestión de la Disponibilidad y que
debe poner a disposición del cliente en los informes de disponibilidad
correspondientes incluyen:
– Tiempo Medio de Reparación (MTTR): Es el tiempo promedio dedicado
a reparar un servicio. Se mide desde que el servicio falla hasta que es
reparado. No incluye el tiempo necesario para recuperar o restaurar.
– Tiempo Medio de Restauración del Servicio (Downtime o MTRS): Es
el tiempo medio dedicado a restaurar un servicio tras un fallo. Se mide
desde que el servicio falla hasta que es complementamente restaurado.
– Tiempo Medio entre Fallos (Uptime o MTBF): es el tiempo medio
durante el cual el servicio está disponible sin interrupciones.
– Tiempo Medio entre Incidencias (MTBSI): es el tiempo medio
transcurrido entre incidentes. El Tiempo Medio entre Incidentes es una
medida de la fiabilidad del sistema.
MTBSI = MTBF + MTRS
Métricas de Disponibilidad
Actividades Reactivas/Proactivas
• La Gestión de la Disponibilidad debe desempeñar actividades reactivas y
proactivas.
– Actividades Reactivas:
• Monitorización, medición, análisis y comunicación de la disponibilidad
de servicios y componentes.
• Análisis de la falta de disponibilidad.
• Análisis de Fallos del Servicio (SFA)
– Actividades Proactivas:
• Análisis y Gestión de Riesgo.
• Programas de pruebas de disponibilidad.
• Análisis de Impacto del Fallo de Componentes (CFIA)
• Análisis de Punto Individuales de Fallo (SPOF)
• Análisis por Arboles de Fallos (FTA)
Actividades Reactivas/Proactivas
Disponibilidad Servicio y Componentes
• La Gestión de la Disponibilidad se compone de dos niveles
interconectados:
– Disponibilidad del Servicio: todos los aspectos (end-to-end) de
la disponibilidad del servicio
– Disponibilidad de Componentes: todos los aspectos de la
disponibilidad de los componentes individuales que componen
uno o más servicios
Métodos y Técnicas
• La Gestión de la Disponibilidad tiene a su disposición un buen
número de métodos y técnicas que le permiten determinar qué
factores intervienen en la disponibilidad del servicio y que le
permiten consecuentemente prever qué tipo de recursos se deben
asignar para las labores de prevención, mantenimiento y
recuperación, así como elaborar planes de mejora a partir de
dichos análisis.
• Entre dichas técnicas se cuentan:
– Análisis del Impacto de Fallo de Componentes (CFIA)
– Análisis del Árbol de Fallos (FTA)
– Método de Gestión y Análisis de Riesgos de la CCTA (CRAMM)
– Análisis de Interrupción del Servicio (SOA)
Análisis Impacto Fallo Componentes
• El CFIA (siglas de Component Failure Impact Analysis), identifica el
impacto de cada elemento de configuración en la disponibilidad del
servicio.
• Requiere de una CMDB correctamente actualizada.

Fuente: Van Bon, Jan y otros (2008) p.171.

Análisis del Árbol de Fallos
• El FTA (siglas de Failure Tree Analysis) tiene como objetivo
estudiar cómo se "propagan" los fallos a través de la
infraestructura TI para comprender mejor su impacto en la
disponibilidad del servicio.

Fuente: Van Bon, Jan y otros (2008) p.172.

Método Gest. y Análisis Riesgos CCTA
• El CRAMM (siglas de CCTA Risk Analysis and Management
Method) tiene como objetivo identificar los riesgos y
vulnerabilidades a los que está expuesta la infraestructura TI, con
el objetivo de adoptar contramedidas que los reduzcan o que
permitan recuperar rápidamente el servicio en caso de interrupción
del mismo.
Análisis de Interrupción del Servicio
• El SOA (siglas de Service Outage Analysis) es una técnica cuyo
objetivo consiste en analizar las causas de los fallos detectados y
proponer soluciones a los mismos.
• Se diferencia de los anteriores métodos en que realiza el análisis
desde el punto de vista del cliente, haciendo especial énfasis en
aspectos no exclusivamente técnicos ligados directamente a la
infraestructura TI.
4.- Gestión de la Capacidad
• El objetivo primordial es poner a disposición de clientes, usuarios y
del propio departamento TI los recursos informáticos necesarios
para desempeñar de una manera eficiente sus tareas y todo ello
sin incurrir en costes desproporcionados.
• Para ello, la Gestión de la Capacidad debe:
– Asegurar que se cubren las necesidades de capacidad TI tanto
presentes como futuras.
– Controlar el rendimiento de la infraestructura TI.
– Desarrollar planes de capacidad asociados a los niveles de
servicio acordados.
– Gestionar y racionalizar la demanda de servicios TI.
Proceso Gestión de la Capacidad

Fuente: itilv3.osiatis.es/itil.php
Actividades G. Capacidad
• Las principales actividades se resumen en:
– Desarrollo del Plan de Capacidad y modelado de diferentes
escenarios de capacidad.
– Monitorización de los recursos de la infraestructura TI.
– Supervisión de la capacidad y administración de la Base de
Datos de la Capacidad (CDB) contenida en el Sistema de
Información de Gestión de la Capacidad (CMIS).
Actividades G. Capacidad

Fuente: itilv3.osiatis.es/itil.php
Base de Datos de la Capacidad (CDB)
• La CDB debe cubrir toda la información de negocio, financiera,
técnica y de servicio que reciba y genere la Gestión de la
Capacidad relativas a la capacidad de la infraestructura y sus
elementos.
• Idealmente la CDB debe estar interrelacionada con la CMDB para
que esta última ofrezca una imagen integral de los sistemas y
aplicaciones con información relativa a su capacidad. Esto no es
óbice para que ambas bases de datos puedan ser "físicamente
independientes".
Sist. Informac. G. Capacidad (CMIS)

Fuente: Van Bon, Jan y otros (2008) p. 208.

Subprocesos G. Capacidad
• El proceso de Gestión de la Capacidad puede segmentarse en
subprocesos que analizan las necesidades de capacidad TI desde
diferentes puntos de vista:
– Gestión de la Capacidad del Negocio (BCM - Business Capacity
Management): que centra su objeto de atención en las necesidades
futuras de usuarios y clientes.
– Gestión de la Capacidad del Servicio (SCM - Service Capacity
Management): que analiza el rendimiento de los servicios TI con el
objetivo de garantizar los niveles de servicio acordados.
– Gestión de la Capacidad de Componentes (CCM - Component
Capacity Management): que estudia tanto el uso de la infraestructura
TI como sus tendencias para asegurar que se dispone de los recursos
suficientes y que estos se utilizan eficazmente.
Subprocesos G. Capacidad

Fuente: Van Bon, Jan y otros (2008) p. 210.

5.- Gestión Seguridad de Información
• Los principales objetivos de la Gestión de la Seguridad se
resumen en:
– Diseñar una política de seguridad, en colaboración con clientes
y proveedores, correctamente alineada con las necesidades del
negocio.
– Asegurar el cumplimiento de los estándares de seguridad
acordados en los SLAs.
– Minimizar los riesgos de seguridad que amenacen la
continuidad del servicio.
– La correcta Gestión de la Seguridad no es responsabilidad
(exclusiva) de "expertos en seguridad" que desconocen los
otros procesos de negocio. La Seguridad la define el negocio.
Principios Básicos Seg. Información
• Los principios básicos de la seguridad de la información son:
– Confidencialidad: la información debe ser sólo accesible a sus
destinatarios predeterminados.
– Integridad: la información debe ser correcta y completa.
– Disponibilidad: debemos de tener acceso a la información
cuando la necesitamos.
– Autenticidad: Asegura que las transacciones y la identidad de
las partes son genuinas.
– No Repudio (Aceptación): Asegura que las transacciones una
vez completadas, no podrán ser revertidas sin aprobación.
Actividades G. Seg. Información
• Para que esa colaboración sea eficaz, es necesario que la Gestión de la
Seguridad:
– Establezca una clara y definida política de seguridad que sirva de
guía a todos los otros procesos.
– Elabore un Plan de Seguridad que incluya los niveles de seguridad
adecuados tanto en los servicios prestados a los clientes como en los
acuerdos de servicio firmados con proveedores internos y externos.
– Implemente el Plan de Seguridad.
– Monitorice y evalúe el cumplimiento de dicho plan.
– Supervise proactivamente los niveles de seguridad analizando
tendencias, nuevos riesgos y vulnerabilidades.
– Realice periódicamente auditorías de seguridad.
Actividades G. Seg. Información

Fuente: itilv3.osiatis.es/itil.php
Política y Plan Seg. Información
• La Política de Seguridad de la Información:
– Dispone de un marco general en el que encuadran todos los subprocesos asociados a la
Gestión de la Seguridad. Su complejidad e intricadas interrelaciones necesitan de una
política global clara en donde se fijen aspectos tales como los objetivos, responsabilidades y
recursos.
– Debe determinar:
• La relación con la política general del negocio.
• Los protocolos de acceso a la información.
• El nivel de monitorización de la seguridad.
• El alcance del Plan de Seguridad.
• La estructura y responsables del proceso de Gestión de la Seguridad.
• Los auditores externos e internos de seguridad.
• Los recursos necesarios: software, hardware y personal.
– Debe de estar disponible para todos los clientes, usuarios y equipo de TI.
• El Plan de Seguridad:
– Fija los niveles de seguridad que han de ser incluidos como parte de los SLAs, OLAs y UCs.
– Debe ser diseñado con el fin de ofrecer un mejor y más seguro servicio al cliente y nunca
como un obstáculo para el desarrollo de sus actividades de negocio.
– Siempre que sea posible, deben definirse métricas e indicadores clave que permitan evaluar
los niveles de seguridad acordados.
6.- Gest. Continuidad de los Servicios
• Los objetivos principales de la Gestión de la Continuidad de los
Servicios TI (ITSCM) se resumen en:
– Garantizar la pronta recuperación de los servicios (críticos) TI
tras un desastre.
– Establecer políticas y procedimientos que eviten, en la medida
de lo posible, las perniciosas consecuencias de un desastre o
causa de fuerza mayor.
• Una correcta ITSCM debe formar parte integrante de la Gestión de
Continuidad del Negocio (BCM) y debe estar a su servicio. Los
servicios TI no son sino una parte, aunque a menudo muy
importante, del negocio en su conjunto.
BCM & ITSCM

Actividades Claves
Gestión de la Ciclo de Vida ITSCM
Continuidad del •Establecimiento de Políticas
Negocio (BCM) Iniciación •Alcance
•Comienzo de un proyecto

Estrategia de
Continuidad del Requerimientos •Análisis de Impacto del Negocio (BIA)
•Evaluación del Riesgo
Negocio y Estrategia
•Estrategia Continuidad Servicio TI

•Desarrollar Planes Continuidad Servicios TI

Planes de •Desarrollar Planes/Procedimientos
Continuidad del Implementación Recuperación TI
Negocio •Planeación de la Organización
•Estrategias de Pruebas.

•Educación, Conciencia y Entrenamiento

Operación •Revisión y Auditoría
Invocación Activa •Pruebas
•Gestión del Cambio
Fases G. Continuidad del Servicio
7.- Gestión de Proveedores
• Los principales objetivos de la Gestión de Proveedores consisten
en:
– Aportar el máximo valor añadido al menor coste en aquellos
servicios que prestan los proveedores.
– Asegurar que los contratos y acuerdos con proveedores están
alineados con la estrategia y necesidades de negocio de la
organización.
– Gestionar la relación con los proveedores.
– Gestionar el rendimiento de los proveedores.
– Negociar los contratos con los proveedores y gestionarlos a lo
largo de su ciclo de vida.
– Mantener una política de proveedores y una Base de Datos de
Proveedores y Contratos (SCD).
Categorización de Proveedores
• La cantidad de tiempo y esfuerzo para gestionar un proveedor y su
contrato dependerá de la categoría de Proveedor y la importancia
que proporciona al negocio.
• Tomando en cuenta el riesgo e impacto, asociado con su valor e
importancia, los proveedores se pueden categorizar en:
– Proveedores Estratégicos: Involucra a la alta gerencia con los que se tiene
alianzas estratégicas para facilitar los planes a largo plazo. Involucra
contactos y revisiones frecuentes.
– Proveedores Tácticos: Manejada por la gerencia del medio, involucra
también contactos y revisiones frecuentes.
– Proveedores Operacionales: Esta relacionad a los productos o servicios
operacionales de soporte. No es el “core” del negocio. Es el nivel ejecutor.
– Proveedores de Mercancías (Commodity): Esta relacionado con servicios
y/o productos de bajo valor o de fácil acceso. Pueden ser abastecidos por
otro proveedor. Contacto y revisión menos frecuente.
Categorización de Proveedores
BD Proveedores y Contratos (SCD)
• La SCD (Supplier & Contracts
Database) es un repositorio
documental donde se archiva toda
la información relacionada con los
proveedores y los servicios que
prestan, incluyendo por supuesto
copias de los contratos (UCs) en
vigor.
• Es aconsejable que la Base de
Datos de Proveedores y Contratos
esté integrada en el Sistema de
Gestión de la Configuración (CMS)
y en el Sistema de Gestión del
Conocimiento del Servicio (SKMS).
Actividades G. Proveedores
• La Gestión de Proveedores se ocupa de definir y gestionar:
– Los requisitos de contratación que se van a exigir a los
proveedores.
– Los procesos de evaluación y selección de proveedores.
– La clasificación y documentación de la relación con los
proveedores.
– Gestión del Rendimiento de los proveedores
– Renovación o terminación.
Actividades G. Proveedores

Fuente: itilv3.osiatis.es/itil.php
Transición del Servicio
Misión/Objetivos Transición Servicio
• La misión de esta fase es hacer que los productos y servicios definidos en
la fase de Diseño del Servicio se integren en el entorno de producción y
sean accesibles a los clientes y usuarios autorizados.
• Es una interfaz entre el Diseño del Servicio y las Operaciones del Servicio
y esta influenciada por las entradas de la Estrategia del Servicio y Diseño
del Servicio.
• Sus principales objetivos se resumen en:
– Planear y gestionar la capacidad y recursos requeridos para empaquetar, construir,
probar, y desplegar una implementación a producción.
– Supervisar y dar soporte a todo el proceso de cambio del nuevo (o modificado)
servicio.
– Garantizar que los nuevos servicios cumplen los requisitos y estándares de calidad
estipulados en las fases de Estrategia y la de Diseño.
– Minimizar los riesgos intrínsecos asociados al cambio reduciendo el posible impacto
sobre los servicios ya existentes.
– Mejorar la satisfacción del cliente respecto a los servicios prestados.
– Comunicar el cambio a todos los agentes implicados.
Sist. G. Conocimiento Servicios
• El SKMS (Service Knowledge Management System ) se define como un
conjunto de herramientas y bases de datos que se utilizan para gestionar
conocimiento e información.
• El objetivo del SKMS es proporcionar información efectiva y útil,
conocimiento y sabiduría para los usuarios del negocio y departamentos de
TI que tengan que tomar importantes decisiones.
• El SKMS utiliza una base más amplia de conocimiento en la experiencia de
usuario, cifras de rendimiento de la empresa u otro tipo de información como
experiencia del personal, siempre y cuando esta información y conocimiento
aporte algo de “sabiduría” o sentido común a los diferentes usuarios que
tienen que tomar decisiones.
• El SKMS incluye el CMS (Configuration Management System) así como
otras herramientas y bases de datos.
• El SKMS almacena, gestiona, actualiza y presenta toda la información que
un proveedor de servicios TI necesita para gestionar todo el ciclo de vida de
los servicios TI.
Sist. G. Conocimiento Servicios
Relación CMDB, CMS y SKMS
• En primer lugar, un CMS incluye múltiples CMDBs de una manera
federada. Los CMDBs crean un CMS en conjunción con otros datos, y un
CMS crea a su vez un SKMS. El CMS proporciona información a los que
tienen que decidir sobre tecnología en una empresa. Entre esta
información se encuentra la que interesa para los elementos de
configuración como pueden ser costes, fechas de compra, proveedores y
niveles de soporte, estado de los acuerdos de nivel de servicio (SLA),
situación, información de contacto, etc. El CMS ofrece esta información
al SKMS.
• En segundo lugar, la industria reconoce que no es tan fácil como parece
implantar un CMDB (tal vez ITIL v3 de SKMS es la prueba). Por tanto, el
modelo federado actúa como un CMS permitiendo coger información de
múltiples CMDBs ( tanto caseros como comerciales). El CMS alimenta al
SKMS (así como otros elementos importantes para el negocio) para
procesar y presentar a los usuarios que convenga a través de cuadros
de mando y portales inteligentes.
CMDB, CMS y SKMS
Elementos de configuración (CIs)
• Los CIs son activos de servicio, componentes de servicio, o cualquier elemento que
está o estará bajo el control de la Gestión de las Configuraciones. Los CIs pueden ser
un simple módulo como un monitor, o elementos más complejos, como un sistema
completo.
• Un CI es una instancia de una entidad que es parte del ambiente configurable y que
tiene atributos configurables específicos para esa instancia. Pero todo esto tiene que
ser una parte directa del ambiente, y no información sobre esa parte.
• Todos, tanto los componentes de los servicios TI como los servicios que éstos nos
ofrecen, constituyen diferentes elementos de configuración. A modo de ejemplo
citaremos:
– Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. así como sus
componentes: tarjetas de red, teclados, lectores de CDs, etc.
– Software: sistemas operativos, aplicaciones, protocolos de red, etc.
– Documentación: manuales, acuerdos de niveles de servicio, etc.
• Cada información registrada sobre un CI recibe el nombre de atributo. Son ejemplos de
atributos: número de versión, nombre, etc.
Ejemplos de CIs
Elementos de Configuración Elementos que no son de Configuración
(Configuration Items o CI) (no son Configuration Items o CI)
• Una computadora es parte del entorno de • Una persona que llega a visitar las
trabajo y tiene atributos configurables, tales instalaciones de la empresa tiene atributos
como número de serie, velocidad del configurables pero no es parte directa del
procesador, y dirección IP. ambiente de trabajo.
• Un edificio es parte del entorno de trabajo y • Manual de usuario de un equipo tiene
tiene atributos configurables, tales como atributos configurables pero no forma parte
número de cuartos, sistema de control de directa del ambiente de trabajo, sino que
temperatura, y sistema de alarma. solamente contiene información acerca de
• Una instancia de un programa instalado en otras entidades, como por ejemplo una
una computadora es parte del ambiente de computadora o una impresora.
trabajo y tiene atributos configurables, tales
como número de serie, ruta o ruta de acceso
para usarlo, etc.  
• Un servicio recibido por un negocio es parte  
del entorno de trabajo y tiene atributos
configurables tales como el beneficio
económico recibido por dicho servicio, el costo
que tiene la interrupción del servicio, etc.
Atributos de CIs
• Los atributos de Cis son la información a almacenar de un CI, esto depende lo
que sea relevante para una organización. ITIL recomienda algunos atributos
básicos:

• Es evidente que esto no es todo lo que se debe de almacenar de un CI, existen

otros datos importantes como el numero de serie, numero de modelo,
fabricante, categoría, ubicación, propietario responsable, licencia, estado
actual, costos y algunos otros comentarios.
BD G. Configuración y Activos TI
• EL principal objetivo de la CMDB (Configuration Management DataBase) es proporcionar un
Modelo Lógico de la infraestructura de TI, identificando, controlando, manteniendo y verificando
las versiones de todos los elementos de configuración que existen. Esto permite la gestión de la
actividad TI como de la infraestructura tecnológica, desde el punto de vista del negocio.
• La CMDB no sólo es un repositorio de las configuraciones de elementos, soportado en un
motor de base de datos; sino que posee las reglas de dependencias, prioridades y
propagaciones fundamentales que permiten entender cómo un componente de tecnología
puede o no provocar un impacto en el negocio. Estos componentes (muchas veces abstractos),
se pueden explicar en la necesidad de calificar y cuantificar la experiencia de los usuarios
finales respecto a TI con métricas de negocio, tiempos de respuesta, disponibilidad, etc.
• Esta base de datos debe incluir:
– Información detallada de cada elemento de configuración.
– Interrelaciones entre los diferentes elementos de configuración, como, por ejemplo, relaciones
"padre-hijo“, relaciones “usa-usada por” o interdependencias tanto lógicas como físicas.
• La CMDB no se limita a una mera enumeración del stock de piezas, sino que nos brinda una
imagen global de la infraestructura TI de la organización .
Sist. Gest. Configuración (CMS)
• Es un sistema de apoyo diseñado para infraestructuras de
servicios TI de gran complejidad.
Biblioteca Definitiva de Medio
• La DML (Definitive Media Library), es definida como una o más
locaciones que almacena en forma segura las versiones
autorizadas y definitivas de todo los CIs.
• Almacena toda la información relativa a un elemento de
configuración en cualquier formato.
• Es un área de almacenamiento lógico aunque existan locaciones
múltiples
• Puede contener otros CIs asociados, tales como licencias y
documentación.
• Es el único proveedor de software para el uso de una versión.
• No se guarda copia de datos
Cambio de Servicio
• Implica un cambio a un servicio existente o la
introducción de un nuevo servicio.
• Es el agregado, modificación, eliminación de un servicio
autorizado, planeado o soportado o de un componente
del servicio y a su documentación asociada
Tipos de Cambio
• Cambio Estándar:
– Es un cambio pre-aprobado que es de bajo riesgo, relativamente
común y sigue un procedimiento de trabajo
– No requieren RFCs y son registrados y seguidos empleando otros
mecanismos como Peticiones de Servicio (a través del Service Desk).
• Cambio Normal:
– Es generado por un RFCs (Petición de Cambio) de parte del iniciador
que requiere el cambio.
– Aprobado por el CAB
• Cambio de Emergencia.
– Realizados para reparar un error en un servicio de TI que tiene un
impacto de alto nivel en el negocio.
– De ser posible debe ser diseñado con cuidado y probado antes de su
uso.
– Aprobado por el ECAB.
Las 7 Erres de G. Cambio
• Son usadas para evaluar el impacto de los cambios:
1. Who Raised the change?  (¿Quién solicitó el cambio?)
2. What is the Reason for the change? ( ¿Cuál es la razón del cambio? )
3. What is the Return required from the change ( ¿Cuál es el retorno del
cambio?)
4. What are the Risks involoved in the change  ( ¿Cuáles son los riesgos
involucrados en el cambio?)
5. What Resources are required to deliver the change ?  (¿Cuáles son los
recursos requeridos para entregar el cambio? )
6. Who is Responsabile to build test and implement the change ? ¿Quién es
el responsable de construir probar e implementar el cambio?
7. What is the Relationship between the change and other changes? ¿Cuál
es la relación entre este cambios y otros cambios?
Unidad de Implementación
• Es la porción del servicio o infraestructura que es afectado por un
cambio.
• Es conjuntamente implementado normalmente de acuerdo con la
política de implementación de la organización.
• Puede variar dependiendo de los tipos o elementos de software y
hardware.
Modelo en V
• El Modelo en V es una metodología para ejecutar pruebas en todo
el ciclo de vida del servicio.
• Es una herramienta clave para formular la planificación de
entregas, que sirve para identificar los diferentes niveles de test
necesarios para aceptar una versión durante el proceso de
Validación y Pruebas.
• La metodología del Modelo en V consiste en definir, en el brazo
izquierdo de la V, las especificaciones del servicio que es
necesario cumplir para aceptar una versión. En el brazo derecho
se van indicando, de forma paralela, las pruebas mediante las
cuales se van a comprobar cada una de las especificaciones de la
izquierda.
Modelo en V

Nivel 1: Necesidades del

Cliente/Negocio

Nivel 2: Requerimientos del

Servicio

Nivel 3: Solución de Servicio

Nivel 4: Implementación del

Servicio

Nivel 5: Componentes y
Ensamblaje

Actividades Pruebas
Procesos Transición del Servicio
Proceso Responsabilidad
Supervisar y aprobar la introducción o modificación de los
servicios prestados garantizando que todo el proceso ha sido
G. de Cambios
convenientemente planificado, evaluado, probado, implementado
y documentado.
G. Configuración y Registro y gestión de los elementos de configuración (CIs) y
Activos del Servicio activos del servicio. Este proceso da soporte a prácticamente
todos los aspectos de la Gestión del Servicio.
Desarrollar, probar e implementar las nuevas versiones de los
G. de Entregas y
servicios según las directrices marcadas por el Diseño del
Despliegues
Servicio.
Planificación y Planificar y coordinar todo el proceso de transición asociado a la
Soporte creación o modificación de los servicios TI.

Validación y Garantizar que los servicios cumplen los requisitos

Pruebas preestablecidos antes de su paso al entorno de producción.
Evaluar la calidad general de los servicios, su rentabilidad, su
Evaluación
utilización, la percepción de sus usuarios, etc.
G. Conocimiento Gestionar toda la información relevante a la prestación de los
1.- Gestión de Cambios
• El principal objetivo de la Gestión de Cambios es la evaluación y
planificación del proceso de cambio para asegurar que, si éste se lleva
a cabo, se haga de la forma más eficiente, siguiendo los
procedimientos establecidos y asegurando en todo momento la calidad
y continuidad del servicio TI.
• La Gestión de Cambios debe trabajar para asegurar que los cambios:
– Están justificados.
– Se llevan a cabo sin perjuicio de la calidad del servicio TI.
– Están convenientemente registrados, clasificados y documentados.
– Han sido cuidadosamente testeados en un entorno de prueba.
– Se ven reflejados en la CMDB.
– Pueden deshacerse mediante planes de "retirada del cambio"
(back-outs) en caso de un incorrecto funcionamiento tras su
implementación.
Actividades G. Cambio
• Las principales actividades de la Gestión de Cambios se resumen
en:
– Registrar, evaluar y aceptar o rechazar las RFCs recibidas.
– Planificación e implementación del cambio
– Convocar reuniones del CAB, excepto en el caso de cambios
menores, para la aprobación de las RFCs y la elaboración del
FSC (Calendario del Cambio).
– Evaluar los resultados del cambio y proceder a su cierre en
caso de éxito.
Actividades G. Cambio

Fuente: itilv3.osiatis.es/itil.php
Proceso de Cambio

Fuente: es.scribd.com/doc/48115493/Manual-Itil-v3
Petición de Cambio (RFC)
• Una solicitud de cambio es conocida como RFC, Request for change o
Petición de Cambio.
• Es una comunicación formal que busca una alteración de uno o más
elementos de la configuración.
• El origen de una RFC, puede ser de distinta índole: Gestión de
problemas, nuevos servicios, estrategia empresarial, actualización de SW
de terceros, imperativo legal, etc..
• No siempre un cambio implica una RFC. Para cambios de escasa
importancia o que se repiten periódicamente pueden acordarse
procedimientos estándar que no requieran la aprobación del CAB.
• Independientemente de su origen, una RFC requerirá, los siguientes
datos: Fecha de recepción, Identificador único de la RFC, Identificador del
error conocido asociado (dado el caso), Descripción del cambio
propuesto, Estatus ("registrado“, "aceptado", "rechazado",
"implementado", etc), Prioridad y categoría, Planes de back-out, Recursos
asignados, etc.
Aceptac. y Clasificac. del cambio
• Una RFC puede ser simplemente rechazada si se considera que el
cambio no esta justificado.
• La aceptación del cambio no implica su posterior aprobación por el
CAB.
• Tras su aceptación se debe asignar a la RFC: Prioridad y
Categoría.
• La Prioridad determina la importancia relativa a otras RFCs. Esta
compuesta por el Impacto y la Urgencia. Niveles: Baja, normal,
alta, urgente.
• La Categoría determina la dificultad e impacto de la RFC y será
relevante para la asignación de recursos necesarios, los plazos
previstos y el nivel de autorización requerido..
Aprobac. y Planificac. del Cambio
• En primer lugar el CAB debe reunirse periódicamente para analizar
y eventualmente aprobar los RFCs pendientes y elaborar el FSC o
calendario del cambio correspondiente.
• En el caso de cambios que tengan un alto impacto, debe también
consultarse a la dirección pues pueden entrar en consideración
aspectos de carácter estratégico y de política general de la
organización.
• Una vez aprobado el cambio (en caso contrario se seguiría el
proceso ya descrito para el caso de no aceptación) debe evaluarse
si éste ha de ser implementado aisladamente o dentro de un
"paquete de cambios", que formalmente equivaldrían a un solo
cambio.
Implementación del Cambio
• Los cambios autorizados deberán ser pasados a los grupos técnicos
apropiados (típicamente como órdenes de trabajo).
• Aunque la Gestión de Cambios NO es la encargada de implementar el
cambio, algo de lo que se encarga habitualmente la Gestión de Entregas
y Despliegues, sí lo es de supervisar y coordinar todo el proceso.
• En la fase de desarrollo del cambio se deberá monitorizar el proceso para
asegurar que:
– Tanto el software desarrollado como el hardware adquirido se ajustan
a las especificaciones predeterminadas.
– Se cumplen los calendarios previstos y la asignación de recursos es la
adecuada.
– El entorno de pruebas es realista y simula adecuadamente el entorno
de producción.
– Los planes de back-out permitirán la rápida recuperación de la última
configuración estable.
Revisión y Cierre
• Antes de proceder al cierre del cambio, es necesario verificar que
ha sido positivo para el servicio, ya porque el nivel de calidad se ha
visto aumentado o porque contribuye a mejorar la productividad de
la organización.
• Aunque la Gestión de Cambios es la encargada de emitir el
dictamen final, es la Evaluación del servicio la que ha de
proporcionar a ésta los informes.
• Si la evaluación final determina que el proceso y los resultados han
sido satisfactorios, se procederá al cierre de la RFC y toda la
información se incluirá en la PIR (Revisión Post Implementación)
asociada.
• Las lecciones aprendidas deberán ser retroalimentadas para
cambios futuros.
Alcance G. Cambios
• El alcance de los procesos de la Gestión del Cambio
cubre:
– Cambios estratégicos (Ej. : introducción de un nuevo servicio
como consultas en línea)
– Cambios tácticos (Ej.: creación de modelo nuevo para el
manejo de incidentes mayores)
– Cambios operacionales ( Ej.: un cambio que corrige una falla en
un ítem de configuración del centro de computo)
Roles G. Cambio
• 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 Gestión de Cambios.
– Preside el CAB y ECAB
– Autoriza los cambios aceptados.

• 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 gestión de
servicios TI. Sin embargo, en algunos casos también puede incorporar:
• Consultores externos.
• Representantes de los colectivos de usuarios.
• Representantes de los principales proveedores de software y hardware.
2.- Activos Serv. y G. Configurac.
Relación entre DML y CMDB

Fuente: es.scribd.com/doc/48115493/Manual-Itil-v3
• Paquete de Diseño de Servicio
• ServiceDesign Package (SDP):
• ‡define todos los aspectos de un servicio IT y
• sus requisitos a lo largo de cada etapa de su
• ciclo de vida.
• ‡Un SDP se produce para cada:
• ±nuevo servicio IT,
• ±cambio relevante
• ±o servicio IT retirado
Bibliografía
• Osiatis. ITIL V3 Gestión de servicios TI. Recuperado Marzo
de 2011, de: http://itilv3.osiatis.es/itil.php
• Van Bon, Jan y Otros (2008). Fundamentos de la Gestión
de Servicios TI basada en ITIL v3. Van Haren Publishing.
• Long O., John (2008). ITIL® VERSION 3 AT A GLANCE.
Springer Science+Business Media.