Manual ITIL Última Versión PDF

FUNDAMENTOS
Profesor: Angel Caro Amián www.avante.es avante@avante.es

consultas@avante.es 902 117 902 954 186 540
ITIL
La Biblioteca de Infraestructura de Tecnologías de Información, abreviada
como ITIL (del inglés Information Technology Infraestructure Library), es
un conjunto de conceptos y prácticas (Compendio de Buenas Prácticas)
para la gestión de servicios de tecnologías de la información.
ITIL da descripciones detalladas de un extenso conjunto de

procedimientos de gestión, ideados para ayudar a las organizaciones a
lograr calidad y eficiencia en las operaciones de IT.
Estos procedimientos son independientes del proveedor y han sido

desarrollados para servir como guía que abarque toda infraestructura,
desarrollo y operaciones de IT.
ITIL FUNDAMENTOS
En este curso entenderemos el concepto de vida de los servicios, así como
las diferentes etapas por las que se recomienda que pase un servicio
desde su concepción a su operación.
OBJETIVOS
Al finalizar el curso los alumnos podrán:
• Conocer los principios y conceptos fundamentales en la Gestión de
Servicios TI
• Entender los beneficios y ventajas que aporta la implementación de
ITIL en una organización
• Conocer y entender la estructura de procesos de ITIL en la Gestión
de Servicios.
• Comprender como se estructuran los procesos en el ciclo de vida de
un servicio
• Entender como la aplicación de ITIL nos ayuda a entregar servicios
de mayor calidad
• Conocer qué factores contribuyen y como a la efectividad y
eficiencia de cada proceso
• Entender las actividades y roles en el modelo ITIL, para poder
implementarlos con éxito
¿PARA QUÉ SIRVE ITIL?
• ITIL sirve para “hacer las cosas mejor”.
• Siguiendo las buenas prácticas que ITIL provee, podemos generar
valor en nuestra organización
• ITIL intenta integrar los objetivos de nuestra organización, con las
capacidades del área de IT.
• Las buenas prácticas se erigen sobre la convivencia de tres puntos
clave:
• Procesos, Personas y Tecnología.
• De dicha convivencia armónica, se genera un valor más allá de lo
netamente económico, que se mide por la satisfacción del cliente y
todo lo que conlleva.
VENTAJAS PARA MI ORGANIZACIÓN APLICANDO ITIL

• Es un estándar de facto mundial
• Consigue que tengamos identificados todos los servicios y el ciclo de
vida de los mismos
• Nos ayuda a entregar servicios de mayor calidad
• Permite gestionar eficazmente los cambios constantes
• Permite tener identificados todos los Componentes y elementos
• Nos ayuda a identificar los KPI’s adecuados
• Evita la dependencia de “gurús”
• Permite dar a los usuarios un soporte organizado y eficiente
• Ayuda a cumplir los SLA´s
CONTENIDO DE ITIL FUNDAMENTOS
1. Introducción
2. Gestión por Procesos
3. Procesos en ITIL
3.1 Estrategia del Servicio
3.2 Diseño del Servicio
3.3 Transición del Servicio
3.4 Operación del Servicio
3.5 Mejora Continua del Servicio
4. Indicadores KPI
5. Implementación de ITIL
6. Bibliografía
7. Glosario
8. Examen de Prueba
CERTIFICACIÓN
Este curso te prepara para la realización del examen de certificación para
obtener el título oficial de ITIL Fundamentos.
1. Introducción
FUNDAMENTOS
Ángel Caro Amián 1
www.avante.es avante@avante.es 902 117 902
1. Introducción
INDICE DEL CURSO y DOCUMENTACIÓN
1. Introducción
3. Procesos en ITIL
4. Indicadores KPI
5. Implementación de ITIL
6. Bibliografía
7. Glosario
8. Examen de Prueba
1. Introducción
EXAMEN
• Duración del Examen
– 60 minutes
• Detalle del examen
– Número de preguntas: 40
• Nota mínima para aprobar:
– 65% (26 de 40)
• Documentación en el examen:
– no
• Equipos electrónicos permitidos:
– no
1. Introducción
1. Introducción
1. INTRODUCCIÓN A ITIL
1. Introducción
GOBIERNO DE TI
• Gobierno de TI es el alineamiento
de las Tecnologías de la
información y la comunicación (TI)
con la estrategia del negocio.
• Hereda las metas y la estrategia a
todos los departamentos de la
organización y proporciona el
mejor uso de la tecnología y de sus
estructuras organizativas para
alcanzarlas..
• Garantiza que:
– Los servicios y funciones de TI se proporcionan con el máximo valor posible o de
la forma más eficiente.
– Todos los riesgos relacionados con TI son conocidos y administrados y los
recursos de TI están seguros.
1. Introducción
¿QUÉ ES UN SERVICIO de TI?
Un SERVICIO es
• Un conjunto de actividades que buscan responder las
necesidades de un cliente.
• Un medio para ofrecer valor a los clientes al facilitar resultados
que ellos quieren lograr sin la propiedad de costos y sin riesgos
específicos
Un SERVICIO DE TI es
• Un sistema de información con
• Soporte que se entrega a un cliente con unos
• Niveles de calidad, previamente acordados
Un sistema de información (SI) es un conjunto de Ejemplos de Servicios de TI
elementos orientados al tratamiento y administración de • Correo electrónico
datos e información, organizados y listos para su uso • Mensajería
posterior, generados para cubrir una necesidad o un • Almacenamiento
objetivo • Servicios generales de TI
• Hosting, etc. 7
Ángel Caro Amián www.avante.es avante@avante.es 902 117 902
1. Introducción
¿QUÉ ES LA GESTIÓN UN SERVICIO?
La Gestión de un servicio es
• Un conjunto de capacidades
organizacionales especializadas para
proporcionar valor a clientes en la forma
de servicios
1. Introducción
QUIERO UNA PIZZA
• Dos alternativas:
Yo me la hago
Contrato el servicio
Un servicio:
Un medio para ofrecer valor a los clientes al
facilitar resultados que ellos quieren lograr sin la
propiedad de costos y sin riesgos específicos
1. Introducción
QUIERO ELECTRICIDAD EN CASA
• Dos alternativas:
Yo la creo
Contrato el servicio
Un servicio:
Un medio para ofrecer valor a los clientes al
facilitar resultados que ellos quieren lograr sin la
propiedad de costos y sin riesgos específicos
1. Introducción
CAMBIO DE MENTALIDAD:
DE ADMINISTRADOR DE TECNOLOGÍA A PROVEEDOR DE SERVICIOS
Ejemplo: SERVICIO DE CORREO ELECTRÓNICO
ADMINISTRADOR DE TECNOLOGÍA PROVEEDOR DE SERVICIOS
"Yo tengo a cargo el sistema de correo, el cual "Yo proveo mensajería de correo electrónico nacional e
funciona vía SMTP e IMAP desde un servidor internacional, con capacidad diferida y capacidad para
Exchange. encriptar mensajes confidenciales.
El servidor tiene alta disponibilidad porque El servicio puede ser entregado vía ordenadores de
está en una solución de clúster. sobremesa, portátiles, smpartphones y tablets.
El tamaño del buzón es de 100 Mb pero si Se entrega un tamaño de buzón estándar y usuarios
requieres más espacio, te puedes crear un debidamente justificados pueden acceder a
archivo PST. capacidades o tamaños de buzón especiales: tenemos
Si los usuarios utilizan el cliente Firebird, deben tamaño X1, X2 y X3, cada uno definido para un tipo de
cambiarlo por Outlook, pero eso es usuario específico.
responsabilidad de los chicos que reparan los Ofrecemos una disponibilidad del 99,99% al mes y en
ordenadores. caso de fallos garantizamos restaurarlo en 1 hora, al
Por otro lado si el problema está en el menos para el 90% de los casos, lo cual está dentro de
Exchange, yo me hago cargo, pero si es la lo que el Negocio puede admitir.
conectividad de la red, es tema de los chicos de Para garantizar el uptime y la recuperación ante fallos,
Networking." nos apoyamos en nuestros proveedores internos de
servicios de Infraestructura."
1. Introducción
REFLEXIONES INICIALES
¿CUÁL ES LA REALIDAD DE LOS DEPARTAMENTOS TI?
• Cambios constantes
• Componentes y elementos sin identificar
• Costes desconocidos de los servicios del departamento
• Incapacidad de justificar inversiones
• No mediciones o pruebas de mejora
• Dependencia de “gurús”
• Soporte a usuarios desorganizado y poco eficiente
• Escasos Acuerdos de Nivel de Servicio
Posible solución  Implantación procesos ITIL
1. Introducción
REFLEXIONES INICIALES
¿QUIÉN EMPLEA LOS PROCESOS DE ITIL?
Actualmente esta pregunta se ha de reformular por… ¿Quién no usa
ITIL?
ABN‐AMRO Bank KPMG
AT&T Solutions Lucent Technologies
AXA Insurance Group Merrill Lynch
Barclays Bank Microsoft Corp.
British Airways National Westminster Bank
British Telecom Oracle
Cable & Wireless Perot Systems UK
CGI Post Office
EDS Procter & Gamble
Exxon
Royal Bank of Scotland
Federal Express
Guinness/UDV Royal Mail
Hewlett Packard Shell
IBM/ISM Vodafone
ING Bank Zurich Insurance
1. Introducción
QUIEN ES QUIEN
• itSMF® (Information Technology Service Management
Forum)
– Red mundial de grupos de usuarios de las TI que ofrecen
mejores prácticas y guías basadas en estándares para la
provisión de Servicios de TI sin compromisos con ningún
proveedor.
• AXELOS®
– Es la empresa propietaria del esquema de certificación de ITIL ®.
– Se crea para gestionar y administrar la marca ITIL® en julio 2013.
– Presta Servicios de Acreditación y Certificación a través de su red
internacional de Institutos Examinadores (EIs) que a su vez
acreditan Centros para impartir la Formación y gestionar los
correspondientes exámenes.
– Es la depositaria de la marca ITIL ® y responsable de su
conservación y mejora.
1. Introducción
¿QUÉ ES LA GESTIÓN DE SERVICIOS IT (ITSM)?
• Es una disciplina basada en procesos, enfocada
en ALINEAR E INTEGRAR los servicios de IT con
las necesidades y objetivos de la organización
y las empresas, poniendo especial énfasis en
los beneficios que el cliente final ha de recibir.
• La gestión de servicios tiene dos columnas

principales, basadas en ITIL e ISO/IEC 20000,
buenas prácticas y norma internacional,
respectivamente.
Servicio (ITIL edición 2011)
Buenas Prácticas. Certificación Individual
Servicio (ISO20000:2011)
Sistema de Calidad. Certificación Organización
1. Introducción
¿QUÉ ES ITIL?
• La Biblioteca de Infraestructura de Tecnologías de
Información, frecuentemente abreviada ITIL (del inglés
Information Technology Infraestructure Library), es un
conjunto de conceptos y prácticas (Compendio de
Buenas Prácticas) para la gestión de servicios de
tecnologías de la información.
• ITIL da descripciones detalladas de un extenso conjunto

de procedimientos de gestión, ideados para ayudar a las
organizaciones a lograr calidad y eficiencia en las
operaciones de IT.
• Estos procedimientos son independientes del proveedor

y han sido desarrollados para servir como guía que
abarque toda infraestructura, desarrollo y operaciones
de IT.
1. Introducción
¿QUÉ ES ITIL?
₋ Es un conjunto de libros que recogen las mejores prácticas para
gestionar los departamentos de Sistemas de Información.
₋ Mejores prácticas: actividades o procesos que han demostrado
resultados satisfactorios en múltiples organizaciones.
¿Por qué?
• Las empresas proveedoras de servicios IT están sujetas a un entorno
de competitividad agresivo.
• Este entorno fuerza a que las empresas del sector hagan
benchmarking entre ellas.
• La adopción de mejores prácticas extendidas en la industria colabora
en las capacidades de gestión.
• No seguir los marcos de mejores prácticas puede constituir una
desventaja para una organización IT.
1. Introducción
HISTORIA Y EVOLUCIÓN
₋ 1981: IBM Yellow Books
₋ 1986: Inicia el desarrollo de ITIL
₋ 1989: Primeras publicaciones de ITIL
₋ 1991: Fundación del grupo de usuarios (itSMF)
₋ 2000: Publicación de ITIL v2
₋ 2000: Publicación BS 15000:2000
₋ 2005: Publicación serie ISO/IEC 20000:2005 Está en proceso de mejora
continua, siendo la versión 3
₋ 2007: Publicación de ITIL v3 la última en vigor desde 2011.
₋ 2011: Publicación serie ISO/IEC 20000:2011 Referencias:
www.itil.co.uk
₋ 2011: Publicación ITIL Edición 2011 www.itsmf.es
www.itil‐officialsite.com
1. Introducción
HISTORIA Y EVOLUCIÓN
1. Introducción
¿PARA QUÉ SIRVE ITIL?
• ITIL sirve para “hacer las cosas mejor”.
• Siguiendo las buenas prácticas que ITIL provee,
podemos generar valor en nuestra
organización
• ITIL intenta integrar los objetivos de nuestra
organización, con las capacidades del área de
IT.
• Las buenas prácticas se erigen sobre la
convivencia de tres puntos clave:
• Procesos, Personas y Tecnología.
• De dicha convivencia armónica, se genera un
valor más allá de lo netamente económico, que
se mide por la satisfacción del cliente y todo lo
que conlleva.
1. Introducción
ITIL NOS APORTA:
• Visión clara y más confianza de los servicios IT
• Mejora de la calidad de los servicios suministrados
• Mayor flexibilidad y adaptabilidad para las
organizaciones a través de un entendimiento con las
IT
• Reducción en el tiempo para efectuar los cambios y
una efectividad
• Integración de los servicios IT con las necesidades
del negocio
• Asegura una mejor comunicación entre IT y el
negocio, con un lenguaje común
• Crea una base sólida para la mejora continua
• Incrementa la transparencia y control de las
organizaciones de IT
1. Introducción
CARECTERÍSTICAS DE ITIL:
• Es independiente de los proveedores
• Es independiente de la tecnología
• Está basado en “Mejores prácticas”
• PROPORCIONA:
• Independencia entre los procesos
• Alineamientos para la implementación
• Calidad en la Gestión de TI
• El QUÉ, no el Cómo ni el Quién
1. Introducción
IMPLEMENTANDO ITIL
Características
•ITIL establece procesos para conseguir
prestar servicios de forma óptima
•Implantar ITIL en una organización impacta
directamente contra la cultura de la misma
¿Cuál suele ser el principal

problema?
•Habitualmente las personas y su
resistencia inherente al cambio.
1. Introducción
VENTAJAS DE USAR ITIL
PARA CLIENTES Y USUARIOS
• La provisión de los servicios se centra más en el cliente.
• Los servicios están mejor descritos y además en un idioma que el
cliente/usuario pueda entender.
• Mejor comunicación entre el cliente/usuario con el departamento IT, gracias
al Service Desk.
PARA LA ORGANIZACIÓN IT
• La organización IT desarrolla una estructura más clara, eficaz y más
orientada hacia los objetivos de la organización.
• Se tiene mayor control sobre los servicios y la infraestructura, los cambios
se gestionan mejor.
• Una organización por procesos proporciona un buen marco de trabajo para
la externalización de algunos elementos IT.
• Facilita en gran medida la introducción de sistemas de calidad (ISO/IEC
20000).
• Facilita la comunicación interna y con los proveedores y tiende hacia la
normalización. 24
1. Introducción
CREACIÓN DE VALOR
La creación de VALOR se produce cuando se combinan:
Utilidad y Garantía del servicio
• UTILIDAD: el servicio hace lo que quiero que haga (“fit for purpose”).
• GARANTÍA: y lo hace como quiero que lo haga (“fit for use”).

La garantía está relacionada con las condiciones en cuanto a
términos como:
• Disponibilidad,
• Capacidad,
• Continuidad
• Seguridad.
Ejemplo:
• Utilidad sin garantía: servicio de email que se cae 3 horas al día.
• Garantía sin utilidad: servicio de hosting impecable que nadie ha pedido y
nadie usa.
1. Introducción
1. Introducción
CONCEPTOS
EN
ITIL
1. Introducción
CICLO DE VIDA DEL SERVICIO
₋ Constituye las “fases o etapas en la vida de un servicio
desde que se concibe, se diseña, se libera, se opera, y se
mejora hasta que se retira”.
₋ ITIL estudia las distintas fases o etapas en la vida de un
servicio, y los procesos necesarios para darles soporte.
₋ ITIL v3 hace énfasis en gestión e integración de estos
servicios en su ciclo de vida: desde el “nacimiento” hasta su
retirada.
• En v2 los servicios aparecían “mágicamente” listos para su entrega,

no se ocupaba excesivamente de su diseño y definición.
• La v3 está centrada exclusivamente en el ciclo de vida del servicio mientras
que la v2 hacía mayor foco en los procesos de entrega y de soporte.
• La v3 nos proporciona un enfoque mucho más estratégico debido a este
cambio.
1. Introducción
CICLO DE VIDA DEL SERVICIO
• Es un acercamiento a la gestión de
las áreas de IT que pone énfasis en
la Estrategia, Diseño, Transición, 3º
Operación y Mejora Continua de
los servicios proporcionados al
negocio 1º
2º
4º
• Lo hace a través de diferentes
funciones, procesos y sistemas
necesarios para gestionar estos
servicios a lo largo de su ciclo de
el
vida.
CICLO DE VIDA
1. Introducción
DEL SERVICIO
Los 7 pasos de Mejora
MEJORA CONTINUA DE LOS SERVICIOS
ESTRATEGIA DISEÑO TRANSICIÓN OPERACIÓN
DEL SERVICIO DEL SERVICIO DEL SERVICIO DEL SERVICIO
Gestión del Catálogo de Gestión de Peticiones de
Gestión de la Estrategia Gestión del Conocimiento
Servicios Servicio
Gestión de la Demanda Coordinador del Diseño Evaluación del Cambio Gestión de Eventos
Gestión de la Cartera de Validación y Pruebas de Servicio Gestión de Accesos

Servicios Gestión de Suministradores
Gestión de la Seguridad de la Planificación y Soporte a la
Gestión de las Relaciones con el Transición
Información
Negocio
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐V2‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
Gestión Financiera Gestión de la Continuidad Gestión de Vers. Y Despliegues Gestión de Incidencias
Gestión de la Disponibilidad Gestión de Cambios Gestión de Problemas
Gestión de la Configuración y Función Gestión
Gestión de la Capacidad Activos
de Aplicaciones
Gestión del Nivel de Servicios Función Gestión Función Gestión
Operaciones TI Técnica
Función Centro 30
Ángel Caro Amián Control de Instalaciones Control de Operaciones TI
www.avante.es avante@avante.es 902 117 902 Servicio al Usuario
1. Introducción
ESTRATEGIA DEL SERVICIO
• En esta fase se intenta alinear los servicios ESTRATEGIA
DEL SERVICIO
proporcionados por IT a los objetivos
estratégicos de la organización. Gestión de la Estrategia
Gestión de la Demanda
• Los requerimientos del servicio son
identificados y estipulados dentro del Paquete Gestión de la Cartera de
Servicios
del Nivel del Servicio (SLP) en un conjunto
definido de resultados a entregar a la Gestión de las Relaciones con el
Negocio
organización, estableciendo además su validez
financiera y generando las bases para su
diseño, transición y operación. Gestión Financiera
• Aquí se expone el cómo transformar la Gestión

del Servicio en un activo estratégico.
1. Introducción
DISEÑO DEL SERVICIO
DISEÑO
DEL SERVICIO
• En esta fase se diseñan y desarrollan los servicios,
Gestión del Catálogo de
los procesos y las capacidades de la Gestión del Servicios
Servicio a fin de asegurar el cumplimiento del
Coordinador del Diseño
valor establecido como parte de la estrategia.
Gestión de Suministradores
• Se utilizan los principios y métodos de diseño para Gestión de la Seguridad de la

Información
convertir objetivos estratégicos en planes
tácticos que garanticen y mejoren los niveles de
disponibilidad, capacidad, seguridad y Gestión de la Continuidad
continuidad de todos los servicios.

Gestión de la Disponibilidad
Gestión de la Capacidad
Gestión del Nivel de Servicios
1. Introducción
TRANSICIÓN DEL SERVICIO
TRANSICIÓN
DEL SERVICIO
• En esta fase se desarrollan y mejoran las
Gestión del Conocimiento
capacidades para la transición de nuevos
servicios y/o cambios a los ya existentes, Evaluación del Cambio
asegurando los requerimientos de la estrategia
de servicio. Validación y Pruebas de Servicio
Planificación y Soporte a la
• Es una guía para gestionar la complejidad Transición
relacionada con los cambios a servicios y

gestión de procesos de servicios, previniendo
Gestión de Vers. Y Desp
consecuencias indeseables, como fallos e
interrupciones. Gestión de Cambios
Gestión de la Configuración y
Activos
1. Introducción
OPERACIÓN DEL SERVICIO
• Esta fase demuestra cómo se puede alcanzar OPERACIÓN
DEL SERVICIO
la efectividad y eficiencia en la entrega y
Gestión de Peticiones de
soporte de servicios para asegurar el valor, Servicio
tanto al cliente como al proveedor del
Gestión de Eventos
servicio.
Gestión de Accesos
• La Operación del Servicio es donde los planes,
diseños y optimizaciones son ejecutados y
medidos.
Gestión de Incidencias
• Desde el punto de vista del cliente, la

Gestión de Problemas
Operación del Servicio es donde realmente se
aprecia el valor del servicio.
1. Introducción
MEJORA CONTINUA DEL SERVICIO
• Se preocupa de crear y mantener el valor para

el cliente a través de un mejor diseño,
introducción y operación de los servicios. MEJORA CONTINUA DE
• Propone la mejora de todos los procesos. LOS SERVICIOS
Los 7 pasos
• Estrategia, Diseño, Transición y Operación del de Mejora
Servicio,
• Busca identificar oportunidades para mejorar las
debilidades o fallos dentro de cualquiera de las
etapas.
1. Introducción
PROCESOS EN EL CICLO DE VIDA
1. Introducción
ORGANIZACIÓN EN BASE A PROCESOS
• Un proceso es un conjunto estructurado de
actividades diseñado para cumplir un objetivo
concreto, el cual de forma directa o indirecta crea
valor para los beneficiarios (stakeholders).
• ITIL está orientado a la gestión del ciclo de vida de

los servicios a través de procesos.
• Un proceso está diseñado para cumplir un objetivo

y para obtener unos resultados.
o Un PROCESO es un conjunto de ACTIVIDADES
organizadas.
o Cada ACTIVIDAD es asignada a un RECURSO para su
ejecución.
1. Introducción
ORGANIZACIÓN EN BASE A PROCESOS
• Un proceso es una serie estructurada de
actividades diseñadas para lograr un objetivo
específico.
• Un proceso asume una o más entradas
definidas y las convierte en resultados definidos
• Los procesos tienen usuarios/clientes.
• Los procesos recogen actividades que se

realizan en distintos puntos de la organización.
• Atraviesan la organización de forma transversal.
• Los procesos han de tender a ser:
• Eficaces (aportando al cumplimiento de
objetivos de negocio) puesto que son
repetitivos, medidos y gestionados
• Eficientes, procurando operarlos utilizando
los mínimos recursos posibles.
1. Introducción
¿QUÉ NECESITO PARA DESCRIBIR UN PROCESO?
• Entradas
• Salidas
• Actividades y subprocesos
• Roles y recursos implicados
• Control del proceso:
o Propietario o Dueño del proceso
o Objetivo del proceso (definidos en términos medibles y su relación de
beneficio al negocio)
o Métricas
1. Introducción
CARACTERÍSTICAS DE UN PROCESO
• Debe ser medible: enfocado al rendimiento

• Resultados específicos: es la razón de su
existencia
• Clientes: entrega sus resultados básicos a
clientes o stakeholders
• Responde o se lanza en base a un evento
específico
1. Introducción
HERRAMIENTA DE DEFINICIÓN DE ROLES:
MATRIZ RACI
Para cada actividad en ITIL se definen cuatro posibles roles:
• RESPONSIBLE (R): responsable de ejecutar la tarea.
• ACCOUNTABLE (A): responsable último (sólo puede haber uno, si no…).
• CONSULTED (C): persona a la que se debe consultar antes de tomar una
decisión o es consultable para la realización de una actividad en concreto.
• INFORMED (I): persona a la que se ha de informar respecto de la realización
de una tarea.
Rol 1 Rol 2 Rol 3

Ejemplo: Actividad 1 A R C
Actividad 2 AR I
1. Introducción
1. Introducción
DEFINICIÓN DE FUNCIÓN en ITIL
• Una función es una subdivisión o grupo de trabajo de una organización
que está especializada en realizar un tipo concreto de trabajo y tiene la
responsabilidad de obtener resultados concretos.
• Tienen las capacidades y recursos necesarios para alcanzar los
resultados exigidos.
• Tienen sus propias prácticas y su propio cuerpo de conocimiento.
• Proporcionan estructura y estabilidad a las organizaciones.
• En ITIL se diferencia claramente entre el concepto de proceso y función:

• Proceso implica actividades, coordinación entre personas
• Funciones se refiere a grupos de personas.
1. Introducción
FUNCIONES en ITIL
FUNCIONES DE
OPERACIONES DE
SERVICIOS
2. Gestión de 4. Centro de
1. Operaciones TI 3. Gestión Técnica
Aplicaciones Servicio al Usuario
1.1 Control de
Operaciones TI
1.2 Gestión de
Instalaciones
1. Introducción
ROL
₋ Conjunto de responsabilidades, actividades y autoridades de una
persona o equipo.
₋ Una persona o un equipo puede desempeñar múltiples roles: por
ejemplo, gestor de la configuración y gestor de cambios.
₋ Algunos roles relacionados con procesos ITIL:
₋ Dueño de proceso
₋ Gestor del proceso
₋ Dueño del servicio
1. Introducción
DUEÑO DEL PROCESO

Es el responsable de que el proceso cumpla su propósito, pero también:
• De la mejora continua del proceso. Proporciona inputs para el Programa
de Mejora del Servicio SIP (Service Improvement Program).
• Encargado del diseño y de los cambios que se realicen en el proceso
así como de la definición de la estrategia del proceso.
• Es el patrocinador.
• Es el encargado de documentarlo y publicarlo.
GESTOR DEL PROCESO

Es el responsable de que el proceso funcione:
• Planificador
• Coordinador de actividades
• De la mejora continua del proceso (ambos roles comparten esta tarea)
• Monitorización y reporting
Nota: habitualmente estos dos roles recaen sobre la misma persona pero en organizaciones de gran
tamaño tienden a separarse.
1. Introducción
DEFINICIÓN DE SERVICIO
₋ Es una forma de proporcionar valor al cliente,
facilitándole resultados que desea conseguir pero sin
ser responsables de riesgos y costes específicos.
₋ Si los clientes lo gestionaran todo, no necesitarían de
nuestros servicios.
₋ ¿Cómo facilito resultados?

₋ Aumentando el rendimiento / aumentando la
probabilidad de los resultados esperados
₋ Eliminando restricciones o impedimentos
Ejemplo:
¿Qué resultado quiere conseguir el departamento de
Ventas? Poder pasar más tiempo cerca de sus clientes.
Para ello, se implementa el servicio “acceso remoto a la
BBDD de clientes y pedidos desde el móvil”.
1. Introducción
DUEÑO DE UN SERVICIO
₋ Es el responsable ante el cliente de su definición, transición,
soporte y mantenimiento
₋ Es el contacto principal
₋ Debe identificar oportunidades de mejora
₋ Es el enlace con los dueños de procesos
₋ Facilita su monitorización y análisis de rendimiento
₋ OJO! No es el responsable de su diseño, es un perfil más
ejecutivo
1. Introducción
¿CÓMO SE EMPAQUETAN LOS SERVICIOS?
PAQUETE DE SERVICIO (SERVICE PACKAGE SP)
• Descripción detallada de un Servicio IT preparado
para ser suministrado a los clientes.
• Un Paquete del Servicio incluye:
• Uno o más Servicios Core (esenciales)
• Servicios de Soporte.
• Paquete del Nivel de Servicio
PAQUETE DE NIVEL DE SERVICIO (SERVICE LEVEL

PACKAGE SLP)
• Nivel definido de Utilidad y Garantía para un determinado
Paquete de Servicio.
1. Introducción
¿CÓMO SE EMPAQUETAN LOS SERVICIOS?
• PAQUETE DE SERVICIO (SERVICE PACKAGE SP)
– Descripción detallada de un Servicio IT preparado para ser
diseñado.
– Un Paquete del Servicio incluye:
• Un Paquete del Nivel de Servicio (SERVICE LEVEL PACKAGE SLP)
– Nivel definido de Utilidad y Garantía para un determinado Paquete de Servicio.
• Uno o más Servicios Core (esenciales)
• Servicios de Soporte
EJEMPLO
Paquete de Servicio 1: SERVICIO DE ACCESO A Paquete de Servicio 2: SERVICIO DE ACCESO A
INTERNET INTERNET PREMIUM
Servicio Core : Acceso a Servicio Core : Acceso a

Internet Internet
Servicios de Soporte : IP Servicios de Soporte : IP
Fija, Paquete Nivel Fija, Paquete Nivel
Filtrado AntiSpam, Espacio Servicio ESTÁNDAR Filtrado AntiSpam, Espacio ServicioPREMIUN
Web Web
50 MB 50 MB
UTILIDAD GARANTÍA UTILIDAD GARANTÍA
BW máx: 10 Mbps 95% de BW máx: 50 Mbps 98% de Disponibilidad
Tráfico de bajada Disponibilidad Tráfico de bajada Soporte 24x7
30 GB máx Soporte L-V 100 GB máx
08:30 –19:00
18:00
EXAMEN ITIL V3 2011
REORGANIZADO
1. 1. GESTIÓN DEL SERVICIO COMO PRÁCTICA
Y EL CICLO DE VIDA DE LOS SERVICIOS.
1.1 ¿Para qué se utiliza el modelo RACI?

A. Documentar los roles y las responsabilidades de los interesados en un
proceso o actividad
B. Definir los requerimientos para un nuevo servicio o un proceso.
C. Analizar el impacto de una incidencia en el negocio.
D. Crear un cuadro de mando que muestra el estado global de la gestión de
servicios.
1.2 ¿Cuál de los siguientes conceptos NO es una etapa del ciclo de vida
del servicio?
A. Optimización del servicio
B. Transición del servicio
C. Diseño del servicio
D. Estrategia del servicio
1.3 ¿Qué rol debe asegurar que la documentación del proceso esté
vigente y disponible?
A. El propietario del servicio
B. El director de TI
C. El gestor del conocimiento
D. El propietario del proceso
1.4 ¿Cuáles de los siguientes conceptos son características de

todo proceso?
1. Es medible
2. Entrega un resultado específico
3. Entrega sus resultados principales a un cliente o a otros
interesados
A. Sólo 1 y 3
B. Sólo 1 y 2
C. Sólo 2 y 3
D. Todos los anteriores
1.5 ¿Cuál de los siguientes conceptos son las características claves
que contribuyen al éxito de ITIL?
1. Es neutral respecto a fabricantes y vendedores
2. No es prescriptivo
3. Es una mejor práctica
4. Es un estándar
A. Sólo 3
B. Sólo 1, 2 y 3
C. Todos los anteriores
D. Sólo 2, 3 y 4
1.6 ¿Cuál de las siguientes afirmaciones acerca de los clientes internos y

externos es la MÁS correcta?
A. Los clientes externos deben recibir un mejor servicio al cliente, ya que pagan
por los servicios de TI.
B. Los clientes internos deben recibir un mejor servicio al cliente debido a que
pagan los salarios de los empleados.
C. El mejor servicio al cliente debe darse al cliente que paga más dinero.
D. Clientes internos y externos deben recibir el nivel de servicio al cliente que se
haya acordado.
1.7 ¿Cuál de los siguientes atributos debe entregar un servicio de TI a los

clientes?
A. Capacidades
B. Coste
C. Riesgo
D. Valor
1.8 ¿Cuál de los siguientes podrían ser considerados parte interesada

(stakeholder) en una gestión de proyecto de servicios?
1. Usuarios
2. Clientes
3. Suministradores
4. Funciones
A. Sólo 1 y 2
B. Sólo 3 y 4
C. Sólo 2 y 4
D. Todos
1.9 ¿Cuál de las siguientes afirmaciones es CORRECTA para TODOS
los procesos?
A. Definen funciones como parte de su diseño.

B. Entregan resultados al cliente o a interesados.
C. Son llevados a cabo por un proveedor de servicios externo, en apoyo a un
cliente.
D. Son unidades de organizaciones responsables de resultados específicos.
1.10 ¿Cuáles de los siguientes roles están definidos en el modelo RACI?

A. Responsable, Encargado, Consultado, Informado.
B. Responsable, Factible, Consultado, Informado.
C. Realista, Encargado, Consultado, Informado.
D. Responsable, Encargado, Correcto, Informado.
1.11 ¿Cuáles de las siguientes actividades debería emprender el dueño

de un servicio?
1. Representar un servicio específico en toda la organización.
2. Actualizar el sistema de gestión de configuración (CMS) después
de un cambio.
3. Ayudar a identificar mejoras en el servicio.
4. Representar un servicio específico en las reuniones del comité
asesor de cambios (CAB).
A. Sólo 2, 3 y 4
B. Todas
C. Sólo 1, 2 y 3
D. Sólo 1, 3 y 4
2. ESTRATEGIA DEL SERVICIO
2.1 ¿Cuál de las siguientes frases acerca de la creación de valor a través

de los servicios es CORRECTA?
A. La percepción que el cliente tiene acerca del servicio es un factor importante

en la creación de valor
B. El valor de un servicio únicamente puede medirse en términos financieros.
C. Entregar los resultados de un proveedor de servicios es importante en el
valor de un servicio
D. Las preferencias del proveedor de servicios determinan la percepción del
valor de un servicio
2.2 ¿Qué significa “Garantía de un servicio”?
A. El servicio se ajusta al propósito

B. No habrá fallas en las aplicaciones ni en la infraestructura asociada al servicio
C. Todos los problemas relacionados con el servicio se solucionan
gratuitamente durante un período determinado de tiempo
D. A los clientes se les aseguran ciertos niveles de disponibilidad, capacidad,
continuidad y seguridad
2.3 ¿Qué fase del ciclo de vida del servicio decide qué servicios deberían
ser ofrecidos y a quién se les va a ofrecer?
A. Mejora continua del servicio

B. Operación del servicio
C. Diseño del servicio
D. Estrategia del servicio
2.4 ¿Cuál de los siguientes sujetos es el MAS apropiado para definir el

valor de un servicio?
A. Cliente
B. Dirección de TI
C. Gestor financiero de servicios TI
D. Suministradores
2.5 ¿Cuál de los siguientes es un propósito básico de la gestión
de relaciones con el negocio?
A. Llevar a cabo actividades operacionales para dar soporte de servicios

B. Asegurar que todos los objetivos dentro del acuerdo de nivel de servicio se
cumplan
C. Maximizar el valor del contrato y la eficiencia operacional de los servicios
que son entregados
D. Entender las necesidades del cliente y asegurar que se cumplen
3. DISEÑO DEL SERVICIO
3.1 ¿Cuál de las siguientes afirmaciones es la MEJOR descripción de

un acuerdo de nivel operativo (OLA)?
A. Un acuerdo entre un proveedor de servicios de TI y otra parte de la misma

organización que colabora en la prestación de servicios
B. Un acuerdo escrito entre el proveedor de servicios de TI y sus clientes, el cual
define las metas clave y responsabilidades de ambas partes
C. Un acuerdo entre dos proveedores de servicios sobre los niveles de servicio
requeridos por el cliente
D. Un acuerdo entre un Centro de Servicios externo y el cliente de TI acerca de
los tiempos de respuesta y de reparación.
3.2 ¿Cuál es el propósito PRINCIPAL de la gestión de disponibilidad?
A. Monitorizar e informar la disponibilidad de los componentes

B. Asegurar que se cumplen todas las metas del acuerdo de nivel de servicios
(SLA)
C. Garantizar los niveles de disponibilidad de los servicios y de los componentes
D. Asegurar que la disponibilidad del servicio satisface las necesidades
acordadas con el negocio
3.3 ¿Cuáles son los tres sub-procesos de gestión de la capacidad?
A. Gestión de capacidad del negocio, gestión de capacidad del servicio y gestión

de capacidad de los componentes.
B. Gestión de capacidad de los suministradores, gestión de capacidad del
servicio y gestión de capacidad de los componentes.
C. Gestión de capacidad de los suministradores, gestión de capacidad del
servicio y gestión de capacidad de la tecnología.
D. Gestión de capacidad del negocio, gestión de capacidad de la tecnología y
gestión de capacidad de los componentes.
3.4 ¿Qué proceso es responsable de revisar regularmente los acuerdos
de nivel operativo (OLA)?
A. Gestión de suministradores
B. Gestión de niveles de servicio
C. Gestión del porfolio de servicios
D. Gestión de demanda
3.5 ¿Quiénes deben tener acceso a la política de seguridad de

la información?
A. Altos ejecutivos del negocio y el personal de TI

B. Altos ejecutivos del negocio, los ejecutivos de TI y el gestor de seguridad de
la información
C. Todos los clientes, los usuarios y el personal de TI
D. Sólo el personal de la gestión de seguridad de la información
3.6 ¿Cuál de los siguientes elementos son válidos en un paquete de

diseño de servicios (SDP)?
1. Requerimientos de negocio acordados y documentados
2. Un plan para la transición del servicio
3. Requerimientos para un proceso nuevo o modificado
4. Métricas para medir el servicio
A. Sólo 1
B. Sólo 2 y 3
C. Sólo 1, 2 y 4
D. Todos los anteriores
3.7 ¿Cuál de las siguientes actividades es parte del proceso de gestión de

niveles de servicio (SLM)?
A. El diseño del sistema de gestión de la configuración desde una perspectiva

de negocio.
B. La creación de métricas tecnológicas para alinearse con las necesidades del
cliente.
C. Monitorización del desempeño de los servicios comparado con los acuerdos
de niveles de servicio (SLAs).
D. Formación del personal del centro de servicio a usuarios acerca de cómo
lidiar con las quejas de los clientes sobre el servicio.
3.8 ¿Cuál de los siguientes elementos debería estar contenido en
un catálogo de servicios?
A. La información sobre las versiones de todo el software

B. La estructura organizacional de la compañía
C. Información de los activos
D. Detalles de todos los servicios operativos
3.9 ¿Qué etapa del ciclo de vida del servicio asegura que los métodos de
medición proporcionarán las métricas necesarias para los servicios
nuevos o modificados?
A. Diseño del servicio

B. Operación del servicio
C. Estrategia del servicio
D. Entrega del servicio
3.10 ¿Cuáles de los siguientes procesos tienen que ver con la

gestión de riesgos de los servicios?
1. Gestión de continuidad del servicio de TI
2. Gestión de seguridad de la información
3. Gestión del catálogo de servicios
A. Todos los anteriores

B. Sólo 1 y 3
C. Sólo 2 y 3
D. Sólo 1 y 2
3.11 ¿Cuál de las siguientes alternativas es la lista correcta de las cuatro P

del diseño del servicio?
A. Planificación, productos, posición, procesos

B. Planificación, perspectiva, posición, personas
C. Perspectiva, asociados (partners), problemas, personas
D. Personas, asociados (partners), productos, procesos
3.12 ¿De qué procesos se podría considerar información de entrada
para la gestión de niveles de servicio cuando se está negociando un
acuerdo de niveles de servicio (SLA)?
A. De todos los demás procesos de ITIL

B. Solamente de la gestión de disponibilidad y de la gestión de la capacidad
C. Solamente de la gestión de incidencias y de la gestión de problemas
D. Solamente de la gestión de cambios y de la gestión de versiones y
despliegues
3.13 ¿Cuál/es de los siguientes aspectos del diseño de servicios debería/n

ser considerados cuando se diseña una solución?
1. Métodos de mediciones y métricas
2. Sistemas y herramientas de gestión de la información
3. Arquitectura tecnológica
4. Los procesos requeridos
A. Sólo 1 y 2
B. Sólo 2 y 3
C. Sólo 2, 3 y 4
D. Todas
3.14 ¿Cuáles dos procesos están involucrados en la MAYORÍA de

las negociaciones y acuerdos contractuales para la provisión de
capacidad de recuperación que dan soporte a los planes de
continuidad?
A. Gestión de niveles de servicio y gestión de capacidad
B. Gestión de suministradores y gestión de niveles de servicio
C. Gestión de continuidad de servicio y gestión de niveles de servicio
D. Gestión de continuidad de servicio y gestión de suministradores
3.15 ¿Cuál de los siguientes es un tipo de acuerdo de niveles de servicio

(SLA) descrito en el libro ITIL de diseño del servicio?
A. SLA basado en la prioridad

B. SLA basado en la tecnología
C. SLA basado en la ubicación
D. SLA basado en el cliente
3.16 ¿Cuál de los siguientes NO es un propósito u objetivo de la
gestión de la disponibilidad?
A. Monitorizar e informar sobre la disponibilidad de componentes

B. Asegurar que la disponibilidad de los servicios se ajusta a las necesidades
acordadas del negocio
C. Evaluar el impacto de los cambios sobre el plan de disponibilidad
D. Asegurar que los planes de continuidad del negocio están alineados con
objetivos del negocio
3.17 ¿Cuál de las siguientes es la descripción CORRECTA de las cuatro Ps

del diseño del servicio?
A. Un proceso de cuatro pasos para el diseño de una gestión del servicio

efectiva.
B. Una definición del personal y los productos requeridos para un diseño
exitoso.
C. Una serie de preguntas que deben hacerse cuando se revisan las
especificaciones de diseño.
D. Cuatro áreas principales que deben ser consideradas durante el diseño del
servicio.
3.18 ¿Cuál de los siguientes enunciados sobre gestión de

suministradores es INCORRECTO?
A. La gestión de suministradores negocia acuerdos de nivel operacional (OLA).

B. La gestión de suministradores asegura que los suministradores cumplan con
las expectativas del negocio.
C. La gestión de suministradores mantiene información en un sistema de
gestión de suministradores y contratos.
D. La gestión de suministradores negocia acuerdos externos para ayudar en la
provisión de servicios.
3.19 ¿Cuál de las siguientes situaciones es un objetivo del proceso de

coordinación del diseño?
A. Asegurar que los objetivos de disponibilidad del servicio se cumplan.

B. Definir, documentar, acordar, monitorizar, medir y revisar los niveles de
servicios.
C. Proveer y mantener una fuente única de información consistente sobre
todos los servicios operativos.
D. Monitorizar y mejorar el desempeño de la etapa de diseño del ciclo de vida
del servicio.
3.20 ¿Qué proceso asistiría en la identificación y resolución de incidencias
y problemas, asociados con el rendimiento de un servicio o componente?
A. Gestión de la capacidad
B. Gestión de suministradores
C. Gestión de la tecnología
D. Gestión de cambios
4. TRANSICIÓN DEL SERVICIO
4.1 ¿Qué tipos de cambios NO suelen incluirse en el alcance de la

gestión de cambios?
A. Los cambios en un servidor central

B. Cambios en la estrategia del negocio
C. Cambios al acuerdo de niveles de servicios (SLA)
D. El retiro de un servicio
4.2 ¿Qué proceso es responsable de registrar las relaciones entre los

componentes del servicio?
A. Gestión de niveles del servicio

B. Gestión de porfolio de servicios
C. Gestión de activos y configuración del servicio (SACM)
D. Gestión de incidencias
4.3 ¿Cuáles de las siguientes actividades están incluidas como parte

de la transición del servicio?
1. Introducir nuevos servicios
2. Retirar servicios
3. Transferir servicios entre proveedores de servicios
A. Sólo 1 y 2
B. Sólo 2
C. Todas las anteriores
D. Sólo 1 y 3
4.4 ¿Cuál de las siguientes afirmaciones sobre un sistema de gestión de

configuración (CMS) es la CORRECTA?
A. El CMS no debe contener datos corporativos acerca de los clientes y usuarios

B. Puede haber más de un CMS
C. No debe haber más de una base de datos de gestión de la configuración
(CMDB)
D. Aunque una organización externalice sus servicios de TI tiene la necesidad de
un CMS
4.5 ¿Cuáles de los siguientes elementos estarían almacenados en
la biblioteca definitiva de medios (DML)?
1. Copias de software comprado
2. Copias de software desarrollado internamente
3. Documentación relevante de las licencias
4. Calendario de cambios
A. Todas las anteriores

B. Sólo 1 y 2
C. Sólo 3 y 4
D. Sólo 1, 2 y 3
4.6 ¿Cuál de las siguientes acciones son realizadas por la gestión de

versiones y despliegues?
1. Definir y acordar los planes versiones y despliegues
2. Asegurar la trazabilidad de los paquetes de despliegues
3. Autorizar cambios para apoyar el proceso
A. Sólo 1 y 2
B. Todas las anteriores
C. Sólo 2 y 3
D. Sólo 1 y 3
4.7 ¿Qué afirmación sobre la relación entre el sistema de gestión de

configuración (CMS) y el sistema de gestión del conocimiento de
servicios (SKMS) es la CORRECTA?
A. El SKMS es parte de la CMS

B. El CMS es parte del SKMS
C. El CMS y el SKMS son la misma cosa
D. No existe una relación entre el CMS y el SKMS
4.8 ¿Cuál es el rol del comité asesor de cambios de emergencia (ECAB)?
A. Asistir al gestor de cambios para que los cambios no urgentes se realicen

durante periodos de negocio particularmente volátiles
B. Asistir al gestor de cambios en la implementación de cambios de emergencia
C. Asistir al gestor de cambios en la evaluación de los cambios de emergencia y
en la decisión de si deben ser autorizados
D. Asistir al gestor de cambios en la prontitud del proceso de cambios de
emergencia para que no se produzcan retrasos inaceptables
4.9 ¿Cuál de las siguientes afirmaciones sobre un cambio estándar
es INCORRECTA?
A. Está pre-autorizado por la gestión de cambios

B. Siguen un procedimiento o instrucción de trabajo
C. Son los de bajo riesgo
D. Deben ser implementados lo antes posible
4.10 ¿Cuál de los siguientes mantiene las relaciones entre todos l o s

componentes del servicio?
A. El plan de la capacidad
B. La biblioteca definitiva de medios
C. El sistema de gestión de la configuración
D. Un acuerdo de nivel de servicio
4.11 ¿Cuál de las siguientes actividades asegura y desempeña la gestión de

configuración y activos del servicio?
1. Identificar los elementos de configuración (CI)
2. Que los CIs tengan una línea base
3. Controlar los cambios en los CIs
A. Todos
B. Sólo 1 y 2
C. Sólo 3
D. Sólo 2 y 3
4.12 ¿Qué proceso es primordialmente responsable de empaquetar,

construir, probar y desplegar servicios?
A. Planeamiento y soporte de la transición

B. Gestión de versiones y despliegues
C. Gestión de configuración y activos del servicio
D. Gestión del catálogo de servicios
4.13 ¿Cuál de las siguientes afirmaciones de un modelo de
cambios es CORRECTA?
A. Un modelo de cambios NO debe usarse para cambios de emergencia

B. Un modelo de cambios debe ser construido cuando se requiere un cambio
significativo
C. Un modelo de cambios pre-define pasos que deben de seguirse para
gestionar un determinado tipo de cambio
D. Los procedimientos de escalado están fuera del alcance de un modelo de
cambios
4.14 ¿Qué fase del ciclo de vida del servicio provee un marco de referencia
para evaluar las capacidades del servicio y los perfiles de riesgo antes
que un nuevo servicio o un cambio sea desplegado?
A. Estrategia del servicio

B. Mejora continua del servicio
C. Transición del servicio
D. Operación del servicio
4.15 ¿Cuáles de las siguientes son ejemplos de herramientas que

podrían ayudar en la etapa de transición del ciclo de vida del servicio?
1. Una herramienta para almacenar versiones definitivas de software
2. Una herramienta de flujo de trabajo para la gestión de cambios
3. Una herramienta de distribución automatizada de software
4. Herramientas de validación y pruebas
A. Sólo 1, 3 y 4
B. Sólo 1, 2 y 3
C. Todos los anteriores
D. Sólo 2, 3 y 4
5. OPERACIÓN DEL SERVICIO
5.1 ¿Cuál de los siguientes enunciados NO es un propósito de

operación del servicio?
A. Llevar a cabo pruebas para asegurar que los servicios están diseñados para
satisfacer las necesidades del negocio
B. Entregar y gestionar servicios de TI
C. Gestionar la tecnología utilizada para entregar servicios
D. Monitorizar el desempeño de la tecnología y los procesos
5.2 ¿A qué se refiriere el término Control de Operaciones de TI?
A. La gestión de la función de gestión técnica y de la función de gestión de

aplicaciones
B. Supervisar la ejecución y monitorización de las actividades operativas y de
eventos
C. Un conjunto de herramientas que se utilizan para monitorizar y visualizar el
estado de la infraestructura de TI y aplicaciones
D. Un Centro de servicios monitorizando el estado de la infraestructura cuando
los operadores no están disponibles
5.3 ¿Cuál de las siguientes frases sobre la gestión de problemas es/son

CORRECTAS?
1. Asegura que todas las soluciones definitivas o soluciones
temporales que requieren un cambio en un elemento de
configuración (CI) son enviados a través de la gestión del cambio
2. Proporciona información de la gestión acerca del coste de
resolver y de prevenir problemas
A. Sólo 1
B. Sólo 2
C. Ambos
D. Ninguno
5.4 ¿Cuál es el propósito del proceso de peticiones de servicio?
A. Tramitar las peticiones de servicio de los usuarios

B. Asegurar que todas las peticiones dentro de una organización de TI se
satisfagan
C. Asegurar el cumplimiento de una solicitud de cambio
D. Asegurar que los acuerdos de nivel de servicio (SLA) son cumplidos
5.5 ¿Cuál de las siguientes afirmaciones resume MEJOR el propósito de la

gestión de eventos?
A. La habilidad de detectar eventos, darles sentido y determinar las acciones de

control apropiadas
B. La habilidad de detectar eventos, restablecer el servicio a la normalidad tan
pronto como sea posible y minimizar el impacto adverso en las operaciones
del negocio
C. La habilidad de monitorizar y controlar las actividades del personal técnico
D. La habilidad de informar sobre la entrega exitosa de los servicios al comprobar
el tiempo de funcionamiento de los dispositivos de la infraestructura
5.6 ¿Cuál de las siguientes afirmaciones es una ventaja que se obtiene al

utilizar un modelo de incidencia?
A. Hará que los problemas sean más fáciles de identificar y diagnosticar

B. Significa que los tipos conocidos de incidencias no se repetirán
C. Proporciona pasos predefinidos para manejar determinados tipos de
incidencias
D. Asegura que todas las incidencias sean fáciles de resolver
5.7 ¿Cuál de los siguientes enunciados indica la secuencia CORRECTA de

actividades para el manejo de una incidencia?
A. Identificación, registro, categorización, priorización, diagnóstico inicial,

escalado, investigación y diagnóstico, resolución y recuperación, cierre.
B. Priorización, identificación, registro, categorización, diagnóstico inicial,
escalado, investigación y diagnóstico, resolución y recuperación, cierre.
C. Identificación, registro, diagnóstico inicial, categorización, priorización,
escalado, resolución y recuperación, investigación y diagnóstico, cierre.
D. Identificación, diagnóstico inicial, investigación, registro, categorización,
escalado, priorización, resolución y recuperación, cierre
5.8 ¿Cuál/es de las siguientes afirmaciones sobre el centro de
servicio al usuario/son CORRECTAS?
1. El Centro de Servicios es una función que proporciona un medio de
comunicación entre TI y los usuarios sobre todas las cuestiones
operativas
2. El Centro de Servicios debe ser el propietario del proceso de
gestión de problemas
A. Sólo 2
B. Sólo 1
C. Ambos
D. Ninguno
5.9 ¿Cuál de las siguientes alternativas representa la MEJOR acción a

ejecutar cuando se consigue una solución temporal a un problema?
A. Se cierra el registro del problema.

B. El registro de problemas permanece abierto y los detalles de la solución
temporal son documentados en el registro.
C. El registro de problemas permanece abierto y los detalles de la solución
temporal son documentados en todos los registros de las incidencias
relacionadas.
D. Se cierra el registro del problema y los detalles de la solución temporal son
documentados en una solicitud de cambio (RFC).
5.10 ¿Cuál de las siguientes afirmaciones respecto al centro de servicios es

CORRECTA?
1. Provee un punto único de contacto entre usuarios y proveedor TI
2. Gestiona incidencias y peticiones de servicio
3. Es un proceso de gestión de servicios
4. El personal del centro de servicios trata de restaurar el servicio lo
más rápido posible

B. Sólo 1, 2 y 4
C. Sólo 2 y 4
D. Sólo 2 y 3
5.11 ¿Cuál de las siguientes afirmaciones respecto a funciones
es CORRECTA?
1. Pueden incluir herramientas
2. Son grupos que utilizan recursos para llevar a cabo una o más
actividades
3. Una persona o grupo puede desarrollar múltiples funciones
4. Son más caras de implantar comparado con los procesos
A. Sólo 1, 2 y 3
B. Sólo 1, 2 y 4
C. Todas
D. Ninguna
5.12 ¿Cuál de las siguientes definiciones es la MEJOR descripción de las

actividades que lleva a cabo la gestión de las instalaciones?
A. La gestión de servicios de TI considerados como "utilidades", tales como

impresoras o puntos de acceso de red
B. Aconsejar a operaciones de TI sobre las herramientas y metodología para la
gestión de los servicios de TI
C. La gestión del entorno físico de TI, como por ejemplo el centro de
procesamiento de datos
D. La provisión y mantenimiento de las herramientas usadas por el personal de
operaciones de TI para el mantenimiento de la infraestructura
5.13 ¿Cuál de las siguientes definiciones respecto de la base de datos de

errores conocidos (KEDB) es la MEJOR?
A. La KEDB es la misma base de datos que el sistema de gestión del

conocimiento del servicio (SKMS)
B. La KEDB debería de usarse durante la fase de diagnóstico de incidencias para
intentar acelerar el proceso de resolución
C. Debe tenerse cuidado para evitar duplicar registros en la KEDB. Esto puede
ser realizado al ser posible dar acceso de creación de nuevos registros a
muchos técnicos.
D. Acceder a la KEDB debería estar limitado al centro de servicio a usuarios
5.14 Una petición de un cliente ¿debería ser SIEMPRE cumplida?
A. Si - si el cliente es externo ya que está pagando por el servicio

B. No - si el cliente es interno ya que no siempre paga por el servicio
C. No - es responsabilidad del proveedor TI de llevar a cabo las debidas
diligencias antes que la petición sea cumplida
D. Si - el proveedor del servicio debería asegurarse que todas las peticiones
para nuevos servicios sean cumplidas
5.15 ¿Cuál/es de las siguientes afirmaciones son CORRECTAS?

1. La gestión de problemas puede apoyar al centro de servicio al
usuario aportando errores conocidos para acelerar la resolución de
incidencias.
2. La gestión de problemas es la única fuente de información que
tiene la gestión de niveles de servicio respecto del impacto de los
cambios.
A. Solamente la 1
B. Solamente la 2
C. Ambas
D. Ninguna
5.16 Una herramienta de monitorización ha detectado un fallo

ocurrido en un sistema que da soporte un servicio TI en
producción. ¿Cuándo debería notificarse la incidencia?
A. Solo cuando los usuarios noten el fallo

B. Una incidencia no debería notificarse si los técnicos la han visto antes y tiene
una solución temporal (workaround)
C. Sólo si el fallo impacta y los niveles acordados del servicio no son cumplidos
D. Inmediatamente para limitar o prevenir el impacto en los usuarios
5.17 ¿Cuál de las siguientes definiciones es el MEJOR ejemplo de una
solución temporal (workaround)?
A. Un técnico instala un script para redirigir la impresión a una impresora

alternativa hasta que se pueda aplicar una solución permanente
B. Un técnico intenta resolver una incidencia de diferentes maneras. Una de
ellas funciona aunque no sabe cuál
C. Después de notificar la incidencia al centro de servicio, el usuario se dedica a
otras tareas mientras se identifica y resuelve el problema
D. Un dispositivo funciona de forma intermitente, permitiendo al usuario trabajar
con un rendimiento degradado mientras el técnico diagnostica la incidencia
5.18 ¿Cuál de las siguientes es la MEJOR definición de un modelo de

incidencias?
A. La plantilla que define el formulario de registro de incidencias usado para

informar las incidencias
B. Un tipo de incidencia que acarrea un tipo estándar (o modelo) de elemento
de configuración (CI)
C. Un conjunto predefinido de pasos a seguir al tratar con un tipo conocido de
incidencia
D. Una incidencia que es fácil de resolver
5.19 ¿Cuál de las siguientes es la MEJOR definición de un evento?
A. Una situación donde un umbral de rendimiento se ha superado y esto

impacta a un nivel de servicio acordado
B. Un cambio de estado significativo para la gestión de un servicio TI
C. Un defecto conocido del sistema que genera múltiples incidencias
D. Una reunión planificada entre los clientes y el personal TI para anunciar un
servicio nuevo o un programa de mejoras
5.20 ¿Cuál de las siguientes situaciones debería ser tratada como
una incidencia?
1. Un usuario es incapaz de acceder a un servicio durante el horario
de servicio.
2. Un miembro autorizado del personal TI no puede acceder a un
servicio durante el horario de servicio.
3. Un componente de red falla pero el usuario no percibe ninguna
alteración del servicio.
4. Un usuario contacta con el centro de servicio para informar que
una aplicación presenta un rendimiento lento.

B. Solamente 1 y 4
C. Solamente 2 y 3
D. Ninguna
5.21 ¿Cuáles son los procesos de operación del servicio que faltan
en la siguiente lista?
1. Gestión de incidencias
2. Gestión de problemas
3. Gestión de accesos
4. ?
5. ?
A. Gestión de eventos y gestión de peticiones

B. Gestión de eventos y centro de servicio al usuario
C. Gestión de las instalaciones y gestión de eventos
D. Gestión de cambios y gestión de niveles de servicio
5.22 ¿Cuál de las siguientes es la MEJOR descripción de la revisión
de un problema mayor?
A. Facilitado por el gestor de problemas, una revisión de problema mayor es

diseñado para determinar la culpa después de haber encontrado la solución
B. Ejecución como parte del comité de cambios (CAB). Se lleva a cabo después
que una solicitud de cambio (RFC) para resolver el problema ha sido
aceptada
C. Facilitado por el gestor del centro de servicios para que las lecciones puedan
ser aprendidas después de haber resuelto un problema mayor
D. Facilitado por el gestor de problemas, la revisión es dirigida para que las
lecciones puedan ser aprendidas desde el problema mayor y provea
formación y concienciación en el personal de soporte
6. MEJORA CONTINUA DEL SERVICIO
6.1 ¿Cuál es la primera actividad del enfoque de la mejora continua

del servicio (CSI)?
A. Entender la visión y objetivos del negocio

B. Llevar a cabo una evaluación inicial para conocer la situación actual
C. Acordar las prioridades para la mejora
D. Crear y verificar un plan
6.2 ¿Cuál de las siguientes alternativas NO es un tipo de métrica que se

describe en la mejora continua del servicio (CSI)?
A. Métricas del proceso

B. Métricas del servicio
C. Métricas de personal
D. Métricas tecnológicas
6.3 ¿Cuál/es de las siguientes frases respecto de los indicadores claves

de rendimiento (KPI) y de las métricas son CORRECTAS?
1. Las métricas del servicio miden el servicio de principio a fin
2. Cada KPI debería estar relacionado a un factor crítico de éxito
3. Se pueden usar métricas para identificar oportunidades de mejora
4. Los KPI pueden ser tanto cualitativos como cuantitativos
A. Sólo 1
B. Sólo 2 y 3
C. Sólo 1, 2, y 4
D. Todas
6.4 ¿Cuál de las siguientes listas de pasos del Ciclo de Deming es la

CORRECTA?
A. Planificar, Medir, Monitorizar, Informar

B. Planificar, Revisar, Reaccionar, Implementar
C. Planificar, Hacer, Actuar, Auditar
D. Planificar, Hacer, Revisar, Actuar
6.5 ¿Cuáles de las siguientes provee orientación la mejora continua
del servicio (CSI)?
1. Cómo mejorar la eficiencia y la efectividad de los procesos
2. Cómo mejorar los servicios
3. Mejorar todas las fases del ciclo de vida de los servicios
A. Sólo 1 y 2
B. Sólo 1 y 3
C. Sólo 2 y 3
D. Todas
6.6 El enfoque de mejora continua del servicio utiliza una serie de

técnicas ¿Cuál de las siguientes técnicas ayudaría MEJOR a entender
del negocio “¿dónde estamos ahora”?
A. Revisando los factores críticos de éxito

B. Entendiendo la visión del negocio Desarrollando una
C. evaluación de la línea base Revisando el registro de
D. mejora continua del servicio
2. GESTIÓN POR PROCESOS
GESTIÓN POR PROCESOS
LOS PROCESOS SON TRANSVERSALES
TIPOS DE PROCESOS
ELEMENTOS
DE
LOS PROCESOS
INTRODUCCIÓN
La Gestión
PROCESO
ELEMENTOS DE LOS PROCESOS
TIPOS
DE
PROCESOS
MAPA DE PROCESOS
P
R C
O L
V I
E E
E N
D T
O E
R
PROCESOS ESTRATÉGICOS
Procesos de Gestión
Son los procesos que dirigen y rigen la organización
PROCESOS OPERATIVOS
Procesos operativos
PROCESOS OPERATIVOS
PROCESOS DE APOYO
Procesos de apoyo
LOS MODELOS DE GESTIÓN
Y
EL ENFOQUE BASADO EN
PROCESOS
LOS MODELOS DE GESTIÓN Y EL ENFOQUE
BASADO EN PROCESOS
LOS MODELOS DE GESTIÓN Y EL ENFOQUE
BASADO EN PROCESOS
GESTION POR PROCESOS EN SISTEMAS DE
El enfoque basado en procesos en los modelos de gestión
CALIDAD
2. Gestión por Procesos I. Introducción
ISO 9001:2015
2. Gestión por Procesos I. Introducción
ISO 9001:2015
Una de las grandes incorporaciones que ha asumido la norma
UNE‐EN ISO 9001 a partir del año 2000 ha sido la orientación
a procesos.
Enfoque basado en procesos
• La aplicación de un sistema de procesos dentro de la organización, junto
con la identificación e interacciones de estos procesos, así como su
gestión para producir el resultado deseado, puede denominarse como
"enfoque basado en procesos".
ENFOQUE A PROCESOS
DECISIONES BASADAS EN DATOS
PROCESOS
PASOS GESTIÓN
POR PROCESOS
PASOS PARA GESTIONAR POR PROCESOS
1. IDENTIFICACIÓN Y SECUENCIA DE LOS
Identificación y secuencia de los procesos. Mapa de procesos
PROCESOS: MAPA DE PROCESOS
MAPA DE PROCESOS
P
R C
O L
V I
E E
E N
D T
O E
R
DETALLE DEL MAPA DE PROCESOS
P
R C
O L
V I
E E
E N
D T
O E
R
MAPA DE PROCESOS
MAPA DE PROCESOS
P
R C
O L
V I
E E
E N
D T
O E
R
MAPA DE PROCESOS
DETALLE DEL MAPA DE PROCESOS TI
ITIL
MAPA DE PROCESOS TI con ITIL
ESTRATEGIA
DEL SERVICIO ITIL
DISEÑO
DEL SERVICIO ITL
TRANSICIÓN
OPERACIÓN
DEL SERVICIO ITIL
DEL SERVICIO ITIL
Los 7 pasos de Mejora ITIL
2. DESCRIPCIÓN DE LOS PROCESOS
DIAGRAMA DE FLUJO DE UN PROCESO
DIAGRAMA DE FLUJO DE UN PROCESO
FICHA DE UN PROCESO
Descripción de las características del proceso (Ficha de proceso)
FICHA DE UN PROCESO
INFORMACIÓN EN LA FICHA DE PROCESOS
INFORMACIÓN INCLUIDA EN LA FICHA DE PROCESO
MISIÓN U OBJETO:
• Es el propósito del proceso. Hay que preguntarse ¿Cuál es la razón de ser del
proceso?, ¿Para que existe este proceso?.
• La misión u objeto debe inspirar los indicadores y la tipología de resultados que
interesa conocer.
PROPIETARIO DEL PROCESO:
• Tiene la responsabilidad del proceso
• Que este obtenga los resultados esperados (objetivos).
• Es necesario que tenga capacidad de actuación y liderazgo, para implicar y
movilizar a los actores que intervienen.
LÍMITES DEL PROCESO:
• Están marcados por las entradas y las salidas, así como por los proveedores
(quienes dan las entradas) y los clientes (quienes reciben las salidas).
• Permite reforzar las interrelaciones con el resto de procesos y es necesario
asegurarse de la coherencia con lo definido en el diagrama de proceso y en el
propio mapa de procesos.
INFORMACIÓN EN LA FICHA DE PROCESOS
INFORMACIÓN INCLUIDA EN LA FICHA DE PROCESO
Alcance del proceso: Aunque debería estar definido por el propio diagrama de proceso, el
alcance pretende establecer la primera actividad (inicio) y la última actividad (fin) del proceso,
para tener noción de la extensión de las actividades en la propia ficha.
Indicadores del proceso: son los indicadores que permiten hacer una medición y seguimiento
de cómo el proceso se orienta hacia el cumplimiento de su misión u objeto. Estos indicadores
van a permitir conocer la evolución y las tendencias del proceso, así como planificar los valores
deseados para los mismos.
Variables de control : Se refieren a aquellos parámetros sobre los que se tiene capacidad de
actuación dentro del ámbito del proceso (es decir, que el propietario o los actores del proceso
pueden modificar) y que pueden alterar el funcionamiento o comportamiento del proceso, y por
tanto de los indicadores establecidos. Permiten conocer a priori dónde se puede “tocar” el
proceso para controlarlo.
Inspecciones: Se refiere a las inspecciones sistemáticas que se hacen en el ámbito del proceso
con fines de control del mismo. Pueden ser inspecciones finales o inspecciones en el propio
proceso.
Documentos y/o registros: Se pueden referenciar en la ficha de proceso aquellos documentos o
registros vinculados al proceso. En concreto, los registros permiten evidenciar la conformidad
del proceso y de los productos con los requisitos.
Recursos: Se pueden también reflejar en la ficha (aunque la organización puede optar en
describirlo en otro soporte) los recursos humanos, la infraestructura y el ambiente de trabajo.
PROCESO vs PROCEDIMIENTO
Proceso “versus” procedimiento
PROCESO vs PROCEDIMIENTO
3. SEGUIMIENTO Y MEDICIÓN DE LOS PROCESOS
El seguimiento y la mediación de los procesos
KPI: INDICADORES DE PROCESO
Indicadores del proceso
4. MEJORA DE LOS PROCESOS
La mejora de los procesos
LA MEJORA DE LOS PROCESOS
CICLO PDCA
LA MEJORA DE LOS PROCESOS
DATOS
GESTIÓN POR PROCESOS PARA CONSEGUIR
OBJETIVOS
GESTIÓN POR PROCESOS PARA CONSEGUIR
OBJETIVOS
3.1 ESTRATEGIA DEL SERVICIO
ITIL FUNDAMENTOS
• En esta fase se intenta alinear los servicios ESTRATEGIA
DEL SERVICIO
proporcionados por IT a los objetivos
estratégicos de la organización. Gestión de la Estrategia
Gestión Financiera
• Los requerimientos del servicio son
identificados y estipulados dentro del Paquete Gestión de la Demanda
del Nivel del Servicio (SLP) en un conjunto Gestión de la Cartera de
definido de resultados a entregar a la Servicios
organización, estableciendo además su validez Gestión de las Relaciones con el

financiera y generando las bases para su Negocio
diseño, transición y operación.
• Aquí se expone el cómo transformar la Gestión

del Servicio en un activo estratégico.
MISIÓN. OBJETIVOS
• La estrategia del Servicio define las directrices para el diseño, desarrollo e
implantación de la Gestión del Servicio como un recurso estratégico.
• La estrategia ayuda a la organización a identificar, seleccionar y priorizar
oportunidades
• La MISION de la Fase de Estrategia del Servicio es desarrollar las capacidades
necesarias para lograr y mantener una ventaja estratégica:
• ¿Qué servicios deberíamos ofrecer y a quien?
• ¿Cómo nos diferenciamos de la competencia?
• Cómo realmente creamos valor para nuestros clientes?
• ¿Cómo asignar recursos de forma eficaz en una cartera de servicios?
• OBJETIVOS:
• Definir objetivos estratégicos
• Determinar las oportunidades de crecimiento
• Definir prioridades de inversión
• Crear activos estratégicos
• Superar a la competencia ofreciendo un producto diferenciado
• Desarrollar planes para tener predominio futuro sobre la competencia
CREACIÓN DE VALOR
La creación de VALOR para el cliente se produce, cuando se combinan:
Utilidad y Garantía del servicio
₋UTILIDAD: el servicio hace lo que quiero que haga (“adecuado para el propósito”).
₋GARANTÍA: y lo hace como quiero que lo haga (“adecuado para el uso”).

La garantía está relacionada con las condiciones en cuanto a términos
como:
• Disponibilidad,
• Capacidad,
• Continuidad
• Seguridad.
Ejemplo:
Utilidad sin garantía: servicio de email que se cae 3 horas al día.
Garantía sin utilidad: servicio impecable que nadie ha pedido y nadie usa.
ACTIVOS DEL SERVICIO (Assets)
• RECURSOS Y CAPACIDADES
• Los recursos y las capacidades
son tipos de activos que las
organizaciones utilizan para
crear valor en forma de bienes y
servicios
• Los RECURSOS se pueden
comprar
• Las CAPACIDADES se tienen que
desarrollar
• Las personas las convierten

ambos en valor, mediante los
servicios
ACTIVOS DEL SERVICIO (Assets)
• TIPOS DE ACTIVOS
ELEMENTO DE CONFIGURACIÓN (CI)
(Assets)
(Configuration Item)
• De Gestión
• Activos que tienen un impacto directo
• De organización
en la prestación de servicios.
• Procesos
• Un CI es un activo, componente del
• Conocimientos servicio u otro elemento que necesite
ser gestionado con el objeto de proveer
• Personas
un servicio de TI
• Información
• Los servicios, los dispositivos, el
• Aplicaciones software, la documentación…
• Infraestructura • Todo CI es un Asset, pero no al revés…
• Capital Financiero
CMS – CMDB ‐ CI
CMDB (Configuration Management Data Base)
BASE DE DATOS DE LA CONFIGURACIÓN:
• Base de datos que almacena los atributos de los CI´s y las relaciones de
unos CI´s con otros, durante todo el ciclo de vida del servicio.
CMS (Configuration Management System)

SISTEMA DE GESTIÓN DE LA CONFIGURACIÓN:
• Sistema que explota la CMDB
• Conjunto de herramientas, datos e información que se utiliza para apoyar la
gestión de activos de servicio y su configuración.
• El CMS incluye herramientas para recopilar, almacenar, gestionar,
actualizar, analizar y presentar datos sobre todos los CI´s y sus relaciones.
• El CMS también puede incluir información sobre incidentes, problemas,
errores conocidos, cambios y entregas.
CMS – CMDB ‐ CI
El CMS puede mantener una o más CMDBs
CMS (Configuration Management System): Sistema de Gestión de la Configuración

CMDB1: CMDB2:
(Configuration Management Data Base) (Configuration Management Data Base)
Base de Datos de Configuración Base de Datos de Configuración
CI´s Elementos de CI´s Elementos de

Configuración Configuración
Etc…
CMS – CMDB ‐ CI
REGISTROS TÍPICOS DE UNA CMDB
Dependiendo del tipo de CI, los atributos típicos de un Registro de CI
incluyen:
1. Identificador único (ID)
2. Nombre
3. Descripción
4. Propietario del CI / persona a cargo
5. Clasificación
1. Categoría (por ej. Servicio, Equipo, Aplicación, Documento, Personal ...)
2. Tipo (por ej. Servidor, Impresora, ... – particularización de la clasificación en categorías)
6. Información del fabricante
1. Nombre del fabricante
2. Número de serie
3. Número de licencia / referencia al contrato de licencia
7. Versión
8. Historia de modificaciones del Registro de CI
1. Fecha de creación
2. Modificaciones
3. Descripción de la modificación
4. Fecha
5. Persona a cargo
9. Localización
6. Localización física, si aplica
7. Localización lógica, si aplica (por ej. directorio del servidor)
10. Historia del estado (descripción del ciclo de vida de un CI con los datos de su
estado, por ejemplo, "A Prueba", "Activo", "Bajo Mantenimiento", "Fuera de
operación" ...)
1. Estado y versión actual
2. Historia del estado y versión (cambios históricos al estado del CI o Cambios planificados
para el futuro)
1. Cambio de estado
2. Descripción
3. Hora y fecha del Cambio de estado
11. Relación a Servicios de TI
12. Relación a otros CI’s, por ej.:
1. Es un componente de
2. Está asociado con
3. Utiliza
4. Es una característica de
5. Es una versión nueva de
6. Será reemplazado por
13. Relación con otros objetos de datos en la Gestión de Servicios de TI
11. Registros de Incidentes
12. Registros de Problemas
13. Errores Conocidos
14. Registros de Cambios
14. Detalles de la licencia
15. Referencias a documentos
11. Documentación de contratos
12. Documentación Operativa
13. Documentación del Usuario
14. Documentación relevante en emergencias
15. Otra documentación 11
TIPOS DE PROVEEDORES DE SERVICIO
• TIPO I. Proveedor INTERNO de Servicios
o Aquellos que prestan sus servicios
dentro de sus propias unidades de
negocio
• Tipo II. Unidad de Servicios COMPARTIDOS
o Aquellos que prestan servicios a
unidades de negocio que operan dentro
de la misma empresa
• Tipo III. Proveedor EXTERNO de Servicios
o Prestan servicios en entornos
competitivos que necesitan estructuras
flexibles
• 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.
- Las ventajas:
• Mayor control sobre los servicios
prestados.
• Mayores niveles de
personalización.
• Comunicación directa.
- Las desventajas:
• Los recursos pueden no estar
optimizados.
• Dificultad a la hora de
incrementar las capacidades.
• Organizaciones más endogámicas
y menos flexibles.
• Concentración de costes y riesgos
• UNIDADES DE SERVICIO COMPARTIDAS (Tipo II)
– Este tipo de proveedor presta servicio a diferentes unidades de negocio que
operan bajo un paraguas común.
- Las ventajas:
• Se comparten costes y riesgos
entre diferentes unidades.
• Posicionamiento más competitivo
frente a proveedores externos.
• Estandarización de procesos.
• Mayores opciones de crecimiento
- Las desventajas :
• Asumir actividades que no
aportan ventajas competitivas a la
organización.
• Posibles conflictos de intereses
entre diferentes unidades de
negocio.
• PROVEEDORES DE SERVICIOS EXTERNO (Tipo III)
– Estos proveedores ofrecen sus servicios en el mercado a diferentes
clientes que frecuentemente serán competidores entre sí.
- Las ventajas:
• Mayor flexibilidad y oferta.
• Se minimizan los riesgos pues
estos son compartidos entre una
amplia red de clientes.
• Procedimientos estandarizados.
- Las desventajas:
• Altos niveles de personalización
de los servicios pueden resultar
costosos.
• El cliente puede caer cautivo de
un proveedor externo.
PROCESOS DE LA ESTRATEGIA DEL SERVICIO
• Los procesos de los que consta la Estrategia del Servicio son:
1. GESTIÓN DE LA ESTRATEGIA DE TI
2. GESTIÓN FINANCIERA
3. SPM. GESTIÓN DE LA CARTERA DE SERVICIOS
4. GESTIÓN DE LA DEMANDA
5. GESTIÓN DE LAS RELACIONES CON EL NEGOCIO
• Para obtener resultados positivos, el proveedor de servicios tiene que
planificar sus servicios de manera estratégica.
• Una buena estrategia de servicio define un enfoque único para la entrega
de mejor valor
• OBJETIVOS :
• Analizar el entorno interno y externo para identificar oportunidades
• Identificar la limitaciones que pueden impedir conseguir los
resultados
• Aplicar las 4 “P´s” de la Estrategia
• Crear y mantener la “Estrategia de Planificación”
• Estrategia de TI
• Estrategia de gestión de servicios
• Planes estratégicos para cada servicio
• Asegurar que los Planes estratégicos se han traducido a Planes Tácticos y
operativos, para cada unidad
LAS 4 “P” DE LA ESTRATEGIA
• Para garantizar que los servicios desarrollados satisfacen las expectativas
del cliente son necesarias las siguientes acciones:
₋ PERSPECTIVA. Visión. ¿Dónde quiero estar?
₋ Determina la dirección tomada por el proveedor de servicios
para alcanzar sus objetivos
₋ POSICIÓN. Realidad. ¿Dónde estoy ahora mismo?
₋ Define las características propias del proveedor de servicios a los
ojos del cliente
₋ PLAN. De Acción ¿Qué voy a hacer para llegar?
₋ Plan a través del cual, los proveedores de servicios planifican e
implementan la estrategia
₋ PATRON. Cómo. ¿De que manera voy a seguir el plan?
₋ Representa los procedimientos y maneras de trabajar
• ACTIVIDADES, MÉTODOS Y TÉCNICAS
• ACTIVIDADES:
1. Definir el mercado
• Entendimiento del Cliente
• Entendimiento de las oportunidades
• Clasificación y visualización de los servicios
2. Desarrollar las Ofertas
• El espacio de mercado
• Definición de los servicios basados en resultados
• Cartera de servicios
3. Desarrollar los activos estratégicos
4. Preparase para la implementación
• FACTORES CRÍTICOS DE ÉXITO (CSF)
• Son aquellos factores claves que determinarán el éxito o fracaso de
una estrategia
• Dependen de:
• Clientes CARTERA DE
MERCADO
SERVICIO
• Competencia
• Suministradores
• Reguladores CARTERA DE
CSF
CLIENTES
• Cada CSF debe tener KPI´s que indiquen si se ha alcanzado
• Es el proceso que maneja los activos y los recursos económicos en el área
TI de una manera eficiente
• El OBJETIVO es asegurar el nivel de financiación adecuado para diseñar,
desarrollar y ofrecer Servicios de acuerdo con la estrategia diseñada
• Estima todos los INGRESOS que se esperan
• Estima los COSTES:
• Costes de Capital/Operativos (compra activos/operación)
• Costes Directos/Indirectos (del propio servicio/generales)
• Costes Fijos/Variables (dependen del volumen del servicio o no)
• Hace un PLAN DE NEGOCIO. Cálculo de la rentabilidad y del ROI(retorno inversión)
• Hace un ANÁLISIS DE IMPACTO EN EL NEGOCIO (BIA)
• ¿Qué sucede económicamente si falla o cae el servicio?
• ANÁLISIS FINANCIERO
– El Análisis Financiero contiene información sobre el costo de proveer servicios y
arroja luz sobre la rentabilidad de los servicios y los clientes.
CONTENIDO ANÁLISIS FINANCIERO
El Análisis Financiero contiene normalmente la siguiente información:
1. ANÁLISIS ENFOCADO EN EL SERVICIO
1. Costos de proveer cada servicio, detallado por tipos de costo (por ej.
licencias, materiales, laboral)
a) Costos directos (claramente atribuibles a un servicio específico)
b) Costos indirectos (compartidos entre múltiples servicios)
2. Tendencias en los costos de provisión de servicios
3. Dinámica de costos variables
a) Estimaciones de cómo cambiarán los costos en caso de
b) Aumento en la demanda del servicio
c) Disminución en la demanda del servicio
d)Límites de la demanda del servicio que requieren que el proveedor de servicio haga inversiones
significativas
1. ANÁLISIS ENFOCADO EN EL SERVICIO (cont…)
4. Potencial de Valor del Servicio (estimación del precio que un cliente aceptará pagar
por los servicios)
a) Alternativas de competencia y sus precios
b) Valor de las ventajas comparadas del proveedor del servicio (por ej. conocimientos únicos de los
procesos de negocios de los clientes, asuntos de seguridad)
c) Costos para cambiar a servicios de la competencia
5. Rentabilidad
a) Ingresos reales de cada servicio
b) Márgenes de ganancia de cada servicio
6. Identificación de servicios no viables financieramente
a) ¿Qué servicios ya no se proveen eficientemente en relación a la competencia?
b) ¿Qué servicios se proveen a los clientes resultando en una pérdida financiera?
c) ¿Qué servicios podrían resultar no rentables debido a una baja en la demanda?
2. RENTABILIDAD POR CLIENTES
1. Ingresos reales por cada cliente
2. Ganancias por cada cliente
3. VALORIZACIÓN DE ACTIVOS
1. Valores de activos tangibles de servicios (componentes de infraestructura)
2. Estimaciones de los valores de activos intangibles (por ej. pericia técnica, conocimientos de los procesos de
negocios de los clientes)
4. GASTOS REALES VS. PLANIFICADOS: PARA TODO LO QUE CUBRE EL PRESUPUESTO DE TI.
1. Pronóstico (presupuesto planificado)
2. Gastos reales registrados
3. Dado el caso, un análisis del déficit
5. ANÁLISIS DE ROI (RENTABILIDAD SOBRE LA INVERSIÓN, "RETURN ON INVESTMENT")
1. Inversión/ proyecto
2. Caso de negocio
3. Presupuesto gastado
4. Beneficios esperados
5. Beneficios realizados
• SPM: Service Portfolio Management
• El OBJETIVO de SPM es decidir cuales serán los servicios que ofrecerán el
mayor valor a la organización
• Responde a las preguntas:
• ¿Qué servicios deberíamos ofrecer y a quien?
• ¿Qué oportunidades existen en el mercado?
• ¿Por qué nos va a comprar el servicio a nosotros el cliente?
• Hace un DAFO (Debilidades, Amenazas, Fortalezas, Oportunidades)
• ¿Cómo deberíamos asignar nuestros recursos y capacidades?
• Decide que Servicios incorporar, mantener o eliminar de la Cartera de
Servicios
SP CARTERA DE SERVICIOS (Service Portfolio):
Requisito-Definido-Analizado-Aprobado Planificado-Diseñado-Desarrollado-Construido-Probado-Entregado-Operativo Retirado
SP CARTERA DE SERVICIOS
PIPE LINE SC (Service
Canal Entrada Catalogue) SERVICIOS
(En desarrollo: RETIRADOS
Catálogo de
oculto al cliente)
Servicios
SP: SERVICE
PORTFOLIO
Servicios de Apoyo subcontratados
SP. CARTERA DE SERVICIOS
• Es una lista completa de los servicios gestionados por un
proveedor de servicios.
SP: SERVICE
PORTFOLIO
• El SP contiene también:
– Compromisos contractuales vigentes,
– Información sobre el desarrollo de servicios nuevos y
– Planes de mejora continuo a los servicios
• También incluye servicios externos que forman parte integral
de la oferta de servicios a los clientes.
• El Portafolio de Servicios se divide en tres fases:
– Pipe Line: Proyección de Servicios
– SC. Catálogo de Servicios (único visible por los clientes)
– Servicios Retirados.
• La Cartera de Servicios NO es parte del CMS.
• La gestión de la cartera de servicios es
un proceso dinámico y continuo:
• DEFINIR
- Inventario de Servicios
- Caso de negocio por cada servicio
• ANALIZAR
- Inversiones para mantener el
negocio
- Inversiones para crecimiento
• APROBAR
- Añadir/Eliminar Servicios
• INSTITUIR
- Los servicios pasan a Diseño
Contenido CARTERA DE SERVICIOS (SP):
1. Nombre del Servicio
2. Situación actual (por ej. “Proyectado”, “Activo (Catálogo
de Servicios)”, “Retirado”)
SP: SERVICE
PORTFOLIO
3. Tipo de Servicio
1. Servicio de Negocio (visible para el cliente) o Servicio de
Infraestructura (invisible para el cliente, usado como
cimiento para Servicios de Negocio)
2. Internos/ externos: Servicio que se provee internamente o
un servicio contratado de un proveedor externo
4. Propietario del Servicio (responsabilidad por el
suministro)
5. Clientes que actualmente usan este servicio
6. Contactos y procedimientos para inscribirse para el servicio
1. por ej. Detalles de contacto del Gestor del Nivel de Servicio
responsable
SP: SERVICE
PORTFOLIO
2. Procedimiento para la inscripción
7. Descripción/ resultado deseado por el cliente
1. Justificación del negocio (valor añadido desde el punto de vista
empresarial)
2. Procesos/ actividades de negocios de los clientes a los que apoya
este servicio
3. Resultado deseado en cuanto a utilidad (ejemplo: "El personal de
campo puede acceder a las aplicaciones xxx y zzz de la empresa sin
limitaciones de lugar o tiempo")
4. Resultado deseado en cuanto a garantías (ejemplo: "Acceso
facilitado mundialmente de manera segura y confiable“)
8. Ofertas y paquetes, variaciones
SP: SERVICE
PORTFOLIO
1. por ej. diferentes ofertas de paquetes de Nivel de Servicio
2. por ej. diferente cobertura en husos horarios
3. por ej. diferente cobertura en regiones geográficas
9. Costos y precios
1. Esquemas de precios disponibles para proveer el servicio
2. Reglas para penalidades / reversión de cargos
10.Dependencias
1. Servicios
1. Servicios de Infraestructura requeridos (Servicios de Infraestructura de los cuales
depende este servicio)
2. Servicios que apoya (otros servicios que dependen de este servicio)
2. Infraestructura / Elementos de Configuración (CI's) importantes, como del que depende este
servicio)
11.Cambios planificados al servicio (si alguno)
1. Referencias a planes relevantes (por ej. Plan Estratégico de Servicios,
SP: SERVICE
PORTFOLIO
Plan de Mejoras al Servicio/ SIP)
2. Caso de negocio / análisis de costo‐beneficio
3. Prioridad de cambio contemplado
4. Riesgos asociados con el cambio contemplado
5. Calendario e información de situación actual
12.Referencias a documentos adicionales
13.Glosario
SKMS Sistema de Gestión del Conocimiento del Servicio
(Service Knoledge Management Sistem)
La Cartera de Servicios (SP) y el Sistema de Gestión de la Configuración (CMS)
forman parte del SKMS
4. DM. GESTIÓN DE LA DEMANDA
• DM: Demand Management
• OBJETIVOS:
• Adaptar el suministro (Capacidad) a la demanda del servicio
(sincronizar la producción y el consumo).
• Demasiada Capacidad, implica costes que no generan valor
• Una Capacidad insuficiente, implica baja calidad del
servicio y limita crecimiento
• Para predecir con la mayor exactitud posible la demanda futura del
servicio:
• PBA PATRONES DE ACTIVIDAD DE NEGOCIO (Patterns of
Business Activity). Como el cliente usará el servicio 
o UP Perfiles de Usuarios (User profile) pueden ser asociados a
uno o varios PBA
• Además de Predecir DM, debe “gestionar” la demanda
• CONCEPTOS:
• SP: PAQUETE DE SERVICIO (Service Package)
• Es una descripción detallada de un servicio TI, que está
disponible para entregarse a los clientes.
• CSP: PAQUETE DEL SERVICIO PRINCIPAL (Core Service Package)

• Es una descripción detallada de un servicio esencial que puede
tener dos o más SLP.
• SLP: PAQUETE DE NIVEL DE SERVICIO (Service Level
Package)
• Es un nivel definido de funcionalidad y garantía para un
determinado CSP.
• Cada SLP está diseñado para satisfacer las necesidades
de un determinado patrón de actividades de negocio.
Un CSP
con varios
SLP
La combinación de SP y SLP forman Líneas de Servicios LOS (Line
of Services)
ENTREGABLES PRINCIPALES
SP SDP SAC
SLP
SERVICE SERVICE
DESIGN ACCEPTANCE
SERVICE PACKAGE CRITERIA
PACKAGE
SERVICE
LEVEL PACKAGE
• ACTIVIDADES:
• Desarrollo de una oferta diferenciada
• Balancear la oferta con la demanda
• Ayuda a responder a los cambios de los PBA de los clientes
• Analiza los Perfiles de Usuarios (UP: User Profile)
• Desarrolla los SP (Paquetes de Servicio)
• Defines los SLP (Paquetes de Nivel de Servicio)
• Define las LOS (Líneas de Servicio)
5. BRM. GESTIÓN DE RELACIONES CON EL NEGOCIO
• BRM: Business Relationship Management
• OBJETIVOS:
• Asegurar una buena relación del Proveedor TI con los clientes
• Entender las necesidades y requerimientos de los clientes
• Asegurar que el SP y SLP satisface las necesidades de los clientes y lo
que están dispuestos a pagar
• ACTIVIDADES
• Mantener relaciones con los clientes
• Identificar los requisitos de Servicio
• Inscribirse los clientes de los servicios estándar
• Manejar quejas del cliente
• Monitorear quejas del cliente
• Encuesta de Satisfacción del Cliente
ROLES EN LA FASE
DE ESTRATEGIA
ROLES PRINCIPALES
• Consejo de Dirección de TI (ISG)
– El Consejo de Dirección de TI (IT Steering Group, ISG) establece la dirección y la
Estrategia del Servicios de TI.
– Incluye a miembros de la alta dirección de la empresa y de TI.
– El ISG revisa las estrategias de la empresa y de TI para asegurar que estén en
concordancia.
– También establece prioridades para el desarrollo de servicios y proyectos.
• Gestor del Portafolio de Servicios
– Determina la Estrategia del Servicio al cliente en coordinación con el Consejo
de Dirección de TI (ISG), y desarrolla las ofertas y capacidades del proveedor de
servicios.
• Gestor Financiero
– Se ocupa de gestionar el presupuesto, la contabilidad y los requisitos de cobro
de un proveedor de servicios de TI.
• Dueños y Gestores del resto de procesos
3.2 DISEÑO DEL SERVICIO
ITIL FUNDAMENTOS
DISEÑO
DEL SERVICIO
• En esta fase se diseñan y desarrollan los servicios,
Gestión del Catálogo de
los procesos y las capacidades de la Gestión del Servicios
Servicio a fin de asegurar el cumplimiento del
Coordinador del Diseño
valor establecido como parte de la estrategia.
Gestión de Suministradores
• Se utilizan los principios y métodos de diseño para Gestión de la Seguridad de la

Información
convertir objetivos estratégicos en planes
tácticos que garanticen y mejoren los niveles de
disponibilidad, capacidad, seguridad y Gestión de la Continuidad
continuidad de todos los servicios.

Gestión de la Disponibilidad
Gestión de la Capacidad
Gestión del Nivel de Servicios
MISIÓN. OBJETIVOS
• El Diseño del Servicio se ocupa del diseño y desarrollo de servicios y sus
procesos relacionados para su paso a producción.
• No afecta solo a los nuevos servicios, sino también a los que han sido
modificados.
• Sus principales OBJETIVOS se resumen en:
₋ Contribuir a los objetivos del negocio
₋ Contribuir (en la medida de lo posible) a ahorrar tiempo y dinero
₋ Minimizar o prevenir riesgos
₋ Contribuir a satisfacer las necesidades presentes y futuras del
mercado
₋ Evaluar y mejorar la eficacia y estándares para servicios de TI
(desarrollo de medidas y métricas)
₋ Contribuir a mejorar la calidad de los servicios de TI
REQUERIMIENTOS
• Para garantizar que los servicios desarrollados satisfacen las expectativas
del cliente son necesarias las siguientes acciones:
₋ El nuevo servicio se debe añadir desde la fase de concepto en la
Cartera de Servicios.
₋ Los requerimiento del cliente SLR (Service Level Requirement) deben
estar claros antes de la entrega
₋ En base a los SLR el equipo de Gestión de la Capacidad puede
modelar los requisitos dentro de la infraestructura existente
₋ Gestión Financiera participa si hay nueva infraestructura
₋ Antes de empezar la implementación
₋ BIA (Business Impact Analysis) Análisis de Impacto en el negocio
₋ ITSCM (IT Service Continuity Management) Gestión de la
Disponibilidad
SP SDP SAC
SLP
SERVICE SERVICE
DESIGN ACCEPTANCE
PACKAGE
SERVICE
LEVEL PACKAGE
CONCEPTOS
• PROVEEDOR DE SERVICIOS (SP: Service Provider)
₋ Entidad responsable de la entrega de un servicio
• PROVEEDOR (SUPPLIER)
₋ Cualquier entidad externa necesaria para proporcionar las líneas de ayuda a
los componentes requeridos, para crear las redes de valor del servicio.
• SLR (Service Level Requirements) Requerimientos a Nivel del Servicio
₋ Definición detallada de las necesidades de un cliente
• TIPOS DE ACUERDOS:
₋ SLA (Service Level Agreement)
₋ Un acuerdo legal con un cliente. Cubre las obligaciones que cada entidad
tiene con la otra
₋ UC (Underpining Contract)
₋ Un acuerdo legal con un proveedor. Cubre las obligaciones que cada
entidad tiene con la otra
₋ OLA (Operational Level Agreement)
₋ Acuerdo de Nivel Operacional. Igual que SLA pero con un cliente interno
TIPOS DE ACUERDOS DE SERVICIOS
(Operational Level Agreement) OLA

SLR
Acuerdo de Nivel Operacional (Service Level Requirements)
Requerimientos a
Nivel de Servicio
SP (Service
SUPPLIER UC Provider) SLA CUSTOMER
Proveedor Proveedor del Cliente
Servicio
(Underpinning Contract) (Service Level Agreement)

Acuerdo con proveedores Acuerdo de Nivel de Servicio
ACUERDOS DE SERVICIOS
SLA/OLA/UC. PERSPECTIVA GENERAL
– Esta lista de control cubre tres tipos de documentos que tienen estructuras idénticas:
• Acuerdo de Nivel de Servicio (Service Level Agreement, SLA) – un acuerdo entre un proveedor de
servicio de TI y un cliente
• Acuerdo de Nivel Operacional (Operational Level Agreement, OLA) – un acuerdo entre un proveedor
de servicio de TI y otra parte de la misma organización; gobierna la prestación de un Servicio de
Apoyo
• Contrato de Apoyo (Underpinning Contract, UC) – un contrato entre un proveedor de servicio de TI y
un proveedor externo de un Servicio de Apoyo
– Ya que UC’s son contratos formales con suministradores externos, pueden contener referencias a
términos y condiciones generales o una primera sección adicional que especifica detalles comerciales y
legales.
• Los siguientes datos sobre los Acuerdos de Nivel de Servicio (SLA’s) son por lo tanto igualmente
válidos para los OLA’s y UC’s, con un punto importante a considerar: al acordar un SLA, el Gestor
de Nivel de Servicio funciona como un proveedor de servicios al negocio; sin embargo, en los
casos de OLA/ UC tiene el rol de cliente.
• El Acuerdo de Nivel de Servicio extiende las definiciones de los servicios del Catálogo de
Servicios, al definir detalles de metas de niveles de servicio, responsabilidades mutuas y otros
requisitos específicos de un servicio que se provee a cierto (grupo de) cliente(s). Enfoca la
definición de requisitos desde el punto de vista del cliente.
• El documento de SLA sale de los Requisitos de Nivel de Servicio (SLR’s) durante el proceso de
Diseño del Servicio (Service Design).
CONTENIDO ACUERDO DE NIVEL DE SERVICIO:
Un Acuerdo de Nivel de Servicio contiene normalmente la siguiente información (el contenido real
puede variar dependiendo del tipo de servicio):
1. Nombre del Servicio
2. Información de autorización (con fecha y lugar)
1. Gestor del Nivel de Servicio
2. Cliente
3. Duración del contrato
1. Fechas de comienzo y final
2. Reglas sobre la terminación del acuerdo
4. Descripción/ resultado deseado por cliente
1. Procesos/actividades de negocios de los clientes a los que apoya este servicio
2. Resultado deseado en términos de utilidad (por ej. “Personal de campo puede acceder a las
aplicaciones xxx o yyy de la empresa sin limitaciones de lugar y hora”)
3. Resultado deseado en términos de garantía (por ej. "El acceso se facilitará en todo el mundo
de manera segura y confiable“)
CONTENIDO ACUERDO DE NIVEL DE SERVICIO:
5. Criticidad del servicio y de los activos
1. Identificación de activos esenciales para el negocio conectados con el servicio
1. Funciones Vitales para el Negocio (Vital Business Functions, VBF’s) apoyadas por el
servicio
2. Otros activos críticos usados dentro del servicio (por ej. ciertos tipos de datos del
negocio)
2. Estimación del impacto en el negocio causado por una pérdida de servicio o activos (en
términos monetarios, o usando un esquema de clasificación)
6. Referencia a contratos adicionales que también se aplican (por ej. a un SLA
Maestro, o en el caso de los UC’s, a contratos con importantes suministradores
subcontratados)
7. Tiempo del servicio
1. Horario que estará disponible el servicio
2. Excepciones (por ej. fines de semana, días feriados)
3. Periodo de mantenimiento
CONTENIDO ACUERDO DE NIVEL DE SERVICIO
8. Tipos y niveles de apoyo requeridos
1. Apoyo in situ
1. Área/ localizaciones
2. Tipos de usuarios
3. Aplicaciones y componentes de infraestructura a apoyar
4. Tiempos de reacción y resolución (según prioridades, definiciones de prioridades, por ej.
para la clasificación de Incidentes)
2. Apoyo a distancia
1. Área/ localizaciones
2. Tipos de usuarios (grupos de usuarios con acceso al servicio)
3. Aplicaciones y componentes de infraestructura a apoyar
4. Tiempos de reacción y resolución (definición de las prioridades, según las mismas, por ej.
para la clasificación de Incidentes)
9. Requisitos/ metas de Nivel de Servicio
1. Metas de Nivel de Disponibilidad
1. Condiciones bajo las cuales se considera que el servicio no está disponible (por ej. si el
servicio se ofrece en varios lugares)
2. Metas de disponibilidad (definición exacta de cómo se calcularán los niveles de
disponibilidad acordados, basados en el tiempo de servicio e inactividad acordado)
3. Metas de confiabilidad (requeridas por algunos clientes, usualmente definidas como
Tiempo Medio Entre Fallos (MTBF) o Tiempo Medio Entre Incidentes de Servicio [MTBSI])
4. Metas de sustentabilidad (requeridas por algunos clientes, usualmente definidas como
Tiempo Medio Para Restaurar el Servicio [MTRS])
5. Tiempos de inactividad para mantenimiento (cantidad de tiempos de inactividad
permitidos, periodos de pre notificación)
6. Restricciones en el mantenimiento, por ej. ventanas permitidas para mantenimiento,
restricciones de mantenimiento durante temporadas
7. Procedimientos para anunciar interrupciones al servicio (planificados/ sin planificar)
8. Requisitos referentes a los informes de disponibilidad
10. Requisitos/ metas de Nivel de Servicio
2. Metas de capacidad/ desempeño
1. Capacidad requerida (límite más bajo/ alto) para el servicio, por ej.
1. Números y tipos de transacciones
2. Números y tipos de usuarios
3. Ciclos del negocio (diario, semanal) y variaciones por temporadas
2. Tiempo de respuesta de aplicaciones
3. Requisitos de escalabilidad (suposiciones para el aumento a mediano y largo plazo en el
volumen del trabajo y la utilización del servicio)
4. Requisitos referentes a los informes de capacidad y desempeño
3. Compromisos de Continuidad del Servicio (disponibilidad del servicio en caso de un
desastre)
2. Tiempo en que un nivel de servicio definido debe ser restablecido
3. Tiempo en que los niveles normales de servicio deben ser restaurados
11.Estándares técnicos ordenados y la especificación de la interfaz del servicio
técnico
12. Responsabilidades
11. Deberes del proveedor de servicios
12. Deberes del cliente (socio en el contrato para el servicio)
13. Responsabilidades de los usuarios del servicio (por ej. con respecto a la seguridad de TI)
14. Aspectos de la Seguridad de TI que se deben observar al usar el servicio (dado el caso,
referencias a Políticas de Seguridad de TI relevantes)
13.Costos y precios
11. Costo de proveer el servicio
12. Reglas para penalidades/ reversiones
14.Historia de Cambios
15.Lista de anejos
LOS CINCO ASPECTOS DEL DISEÑO
• Para conseguir la máxima calidad posible con un efoque de mejora
continua, la organización necesita un planteamiento estructurado.
• Los 5 aspectos del diseño:

1. El diseño de soluciones de servicio
2. El diseño de la cartera de Servicios
(SP: Service Portfolio)
3. El diseño de la Arquitectura
4. El diseño de los Procesos
5. El diseño de Métricas y sistemas
de medición
1. EL DISEÑO DE SOLUCIONES DE SERVICIO
• Análisis de los requisitos acordados con el negocio
• Revisión de los servicios e infraestructuras TI existentes
• Diseño de los servicios a partir de los requisitos
• Inclusión en el diseño de los Criterios para la Aceptación del Srvicio (SAC:
Service Acceptance Criteria)
• Evaluación del coste de alternativas
• Acuerdo sobre gastos y costes
• Evaluación y confirmación de beneficios para el negocio
• Conocer los deseos y requerimientos del cliente SLR (Service Level
Requirements)
• Monitorización de los servicios, de acuerdo con la estrategia general
• Garantía de los controles de seguridad
• Acuerdos de soporte necesarios para la provisión del servicio
• Elaboración del SDP (Service Design Package) Paquete de Diseño del
Servicio
2. EL DISEÑO DE LA CARTERA DE SERVICIOS (SP) SP se termina de crear en
Diseño (SC)
• Describe la provisión del servicio en términos del valor que genera para el
cliente y debe incluir toda la información del servicio y su estado
Requisito-Definido-Analizado-Aprobado Planificado-Diseñado-Desarrollado-Construido-Probado-Entregado-Operativo Retirado
SP CARTERA DE SERVICIOS
PIPE LINE SC (Service
Canal Entrada Catalogue) SERVICIOS
(En desarrollo: RETIRADOS
Catálogo de
oculto al cliente)
Servicios

SP ES PARTE DE SKMS
SKMS (Service Knoledge Management System):
Sistema de Gestión de Conocimientos del Servicio
SP: Cartera de servicios
Todos los documentos generados
por el resto de procesos:
PIPE SERVICIOS
LINE SC RETIRADOS Calidad:
Políticas, procesos,
procedimientos, etc
Servicios:
SPs, informes del servicio.
Activos y Configuración:
CMS Sistema de Gestión de la Configuración Activo financiero, información
CMDB: del CMS, informes de estado,
Base de Datos de Configuración datos de la CMDB
Centro de Servicios / Soporte:
Clientes, usuarios, CIs,
CI´s incidencias, problemas,
Elementos de cambios, entregas,
Configuración rendimientos
PARA CADA SERVICIO, LA CARTERA DE SERVICIOS (SP) DEFINE:
1. Nombre
2. Situación actual (por ej. “Proyectado”, “Activo (Catálogo de Servicios)”, “Retirado”)
3. Tipo de Servicio
1. Servicio de Negocio (visible para el cliente) o Servicio de Infraestructura (invisible para el
cliente, usado como cimiento para Servicios de Negocio)
2. Internos/ externos: Servicio que se provee internamente o un servicio contratado de un
proveedor externo
4. Propietario del Servicio (responsabilidad por el suministro)
PORTFOLIO
SP: SERVICE
5. Clientes que actualmente usan este servicio
6. Contactos y procedimientos para inscribirse para el servicio
1. por ej. Detalles de contacto del Gestor del Nivel de Servicio responsable
2. Procedimiento para la inscripción
7. Descripción/ resultado deseado por el cliente
1. Justificación del negocio (valor añadido desde el punto de vista empresarial)
2. Procesos/ actividades de negocios de los clientes a los que apoya este servicio
3. Resultado deseado en cuanto a utilidad (ejemplo: "El personal de campo puede acceder a las
aplicaciones xxx y zzz de la empresa sin limitaciones de lugar o tiempo")
4. Resultado deseado en cuanto a garantías (ejemplo: "Acceso facilitado mundialmente de
manera segura y confiable“)
PARA CADA SERVICIO, LA CARTERA DE SERVICIOS (SP) DEFINE:
8. Ofertas y paquetes, variaciones
1. por ej. diferentes ofertas de paquetes de Nivel de Servicio
PORTFOLIO
2. por ej. diferente cobertura en husos horarios
SP: SERVICE
3. por ej. diferente cobertura en regiones geográficas
9. Costos y precios
1. Esquemas de precios disponibles para proveer el servicio
2. Reglas para penalidades / reversión de cargos
10.Dependencias
1. Servicios
1. Servicios de Infraestructura requeridos (Servicios de Infraestructura de los cuales depende este
servicio)
2. Servicios que apoya (otros servicios que dependen de este servicio)
2. Infraestructura / Elementos de Configuración (CI's) importantes, como del que depende este servicio)
11.Cambios planificados al servicio (si alguno)
1. Referencias a planes relevantes (por ej. Plan Estratégico de Servicios, Plan de Mejoras al Servicio/ SIP)
2. Caso de negocio / análisis de costo‐beneficio
3. Prioridad de cambio contemplado
4. Riesgos asociados con el cambio contemplado
5. Calendario e información de situación actual
12.Referencias a documentos adicionales
13.Glosario 20
3. EL DISEÑO DE LA ARQUITECTURA
• Es el desarrollo y mantenimiento de políticas, estrategias, arquitectura,
diseños, documentos, planes y procesos de TI para el despliegue,
implementación y mejora de servicios y soluciones de TI apropiados en
toda la organización.
• HAY QUE GARANTIZAR QUE:
• Satisface las necesidades del negocio
• Equilibrio entre: innovación, riesgos y costes
• Cumple las políticas, estrategias, marcos de trabajo, etc
• Hay buena coordinación entre diseñadores, planificadores, estrategas,
etc
• MARCOS DE TRABAJO
• Arquitectura de Servicios
• Arquitectura de aplicaciones
• Arquitectura de la Información
• Arquitectura de la infraestructura TI
• Arquitectura del entorno
4. EL DISEÑO DE LOS PROCESOS
• ITIL se basa en el trabajo con procesos definidos
• La definición de las actividades y de sus entradas y salidas permite trabajar
de una forma más eficaz y más orientado al cliente
5. EL DISEÑO DE MÉTRICAS Y SISTEMAS DE MEDICIÓN

• Para dirigir y mejorar de forma eficaz un proceso, es necesario medir
• Los tipos elementos que se pueden medir son cuatro:
• Progreso
• Cumplimiento
• Eficacia
• Eficiencia
MODELOS DE DISEÑO DEL SERVICIO
• La elección del modelo a utilizar para desarrollar servicios TI
depende en gran medida del modelo escogido para la provisión
del servicio.
• Antes de adoptar un modelo. Análisis de los siguientes
elementos:
– Directrices y demandas del negocio
– El ámbito y las capacidades del proveedor de servicios actual
– Los requisitos y objetivos del nuevo servicio
– El ámbito y las capacidades de los proveedores externos
– La madurez de las organizaciones y sus procesos
– La cultura de las organizaciones
– La infraestructura de TI, aplicaciones, datos, servicios y otros componentes
– El nivel de gobierno corporativo y de TI
– El presupuesto y los recursos disponibles
– El nivel del personal disponible y sus aptitudes
LAS CUATRO “P” DEL DISEÑO
• Para asegurarse de que el diseño de servicios tenga éxito, hay cuatro P que
deben ser considerados cuando se trata de diseño de servicios:
• Personas (People)
• Producto (Products)
• Procesos (Processes)
• Socios o asociados
(Partners)
PAQUETE DE DISEÑO DEL SERVICIO
SDP (Service Design Package)
• El SDP se basa en los Requisitos del Nivel de Servicio (SLP).
• Especifica más esos requisitos desde el punto de vista del
cliente y define cómo se cumplen desde un punto de vista
técnico y organizativo.
• Combina los Servicios de Apoyo en un paquete, para brindarle
un servicio al cliente.
• El SDP pasa del Diseño del Servicio al proceso de Transición del
Servicio
• Detalla toda la información requerida para desarrollar la
solución del servicio, incluyendo un calendario preliminar
(propuesto) para la fase de Transición del Servicio.
CONTENIDO TÍPICO DE UN SDP
El Paquete de Diseño del Servicio contiene la siguiente información (los detalles reales pueden variar,
dependiendo del tipo de servicio):
PARTE 1: ENCABEZADO
1. Nombre del servicio
2. Información de la autorización (con lugar y fecha)
A. Autorización del Gestor de Diseño del Servicio
B. Autorización del Paquete de Diseño del Servicio por la Gestión de Servicios (confirmación
que los requisitos, según presentados en este documento, se pueden cumplir; donde sea
necesario, especificar cualquier condición que debe cumplirse antes de que el servicio esté
operativo)
a) Gestor de la Capacidad
b) Gestor de la Disponibilidad
c) Gestor de la Continuidad del Servicio de TI
d) Gestor de la Seguridad de TI
e) Gestor de Cumplimiento
f) Gestor Financiero
PARTE 2: ESPECIFICACIONES DE REQUISITOS DETALLADOS COMO BASE DE LA
Esta parte se basa en los Requisitos de Nivel de Servicio y especifica con más detalle qué
condiciones deben cumplir el servicio nuevo y sus aplicaciones e infraestructura subyacentes;
provee toda la información necesaria para construir el servicio nuevo.
1. Requisitos de Nivel de Servicio (referirse al documento de SLR, que define los Requisitos de Nivel de
Servicio)
2. Requisitos funcionales (el documento SLR contiene una descripción resumida del resultado deseado por el
cliente; sin embargo, puede que sea necesario especificar los requisitos funcionales con más detalles,
especialmente si se van a desarrollar nuevas aplicaciones o sistemas)
3. Requisitos de seguridad de TI que son relevantes para el servicio
4. Requisitos de cumplimiento que son relevantes para el servicio
5. Limitaciones arquitectónicas (por ej. tecnología o vendedores específicos )
6. Requisitos de interfaz (por ej. si un sistema nuevo necesita comunicarse con otros sistemas)
7. Requisitos de migración (por ej. si los datos van a migrar de una aplicación existente a una nueva)
8. Requisitos operacionales (por ej. requisitos para mecanismos de backup y restauración, compatibilidad con
herramientas existentes para monitorizar el sistema)
9. Derechos de acceso requeridos (qué usuarios o grupos de usuarios puedan requerir acceso al servicio, y
qué niveles de acceso se les debe proveer)
PARTE 3: PLAN DE IMPLEMENTACIÓN TÉCNICA Y ORGANIZACIONAL
Esta parte detalla lo que se debe hacer durante la Transición del Servicio para cumplir con requisitos
específicos. Información de la autorización (con lugar y fecha)
1. Estrategia de transición (un bosquejo breve del enfoque seleccionado para implementar un
servicio nuevo)
A. Estrategia de pruebas
B. Estrategia de despliegue
C. Concepto de migración
D. Estrategia de refuerzo en caso de fracaso del despliegue
2. Descomposición del Servicio de Negocio en Servicios de Apoyo
A. Servicios Internos de Apoyo que son base de este servicio
a) Nombres de Servicios de Apoyo
b) Proveedores de los servicios (Propietarios de Servicio responsables)
c) Referencias a Acuerdos de Nivel Operacional (OLA’s)
d) Cambios requeridos a los OLA’s, si los OLA’s existentes no son suficiente para establecer el negocio
B. Servicios de Apoyo suministrados externamente usados como base para este servicio
a) Nombres de servicios externos
b) Nombres de suministradores
c) Gestor de Suministradores responsable
d) Referencias a Contratos de Apoyo (UC’s)
e) Cambios requeridos a los UC’s, si los UC’s existentes no apoyan la introducción del servicio nuevo
3. Detalles de cambios técnicos requeridos para construir, probar, desplegar y
operar el servicio
A. Desarrollo/ personalización de aplicaciones para el servicio (por ej. si el servicio a
introducir está basado en el sistema SAP o una aplicación personalizada)
B. Herramientas de apoyo
a) Desarrollo/ personalización de herramientas de migración
b) Desarrollo/ personalización de herramientas de pruebas
c) Desarrollo/ personalización de herramientas de despliegue
d) Desarrollo/ personalización de herramientas de refuerzos en caso de fracaso del
despliegue
C. Modificaciones a la infraestructura requeridas para construir, probar, desplegar y
operar el servicio
a) Componentes de infraestructura que se comprarán e instalarán
b) Componentes de infraestructura que se (re)configurarán
D. Cambios requeridos a las facilidades físicas
4. Cambios organizacionales requeridos para implementar y operar el servicio
A. Recursos humanos que se añadirán
a) Especificación de recursos requeridos
b) Estrategia para adquirir los recursos
B. Destrezas que se desarrollarán
a) Especificación de destrezas requeridas
b) Estrategia para adquirir las destrezas
C. Cambios a los procesos
a) Lista de procesos de TI que deben ser cambiados o creados, incluyendo los
propietarios de los procesos
b) Especificación detallada de cambios requeridos en los procesos de TI, por ej. en la
forma de diseños de procesos
5. Concepto operacional, por ej.
A. Tareas administrativas de rutina que se llevarán a cabo
B. Reglas para archivar y backup
PARTE 4: INFORMACIÓN DE PLANIFICACIÓN
Esta parte establece un calendario propuesto para la implementación del servicio y provee
un estimado de los recursos requeridos; esta información puede ser actualizada luego por las
Gestiones de Cambios, Ediciones o Proyectos.
1. Plan Preliminar de Transición del Servicio
1. Importantes fases e hitos del proyecto
2. Calendario propuesto
3. Recursos humanos requeridos
2. Presupuesto requerido para implementar el servicio (detallado)
PROCESOS DEL DISEÑO DEL SERVICIO
• Los procesos de los que consta el Diseño de Servicio son:
1. SCM. GESTIÓN DEL CATÁLOGO DE SERVICIOS
2. SLM. GESTIÓN DEL NIVEL DE SERVICIO
3. CM. GESTIÓN DE LA CAPACIDAD
4. AM. GESTIÓN DE LA DISPONIBILIDAD
5. ITSM. GESTIÓN DE LA CONTINUIDAD DEL SERVICIO
6. ISMS. GESTIÓN DE LA SEGURIDAD DE LA INFORMACIÓN
7. SM. GESTIÓN DE SUMINISTRADORES
8. DC. COORDINACIÓN DEL DISEÑO
• El Catálogo de Servicios (SC) es una parte importante de la Cartera de
Servicios (SP)
• SP se crea en la fase de ESTRATEGIA
• Cuando un producto queda listo para su uso, diseño prepara las
especificaciones que se pueden incluir en el SP
• El PROPÓSITO de SCM es proporcionar una fuente única de información
consistente sobre todos los servicios acordados y garantizar su
disponibilidad para quien lo necesite
• La META de SCM es el desarrollo y mantenimiento de un SC que contenga todos
los detalles, el estado, las posibles interacciones y las dependencias mutuas de
todos los servicios actuales y de los que están siendo preparados para su
funcionamiento operacional.
• El SC es el único recurso que contiene información constante sobre
todos los servicios del proveedor de servicios.
• ACTIVIDADES:
• Acuerdo y documentación de una definición del servicio con
todas las partes relevantes.
• Interacción con SPM para acordar contenido de cada
• Producción y mantenimiento del SC
• Interacción con los equipos de soporte, los proveedores de
servicio y la gestión de la configuración sobre relaciones y
dependencias entre los servicios de TI y los servicios de apoyo,
como CI´s, etc
• Asegurar que la información en el SC está alineada con el negocio
y sus procesos
• INTERFACES
• ENTRADAS SALIDAS
ENTRADAS SALIDAS
• Información del negocio, de la SCM. GESTIÓN DEL • Documentación y
organización y estrategias acuerdo de una
• Análisis de Impacto sobre el CATÁLOGO DE “definición del servicio”
negocio SERVICIOS • Actualización de la
• Cartera de Servicios (SC) cartera de servicios
• CMS (SP)
• Retroalimentación de otros • Actualización del
procesos Catálogo de servicios
(SC)
•METRICAS (KPI´s)
₋ Número de servicios registrados y mantenidos
en el catálogo. Como % de aquellos que se
entregan y se llevan al entorno de producción.
₋ Número de diferencias detectadas entre la

información del SC y la realidad
₋ % de mejoras de la completitud del SC

comparado con los componentes de TI que
soportan los servicios
₋ % de incidencias sin la información adecuada

relativa al servicio
•La META es garantizar que se proporciona un
nivel acordado de servicio TI para todos los
servicios TI actuales y futuros
•OBJETIVOS:
•Definir, documentar, acordar, monitorizar, medir,
comunicar y ejecutar una revisión del nivel de servicio
•Establecer y mejorar la relación con el negocio y con los
clientes.
•Garantizar que la TI y los clientes tengan una expectativa
clara y no ambigua del nivel de servicio que se entregará
•Garantizar que las medidas proactivas que se implementen
para mejorar los niveles de servicio entregados, sean
justificables en coste
• AMBITO
• SLM es el nexo entre el proveedor de servicios TI y
los clientes
• SLM debe gestionar las expectativas de ambas partes
• SLM garantiza que la calidad del servicio entregado
cumple las expectativas
• El proceso de SLM debe incluir los siguientes elementos
• Desarrollo de relaciones con el cliente del negocio
• Desarrollo y gestión de los SLA
• Generación de informes y gestión de todos los servicios y revisión
de debilidades e incumplimientos de los SLA
• Desarrollo y gestión de los Acuerdos de Nivel Operacional (OLA)
• Revisión de contratos de soporte (UC)
• Prevención de posibles fallos del servicio, reducción de riesgos y
mejoras
• SLM es una interlocución consistente con el negocio para todos los
aspectos relacionados con el servicio
• ACTIVIDADES:
• Diseño de marcos de trabajo de SLA
• SLA basados en el Servicio
• Un mismo SLA para todos los clientes
• SLA basados en el cliente
• Un SLA para todos los servicios de un cliente concreto
• SLA multinivel: una combinación
• Algunos servicios para todos los clientes igual SLA
• Algunos clientes algunos SLA específicos para algunos
servicios
• etc
• ACTIVIDADES:
• Monitorización del rendimiento con respecto al SLA y
comunicación de los resultados
• Aumento de la satisfacción del cliente
• Revisión y ajustes de los acuerdos de apoyo
• Elaboración de informes de servicio
• Revisión y mejoras de servicios
• Revisión y ajustes de los SLA
• Desarrollo de contactos y relaciones
• INTERFACES. Posibles Disparadores
• Cambios en la Cartera de Servicios  Cambios de estrategia
• Acuerdos nuevos o modificados  Cumplimientos y quejas
ENTRADAS SALIDAS
• Información de negocio • Informes del servicio
• Requisitos de negocio SLM. GESTIÓN DEL • Plan de mejora del
• SC y SP NIVEL DE SERVICIO servicio (SIP)
• Información de cambios • Plan de Calidad del
• CMS Servicio (SQP)
• Plantillas de documentos
estándar
• SLA, SLR, OLA
• METRICAS (KPI´s)
₋ % de objetivos de SLA incumplidos
₋ % de satisfacción del cliente
• La META es garantizar que en todas la
áreas de TI siempre exista una capacidad
justificable en coste y que cumpla las
necesidades del negocio
• OBJETIVOS:
• Crear y mantener un plan actualizado de capacidad que refleje las
necesidades presentes y futuras del cliente
• Realizar consultas internas y externas sobre la capacidad y el
rendimiento de los servicios
• Gestionar el rendimiento y la capacidad de los servicios
suministrados para garantizar que cumplen los objetivos definidos
• Contribuir a diagnosticar problemas e incidencias de rendimiento y
capacidad
• Adoptar medidas preventivas para mejorar el rendimiento
• AMBITO
• CM es el punto central para todos los temas de rendimiento y
capacidad de TI
• CM también considera la capacidad de los sistemas de
almacenamiento y entornos
• CM tiene una estrecha relación con la estrategia, sobre todo con la
Gestión de la Demanda
• CM ayuda a tomar decisiones respondiendo a:

• Que componentes actualizar
• Cuando actualizarlos
• Cuanto costará la actualización
• El proceso de Gestión de la
Capacidad consta de:
• ACTIVIDADES REACTIVAS
• Monitorización
• Medición
• ACTIVIDADES PROACTIVAS
• Predicción de requisitos
futuros
• Generación de tendencias
Es el único proceso en ITIL que tiene subprocesos
• GESTIÓN DE LA CAPACIDAD DEL NEGOCIO (BCM)
• Convierte los requisitos del cliente en especificaciones para el servicio y
la infraestructura TI, centrándose en requisitos actuales y futuros
• Soporte, Diseño y modelación de configuraciones del servicio
• Verificación del SLA, Aprobación del SLA, Control e Implementación
• GESTIÓN DE LA CAPACIDAD DEL SERVICIO (SCM)
• Identificar y entender los servicios de TI y garantizar que cumplen los
objetivos definidos en los SLA´s
• Monitoriza todos los servicios, mide su rendimiento, registra los datos,
los analiza y comunica esta información
• GESTIÓN DE LA CAPACIDAD DE LOS COMPONENTES (CCM)
• Gestiona, controla y predice el rendimiento, el uso y la capacidad de
componentes individuales de TI.
• Se ejecuta fundamentalmente en la fase de Operación
Es el único proceso en ITIL que tiene subprocesos
SISTEMA DE INFORMACIÓN PARA GESTIÓN DE LA CAPACIDAD
CMIS (Capacity Management Information System)
• El propósito del CMIS es proporcionar información útil para gestión
de la capacidad
• Uno de los elementos más importantes del proceso CM que utilizan
todos los subprocesos
ACTIVIDADES ITERATIVAS
Las actividades de monitorización, análisis ajuste e implementación, siguen
un proceso iterativo
INFORME DE LA CAPACIDAD
• PERSPECTIVA GENERAL
– El Informe de la Capacidad provee información relacionada con factores
de uso y desempeño a otros procesos de Gestión de Servicios y la
dirección de TI.
• CONTENIDO DEL INFORME
1. Utilización y niveles de desempeño de servicios (esta sección incluye detalles
de todos los niveles de servicio supervisados por la Gestión de la Capacidad)
1. Comparación entre utilización y desempeño de servicios medidos y
acordados
2. Rupturas mayores en niveles de servicio debido a insuficiencia de
capacidad
1. Descripción
2. Causas
3. Contramedidas para su eliminación
4. Medidas para evitar futuras rupturas similares 51
INFORME DE LA CAPACIDAD
• CONTENIDO DEL INFORME
2. Utilización y desempeño de recursos /componentes (esta sección incluye
detalles de todos los recursos / componentes TI supervisados por la Gestión de
Capacidad)
1. Comparación entre niveles de utilización y desempeño de recursos medidos y
deseados
2. Cambios inesperados en utilización y desempeño de recursos
3. Eventos excepcionales (por ej. embotellamientos inesperados)
1. Descripción
2. Causas
3. Contramedidas para su eliminación
4. Medidas para evitar futuros eventos similares
3. Información resumida del Plan de Capacidad
1. Pronóstico de utilización y desempeño de servicios
2. Pronóstico de utilización y desempeño de recursos
3. Iniciativas planificadas y en proceso para ajustar la capacidad y el desempeño de servicios
• INTERFACES
• Típicos disparadores: interrupciones de servicio, avisos de capacidad y
rdto, servicios nuevos y modificados, cambios en las estrategias y planes
de negocio, revisión de SLA´s u OLA´s
ENTRADAS SALIDAS
• Información del negocio, de la • CMIS
organización y estrategias CM. GESTIÓN DE • Plan de capacidad (uso
• Rendimiento y capacidad LA CAPACIDAD actual servicios y comp.
componentes Planes)
• Rendimiento servicios, gestión • Rendimiento servicios
incidencias o problemas • Análisis e informes
• Información Financiera carga de trabajo
• CMIS • Previsiones e informes
• Carga de trabajo desde de predicción
operaciones • Umbrales, alertas y
eventos
₋ % de precisión de las predicciones de
tendencias de negocio
₋ Elaboración a tiempo de las previsiones de
carga de trabajo
₋ Mejora de las habilidades para monitorizar el
rendimiento y la respuesta de servicios y
componentes
₋ Justificación a tiempo e implementación de
nuevas tecnologías
₋ Uso de tecnologías obsoletas
₋ Incidencias y problemas relativos a capacidad
inadecuada
• La META es garantizar que los niveles de
disponibilidad que se entregan en todos los servicios,
cumplen o superan las necesidades actuales y futuras
acordadas con el negocio, de manera eficiente en
costes
• OBJETIVOS:
• Crear y mantener un plan actualizado de disponibilidad que refleje las
necesidades presentes y futuras del cliente
• Asesorar en asuntos relacionados con la disponibilidad
• Servir de guía al cliente y al proveedor de servicios
• Garantizar que los niveles de disponibilidad cumplen o superan los
requisitos establecidos
• Colaborar en los diagnósticos de incidencias y problemas relacionados
con la disponibilidad
• Evaluar el impacto de los cambios sobre el plan de disponibilidad y
sobre el rendimiento y capacidad de los servicios y recursos
• Adoptar medidas proactivas para mejorar la disponibilidad
• PROACTIVIDAD vs REACTIVIDAD
– En ITIL todo lo que se haga, una vez ha sucedido el fallo, aunque no le
afecte al cliente es REACTIVO
– PROACTIVIDAD es tomar medidas para disminuir la probabilidad de
que suceda un fallo
– ACTIVIDADES REACTIVAS (Se ejecutan en la parte operativa del Ciclo de Vida)
• Monitorizar, medir…
• Análisis de falta de disponibilidad
• Análisis de fallos
– ACTIVIDADES PROACTIVAS (Se ejecutan en la fase de diseño del Ciclo de Vida)
• Diseño para aumentar la disponibilidad
• Análisis del impacto del fallo de Componentes (CFIA)
• Análisis por árboles de fallo (FTA)
• Análisis y gestión de riesgos
• Mantenimiento planificado y preventivo
• PROACTIVIDAD vs REACTIVIDAD
• La disponibilidad y fiabilidad de los servicios de TI afecta directamente
sobre la satisfacción de los clientes
• AM es un proceso esencial que se debe incluir en todas las etapas del
Ciclo de Vida del servicio (al igual que la Gestión de la Capacidad)
• ACTIVIDADES:
• Determinar los requisitos de disponibilidad del negocio
• Determinar las funciones vitales del negocio (VBFs)
• Determinar el impacto de los fallos de componentes
• Definir los objetivos particulares de disponibilidad, fiabilidad y
capacidad de mantenimiento de los componentes de TI
• Monitorizar y analizar componentes de TI
• Establecer medidas e informes de disponibilidad, fiabilidad y
capacidad de mantenimiento que reflejen las perspectivas del
usuario de negocio y de la organización TI de soporte
• Investigar las razones subyacentes a niveles inaceptables de
disponibilidad
• Crear y mantener un plan de disponibilidad
• PUNTOS DE PATIDA PARA LA GESTIÓN DE LA DISPONIBILIDAD
MTTR
MTRS MTBF
MTBSI
– MTRS: Tiempo medio de restauración del servicio
– MTBSI: Tiempo medio entre incidencias
– MTTR: Tiempo medio de reparación
– MTBF: Tiempo medio entre fallos
• CONCEPTOS
• DISPONIBILIDAD
• Habilidad de un servicio de realizar la función requerida durante un
tiempo acordado
• (Tiempo acordado – Downtime) / Tiempo acordado x 100
• CONFIABILIDAD
• Tiempo que el servicio puede realizar la función acordada sin
interrupciones = MTBF
• MTBF = (Tiempo acordado – Downtime) / cantidad de caídas x 100
• MANTENIBILIDAD
• Que tan rápido se recupera el servicio después de un fallo = MTRS
• MTRS = Tiempo total Downtime / Cantidad de caidas
• INTERFACES
• Típicos disparadores: Necesidades del cliente nuevas o modificadas,
Nuevos SLA, OLA, Fallos del servicio, Eventos y alertas de
disponibilidad
ENTRADAS SALIDAS
• Información del negocio, de la • Sist de Inf para la
organización y estrategias AM. GESTIÓN DE Gestión de la
• Análisis de riesgos Disponibilidad (AMIS)
• Información del servicio del SP
LA DISPONIBILIDAD • Plan de disponibilidad
o SC • Criterios de diseño para
• Calendario de cambios y disponibilidad y
entregas (de Gestión de recuperación
cambios) • Informes
• Objetivos de servicio • Registro de riesgos
• Información de indisponibilidad actualizados
o fallos • Programación de
pruebas de gestión de la
disponibilidad
• Program. Mantenim
Ángel Caro Amián • Paradas programadas 61
₋ % de falta de disponibilidad
₋ % de fiabilidad de servicios y componentes
₋ % disponibilidad del servicio de extremo a
extremo
₋ Costes de la indisponibilidad
₋ Satisfacción de los clientes
5. ITSCM. GESTIÓN DE LA CONTINUIDAD DEL SERVICIO TI
• La META es dar soporte al proceso global de continuidad
del negocio, garantizando que todas las instalaciones
técnicas y de servicio TI necesarias pueden volver a
funcionar en los plazos de tiempo requeridos y acordados
con el negocio
• OBJETIVOS:
• Mantener un conjunto de planes de continuidad y recuperación.
• Realizar periódicamente Análisis de Impacto sobre el Negocio (BIA)
• Realizar periódicamente estimaciones de riesgo y ejercicios de gestión
• Asesorar y guiar a todas las áreas en continuidad y recuperación
• Garantizar que los mecanismos adecuados de continuidad está listos
• Evaluar el impacto de todos los cambios en los planes de continuidad y
recuperación
• Implementar medidas proactivas viables en costes
• Negociar acuerdos con otros proveedores TI en lo relativo a capacidad
de recuperación requerida para soportar los planes de continuidad
• AMBITO
• ITSCM se centra en aquellos sucesos que el negocio puede considerar como desastres
(catástrofes). Mientras que la Gestión de Incidencias se centra en hechos menos
significativos
• ITSCM no se centra en riesgos a largo plazo debido cambios
• ITSCM debe combinar equilibradamente procedimientos:

• Preventivos:
• Medidas y procedimientos que buscan eliminar o mitigar los riesgos de
interrupción y sus posibles efectos.
• Reactivos:
• Procedimientos cuyo propósito es reanudar el servicio tan pronto como sea
posible después de cualquier interrupción.
• Dos Áreas:
• GESTIÓN DE CONTINUIDAD DEL NEGOCIO (BCM)
• Restaurar rápidamente el negocio si sucede un desastre
• Norma BS 25999
• GESTIÓN DE CONTINUIDAD DEL SERVICIO TI
• Manejar los desastres que afectan a uno o más servicios de TI
• Norma BS 25777
• BS 25999 CONTINUIDAD NEGOCIO. Ciclo PDCA:
• BS 25777 CONTINUIDAD SERVICIO TI. Seis principios:
1. Protección – Protegiendo el entorno de las TIC desde fallos del entorno, fallos
de hardware, errores de operaciones, ataques maliciosos y desastres
naturales.
2. Detección – Rápida para deducir impacto.
3. Reacción – Reacción adecuada para una recuperación más eficiente. Una
mala reacción puede ocasionar que una incidencia de menor se convierta en
desastre.
4. Recuperación –Estrategia de recuperación apropiada para asegurar la
reactivación del servicio. La compresión de las prioridades de recuperación
permiten el servicio más crítico para ser reinstalado primero.
5. Operación – Operación en modo recuperación hasta retornar a la normalidad
es posible requerir algo de tiempo y necesitar “ampliar” las operaciones de
recuperación para apoyar con los incrementos de volumen de negocio que se
necesitan para estar sirviendo con el tiempo.
6. Retorno – La elaboración de una estrategia por cada plan de continuidad TI
permite una organización para migrar desde modo de recuperación hasta una
posición en la cual esto pueda apoyar negocios normales.
• ITSCM es un proceso cíclico que adapta continuamente los planes de
recuperación y continuidad del servicio a los planes de continuidad del
negocio
• ACTIVIDADES:
Consta de 4 etapas:
1. Inicio
2. Requisitos y
estrategia
3. Implementación
4. Operación
continuada
• INTERFACES
• Típicos disparadores: Necesidades del cliente nuevas o modificadas,
Nuevos SLA, OLA, Incidencia muy crítica, Actividades periódicas como
Análisis de Impacto o Análisis de Riesgo
ENTRADAS SALIDAS
• Información de negocio
ITSCM. GESTIÓN • Políticas y estrat ITSCM
• Información Financiera DE LA • Informes Anal.de Impact.
• Planes y Estrategias de BCM CONTINUIDAD DEL
• Información de cambios • Plan prev. Riesgos
• CMS SERVICIO TI • Plan Gestión Emergenc.
• Programación de pruebas • Plan de Recuperación
• METRICAS (KPI´s) • Escenarios de pruebas

• Revisiones e informes
₋ Resultado de auditorías periódicas de planes de ITSCM de pruebas
₋ Nivel de acuerdo y documentación de los planes de recuper. en SLA
₋ Resultados pruebas planes ITSCM
₋ Revisión periódica de los planes de ITSCM
•PRINCIPALES RESULTADOS
• INFORME ANÁLISIS DE RIESGOS (“¿Que puede pasar?”)

GRAVEDAD
IMPACTO
MAS SEVERO
FUGA QUÍMICA DAÑOS POR TORMENTA FUEGO EXPLOSIÓN
FALLO DE SERVIDOR
ROBO
FALLO DE RED IMPORTANTE
MENOS SEVERO
RIESGO ACEPTABLE
FALLO DE ALIMENTACIÓN
VERTIDO DE CAFÉ EN PC
BASE DE DATOS CORRUPTA
MENOS PROBABLE MAS PROBABLE

PROBABILIDAD 69
• PLAN PREVENCIÓN RIESGOS (“para que no suceda el
desastre…”)
- Objetivo: evitar o minimizar el impacto de un
desastre en la infraestructura TI.
- Ejemplos
- Utilización de sistemas alternos de suministro
eléctrico
- Políticas de respaldo y custodia para los
archivos y las bases de datos. Duplicación
elementos críticos
• PLAN DE GESTIÓN DE EMERGENCIAS (“ha sucedido…¿qué hacemos?”)
- Las crisis suelen provocar reacciones de pánico, a veces, mayores
daños que el incidente que las haya podido causar…
- Objetivo: que estén definidas las responsabilidades y funciones
del personal en caso de alguna situación de emergencia.
• PLAN DE RECUPERACIÓN (“cómo levantamos el

servicio…”)
- Objetivos:
- Reorganizar al personal involucrado
- Reestablecer los sistemas de hardware
y software necesarios
- Recuperar los datos y reiniciar el
servicio TI
6. ISMS. GESTIÓN DE LA SEGURIDAD DE LA INFORM.
• La META es alinear la seguridad de TI con la del
negocio y garantizar una gestión eficaz de la
seguridad de la información en todos los servicios y
actividades de Gestión del Servicio
• OBJETIVOS:
• Garantizar que la información esté disponible y se pueda usar cuando
se necesite (disponibilidad)
• Garantizar que la información esté disponible exclusivamente para
personas autorizadas (confidencialidad)
• Garantizar que la información sea completa, precisa y esté protegida
contra cambios no autorizados (integridad)
• Garantizar la confiabilidad de las transacciones y el intercambio de
información entre empresas y asociados (autenticidad y no
desconocimiento)
• AMBITO
ISMS debe cubrir toda información de TI y del negocio.
Entre otras cosas, esto incluye:
- La política y los planes actuales y futuros de seguridad del negocio
- Los requisitos de seguridad
- Los requisitos legales
- Las obligaciones y las responsabilidades
- Los riesgos para TI y el negocio (y su gestión)
El proceso ISMS debería incluir los siguientes elementos:

- Elaboración, mantenimiento, distribución y fortalecimiento de una política de
seguridad de la información
- Entendimiento de los requisitos de seguridad, actuales y futuros, del negocio,
que se hayan acordado
- Implementación (y documentación) de controles que faciliten la política de
seguridad de la información y gestionen riesgos
- Gestión de proveedores de servicios TI en lo referente al acceso al sistema
- Mejora proactiva de los sistemas de control y seguridad
• Sistema de Gestión de la Seguridad de la Información
• Para garantizar que se han establecido altos niveles de seguridad se
pueden utilizar las cuatro “P”: Personas, Procesos, Productos y
Partners
• La ISO 27000 es la norma formal con la que las organizaciones
podrían contrastar y certificar su ISMS
CICLO PDCA DE LA ISO 27000

ISO 27000
• GOBIERNO DE LA SEGURIDAD
• El gobierno de la seguridad TI puede arrojar seis resultados:
• Alineación estratégica
• Creación de valor
• Gestión de riesgo
• Gestión del rendimiento
• Gestión de recursos
• Aseguramiento de procesos de negocio
• GESTIÓN DE LA INFORMACIÓN
• Toda la información necesaria para la Gestión de la Seguridad de la
Información se debe conservar en un sistema ISMS que incluya
datos sobre controles de seguridad, riesgos, fallos, procesos e
informes
• INTERFACES
• Típicos disparadores: Política corporativa, Política de seguridad, Procesos
corporativos, Requisitos de Negocio. Nuevos o modificados
ENTRADAS SALIDAS
• Información del negocio (planes, ISM. GESTIÓN DE • Política general de
estrategia) gestión de la seguridad
• Políticas seguridad LA SEGURIDAD DE de la información
• Información de servicios de SLM LA INFORM. • ISMS
• Análisis de riesgos • Informes de riesgos
• Eventos y problemas de segurid revisados
• Cambios. De CM • Controles, auditorías e
• CMS informes de seguridad
• Detalles del acceso de Partners • Programa de pruebas de
seguridad
₋ % de incumplimientos de seguridad
₋ % del impacto de la incidencias en incumplimientos de seguridad
₋ % Uso de los procedimientos de seguridad en la organización
7. SM. GESTIÓN DE SUMINSTRADORES
• La META es gestionar a los suministradores y
los servicios que proporcionan, con el fin de
conseguir una calidad consistente de los
servicios TI al negocio, a un precio adecuado
• OBJETIVOS:
• Conseguir una buena relación calidad‐precio
• Garantizar que los contratos y acuerdos de soporte con los
suministradores, están alineados con las necesidades del negocio
• Gestionar la relaciones con los suministradores y su rendimiento
• Negociar y acordar los contratos (UC) con los suministradores
• Mantener una política de suministradores y una base de datos con sus
contratos (parte del SKMS)
• AMBITO:
• Todos los suministradores necesarios para dar los servicios TI
• En el caso de suministradores externos, se
recomienda redactar un contrato formal
con responsabilidades y objetivos
claramente definidos, aceptados y
documentados (UC)
• CICLO DE VIDA DEL CONTRATO
• Identificación
• Evaluación
• Categorización de suministradores y
contratos
• Gestión del rendimiento
• Terminación del contrato
• INTERFACES
• Típicos disparadores: Directrices corporativas, Estrategias, Requisitos de
Negocio. Nuevos o modificados
ENTRADAS SALIDAS
• Información del negocio (planes, • Base de datos de
estrategia) SM. GESTIÓN DE Suministradores y
• Estrategia de suministradores SUMINISTRADORES contratos
• Planes de Negocio • Inform. de rendimientos
• Contratos con suministradores • Planes de mejora a
• Información de rendimiento suministradores
• Informes de
investigación
₋ % de suministradores que cumplen los acuerdos
contractuales
₋ % de objetivos contractuales alineados con SLA y SLR
8. DC COORDINACIÓN DEL DISEÑO
• La META es asegurar que los objetivos de la etapa de diseño del servicio
son alcanzados proporcionando y manteniendo un único punto de
coordinación y control para todas las actividades y procesos de esta etapa.
• OBJETIVOS:
• Asegurar un diseño consistente.
• Coordinar todas las actividades de diseño, cambios y equipos de
soporte/suministro
• Gestionar las planificaciones, recursos y conflictos.
• Gestionar los criterios de calidad, requerimientos y puntos de traspaso entre
las etapas de diseño del servicio, estrategia del servicio y transición del servicio.
• Asegurar que todas las partes adoptan un framework común para utilizar
prácticas de diseño reusable.
• AMBITO:
• Todas las actividades de diseño particularmente todas las soluciones de servicio
nuevas o modificadas que son diseñadas para pasar a transición o que son
retiradas.
ROLES EN LA FASE
DE DISEÑO
ROLES PRINCIPALES
• Propietario de cada Proceso
• Gestor del Diseño del Servicio
• Gestor del Catálogo de Servicios
• Gestor del Nivel de Servicio
• Gestor de la Disponibilidad
• Gestor de la Seguridad
ROLES PRINCIPALES
• Gestor del Diseño del Servicio
– Responsable de producir diseños seguros, sólidos y de calidad para servicios nuevos o
mejorados.
– Producción y mantenimiento de toda la documentación de diseños.
• Gestor del Catálogo de Servicios
– Responsable del mantenimiento del Catálogo de Servicios, asegurando que toda la
información contenida en el catálogo sea precisa y actualizada
• Gestor del Nivel de Servicio
– Responsable de negociar SLA y de velar que se cumplan.
– Se asegura que todos los procesos, OLA´s y UC´s sean adecuados para los
niveles de servicio acordados.
– Monitoriza e informa acerca de los niveles de servicio.
• Gestor de la Disponibilidad
– Responsable de definir, analizar, planificar, medir y mejorar todo lo concerniente a la
disponibilidad de servicios de TI.
– Asegurar que toda la infraestructura, procesos, herramientas y funciones de TI sean
apropiados en el renglón de disponibilidad y según el nivel de servicio acordado.
ROLES PRINCIPALES
• Gestor de la Seguridad
– Se ocupa de salvaguardar la confidencialidad, integridad y disponibilidad de los activos,
información, datos y servicios de TI de una organización.
• Gestor de Riesgos
– Se ocupa de identificar, evaluar y controlar riesgos.
– Esto incluye el análisis del valor de activos de la empresa, la identificación de amenazas a
esos activos y la evaluación de la vulnerabilidad de cada activo ante dichas amenazas.
• Gestor de Suministradores
– Está a cargo de monitorizar la relación calidad‐precio en toda transacción con los
suministradores externos.
– Se asegura de que los contratos a proveedores apoyen las necesidades de la empresa y
de que todos los suministradores cumplan sus compromisos contractuales.
3.3 TRANSICIÓN DEL SERVICIO
ITIL FUNDAMENTOS
TRANSICIÓN
DEL SERVICIO
• En esta fase se desarrollan y mejoran las
Gestión del Conocimiento
capacidades para la transición de nuevos
servicios y/o cambios a los ya existentes, Evaluación del Cambio
asegurando los requerimientos de la estrategia
de servicio. Validación y Pruebas de Servicio
Planificación y Soporte a la
• Es una guía para gestionar la complejidad Transición
relacionada con los cambios a servicios y

gestión de procesos de servicios, previniendo
Gestión de Vers. Y Desp
consecuencias indeseables, como fallos e
interrupciones. Gestión de Cambios
Gestión de la Configuración y
Activos
MISIÓN. OBJETIVOS
• La misión de la fase de Transición del Servicio 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.
• Sus principales objetivos se resumen en:
₋ Supervisar y dar soporte a todo el proceso de cambio del nuevo (o
modificado) servicio.
₋ Garantizar que los nuevos servicios cumplen los requisitos y
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.
₋ Permitir la integración del lanzamiento de los procesos y de los
servicios en el Negocio. Evitar el Big Bang.
AMBITO
• La Transición del Servicio incluye:
– La gestión y coordinación de los procesos, sistemas y funciones
necesarios para la construcción, prueba y despliegue de una “versión”
en producción
– La definición del servicio según las especificaciones del cliente y partes
interesadas.
• Pasos típicos de la Transición:
– Planificación y preparación
– Construcción y pruebas
– Pilotos (si los hay)
– Planificación y preparación del despliegue
– Despliegue y transición
– Revisión y cierre de la Transición del Servicio
REQUERIMIENTOS
• Para cumplir adecuadamente estos objetivos es
necesario que durante la fase de Transición del
Servicio:
₋ Se planifique todo el proceso de cambio.
₋ Se creen los entornos de pruebas y
preproducción necesarios.
₋ Se realicen todas las pruebas necesarias para
asegurar la adecuación del nuevo servicio a los
requisitos predefinidos.
₋ Se establezcan planes de roll‐out (despliegue) y
roll‐back (retorno a la última versión estable).
₋ Se cierre el proceso de cambio con una detallada
revisión post‐implementación.
RESULTADO ESPERADO
• Como resultado de una correcta Transición del
Servicio:
₋ Los clientes disponen de servicios mejor
alineados con sus necesidades de negocio.
₋ La implementación de nuevos servicios es más
eficiente.
₋ Se controlan los riesgos y se dispone de planes
de contingencia que eviten una degradación
prolongada del servicio.
₋ Se mantienen correctamente actualizadas las
bases de datos de configuración y activos del
servicio.
₋ Se dispone de una Base de Conocimiento
actualizada a disposición del personal
responsable de la operación del servicio y sus
usuarios
CONCEPTOS
• LINEA BASE (BL: Base Line)
₋ Configuración de un CI, sistema o servicio en un momento específico.
₋ Contiene todos los datos para volver a otro momento. (Back‐outs)
₋ Es una foto instantánea que se registra de un CI o de un grupo de CIs
que se utilizará como referencia y posterior comparación.
₋ La CMDB y/o CMS contiene la trazabilidad de todas líneas base
₋ CRITERIO DE ACEPTACIÓN DEL SERVICIO (SAC: Service Acceptance

Criteria)
₋ Salida del Proceso de Transición
₋ Conjunto de criterios utilizados para asegurar que un Servicio de TI
cumple con su Funcionalidad y Requisitos de Calidad y que el
Proveedor de Servicio de TI está preparado para operar el nuevo
Servicio de TI una vez ha sido Implementado
SP SDP SAC
SLP
SERVICE SERVICE
DESIGN ACCEPTANCE
PACKAGE
SERVICE
LEVEL PACKAGE
CONCEPTOS BÁSICOS
• Para que la Transición de servicio sea eficaz, es necesario:
– Definir e implementar directrices y procedimientos de Transición del Servicio
– Implementar siempre todos los cambios a través de la Transición del Servicio
– Utilizar estándares y marcos de trabajo
– Reutilizar procesos y sistemas existentes
– Alinear los planes de Transición del Servicio con las necesidades del negocio
– Crear y mantener relaciones con las partes interesadas
– Establecer “controles” eficaces
– Producir sistemas para transferir conocimientos y apoyar la toma de decisiones
– Planificar paquetes de versiones y despliegues
– Prever y gestionar cambios de dirección
– Gestionar los recursos de manera proactiva
– Consultar a las partes interesadas que los servicios nuevos satisfacen los requis.
– Garantizar la calidad de un servicio nuevo o modificado
– Mejorar la calidad de manera proactiva durante la fase de Transición
PROCESOS DE LA TRANSICIÓN DEL SERVICIO
• Los procesos de los que consta la Transición de Servicio son:
1. PLANIFICACIÓN Y SOPORTE A LA TRANSICIÓN
2. GESTIÓN DE CAMBIOS
3. GESTIÓN DE LA CONFIGURACIÓN Y ACTIVOS DEL
SERVICIO (SACM)
4. GESTIÓN DE VERSIONES Y DESPLIEGUE
5. VALIDACIÓN Y PRUEBAS
6. EVALUACIÓN DEL CAMBIO
7. GESTIÓN DEL CONOCIMIENTO
• MÍSIÓN de este proceso:
• Planificar y coordinar recursos para garantizar el cumplimiento de les
especificaciones del Diseño del Servicio
• Identificar, gestionar y limitar riesgos que puedan interrumpir el
servicio a partir de la fase de transición
• OBJETIVOS de este proceso:
₋ Planificar y coordinar medios y personas dentro de los marcos de
trabajo
₋ Comprobar que todo el mundo aplica los mismos estándares y marcos
de trabajo
₋ Comunicar problemas de servicio
₋ Elaborar planes claros y exhaustivos
₋ Dar soporte a los equipos de transición y a otros que participen en el
proceso
₋ Planificar cambios de forma controlada
₋ Comunicar problemas, riesgos y otras desviaciones
• ÁMBITO de este proceso:
• Incluir especificaciones de diseño y requisitos de producto en los planes de
transición.
• Gestionar:
- Planes
- Actividades de soporte
- Progreso de la transición
- Cambios
- Problemas
- Riesgos
- Desviaciones
- Procesos
- Sistemas y herramientas de soporte
• Monitorizar los logros de la Transición del Servicio

• Comunicarse con clientes, usuarios e interesados
• CONCEPTOS BÁSICOS
• En la fase de Diseño del Servicio se documentó cada diseño, de cada
servicio, en un documento llamado Paquete de Diseño del servicio (SDP).
• La siguiente información, incluida en el SDP, será necesaria en la fase de
Transición de Servicio:
₋ Paquetes de servicio vigentes
₋ Modelos de servicio
₋ Diseño de la arquitectura necesaria para prestar el servicio ya sea un
servicio nuevo o uno modificado
₋ Definición y diseño de cada paquete de la versión
₋ Diseño detallado de como los componentes del servicio se integran
en el paquete de la versión
₋ Planes de implementación y entregas
₋ Criterios de aceptación del servicio
1. Definición de la estrategia de transición
• La estrategia define el planteamiento global para organizar la
Transición
• El SDP define las distintas fases de la transición (adquisición y
pruebas de componentes, pruebas de entrega del servicio,
pruebas de preparación para la Operación, paso a producción,
ELS: Soporte Temprano, revisión y cierre.)
2. Preparación de la estrategia de transición
• Verificación de los entregables: SDP, SAC e informes
• Identificación, tramitación y programación de RFC´s
• Verificación de que en Gestión de la Configuración se registran
las líneas base de configuración antes de empezar la transición
3. Planificación y coordinación de la Transición
• Tareas necesarias para liberar y desplegar una entrega en los entornos
de prueba y producción:
- Entorno de trabajo e infraestructura
- Programación de hitos
- Actividades y tareas que se realizarán
- Personal, requisitos de recursos, presupuesto y plazo de tiempo en cada
etapa
- Tiempo total de entrega y contingencias
• Preguntas que deben tener respuesta:
• ¿Están los planes de Transición de Servicio y los planes de entrega
actualizados y autorizados y se conocen las fechas de entrega?
• ¿Se ha tenido en cuenta algún riesgo que pueda afectar a los costes, la
organización y la tecnología?
• ¿Son compatibles entre sí y con el entorno, los nuevos elementos de
configuración (CI´s)?
• ¿Ha recibido el personal que vaya a estar implicado la formación necesaria
4. Soporte del Proceso de Transición
• La Transición del Servicio asesora y da soporte a todos los
interesados
• El equipo de planificación y soporte informa a los interesados
sobre:
- Procesos
- Herramientas
- Sistemas de soporte
- Gestión/administración de cambios
- Pedidos de trabajo
- Problemas
- Riesgos
- Comunicaciones y despliegue
- Se monitorizan las actividades de la Transición del Servicio
comparando la implementación de actividades con las
previsiones (que aparecen en el Plan de Transición)
• INTERFACES
• El disparador de la Transición del Servicio es una RFC aprobada
ENTRADAS SALIDAS
• RFC´s autorizadas PLANIFICACIÓN Y • Estrategia de transición
• SDP • Colección integral de
• Definición del paquete de SOPORTE DE LA planes de Transición del
entrega y especificaciones de TRANSICIÓN Servicio
diseño
• SAC
• MÉTRICAS (KPI)
• Número de entregas implementadas que cumplen los requisitos
acordados con el cliente
• Desviaciones respecto al ámbito, la calidad, los costes o recursos prev.
• Número de problemas, riesgos y retrasos 19
• OBJETIVO DE ESTE PROCESO:
₋ Garantizar que los cambios, necesarios en la infraestructura y
servicios TI, se aplican de una manera controlada
• 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.
₋ Se utilizan métodos y procedimientos estándar
₋ 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.
₋ Han tenido en cuenta los riesgos para el negocio
•DEFINICIONES
₋ CAMBIO:
• La adición, modificación o eliminación aprobada y soportada o
inclusive el retorno a la línea base de cualquier CI.
₋ SOLICITUD DE CAMBIO (RFC):
• Forma usada para autorizar y registrar una solicitud de cambio.
₋ MODELO DE CAMBIO
• Grupos de cambios que han sido previamente clasificados, analizados
y autorizados.
• No hay que hacer RFC por cada cambio
₋ PROGRAMA ADELANTADO DE CAMBIOS (FSC – Forward Schedule of Change):

• Programa que contiene los detalles de todos los Cambios aprobados
para implementar así como las fechas de implementación.
₋ REVISIÓN POST‐IMPLEMENTACIÓN (PIR):
• Revisiones después de un cambio para saber si el cambio ha sido
implementado con éxito y se han obtenidos los beneficios esperados.
•ACTIVIDADES GENERALES DE LA GESTIÓN DE CAMBIOS
₋ Planificación y gestión de cambios
₋ Planificación de versiones
₋ Comunicación
₋ Autorización de cambios
₋ Definición de planes de recuperación
₋ Generación de informes
₋ Evaluación de impacto
₋ Mejora continua
•ACTIVIDADES PARA UN CAMBIO CONCRETO

1. Creación y registro de la solicitud de cambio (RFC)
2. Revisión de la RFC
3. Valoración y evaluación del cambio
4. Autorización del cambio
5. Planificación de actualizaciones
6. Coordinación de la implementación del cambio
7. Revisión y cierre del cambio
• ALGUNOS INDICADORES DE QUE LA GESTIÓN
DE CAMBIOS NO ES LA ADECUADA:
₋ Cambios no autorizados
₋ Tiempo de parada no planificado
₋ Cambios implementados con poco éxito
₋ Alto número de “cambios de
emergencia”
₋ Retrasos en la implementación de
proyectos
• POLITICAS QUE FAVORECEN LA CORRECTA GESTIÓN DE CAMBIOS:
₋ Creación de una cultura de tolerancia cero ante cambios no
autorizados
₋ Alineación del proceso de Gestión de Cambios con otros procesos de
cambio en la organización
₋ Priorización efectiva:
₋ Innovación frente a prevención
₋ Detección frente a cambios correctivos
₋ Establecimiento de responsabilidades finales y ejecutores para los
cambios
₋ Establecimiento de un punto único para controlar los cambios
₋ Integración en otros procesos de Gestión del Servicio
₋ Definición de “ventanas de cambio”, mediciones de rendimiento y
evaluaciones de rendimiento y riesgo
• DISEÑO Y PLANIFICACIÓN:
₋ El proceso de Gestión de Cambios se planifica conjuntamente con la
Gestión de la Configuración y la Gestión de versiones
• ACTIVIDADES MÉTODOS Y TÉCNICAS

₋ ACTIVIDADES GENERALES
₋ Planificación y control de cambios
₋ Programación de cambios y entregas
₋ Comunicaciones
₋ Toma de decisión y autorización de cambios
₋ Aseguramiento de que existan planes de corrección
₋ Medición y control
₋ Generación de informes de control
₋ Entendimiento del impacto
₋ Mejora continua
•TIPOS DE CAMBIOS:
₋ CAMBIO ESTÁNDAR:
₋ Utilizado en cambios preautorizados recurrentes, de bajo riesgo.
Ejemplo los cambios habituales de mantenimiento de servicio.
₋ Necesita un “Modelo de Cambio”
₋ CAMBIO NORMAL:
₋ Es el modelo completo para cambios que requieren pasar una
evaluación, autorización y recibir la aprobación del CAB antes de
su implementación.
₋ Necesita RFC
₋ CAMBIO DE EMERGENCIA:
₋ Modelo reservado sólo para cambios muy críticos, necesarios
para restaurar la disponibilidad de un servicio o que impidan un
fallo general que esté a punto de ocurrir.
₋ Es un cambio normal, que necesita RFC
₋ Lo aprueba el ECAB
• 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.
• COMITÉ ASESOR DEL CAMBIO (CAB: Change Advisory Board)

₋ Órgano interno, presidido por el Gestor de Cambios, formado por
representantes de las principales áreas de la gestión de servicios TI.
₋ Se puede incorporar personal externos (consultores, representantes de
usuarios, representantes de proveedores, etc)
₋ Se reúne periódicamente o con cierta antelación.
• COMITÉ ASESOR DE CAMBIOS DE EMERGENCIA (ECAB: Emergency CAB)

₋ Autoriza cambios de emergencia si no da tiempo a convocar al CAB
₋ Se reúne cuando es necesario un cambio de emergencia
• RFC: PETICIÖN DE CAMBIO
• La petición de cambio o RFC (Request por change) será la fuente de
información clave y el catalizador de las actividades de cambio como
son:
₋ Registro del cambio
₋ Revisión
₋ Evaluación
₋ Autorización
₋ Planificación
₋ Coordinación
₋ Revisión
₋ Cierre
• SOLICITUD DE CAMBIO. RFC. PERSPECTIVA GENERAL
– Un Solicitud de Cambio (RFC) es una solicitud formal para la implementación de un Cambio.
– Se envía una Solicitud de Cambio a la Gestión de Cambios para cualquier Cambio que no sea
estándar (la Gestión de Cambios define usualmente un conjunto de Cambios estándares/ de
rutina; estos son cambios menos importantes que no requieren ser sometidos al proceso de
la Gestión de Cambios).
– Un Cambio tiene el apoyo de un Propietario del Cambio, y tiene un presupuesto para su
implementación.
– En muchos casos el Propietario del Cambio es también el que inicia el RFC.
– Normalmente, actúan como Propietarios de Cambio los propietarios de roles de la Gestión
de Servicios de TI (por ej. el Gestor de Problemas o Gestor de la Capacidad) o a la Dirección
de TI.
– La Solicitud de Cambio (RFC) es un precursor del Registro de Cambio y contiene toda la
información requerida para aprobar el Cambio.
– Se añade información adicional según pasa el Cambio por su ciclo de vida.
– La cantidad de detalles depende del tamaño e impacto probable del Cambio.
– Frecuentemente habrá referencias a documentos adicionales con información más
detallada, por ej. una propuesta de Cambio detallada. Ya que los Cambios importantes se
implementan en general como proyectos, el RFC frecuentemente tiene el papel de lo que se
conoce como "Carta de Proyecto“.
Transición del Servicio
• CONTENIDO RFC
1. Identificación única (ID)
2. Fecha de la presentación de la solicitud
3. Propietario del Cambio
4. Quién inicia el RFC (si no es también el Propietario del Cambio)
5. Prioridad del Cambio propuesto (por ej. “Muy alta (Cambio urgente)”, “Alta”, “Normal”,
“Baja” – puede ser cambiada por la Gestión de Cambio durante la evaluación del Cambio)
6. Descripción del Cambio que se solicita
1. Descripción resumida
2. Caso de negocio
1. Razón para implementar el Cambio
2. Costos
3. Beneficios
4. Consecuencias si no se implementa el Cambio
5. Referencias (por ej. a un registro de Problemas que motivó este RFC)
3. Áreas del negocio afectadas por el Cambio en la parte del cliente
4. Servicios afectados por el Cambio
5. Elementos de Configuración (CI's) afectados por el Cambio
6. Aspectos de tecnología (¿se introduce una nueva tecnología?)
Transición del Servicio
• CONTENIDO RFC
7. Riesgos durante la implementación del Cambio
1. Riesgos identificados
2. Contramedidas (por ej. procedimiento de reversión)
3. Estrategia de refuerzo en caso de un fracaso en la implementación de un Cambio
8. Calendario pronosticado/ sugerido para la implementación
9. Estimación de recursos para la implementación
1. Personal requerido (¿de qué áreas?)
2. Estimación de los recursos necesarios en el área de personal
3. Estimación de los costos (detallada en caso de Cambios mayores)
10. Declaración sobre si un presupuesto está asignado y aprobado para este Cambio
11. Si aplica, índice de documentos adicionales de apoyo (por ej. el Paquete de Diseño
del Servicio para adiciones o modificaciones importantes a los servicios)
12. Aprobado o rechazado
1. Fecha
2. Persona a cargo de la aprobación (Gestor de Cambios/ CAB/ EC)
3. Quiénes revisan el Cambio
4. Prioridad asignada por la Gestión de Cambios
5. Restricciones
6. Si aplica, razones para rechazar el RFC
• PREGUNTAS QUE SON NECESARIAS CONOCER ANTE CADA CAMBIO:
₋ ¿Quien pide el cambio?
₋ ¿Cuál es la razón del cambio?
₋ ¿Qué se espera o cuál es el retorno esperado de dicho cambio?
₋ ¿Qué riesgos implica el cambio?
₋ ¿Qué recursos se necesitan para llevar a cabo el cambio?
₋ ¿Quién es el responsable de implementar, probar y poner el
cambio en práctica?
₋ ¿Qué relación existe entre este cambio y otros cambios?
• Sin esta información, la evaluación del impacto de dicho cambio no
puede completarse y podría no quedar claro el balance entre riesgos y
beneficios para el servicio.
• Podría ocurrir que el cambio no entrega todos los beneficios
esperados o que incluso provoca un efecto negativo.
• ACTIVIDADES:
1. Creación y registro de la
solicitud de cambio (RFC)
2. Revisión del RFC y
propuesta de cambio
3. Valoración y evaluación
del cambio
5. Planificación de
actualizaciones
6. Coordinación de la
implementación del
cambio
7. Revisión y cierre del
cambio
ACTIVIDADES
1. Creación y registro de la solicitud de cambio (RFC)
• Todas los RFC quedan registradas y tienen un
identificador único
• El alcance y el riesgo determinan cuanta información
debe llevar
2. Revisión del RFC y propuesta de cambio

• Una vez registrada se revisa y se ve su viabilidad y
conveniencia y se acepta o se rechaza con un motivo
ACTIVIDADES
• Categorización (la Probabilidad x Impacto = Riesgo)
• Evaluación: CAB ó ECAB
• Las “7 R” de la Gestión de Cambios:
1. Reclamación: ¿Quién solicitó el cambio?
2. Razón: ¿Cuál es el motivo del cambio?
3. Resultado: ¿Cuál es el resultado requerido con el cambio?
4. Riesgo: ¿Qué riesgos presenta el cambio?
5. Recursos: ¿Qué recursos se necesitan?
6. Responsabilidad: ¿Quiénes son los responsables de construir,
probar e implementar el cambio?
7. Relación: ¿Qué relaciones existen entre este cambio y otros?
• También la prioridad: Baja, media, alta, inmediata (definiendo los
criterios)
ACTIVIDADES
• También la prioridad:
• Baja: cambio deseable, pero que puede esperar
• Media: no urgente, ni alto impacto, pero no se puede retrasar
• Alta: referido a un fallo grave o problema urgente (máxima
prioridad para CAB)
• Inmediata: fallo muy grave requiere actuación inmediata
(normalmente ECAB)
• Planificación y programación de cambios (SC: Schedule of Changes)

• Calendario con los cambios previstos
ACTIVIDADES
• Todo cambio requiere una autorización.
• El nivel de la autorización, depende del tipo de cambio
ACTIVIDADES
5. Actualización de planes
• Se comprueban y actualizan los planes de: cambio, transición,
entrega y despliegue, pruebas, evaluación, regresión
6. Coordinación de la implantación del cambio
• Las RFC´s autorizadas pasan al grupo técnico adecuado.
• La puesta en funcionamiento: Gestión de entregas y
despliegues
• Las pruebas: Validación y pruebas del Servicio
7. Revisión y cierre del cambio
• Salvo los cambios estándar, el CAB los evalua:
• ¿Ha conseguido el cambio los resultados previstos?
• ¿Están todos los grupos de interés satisfechos con el resultado?
• ¿Ha surgido algún defecto secundario?
• ¿Se han sobrepasado los costes y esfuerzos estimados?
• INTERFACES: 2. GESTIÓN DE CAMBIOS
₋ El proceso de Gestión de Cambios puede tener como disparadores:
₋ Cambios estratégicos
₋ Cambios que afecten a uno o más servicios
₋ Cambios operativos
₋ Cambios para la mejora continua
ENTRADAS SALIDAS
• Política y estrategias de • Solicitudes de cambio
cambios y entregas aprobadas o rechazadas
• RFC´s
• Propuesta de cambio • Servicios, CI´s nuevos o
• Planes de: cambio, transición, modificados
entrega y despliegue, pruebas,
GESTIÓN DE • PSO ajustada
evaluación, regresión CAMBIOS • Programación de
• Programa de Cambio (SC) y Cambios actualizada
Paradas de Servicio • Decisiones, acciones,
Planificadas (PSOs) documentos, registros e
• CI´s informes de cambios
• Resultado de pruebas, informes
y evaluación
• INTERFACES:
₋ La gestión de cambio tiene interfaces con los procesos de cambio del
negocio y con otros procesos de Gestión del Servicio
₋ Gestión de la Configuración y Activos de Servicio
₋ Todo reflejado en la CMS
• MÉTRICAS (KPI’S):
₋ Número de cambios implementados de cumplen las especificaciones del
cliente
₋ Beneficios del cambio frente a los costes
₋ Número de interrupciones del servicio
₋ Número de cambios no autorizados
₋ Números de marchas atrás
₋ Tasa de éxitos de los cambios implementados, frente a los aprobados
₋ Número de cambios no planificados
₋ De Salida:
₋ Nº interrupciones, incidencias y problemas consecuencia de cambios
₋ Número de especificaciones incorrectas de cambios
₋ Número de análisis de impacto incorrectos
₋ Reparaciones de servicios/aplicaciones como consecuencia de
especificaciones incorrectas de cambios
• MÉTRICAS (KPI’S):
₋ De Carga de Trabajo:
₋ Frecuencia de cambios
₋ Número de cambios
₋ De Proceso
₋ Nivel de satisfacción de las personas con la velocidad, la claridad y la
facilidad de uso
₋ Nº y % de cambios que siguen los procedimientos formales
₋ Tasa de solicitudes de cambio planificadas con respecto a las no
planificadas
₋ Tasa de solicitudes de cambio aceptadas con respecto a las rechazadas
₋ Utilización de personal
₋ Comparación de costes frente a presupuesto
SERVICIO (SACM)
• La principal tarea de la Gestión de la Configuración y Activos TI es llevar un
registro actualizado de todos los elementos de configuración de la
infraestructura TI, junto con sus interrelaciones.
• Es esencial conocer en detalle la infraestructura TI de nuestras organizaciones
para obtener el mayor provecho de la misma.
• OBJETIVOS :
₋ Proporcionar información precisa y fiable al resto de la organización de
todos los elementos que configuran la infraestructura TI.
₋ Mantener actualizada la CMDB (Base de Datos de Gestión de
Configuración y Activos TI):
 Registro actualizado de todos los CIs: identificación, tipo, ubicación,
estado...
 Interrelación entre los CIs.
 Servicios que ofrecen los diferentes CIs.
₋ Servir de apoyo a los otros procesos, en particular, a la Gestión de
Incidencias, Problemas y Cambios.
₋ Garantizar la integridad de los activos y de las configuraciones mediante un
Sistema de Gestión de la Configuración (CMS) 45
SERVICIO (SACM)
•ÁMBITO
₋ Todos los activos que se utilizan durante el ciclo de vida
del servicio están incluidos en el ámbito de la Gestión de
Activos.
₋ La Gestión de la Configuración garantiza que todos los
CI´s que forman parte del producto o servicio:
₋ Están identificados
₋ Tienen una línea base de referencia
₋ Están actualizados
₋ Se encarga de asegurar que las entregas están basadas
en aprobaciones formales
₋ Proporciona un modelo lógico de todos los servicios,
activos, la infraestructura física y las relaciones mutuas
• CONCEPTOS SERVICIO (SACM)
₋ El establecimiento de relaciones entre CI´s permite crear un modelo
lógico de los servicios, los activos y la infraestructura:
Este modelo proporciona
información importante
para otros procesos,
como:
• Análisis de impacto para los
cambios propuestos
• Investigación de la causa
de incidentes y problemas
• Planificación y diseño de
cambios, actualizaciones
de software e investigación
• Planificación de paquetes
de versiones y
despliegues
• Optimización en el uso de
activos y costes
SERVICIO (SACM)
•CONCEPTOS
₋ CI: Elemento de Configuración es un activo, componente
de servicio u otro elemento que está (o estará) bajo el
control de la Gestión de la Configuración:
₋ CI´s del Ciclo de Vida del Servicio: ej. Caso de negocio
y los planes de cambios y entregas
₋ CI´s organizativos: ej. Documentación de la estrategia
₋ CI´s internos: ej. Asociados a un proyecto
₋ CI´s externos: ej. Requisitos y acuerdos con clientes
₋ CI´s de interrelación: ej. Necesarios para entregar el
servicio
SERVICIO (SACM)
•CONCEPTOS
₋ CMS: Sistema de Gestión de la Configuración
₋ SACM necesita un Sistema de soporte para gestionar la
infraestructuras y servicios TI de gran tamaño y complejidad: CMS
₋ Normalmente cuatro capas:
₋ Capa de presentación: vistas diferentes para los distintos grupos
₋ Capa de procesamiento de conocimientos para generar informes
y consultas
₋ Capa de integración de la información para ordenar y estructurar
los datos
₋ Capa de datos: información de diversas fuentes como las
CMDB´s, herramientas de detección, información de proyectos,
etc
•CONCEPTOS SERVICIO (SACM)
₋ CMS: Sistema de Gestión de la Configuración
₋ Ejemplo
₋ BIBLIOTECAS
₋ Siempre que sea posible se deben utilizar herramientas automatizadas
(como herramientas de descubrimiento, inventario y auditoría) para
cargar y mantener la CMDB. Minimiza las posibilidades de error y reduce
los costes.
₋ ITIL define varias bibliotecas:
₋ Una Biblioteca segura es
₋ Una colección de software y elementos de configuración electrónico o
documentales, de tipo y estado conocidos
₋ Un Almacén seguro
₋ Lugar donde se almacenan CI´s de forma segura
₋ La DML. Biblioteca de Medios Definitivos
₋ Almacén seguro con las versiones definitivas y autorizadas (aprobadas)
de los CI de medios
₋ Los Repuestos definitivos
₋ Se mantienen en una zona apartada para el almacenamiento seguros
Ángel Caro Amián de repuestos de hardware definitivos 51
SERVICIO (SACM)
• BIBLIOTECA DEFINITIVA DE MEDIOS (DML)
₋ Una biblioteca que contiene una copia de
todo el software instalado en el entorno TI.
₋ Incluye:
₋ Sistemas operativos y aplicaciones,
₋ Controladores de dispositivos
₋ Documentación asociada, como
licencias, etc.
₋ Contiene el histórico completo de versiones
de un mismo software para permitir hacer
back‐out.
₋ Debe ser almacenada en un entorno seguro
y es conveniente que se realicen back‐up
periódicos.
₋ LINEAS BASES DE CONFIGURACIÓN (almacenadas en el CMS)
₋ Es una configuración de un servicio, producto o infraestructura
que ha sido formalmente revisada y acordada
₋ Sirve de base para actividades futuras, como:
₋ Para marcar un hito en el desarrollo de un servicio
₋ Ej. Linea base de referencia de Diseño de servicio
₋ Para construir un componente de un servicio a partir de un
conjunto definido de entradas
₋ Para cambios o reconstrucciones posteriores de versiones
concretas
₋ Para ensamblar todos los componentes relevantes en la
preparación de un cambio o una entrega
₋ Como punto de regresión en caso de que surjan problemas
con las nuevas configuraciones, después de un cambio
SERVICIO (SACM)
₋ Las actividades básicas del proceso SACM son:
1. Dirección y Planificación
• Decidir el nivel de gestión necesario y como conseguirlo (alcance,
requisitos, etc)
2. Identificación de la configuración
• Determinar y mantener los nombres y número de versiones de
CI´s, las relaciones mutuas y los atributos correspondientes
3. Control de la configuración
• Garantiza que ningún elemento CI se puede añadir, modificar, sustituir o
eliminar si no se sigue el procedimiento
4. Seguimiento y soporte del estado de la configuración
• Informe de los estados actuales e históricos de cada CI (ej. Registrado,
aceptado, instalado, retirado)
5. Verificación y auditoría
• SACM realiza auditorías para comprobar que no existen discrepancias
(líneas base correctas, CI existen, hay documentación, etc)
SERVICIO (SACM)
•INTERFACES
₋ SACM tiene interfaces con todos los demás procesos.
₋ Por ejemplo, destacan:
₋ Con Gestión de Cambios: para el análisis de impactos
₋ Con Gestión Financiera para información sobre costes, depreciaciones,
mantenimiento y reparaciones
₋ Con Gestión de la Continuidad, para que la organización sepa los
activos de los que depende el negocio y para el control de elementos
clave
₋ Con Gestión de Incidencias y Problemas para el diagnóstico de los
mismos
₋ Con Gestión de la Disponibilidad, para la detección de puntos de fallo
₋ Con Gestión de entregas y despliegues para la planificación
SERVICIO (SACM)
₋ Número de errores debidos a información
obsoleta
₋ Duración de las auditorias (que sea menor
por un mejor acceso a la información)
₋ Tiempos de diagnósticos y resolución de
incidencias y problemas
₋ Discrepancias entre la situación real y la
reflejada en el CMS
4. GESTIÓN DE ENTREGAS Y DESPLIEGUE
• La Gestión de entregas y despliegues se ocupa de construir, probar y
suministrar las capacidades para proporcionar los servicios especificados
en el Diseño del Servicio, cumpliendo los requisitos de los grupos de interés
y proporcionando los objetivos planteados
• La META es poner las entregas en producción y establecer un uso efectivo

del Servicio
• OBJETIVOS. Garantizar que:
• Existen planes de versiones y despliegues
• Los paquetes de versiones (compilaciones) se despliegan
correctamente
• Existe transferencia de conocimiento a los clientes
• La perturbación de los servicios es mínima
• AMBITO
• Los procesos, sistemas y funciones de empaquetado, construcción,
pruebas y despliegue (según el SDP)
• OBJETIVOS
₋ El despliegue de versiones en producción y facilitar el uso efectivo del
servicio con el fin de entregar valor al cliente.
₋ Establecer una política de implementación de nuevas versiones de
hardware y software.
₋ Implementar las nuevas versiones de software y hardware en el
entorno de producción después de que la Validación y Pruebas las
haya verificado en un entorno realista.
₋ Garantizar que el proceso de cambio cumpla las especificaciones de
la RFC correspondiente.
₋ Asegurar, en colaboración con la Gestión de Cambios y la de
Configuración y Activos TI, que todos los cambios se ven
correctamente reflejados en la CMDB.
₋ Archivar copias idénticas del software en producción, así como de
toda su documentación asociada
• BENEFICIOS
₋ Una gestión de entregas y despliegues efectiva permite al proveedor
de servicios agregar valor al negocio a través de:
 Cambios más rápidos, optimizados en coste y con mínimo riesgo.
 Asegurar que los clientes y los usuarios pueden utilizar el servicio
nuevo o modificado de una manera que es compatible con los
objetivos de negocio.
 Contribuir al cumplimiento de requisitos auditables para la
trazabilidad a través de la Transición de Servicio.
₋ De no realizarse correctamente, el personal TI, empleará una gran
cantidad de tiempo en solucionar problemas y gestionar un sistema
complejo.
₋ En el peor de los casos, se podría incluso parar el servicio o
degradarlo en tiempo real.
• CONCEPTOS
₋ ENTREGA
₋ Un conjunto de elementos de configuración, nuevos o
modificados que son probados e implantados conjuntamente, en
el entorno de producción
₋ UNIDAD DE ENTREGA
₋ La porción del servicio o infraestructura que está incluida en la
entrega
₋ PAQUETE DE ENTREGA
₋ Una sola unidad de entrega o una colección (estructurada) de
unidades de entrega.
₋ Se deben tener en cuenta todos los elementos que forman el
servicio (infraestructura, hardware, software, aplicaciones,
documentación, etc)
• CONCEPTOS
₋ EJEMPLO DE PAQUETE
DE ENTREGA
₋ Las actividades básicas de este proceso son:
1. Planificación
2. Preparación de construcción (compilación), pruebas y
despliegue
3. Construcción y pruebas
4. Pruebas y pilotos de servicios
5. Planificación y preparación d despliegues
6. Transferencia, despliegue y retiro
7. Verificación del despliegue
8. Soporte Post‐Implantación
9. Revisión y cierre
1. PLANIFICACIÓN
• Planes dentro del plan de Transición.
• Aprobados o rechazados por Gestión de Cambios
₋ Subplanes Importantes:
₋ Criterios pase/fallo para cada fase de la entrega y el despliegue
₋ Planes de construcción y pruebas
₋ Describen el método empleado para la construcción, prueba y
mantenimiento del entorno de pre‐producción
₋ Se necesitan entornos diferentes, para cada tipo de prueba:
₋ Pruebas unitarias
₋ Pruebas de entrega del servicio
₋ Pruebas de integración
1. PLANIFICACIÓN
₋ El MODELO EN “V” es una
herramienta útil para identificar los
distintos niveles de configuración en
los que se deben efectuar la
construcción y pruebas
₋ Define las especificaciones del
servicio que es necesario
cumplir para aceptar un versión
(parte izquierda de la “V”)
₋ Indica, en paralelo, las pruebas
mediante las cuales se va a
comprobar cada una de las
especificaciones (parte derecha
de la “V”)
2. PREPARACIÓN DE CONSTRUCCIÓN (COMPILACIÓN),
PRUEBAS Y DESPLIEGUE
• Antes de aprobar el paso a la fase de construcción y
pruebas, el diseño de la versión y el servicio se compara
con las especificaciones del servicio nuevo o modificado
• Puede detectar riesgos
3. CONSTRUCCIÓN Y PRUEBAS
• Gestión de infraestructura y servicios generales
• Uso de documentación de versiones y construcción
• Adquisición, compra y pruebas de componentes y
elementos de configuración para la versión
• Compilación de la versión
• Estructuración y control de los entornos de pruebas
4. PRUEBAS Y PILOTOS DEL SERVICIO
• Prueba de entrega del servicio: que los componentes del servicio
funcionan correctamente y que la versión se puede compliar, istalar y
probar en el entorno de destino
• Prueba de preparación para la Operación del Servicio: garantiza que
se puede transferir al entorno de producción de una forma
controlada.
• Pilotos: permiten probar si existen elementos del servicio que no
cumplen las especificaciones o suponer un riesgo
5. PLANIFICACIÓN Y PREPARACIÓN DEL DESPLIEGUE

• ¿Están preparados para la implementación del paquete de entrega?
• ¿Han preparado el plan de actividades?
• ¿Se han identificado los riesgos potenciales?
• ¿Han recibido todos la formación necesaria?
6. TRANSFERENCIA DESPLIEGUE Y RETIRADA
• Transferencia de activos financieros (ej. Costes de
soporte)
• Transferencia y transición del negocio y la organización
(¿preparados para el nuevo servicio en la
organización?)
• Publicación de documentación (a los usuarios.
Manuales, etc)
• Transferencia de “capacidades de Gestión del Servicio”
(herramientas e información al nuevo equipo)
• Transferencia del Servicio (catálogo actualizado,
problemas, riesgos)
• Despliegue del Servicio (distribuir e instalar el servicio)
• Cancelación de Servicios (obsoletos o redundantes)
• Retirada de activos redundantes
7. VERIFICACIÓN DEL DESPLIEGUE
• Verificar que todos los usuarios, operaciones e interesados, pueden
usar el servicio
8. SOPORTE POST IMPLANTACIÓN (ELS: Early Life Support)

• Soporte adicional después del despliegue de un servicio nuevo o
modificado
• Ayuda también a detectar posibles problemas no previstos
9. REVISIÓN Y CIERRE
• Todo correcto
• Listos para pasar de ELS a producción normal
• INTERFACES
• El disparador de este proceso es una RFC aprobada
ENTRADAS SALIDAS
• RFC, SP, SLP, SDP, SAC, GESTIÓN DE • Planes de versiones y
planes continuidad despliegues, RFC
• Políticas, diseño y modelo de ENTREGAS Y completa, notificaciones
versiones y plan y modelo de DESPLIEGUE de servicio, SC
construcción actualizado
• Planes y estándares de • Informes de servicio y
tecnología, compras, Gestión documentación nueva o
del Servicio y operación actualizada
• Criterios de entrada y salida de • Nuevo entorno y
cada fase de la gestión de de capacidades probadas
versiones y despliegue • SLA, OLA y contratos
• Informe de Transición y
plan de capacidad
• Lista CI´s nuevos o modif69
•METRICAS
₋ KPI´s relacionados con el cliente
₋ Rendimiento del servicio
₋ Número de incidencias
₋ Satisfacción del cliente y usuarios
₋ KPI´s relacionados con el consumidor

₋ Costes de diagnósticos de incidencias y problemas
₋ Número de discrepancias en las auditorías de
configuración, en relación con la situación real
5. VALIDACIÓN Y PRUEBAS DEL SERVICIO
• Las pruebas garantizan que los servicios nuevos o modificados están:
• “ajustados al propósito” (el servicio hace lo que el cliente espera)
• “ajustados al uso” (disponibilidad, continuidad, capacidad y seguridad)
• OBJETIVOS
₋ La entrega proporciona los resultados y el valor esperado por los
clientes, dentro de los costes, capacidad y restricciones previstos
₋ Asegurar que el servicio es “ajustado al propósito” y “apto para el uso”
₋ Planificar e implementar el proceso de pruebas
₋ Que se cumplen los SLA (Aportar evidencias objetivas)
• La implementación y gestión de un entorno de pruebas es esencial para
asegurar que las pruebas se ejecutan de manera repetible y controlable.
• La estandarización facilita la integración de los diferentes bloques para
proporcionar una solución funcional.
• AMBITO
• Este proceso se ejecuta durante todo el ciclo de vida del servicio con el fin
de probar la calidad del mismo.
• CONCEPTOS:
• El Modelo de Servicio describe la estructura y dinámica de un servicio
proporcionado por la Operación del Servicio
• La Estrategia de Pruebas define el planteamiento global de pruebas y la
asignación de los recursos necesarios
• Un Modelo de Pruebas incluye un plan de pruebas, el objeto que se desea
probar y guiones de pruebas
₋ Las actividades básicas de este proceso, no se tienen por que realizar
en ese orden y son:
1. Dirección de validación y pruebas
2. Planificación y diseño
3. Verificación del diseño y plan de pruebas
4. Preparación del entorno de pruebas
5. Realización de
pruebas
6. Evaluación de
criterios de
salida y reporte
7. Limpieza y cierre
• RECOMENDACIONES:
₋ Automatizar la instalación de sistemas y software de aplicaciones en
servidores y estaciones de trabajo reduce las dependencias en las
personas y agiliza los procedimientos.
₋ Dependiendo de la entrega y los planes de despliegue, la instalación
se puede realizar de antemano o puede tener que producirse in situ
en el entorno en vivo.
₋ Los elementos de la infraestructura física, junto con el entorno en el
que va a operar, necesitan ser probados adecuadamente.
₋ Parte de las pruebas deberán centrarse en la replicación de la
solución de infraestructura de un entorno a otro. Esto garantizará
que el despliegue en producción tendrá éxito.
• INTERFACES
• Los disparadores de las pruebas pueden ser una actividad de
pruebas prevista en el plan de versiones, el plan de pruebas o el
plan de aseguramiento de la calidad
ENTRADAS SALIDAS
• SP, SLP VALIDACIÓN DEL • Línea base de
• Definiciones de interface según configuración del entorno
el proveedor de servicios SERVICIO Y de pruebas
• SDP PRUEBAS • Pruebas realizadas
• Planes de versiones y • Resultado de las pruebas
despliegues • Análisis de los resultados
• Criterios de aceptación y • Riesgos de incidencias,
solicitudes de cambios problemas y errores de
pruebas
• Ideas de mejora
• Datos actualizados
• Información y
conocimientos para el
SKMS 75
•METRICAS
₋ KPI´s desde la perspectiva del cliente
₋ Impactos de incidencias y errores en producción, atribuibles a
una nueva transición de servicio
₋ Uso de los recursos e implicación del cliente (ej. Pruebas de
aceptación del usuario)
₋ KPI´s del proveedor de servicios (punto de vista interno)

₋ Esfuerzo y costes para preparar el entorno de pruebas
₋ Esfuerzo para detectar errores y “errores repetidos”
₋ Reutilización de datos de pruebas
₋ % de incidencias relacionadas con errores detectados en las
pruebas
₋ Errores conocidos documentados durante las pruebas
• La Evaluación es un proceso genérico con el que se considera si algo tiene un

rendimiento aceptable, si su relación valor‐precio es adecuada, etc o si se
utilizará, aceptará o se pagará por ello, etc
• OBJETIVO
₋ Determinar el rendimiento de un cambio en un servicio
₋ El rendimiento se evalúa en función del rendimiento esperado y
previsto
• AMBITO
• El ámbito se limita a la evaluación de servicios nuevos o modificados.
• 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.
• Los aspectos fundamentales a tener en cuenta son:
– ¿Se cumplieron los objetivos previstos?
– ¿En qué medida se apartó el proceso de las previsiones realizadas por la Gestión
de Cambios?
– ¿Provocó el cambio problemas o interrupciones del servicio imprevistas?
– ¿Cuál ha sido la percepción de los usuarios respecto al cambio?
– ¿Se pusieron en marcha los planes de back‐out en alguna fase del proceso?¿Por
qué?
– 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 asociada.
₋ Las actividades básicas de este proceso
son:
1. Planificación de la evaluación
• Se evalúan los efectos previsto y se
analizan los imprevistos
2. Evaluación del rendimiento previsto
• Hay que hacer una evaluación del
riesgo basada en los
requerimientos de los clientes, el
rendimiento esperado y el modelo
de rendimiento
3. Evaluación del rendimiento real
• Una vez implementado el cambio, la
Operación del Servicio comunica el
rendimiento real.
• Si el rendimiento no es el esperado se
envía un informe y se interrumpen las
actividades de evaluación a la espera de
una decisión 79
• INTERFACES
• Disparadores del proceso de evaluación:
• Una solicitud de evaluación del gestor de la Transición o de la
Gestión de cambios
• Una actividad de evaluación en el plan de proyecto
ENTRADAS SALIDAS
• SDP • Informe de evaluación
• SAC EVALUACIÓN DEL
• Informes de pruebas CAMBIO
• Resultados
•METRICAS
₋ KPI´s relacionados con el cliente
₋ Diferencias en el rendimiento del servicio y número
de incidencias
₋ KPI´s de rendimiento interno

₋ Número de diseños fallidos y tiempo de evaluaciones
• La META de la Gestión del conocimiento es mejorar la calidad del proceso de
toma de decisiones (de la dirección) haciendo que durante el Ciclo de Vida del
Servicio se disponga de información segura y fiable
• OBJETIVOS
₋ Dar soporte al proveedor de servicios para mejorar la eficiencia y la
calidad de los servicios
₋ Garantizar que el personal del proveedor de servicios dispone de la
información adecuada
• AMBITO
₋ La Gestión del Conocimiento se utiliza durante todo el Ciclo de Vida
• OBJETIVOS:
– Recopilar, analizar, archivar y compartir conocimientos e información
dentro de una organización.
– Mejorar la eficiencia permitiendo que los conocimientos aprendidos,
permanezcan en la organización.
– Que el conocimiento sea accesible
– Transmitir a todos los miembros de la organización TI la importancia de
registrar la información relacionada con su trabajo en las herramientas
dispuestas para ello.
– Instalar una cultura de aprendizaje constante entre los miembros del
personal. No sólo se trata de hacer que los empleados registren los
datos, sino también motivarlos a que acudan a las fuentes de
conocimiento para completar aquello que no saben.
– Mantener el Sistema de Gestión del conocimiento de los Servicios
(SKMS)
SABIDURÍA:
Sabiduría es la capacidad de hacer evaluaciones correctas y tomar las
decisiones adecuadas haciendo el mejor uso de los datos, información y
conocimiento
SKMS (Service Knoledge Management System):
Sistema de Gestión de Conocimientos del Servicio
SP: Cartera de servicios
Todos los documentos generados
por el resto de procesos:
PIPE SERVICIOS
LINE SC RETIRADOS
Calidad:
Políticas, procesos,
procedimientos, etc
Servicios:
SPs, informes del servicio.
Servicios de Apoyo subcontratados Activos y Configuración:
Activo financiero, información
CMS Sistema de Gestión de la Configuración del CMS, informes de estado,
CMDB: datos de la CMDB
Base de Datos de Configuración Centro de Servicios / Soporte:
Clientes, usuarios, CIs,
CI´s incidencias, problemas,
Elementos de cambios, entregas,
Configuración rendimientos
• SKMS
•ACTIVIDADES MÉTODOS Y TÉCNICAS
₋ Las actividades básicas de este
proceso son:
1. Estrategia de Gestión del
conocimiento
2. Transferencia de Gestión del
Conocimiento
3. Gestión de la información y
los datos
4. Uso del sistema SKMS
• SKMS Y SU ALCANCE EN EL CICLO DE VIDA DEL SERVICIO
AMIS: Availability Management Information System

CMIS: Sistema de información de gestión de la capacidad
SCMIS: Supply Chain Management and Information Systems
Sistema de información de la gestión de suministradores y contratos
Ángel Caro Amián SMIS: Security Management Information System 89
•INTERFACES
• Los errores detectados por el
personal de Transición del
Servicio se documentar y
analizan
• Transición proporciona a
operaciones el acceso a
información relativa a las
consecuencias de tales errores y
las posibles soluciones
provisionales
• Transición también manda datos
e información a Diseño
•METRICAS
₋ KPI´s relevantes para el cliente
₋ Duración del Soporte Post‐Implantación
₋ Tiempos de resolución de problemas
₋ Informes innecesarios de errores
₋ KPI´s relevantes para el proveedor de servicios:

₋ Uso de la base de conocimiento y nivel de reutilización de la
documentación
₋ Errores detectados por el personal o en una auditoría
₋ Participación del personal en foros de discusión
₋ Grado de reutilización del material documentado
₋ Satisfacción con los cursos, boletines, notas en la web, etc
ORGANIZACIÓN
• No todas las actividades de un proceso tienen por que corresponder al
mismo departamento.
• Un Gestor de Transición del Servicio podría encargarse de gestionar
activamente la Transición:
– Gestiona y controla el trabajo diario de los equipos de transición y sus
actividades
• Ejemplo de Organización:
3.4 OPERACIÓN DEL SERVICIO
ITIL FUNDAMENTOS
• Esta fase demuestra cómo se puede alcanzar OPERACIÓN
DEL SERVICIO
la efectividad y eficiencia en la entrega y
Gestión de Peticiones de
soporte de servicios para asegurar el valor, Servicio
tanto al cliente como al proveedor del
Gestión de Eventos
servicio.
Gestión de Accesos
• La Operación del Servicio es donde los planes,
diseños y optimizaciones son ejecutados y
medidos.
Gestión de Incidencias
• Desde el punto de vista del cliente, la

Gestión de Problemas
Operación del Servicio es donde realmente se
aprecia el valor del servicio.
SP SDP SAC
SLP
SERVICE SERVICE
DESIGN ACCEPTANCE
PACKAGE
SERVICE
LEVEL PACKAGE
MISIÓN. OBJETIVOS
• Disponer de procesos bien diseñados e implementados no sirve de nada si
no se organiza correctamente la ejecución diaria de esos procesos.
• OBJETIVOS:
₋ La coordinación y ejecución de las actividades y procesos necesarios
para entregar y gestionar servicios para usuarios y clientes con el nivel
especificado.
₋ Gestionar la tecnología necesaria para la prestación y el soporte de los
servicios.
₋ Optimización del rendimiento de la Operación del Servicio
₋ Mejora incremental a largo plazo
₋ Mejora continua a corto plazo
₋ AMBITO:
₋ Los servicios
₋ Los procesos de Gestión del Servicio
₋ La tecnología
₋ Las personas
EQUILIBRIO EN LA OPERACIÓN DEL SERVICO
• Estabilidad frente a capacidad de respuesta
– Tecnologías y procesos adaptables
– Proceso robusto y ágil desde estrategia a operación
– Operación participa en estrategia y diseño
• Calidad frente a coste del servicio
– No todo el peso puede estar sobre Operación
• Organización reactiva frente a proactiva
– No olvidar la mejora continua
• La comunicación es clave en la Operación
– Interna, externa, vertical, horizontal…
– Es el contacto con el cliente…
PROCESOS DE LA OPERACIÓN DEL SERVICIO
• Los procesos de los que consta la Operación de Servicio son:

1. GESTIÓN DE EVENTOS
2. GESTIÓN DE INCIDENCIAS
3. GESTIÓN DE PROBLEMAS
4. GESTIÓN DE ACCESOS
5. GESTIÓN DE PETICIONES
CONCEPTOS
• EVENTO:
– Cualquier ocurrencia perceptible o discernible que tenga relevancia
para la gestión del sistema
• INCIDENCIA
– Cualquier evento que interrumpa o pueda interrumpir el servicio
• PROBLEMA
– Causa desconocida de una incidencia
• ERROR CONOCIDO
– Problema del que se tiene una causa raíz conocida y documentada y
una solución, al menos, provisional
• WORKAROUND (Solución provisional)
– Reducción o eliminación del impacto de una incidencia o problema
para la que aun no existe una solución completa.
• EVENTO:
Cualquier ocurrencia perceptible o discernible que tenga
relevancia para la gestión del sistema
Los eventos son notificaciones generadas por un servicio
de TI, un CI ó una herramienta de monitorización.
• TIPOS DE EVENTOS
• Información. Indican una operación normal
(ej. el usuario ha entrado)
• Advertencia. Situación no excepcional
(ej. memoria 30%)
• Excepción. Indican una situación excepcional
(ej. memoria al 95%)
• OBJETIVO GESTIÓN DE EVENTOS

• Detectar Eventos, analizarlos y determinar la acción de
gestión apropiada
• ACTIVIDADES:
1. Ocurrencia del evento
2. Notificación
3. Detección
4. Filtrado
5. Significado (clasificación)
6. Correlación
7. Disparador
8. Selección de respuesta
9. Cierre
• Excepción cualquiera  Cambios de estado disp.
• Tarea completada  Acceso usuario
₋ Nº eventos por categoría
₋ Nº eventos por importancia
₋ Nº eventos por plataforma o aplicación
₋ Nº y % eventos que requieren intervención humana y si se ha hecho
₋ Nº y % eventos que han dado como resultado una incidencia
2. GESTIÓN INCIDENCIAS
• INCIDENCIA
• Cualquier evento que interrumpa o pueda interrumpir el
servicio
• Una interrupción no planificada o una reducción de calidad de
un servicio TI
• En la nomenclatura ITIL una incidencia nunca es un problema

• (un problema es una causa desconocida de una incidencia)
• OBJETIVO GESTIÓN INCIDENCIAS

• Restaura la operación normal tan rápido y eficiente como sea
posible
• Minimizar el impacto adverso en las operaciones del negocio y del
usuario
• Mantener un registro actualizado de las incidencias
• El objetivo NO es buscar la causa (eso lo haremos en Gestión de

problemas)
• ACTIVIDADES:
1. Identificación
2. Registro
3. Categorización
4. Priorización
5. Diagnóstico (inicial)
6. Escalado
7. Investigación y diagnóstico
8. Resolución y recuperación
9. Cierre
CLASIFICACIÓN: PRIORIDAD Y CATEGORIA
PRIORIZACIÓN CATEGORIZACIÓN
• Impacto en el Negocio Clasificación Incidencias
– Evidencia de efecto en las
actividades de Negocio • Aplicación
– Peligro de incumplimiento – Ej. Servicio no disponible
de Niveles de Servicio • Hardware
– Nº de usuario afectados
– Ej. Impresora no imprime
• Urgencia del Negocio
– Tiempo máximo de demora
• Solicitud Servicio
que acepta el cliente y/o – Clave acceso olvidada
acuerdo SLA
• Seguridad
– Virus
• PRIORIDAD=Impacto x Urgencia
Incidente Mayor ó Grave: ↑Prioridad ó ↑Impacto Facilita seguimiento
ESCALADO Y DIAGNÓSTICO
ESCALADO DIAGNÓSTICO
• Funcional • Cada grupo de soporte investiga lo
– Si el CSU no puede resolver que ha pasado y realiza un
(con la rapidez suficiente) la diagnóstico
incidencia, esta debe ser • Todas estas actividades deben
escalada a un nivel de quedar documentadas en un
soporte más alto registro de incidencias
• Jerárquico
– Las incidencias más graves
deben de ser escaladas para
conocimiento de los
responsables
• El escalado no convierte una
incidencia en un
“problema”…
Registro de Incidente
– Es un conjunto de datos con todos los detalles de un Incidente, que documenta la
historia de los mismos desde su registro hasta su resolución.
– Un Incidente se define como una interrupción no planificada o como la reducción
de calidad de algún Servicio de TI.
– Cualquier evento con potencial de interrumpir un Servicio de TI en el futuro
también se considera un Incidente (por ejemplo, el fallo de un disco duro de un
conjunto de discos de réplica).
• Contenidos ‐ Registro de Incidente
Un Registro de Incidente contiene normalmente la siguiente información:
1. Identificación única del Incidente (ID, por regla general, el sistema la asigna
automáticamente)
2. Fecha y hora del registro
3. Agente del Service Desk responsable por el registro
4. Método de notificación
5. Datos del cliente/ usuario que dio la notificación
6. Vía de comunicación utilizada para la respuesta
7. Descripción de síntomas
8. Usuarios / áreas del negocio afectados
9. Servicios afectados
10. Priorización, una función de los siguientes componentes:
1. Urgencia (tiempo disponible hasta la resolución del Incidente), por ej.
1. Hasta 0,5 horas
2. Hasta 2,0 horas
3. Hasta 6,0 horas
2. Grado de severidad (daño causado al negocio), por ej.
1. "Alto" (interrupción de procesos esenciales del negocio)
2. "Normal" (interrupción del trabajo de empleados individuales)
3. "Bajo" (estorbo al trabajo de empleados individuales; es posible continuar trabajando usando
una solución alterna)
3. Prioridad (por ejemplo en etapas 1, 2 y 3): El resultado de la combinación de la urgencia y el grado
de severidad
11. Relación con los CI‘s
12. Categoría del producto, seleccionado usualmente de un árbol de categorías
según el ejemplo siguiente:
1. PC del cliente
1. Configuración estándar 1
2. ...
2. Impresora
1. Fabricante 1
2. ...
13. Categoría del Incidente, seleccionado usualmente de un árbol de categorías
según el ejemplo siguiente:
1. Error de equipo
2. Error de aplicacion
3. ...
14. Enlaces a Registros de Incidentes relacionados (si existen Incidentes similares sin
resolver, a los cuales se les puede atribuir el nuevo Incidente)
15. Enlaces a Registros de Problemas relacionados (si existen Problemas sin resolver, a
los cuales se les puede atribuir el nuevo Incidente)
16. Registro de actividades
1. Fecha y hora
2. Persona a cargo
3. Descripción de las actividades
17. Datos de resolución y cierre
1. Fecha y hora de la resolución
2. Fecha y hora del cierre
3. Categorías del cierre (si se requiere, categorías revisadas de productos e Incidentes)
Modelo de Incidencias
• Existen incidencias que no son nuevas, sino que ya se han producido
anteriormente y que se volverán a producir en el futuro.
• Muchas organizaciones encuentran útil la definición de modelos de incidencia
que se puedan aplicar a incidencias recurrentes del servicio.
• Los modelos de incidencia permiten optimizar el proceso de resolución.
• Un modelo de incidencia debería incluir:
– Los pasos a seguir para la resolución de la incidencia.
– El orden cronológico de estos pasos y sus dependencias si las hubiera.
– Responsabilidades: quién debe hacer qué.
– Plazos para la realización de las actividades.
– Procedimientos de escalado: quién debería ser contactado y cuando.
• Llamada al CSU
• Evento
₋ Nº total de incidencias
₋ Nº y % de incidencias grvaes
₋ Coste medio por incidencia
₋ Nº y % de incidencias asignadas de manera incorrecta
₋ % de incidencias gestionadas en el plazo correcto
• PROBLEMA
• Causa desconocida de una o más incidencias
• Referido solo a la infraestructura de TI o software
• ERROR CONOCIDO (KE)

Problema del que se tiene una causa raíz conocida y documentada y una
solución, al menos, provisional
• WORKAROUND (Solución provisional)

Reducción o eliminación del impacto de una incidencia o problema para la
que aun no existe una solución completa.
• OBJETIVO GESTIÓN DE PROBLEMAS

• Encontrar la causa raíz y solucionarla La restauración del servicio
• Prevenir problemas e incidencias corresponde a Gestión Incidencias
• Eliminar la repetición de incidencias
• Minimizar el impacto de las incidencias
GESTIÓN REACTIVA DE PROBLEMAS

• Identificación
• Registro
• Clasificación
• Priorización
• Investigación y diagnóstico
• Decisión sobre soluciones provisionales
• Identificación de errores conocidos
• Resolución
• Conclusión
• Revisión
• Corrección de los errores detectados
GESTIÓN PROACTIVA DE PROBLEMAS
• Análisis de tendencias
• ¿Qué se ha hecho incorrectamente?. ¿Cómo impedir que
vuelvan a ocurrir?
• Acción Preventiva Planificada
• ¿Qué tenemos que hacer en el futuro para impedir que
vuelva a suceder algunos problemas?
• Recomendaciones a:
• Gestión de Incidencias
• Desarrollo
• Proveedores
• GESTIÓN DE LA INFORMACIÓN
• El CMS contiene información sobre todos los componentes de la
infraestructura de TI y sobre las relaciones entre ellos
• KEDB (Known Errors Data Base) es una base de datos de los Errores
conocidos
Registro de problema
– El Registro de Problema contiene todos los detalles de un Problema y documenta el historial
del mismo, desde su detección hasta su resolución.
• Contenidos ‐ Registro de Problemas
Un Registro de Problemas contiene normalmente la siguiente información:
1. Identificación única del Problema (ID, por lo general, el sistema la asigna
automáticamente)
2. Fecha y hora de su detección
3. Propietario del Problema
4. Descripción de Síntomas
5. Usuarios / áreas del negocio afectados
6. Servicios afectados
•
Contenidos ‐ Registro de Problemas
7. Priorización, una función de los siguientes componentes:
1. Urgencia (tiempo disponible hasta la resolución del Problema) por ej.
1. Hasta 5 días laborables
2. Hasta 2 semanas
3. Hasta 4 semanas
2. Grado de severidad (daño causado al negocio), por ej.
1. “Alto” (interrupción de procesos esenciales del negocio)
2. “Normal” (interrupción del trabajo de empleados individuales)
3. “Bajo” (estorbo al trabajo de empleados individuales; posible continuar el trabajo por medio
de una solución alterna)
3. Prioridad (por ejemplo en etapas 1, 2 y 3): El resultado de la combinación de urgencia y grado de
severidad
8. Relaciones con los CI‘s
9. Categoría del producto, seleccionada usualmente de un árbol de categorías
según el siguiente ejemplo:
1. PC de cliente
1. Configuración estándar 1
2. ...
2. Impresora
1. Fabricante 1 28
2. ...
• Contenidos ‐ Registro de Problemas
10. Categoría del Problema, seleccionado usualmente de un árbol de categorías
según el siguiente ejemplo:
9. Error de equipo
10. Error de aplicacion
11. ...
11. Enlaces a Registros de Problemas relacionados (si existen otros problemas sin
resolver, relacionados a éste)
12. Enlaces a Registros de Incidentes relacionados (si existen Incidentes sin resolver,
cuya solución depende de la solución de este Problema)
13. Registro de actividades y estado actual del Problema
14. Datos de resolución y cierre
9. Fecha y hora de resolución
10. Fecha y hora de cierre
11. Categorías de cierre (si se requiere, categorías revisadas de productos y Problemas)
• Respuesta a una o más incidencias
• Pruebas de aceptación
• Gestión de cambios
₋ Nº total de problemas
₋ % de problemas resueltos dentro de los objetivos del SLA
₋ Nº y % de problemas cuya resolución requirió más tiempo
₋ Nº de problemas pendientes de solución y su tendencia
₋ Coste medio de procesamiento de un problema
₋ Nº de problemas graves (pendientes, cerrados y retrasados)
₋ % de revisiones correctas de problemas serios
₋ Nº de errores conocidos agregados a la KEDB
₋ % de exactitud de la KEDB (a partir de revisiones)
• OBJETIVOS:
• La gestión de accesos concede a usuarios autorizados el derecho a
usar un servicio
• Deniega el derecho a usuarios “no autorizados”
• ACTIVIDADES:
El acceso (o la limitación del mismo) se puede solicitar a través de diversos
mecanismos:
• Solicitud de RRHH ante nueva contratación o cambio
• Una solicitud de cambio (RFC)
• Una petición (Gestión de Peticiones)
• Verificación
• Concesión de derechos (decidido en estrategia y diseño)
• Monitorización del estado de identidades
• Registro y monitorización de accesos
• Revocación o limitación de derechos
• MÉTRICAS (KPI´s):
• Nº total de solicitudes de acceso
(peticiones de servicio y solicitud de
cambio)
• Nº de veces que un servicio, usuario
o departamento ha concedido
acceso
• Nº de incidencias necesarias para
que se revoquen los derechos de
acceso
• Nº de incidencias causadas por
configuración incorrecta de accesos
• PETICIÓN DE SERVICIO:
• Es una solicitud de información, asesoramiento, cambio
estándar o acceso a un servicio por parte de un usuario
• OBJETIVOS:
• Atender toda solicitud que no sea una incidencia
• Poner a disposición del usuario un canal de solicitar y recibir
servicios o información
• Dar a usuarios información sobre la disponibilidad del
servicio y cómo obtenerlo
• ACTIVIDADES
1. Selección de posibles peticiones en un menú
2. Aprobación financiera/otras
3. Tratamiento
4. Cierre
• MÉTRICAS (KPI´s):
• Nº total de peticiones de servicio
• Nº peticiones pendiente de resolución
• Tiempo medio de gestión para cada tipo
de petición
• Nº y % de peticiones en plazo acordado
• Coste medio para cada tipo de petición
de servicio
• Nivel de satisfacción de los clientes con
la gestión
FUNCIONES
DEFINICIÓN DE FUNCIÓN en ITIL
• Una función es una subdivisión o grupo de trabajo en una
organización que está especializada en realizar un tipo concreto de
trabajo y tiene la responsabilidad de obtener resultados concretos.
• Tienen las capacidades y recursos necesarios para alcanzar
los resultados exigidos.
• Tienen sus propias prácticas y su propio cuerpo de conocimiento.
• Proporcionan estructura y estabilidad a las organizaciones.
• En ITIL se diferencia claramente entre el concepto de proceso y

función:
• Proceso implica actividades, coordinación entre personas
• Funciones se refiere a grupos de personas.
FUNCIONES DE OPERACIONES TI
• Las actividades de las Funciones de Operaciones TI se refieren a las
actividades necesarias para gestionar el área de TI. Gestiona tanto el
hardware como el software, así como toda la parte técnica y la gestión al
usuario
FUNCIONES DE
OPERACIONES DE
SERVICIOS
1. Gestión de 2. Gestión de 4. Centro de

3. Gestión Técnica
Operaciones TI Aplicaciones Servicio al Usuario
1.1 Control de
Operaciones TI
1.2 Gestión de
Instalaciones
FUNCIONES de OPERACIONES TI en ITIL
1. GESTIÓN DE OPERACIONES TI
1.1 FUNCIÓN DE CONTROL DE OPERACIONES
• Las actividades de la Función de Control Operaciones TI se refieren a las
actividades rutinarias necesarias para gestionar el software de la
Infraestructura TI
• PUENTE DE OPERACIONES
• Es un punto de Coordinación Central que centraliza los principales puntos de
observación de la infraestructura de TI, de manera que se puedan monitorizar
y controlar con mínimo esfuerzo
• AMBITO/ACTIVIDADES:
• Planificación de Trabajos y tareas
• Backup y restauraciones
• Impresoras y colas
1. GESTIÓN DE OPERACIONES TI
1.2 FUNCIÓN DE GESTIÓN DE INSTALACIONES DE TI
• Las actividades de las Funciones de Control Operaciones TI se refieren a
las actividades rutinarias necesarias para gestionar y mantener la
Infraestructura TI
• AMBITO/ACTIVIDADES:
• Hardware de los Centros de datos
• Equipos de Energía y A/C
• Consolidación de Infraestructura
• Sitios de recuperación
2. FUNCIÓN DE GESTIÓN DE APLICACIONES
• MISIÓN:
• Gestionar las aplicaciones durante su ciclo de vida
• Son la relación entre el Ciclo de Vida de las Aplicaciones y el Ciclo de
Vida del Servicio
• CICLO DE VIDA DE LAS APLICACIONES

• Requisitos • El ciclo de vida de las aplicaciones no
• Diseño es una alternativa al ciclo de vida de
• Construcción los servicios
• Despliegue • Las aplicaciones se deben tratar como
• Operaciones tales
• Optimización
• OBJETIVOS:
• Dar soporte a los procesos de negocio de la organización, definiendo requsitos
funcionales y de gestión para aplicaciones
• Colaborar en el diseño e implementación de las aplicaciones. Y soporte y mejora
3. FUNCIÓN DE GESTIÓN TÉCNICA
• En esta función se encuentra el conocimiento y la experiencia técnica
sobre toda la Infraestructura de TI
• Proporciona los recursos para soportar todo el Ciclo de Vida de ITSM
• OBJETIVOS
Ayuda a planificar implementar y mantener la infraestructura de TI a través de:
• Una topología técnica de alta capacidad y rentable
• Usar habilidades técnicas para mantener la Infraestructura de TI de forma
óptima
• Uso de habilidades de forma muy rápida para diagnosticar y resolver fallos
técnicos
• ACTIVIDADES
• Solución de Problemas técnicos
• Identificar conocimiento y experiencias requeridas
• Lanzar programas de formación
• Implicación en la Contratación de recursos que no se puedan desarrollar
internamente
• Implicación en la Gestión de la Disponibilidad y la Capacidad para diseñar
nuevos servicios
• Implicación en proyectos durante el Diseño ó Transición del Servicio 42
4. FUNCIÓN DE CENTRO DE SERVICIO AL USUARIO
• Actúa como punto central y UNICO de contacto entre usuarios y la Gestión
de Servicios TI
• El Centro de Servicio al Usuario (CSU) en inglés SD (Service Desk) cubre
un rango de actividades mayor que un Help Desk o Centro de Soporte que
solo se dedica a la resolución de incidencias…
• OBJETIVOS
• Restaurar el servicio “normal” en el menor tiempo posible
• Para ello deberá solucionar un error técnico, satisfacer una petición o
responder una pregunta
• ACTIVIDADES
• Registra todas las llamadas al CSU
• Peticiones
• Incidencias
• Cierra todas la incidencias y cumple con las Peticiones de Servicio
• Restaura el servicio al usuario
• Genera informes, comunica, promociona productos…
• Monitoriza y controla todas las llamadas
4. FUNCIÓN DE CENTRO DE SERVICIO AL USUARIO
• TIPOS DE CSU
• LOCAL
• Físicamente en el mismo lugar que los usuarios
• CENTRALIZADO
• Si hay varias localizaciones, el CSU en único lugar y da servicio a
todas
• VIRTUAL
• Como el centralizado, pero las personas pueden estar en varias
localizaciones o incluso en su casa
• “Siguiendo al sol”
• Tipo concreto de Centro Virtual: cuando se da servicio las 24
horas, por el día se puede dar servicio en un lugar en el que
también es de día y de noche, en otro lugar de la tierra,
donde es de día entonces
ROLES EN LA FASE
DE OPERACIÓN
ROLES PRINCIPALES
• Gestor de Accesos
• Gestor de Incidentes
• Equipo de Incidentes Mayores o Graves
• Gestor de Instalaciones de TI
• Gestor de las Operaciones de TI
• Gestor de Problemas
• Grupo Cumplimiento Solicitud Servicio
• Operador de TI
• Soporte de Primera Línea
• Soporte de Segunda Línea
ROLES PRINCIPALES
• Gestor de Accesos
– Concede el derecho a usar un servicio a usuarios autorizados y previene el acceso de
usuarios no autorizados.
• Gestor de Incidentes
– Es responsable de la implementación efectiva del proceso de Gestión de Incidentes y
prepara los informes correspondientes.
– Ofrece representación durante la primera fase de escalado de incidentes, cuando no se
pueden solucionar en el marco de los niveles de servicio acordados.
• Equipo de Incidentes Mayores o Graves
– Es un equipo de gestores de TI y técnicos expertos establecido dinámicamente,
generalmente bajo el mando de un Gestor de Incidentes, y formulado para concentrarse
en la solución de un Incidente grave.
• Gestor de Instalaciones de TI
– Se ocupa de gestionar el entorno físico donde se encuentra ubicada la infraestructura de
TI.
– Incluye todos los aspectos de gestión del entorno, como los concernientes a fuentes de
energía, acondicionamiento del aire, la gestión de accesibilidad a los edificios y la
monitorización de ambientes.
ROLES PRINCIPALES
• Gestor de las Operaciones de TI
– Se responsabiliza por todas las actividades de Gestión de las Operaciones de TI.
– Asegura que todas las actividades cotidianas se lleven a cabo puntual y confiablemente.
• Gestor de Problemas
– Es responsable de gestionar el ciclo de vida de todos los Problemas.
– Sus objetivos principales son la prevención de Incidentes, y la minimización del impacto
de aquellos que no se pueden evitar.
– Tiene información sobre Errores Conocidos y Soluciones Provisionales.
• Grupo Cumplimiento Solicitud Servicio
– Se especializan en la realización de ciertos tipos de Solicitudes de Servicio.
– Por lo general, el Soporte de Primera Línea procesa los pedidos más simples, mientras
que el resto es referido a los grupos especializados de Cumplimiento de Solicitud de
Servicio.
• Operador de TI
– Personal que a diario lleva a cabo las actividades operativas.
– Entre sus responsabilidades se encuentran: Preparar copias de seguridad, velar para que
se realicen las tareas programadas, instalar equipos comunes en el centro de datos.
ROLES PRINCIPALES
• Soporte de Primera Línea
– Su responsabilidad es registrar y clasificar los Incidentes reportados y llevar a cabo
esfuerzos inmediatos para restaurar lo antes posible un servicio de TI que ha fallado.
– Si no se encuentra una solución adecuada a estos fines, refiere el incidente a grupos de
apoyo técnico especializado (Soporte de Segunda Línea).
– Mantiene informados a los usuarios acerca del estatus de los Incidentes cada cierto
tiempo.
• Soporte de Segunda Línea
– Se hace cargo de los Incidentes que no pueden ser resueltos con los recursos del Soporte
de Primera Línea.
– De ser necesario, requerirá apoyo externo de proveedores de software o hardware.
– La meta es restaurar un servicio de TI fallido en el menor tiempo posible.
– Si no se encuentra solución, el Incidente debe ser referido a Gestión de Problemas.
3.5 MEJORA CONTINUA DEL
SERVICIO
ITIL FUNDAMENTOS
CSI: Continuous Service Improvement
• Se preocupa de crear y mantener el valor MEJORA CONTINUA DE
LOS SERVICIOS
para el cliente a través de un mejor Los 7 pasos
de Mejora
diseño, introducción y operación de los
servicios.
• Propone la mejora de todos los procesos.
• Estrategia, Diseño, Transición y Operación
del Servicio,
• Busca identificar oportunidades para
mejorar las debilidades o fallos dentro de
cualquiera de las etapas.
MISIÓN. OBJETIVOS
• La MISIÓN del CSI es la mejora continua de la eficacia (objetivos) y la
eficiencia (costes) de servicios TI para facilitar el cumplimiento de los
objetivos de la organización.
• Sus principales OBJETIVOS se resumen en:

₋ Medir y analizar Logros de Nivel de Servicio
comparando con los SLA
₋ Recomendar mejoras en todas las fases del Ciclo
de Vida
₋ Introducir actividades que aumenten la calidad, la
eficiencia, la eficacia y la satisfacción de los
clientes
₋ Operar servicios más rentables, sin que le afecte al
cliente
₋ Utilizar métodos de Gestión de Calidad adecuados
para actividades de mejora
AMBITO
• El ámbito del CSI incluye tres áreas importantes:
• Calidad general de la gestión TI
• Ajuste continuo de los servicios de TI a las necesidades presentes y
futuras de la organización
• Ajuste continuo de la Cartera de Servicios de TI
• CSI mide y monitoriza fundamentalmente los siguientes aspectos:

• Conformidad del proceso: ¿Sigue la organización los procesos de
gestión de servicios nuevos o modificados y utiliza las nuevas
herramientas?
• Calidad: ¿Logran sus objetivos las distintas actividades del proceso?
• Rendimiento: ¿Hasta que punto es eficaz el proceso?, ¿Cuáles son
los tiempos transcurridos?
• Valor de un proceso para el negocio: ¿Crea el proceso alguna
diferencia?, ¿Qué opina el cliente?
MÉTRICAS e INDICADORES CLAVE DE RENDIMIENTO
• Los responsables de ITSM necesitan saber si la organización
cumple sus objetivos  MEDIR
• En CSI se necesitan tres tipos de métricas:
• Métricas de Tecnología:
• Miden el rendimiento y disponibilidad de componentes
y aplicaciones
• Métricas de Proceso:
• Miden el rendimiento de los procesos de gestión de
servicios TI
• Métricas de Servicio:
• Miden los resultados del servicio final
• La misión del negocio define los SCF (Factores Críticos de Éxito) y
a partir de éstos, los KPI (Indicadores Clave del Rendimiento)
• Los KPI´s pueden ser cualitativos ó Cuantitativos
DESAFIOS Y BARRERAS A LA MEJORA CONTINUA
• Falta de implicación del personal de desarrollo y de proyectos
• Justificación de los fondos
• Carencia de Gestión del Conocimiento
• Ausencia de objetivos, estrategias y políticas de TI
• Falta de información, monitorización, medidas
• Resistencia a que se evidencien los errores
• Resistencia al cambio
• Relaciones y comunicaciones deficientes
• Falta de cooperación
• Falta de herramientas, estándares y habilidades
• Herramientas demasiado complejas y difíciles de implementar
Modelo DIKW (Datos‐Información‐Conocimiento‐Sabiduría)
(Data‐Information‐Knoledge‐Wisdom)
• Las métricas proporcionan datos cuantitativos (un CSU puede registrar, por ejemplo,
1000 incidencias al día)
• El CSI transforma esos datos en información cualitativa (por ejemplo, el 20% de esas
incidencias son sobre el correo electrónico)
• La combinación de información, experiencia,
contexto, interpretación y reflexión convierte esa
información en conocimiento (por ejemplo si el
negocio tiene una tienda web, podríamos determinar
el impacto de las incidencias en el correo electrónico)
• El CSI convierte ese conocimiento en sabiduría, para
toma decisiones
• La sabiduría es la capacidad de hacer evaluaciones
correctas y tomar las decisiones adecuadas haciendo
el mejor uso de los datos, información y
conocimiento (por ejemplo cambiar la base de datos,
que originan las incidencias que más influyen en las
ventas en la web) 7
CICLO DEMING: PDCA
• Edward Deming desarrolló este modelo de mejora en los años 40,
extendiéndose después en Japón y siendo la base de los sistemas de
calidad.
• P. PLANIFICAR (Plan)
– ¿Qué tiene que ocurrir, quien lo hará
y cómo?
• D. HACER (Do)
– Ejecución de las actividades
planificadas
• C. VERIFICAR (Check)
– Comprobación de que las actividades
dan el resultado deseado
• A. ACT (Actuar)
– Ajuste del plan, en función de los
resultados
CICLO DEMING: PDCA
APLICACIÓN DEL CICLO PDCA A LA MEJORA CONTINUA DEL SERVICIO
MODELO MEJORA: 6P LOS SEIS PASOS DEL IMPULSO
• El efecto de una mejora depende, en gran parte, del rumbo
hacia el que vaya encaminada.
• Las organizaciones deben evaluar continuamente la
relevancia, integridad y viabilidad de su programa de mejoras
6
3
EL PROCESO DE MEJORA EN 7 PASOS
SABIDURÍA
DATOS
SIP
CONOCIMIENTO INFORMACIÓN
Al resultado de la mejora lo llamamos SIP. PLAN DE MEJORA DEL SERVICIO

(Service Improvement Plan)
CONEXIÓN ENTRE
EL PROCESO DE MEJORA: 7 PASOS MEJORA
Y EL MODELO DE MEJORA: 6 PASOS IMPULSO
6 pasos Impulso
7 pasos Mejora
INFORME DE EVALUACIÓN DE SERVICIOS
– El Informe de Evaluación de Servicios un documento que contiene los
resultados y los hallazgos de una Revisión de Servicio.
– Este protocolo constituye un aporte importante en el establecimiento de
iniciativas de mejora.
• CONTENIDOS – INFORME DE EVALUACIÓN DE SERVICIOS
La siguiente información está incluida normalmente en el Informe de Evaluación de Servicios:
1. Nombre del Servicio de TI bajo revisión
2. Fecha y hora de la revisión
3. Persona a cargo de la revisión
4. Participantes en la Reunión de Revisión de Servicios
1. Representantes de clientes y usuarios
2. Representantes del proveedor de servicios
5. Presentación de resumen de niveles de servicio acordados vs. logrados
6. Informe de situaciones excepcionales
INFORME DE EVALUACIÓN DE SERVICIOS
• Contenidos – Informe de Evaluación de Servicios
La siguiente información está incluida normalmente en el Informe de Evaluación de Servicios:
7. Satisfacción en cuanto a la calidad de servicios de parte de los clientes
1. Cumplidos
2. Querellas
8. Áreas que deben enfocar las iniciativas de mejora (resultando en cambios al servicio
y/o a sus procesos subyacentes, o cambios a los acuerdos con los clientes)
1. Desde la perspectiva del cliente: requisitos nuevos o cambiados para el servicio
1. Cambios en procesos o estrategia del negocio que llevan a requisitos funcionales nuevos
2. Cambios en percepciones de riesgos, prioridades y criticidad que llevan a cambios en las
Metas de Nivel de Servicio
3. Cambios anticipados en el consumo del servicio, a corto plazo y también a mediano y largo
plazo
4. Modificaciones requeridas a corto plazo (por ej. debido a problemas actuales / recientes)
5. Requisitos cambiados en cuanto a cómo informar sobre los Niveles de Servicio
2. Desde la perspectiva de TI
1. Áreas donde se debe mejorar la calidad del servicio
2. Áreas donde se pueden optimizar los costos, por ej. usando nuevas tecnologías u optimizando
procesos, o influenciando la demanda del servicio 14
SIP. PLAN DE MEJORA DEL SERVICIO
Contenido de un SIP
• Es el resultado de la Mejora Para cada iniciativa definida para mejorar un
Continua del Servicio proceso o servicio:
1. Proceso o servicio afectado
• El SIP es un plan formal para 2. Persona a cargo del proceso (Propietario
implementar las mejoras a de Proceso) o servicio (Propietario del
los servicios y procesos de TI Servicio)
3. Propietario de la iniciativa (persona a cargo
• El SIP se utiliza para de la iniciativa)
gestionar y documentar las 4. Aprobación de la dirección de TI (iniciativa
iniciativas de mejoramiento aprobada por …)
5. Descripción de la iniciativa
desencadenadas por el 6. Origen de la medida (por ej. Revisión de
Perfeccionamiento Continuo Servicios, Auditoría de Procesos)
del Servicio (CSI). 7. Caso de negocio
• Resultado esperado de la iniciativa
• Estimación del costo
• Resultado específico deseado de la iniciativa,
por ej. una disminución en los costos de
provisión de un servicio)
8. Calendario de implement. y estado actual
• Fecha prevista
Ángel Caro Amián • Estado actual 15
ROLES EN LA
MEJORA CONTINUA
ROLES PRINCIPALES
• Gestor la Mejora Continua del Servicio
– Encargado de gestionar mejoras a los procesos y servicios de Gestión de Servicios de TI y
a Servicios de TI.
– Tomará medidas continuamente del rendimiento del servicio y diseñará mejoras a los
procesos, servicios e infraestructura, de manera que se aumenten la eficiencia, la
efectividad y la rentabilidad.
• Propietario de cada proceso
₋ Es el responsable de que el proceso cumpla su propósito, pero también:
₋ De la mejora continua del proceso. Proporciona inputs para el Programa de Mejora del
Servicio SIP (Service Improvement Program).
₋ Encargado del diseño y de los cambios que se realicen en el proceso así como de la
definición de la estrategia del proceso.
₋ Es el patrocinador, Es el encargado de documentarlo y publicarlo.
• Gestor de cada proceso
₋ Es el responsable de que el proceso funcione:
₋ Planificador, Coordinador de actividades
₋ De la mejora continua del proceso (ambos roles comparten esta tarea)
₋ Monitorización y reporting
4 Indicadores KPI ITIL
4. INDICADORES
DE
PROCESOS ITIL
FUNCIONES
KPI´s PROCESOS
ITIL
INDICADORES KPI ITIL
• Los Indicadores Clave de Rendimiento ITIL (KPI’s) se utilizan para evaluar si los
procesos de una organización de TI – los procesos de ITIL – funcionan según
las expectativas.
• Definir los KPI’s adecuados es fundamental para una "ejecución exitosa de un

proceso".
• Sin KPI’s no es posible evaluar la calidad de los procesos y por tanto no se
podrán mejorar ni optimizar.
• Los KPI’s dependen de cada organización, pero existen una cantidad de KPI’s
típicos utilizados para evaluar los procesos de ITIL.
• Estos indicadores comunes se presentan en las siguientes páginas como una
colección completa de KPI’s para los procesos más importantes de ITIL V3.
• Los KPI’s cumplen con las recomendaciones de ITIL y han sido mejorados con
elementos de COBIT.
¿POR QUÉ MEDIR?
• Medir, como cualquier acción emprendida por una organización, no puede
abordarse sin una motivación y unos objetivos definidos
¿POR QUÉ MEDIR?
• La motivación para medir siempre debe ser el control de los procesos para su
posterior mejora emprendiendo acciones.
• El control de los procesos está incluido en el conocido Ciclo de Deming en el
apartado de control (check).
¿POR QUÉ MEDIR?
• Los objetivos de la medición no son idénticos en todas las organizaciones.
• Cada organización debe reflexionar qué aspectos son más relevantes para
focalizar en ellos.
• No obstante, hay recomendaciones generales que suelen serun buen punto de
partida en la mayoría de los casos.
¿QUÉ ES MEDIR?
• Medir, según la definición que podemos encontrar en cualquier diccionario es
“comparar una cantidad con su respectiva unidad, con el fin de averiguar
cuántas veces la primera contiene la segunda”.
• Las dificultades de medir son, por tanto dos:
• ¿Qué cantidad hay que comparar?
• ¿Cuál es la unidad contra la que se compara?
¿QUÉ ES MEDIR?
• Medir exige identificar y definir el concepto a medir, desarrollar el concepto en
dimensiones que ayuden a comprenderlo y, por último, construir las métricas
que cuantifican cada dimensión.
¿QUÉ ES MEDIR?
INDICADORES KPI ITIL
• Un principio extensamente aceptado mantiene que los “KPI's deben ser
SMART”:
• Específico (Specific)
• ¿Está claro que es lo que mide?
• ¿Se podría malinterpretar?
• Medible (Measurable)
• ¿Es posible medirlo?
• ¿Cómo voy a medir mis progreso?
• Alcanzable (Achievable)
• ¿Son asequibles mis KPIs?
• ¿Lo podremos hacer con los recursos de los que disponemos?
• ¿Objetivo consesuado?
• Relevante (Relevant)
• ¿Este KPI es importante para mi organización? Del 1 al 10 dónde lo situaría.
• En un futuro, ¿encajará este KPI dentro de las perspectiva de mi plan de futuro?
• A tiempo (Timely)
• ¿Es posible seguirlo en el tiempo?
• ¿Tengo definidas las estrategias para cumplir mis KPIs?
PERFECCIONAMIENTO CONTINUO DEL SERVICIO
5. Implementando ITIL
5. IMPLEMENTANDO ITIL
IMPLEMENTANDO ITIL POR ETAPAS
En vez de introducir toda la serie completa de recomendaciones ITIL a la vez, la mayoría de las organizaciones
empieza con una parte de los procesos ITIL.
• Primer paso: Manejando incidentes y problemas
– Frecuente empezar con "Gestión de Incidentes", con el apoyo de "Gestión de Problemas" para resolver
problemas mayores.
– Se suele incluir la "Activos de Servicio y Gestión de la Configuración", porque los datos confiables sobre la
infraestructura de TI mejorarán significativamente la efectividad de la Gestión de Incidentes y Problemas.
• Segundo Paso: Gestión de Cambios y Gestión de Ediciones
– La empresa entera depende de una infraestructura de TI actualizada, confiable y segura, para apoyar sus
procesos de negocios.
– Cualquier cambio en esta infraestructura que no esté autorizado ni coordinado es algo no deseable y puede
llevar a menudo a la interrupción del negocio.
– Los cambios en la infraestructura de TI solamente se lleven a cabo de manera coordinada.
– Establecer los procesos de "Gestión de Cambios" y "Gestión de Ediciones e Implementación“.
• Tercer paso: Enfoque en el cliente
– En el tercer paso, se crean las condiciones para acordar y monitorear los niveles de servicio.
– Esto principalmente requiere una "Gestión del Nivel de Servicio (SLM)", "Gestión de la Disponibilidad", y
"Gestión de la Continuidad del Servicio de TI (ITSCM)" para asegurar el manejo activo de las metas relevantes
de niveles de servicio.
IMPLEMENTANDO ITIL EN 10 PASOS
IMPLEMENTANDO ITIL EN 10 PASOS
• Paso 1: Preparación del proyecto
• Paso 2: Definición de la estructura de servicios
• Paso 3: Selección de roles ITIL y propietarios de roles
• Paso 4: Análisis de procesos existentes (Evaluación de ITIL)
• Paso 5: Definición de la estructura de procesos
• Paso 6: Definición de interfaces de procesos ITIL
• Paso 7: Estableciendo controles de procesos
• Paso 8: Diseñando los procesos en detalle
• Paso 9: Selección e implementación de sistemas de
aplicaciones
• Paso 10: Implementación de procesos y adiestramiento
1: PREPARACIÓN DEL PROYECTO
• FORMACIÓN Y FAMILIARIZACIÓN CON ITIL
• IMPLANTAR LA GESTIÓN POR PROCESOS
– Para alinear la organización de TI con ITIL,
– Asegurar que los procesos nuevos sean continuamente monitoreados y mejorados.
– Requisito central para obtener una certificación ISO 20000.
– Si ya existe una función de Gestión de Procesos o Gestión de Calidad, también puede
manejar los procesos ITIL.
– El objetivo será:
• Asegurar que todos los procesos ITIL funcionen conjuntamente con fluidez;
• Proveer herramientas adecuadas para manejar procesos;
• Asegurar que se documenten adecuadamente los procesos ITIL;
• Ayudar al personal de TI a mejorar sus procesos.
• Si no existen estas condiciones, habrá que seleccionarse un miembro adecuado del personal
de TI para esta función
2: DEFINICIÓN DE LA ESTRUCTURA DE SERVICIOS
• OBJETIVOS
– Identificar los servicios de negocio (clientes) y de soporte (internos TI)
– Crear la estructura de servicios determinando la interdependencia entre
servicios de negocios y de soporte.
• SERVICIOS DE NEGOCIOS Y SERVICIOS DE SOPORTE
– Los servicios de negocios (ofrecidos a clientes) se construyen en una base de
servicios de soporte (visible sólo internamente en la organización de TI).
• Los servicios de negocios se caracterizan por representar un valor directo para el
cliente, por ejemplo, el hecho de proveer correo electrónico y acceso a Internet.
• Los servicios de soporte, por el contrario, no son de valor directo para los clientes
sino que sirven de base para sostener los servicios de negocios.
– Por ejemplo, el cliente quiere acceso fiable a Internet, no algún tipo
específico de infraestructura de red (de hecho, es irrelevante para el cliente
que sea necesaria una infraestructura de red para proveerle acceso a
Internet).
• LISTA DE LOS SERVICIOS DE NEGOCIOS EXISTENTES
– Acuerdos e información previamente establecidos.
– Al menos, una lista básica, que incluya descripciones breves de servicios y clientes
que los utilizan.
• LISTA DE LOS SERVICIOS DE SOPORTE
– Importante asignar responsabilidades para el suministro de tales servicios.
– Se espera que los Propietarios de Servicios responsables se aseguren de que sus
servicios cumplan con las metas de los niveles de servicio, según lo acordado.
– Normalmente están relacionados estrechamente con ciertas partes de la
infraestructura de TI, por ejemplo, con los sistemas principales de aplicaciones o
componentes de la infraestructura: Un ejemplo típico sería "Proveyendo un ambiente
de SAP“.
• DEFINIR LA ESTRUCTURA DE SERVICIOS
– Entender la interrelación entre ambos tipos de servicios
– Los servicios de soporte están a menudo en escalas; por ejemplo, un servicio que es
responsable de manejar cierto sistema de aplicaciones puede que dependa de otro
servicio de soporte para proveer un sistema operativo básico.
– Esta estructura será muy útil para diseñar el Catálogo de Servicios.
• RESULTADOS / ENTREGABLES
– Una lista de servicios de negocios, incluyendo al menos descripciones breves de
servicios y clientes que las usan
– Una lista de servicios de soporte, incluyendo al menos descripciones breves de los
servicios y los Propietarios de Servicios responsables de los mismos
– Estructura de servicios
• FACTORES DE ÉXITO
– Firmar con clientes Acuerdos de Nivel de Servicio (SLA) formales no tiene mucha
importancia en esta etapa temprana del proyecto.
– Los SLA se concluyen como parte de Gestión del Nivel de Servicio (SLM), un proceso
que se implementará más tarde, durante el curso del proyecto.
– Para la mayoría de las organizaciones de TI, un número aproximado de 5 a 15
servicios de negocios debe ser adecuado.
– La estructura de servicios combina típicamente diferentes componentes de servicios
relacionados para crear servicios de negocios.
– Así se pueden negociar paquetes completos con el cliente.
– Por ejemplo, el servicio "Proveer PCs a clientes" puede contener, entre otros
componentes:
• Instalación inicial
• Resolución de incidentes
• Asistencia para el usuario
• Actualizaciones de aplicaciones
• Actualizaciones de equipo
– La estructura de servicios de TI que se definirá, sólo puede ser viable si se crea en
estrecha coordinación con los clientes de la organización de TI.
– En las conversaciones iniciales con el cliente, los representantes de TI deben enfatizar
su objetivo de mejorar la calidad del servicio, como meta del proyecto.
– Se debe evitar dar la falsa impresión de imponerle a un cliente un contrato que no le
conviene.
– Los servicios internos se deben estructurar de manera que sea posible asignar
responsabilidades claras a los Propietarios de Servicios.
– Luego habrá Acuerdos de Nivel Operacional (OLA) con estos Propietarios de
Servicios.
3: SELECCIÓN DE ROLES ITIL Y PROPIETARIOS DE ROLES
• Vital importancia para el éxito del proyecto.
• La persona que luego será responsable de determinado proceso
también debe participar en su diseño.
– Esto asegurará que la mayor experiencia posible fluya en la definición del
proceso, y que los propietarios de roles se identifiquen muy de cerca con
cualquier cambio a las prácticas de trabajo existentes.
• Dependerá de las disciplinas ITIL que se introduzcan.
– Por ejemplo, si se va a implementar Gestión de Problemas, debe nombrarse
un Gestor de Problemas.
• En organizaciones grandes la determinación de los roles no es tan
sencilla.
– Puede ser necesaria una subdivisión de tareas, resultando en una subdivisión
de roles.
• Si el Gestor de Problemas, por ejemplo, no puede manejar todas la tareas en Gestión
de Problemas, se puede considerar el crear roles tales como "Analista de Problemas",
"Gestor de Errores", etc.
• En esta etapa del proyecto no es necesario definir los roles en
detalle
3: SELECCIÓN DE ROLES ITIL Y PROPIETARIOS DE ROLES
• Resultados / Entregables
– Lista de roles ITIL necesarios
– Asignación de roles a propietarios
• Factores de éxito
– Nombrar personas específicas como propietarios de roles
– En caso de dudas, empezar con los roles ITIL obvios, y luego añadir subroles,
si fuera necesario y matriz RACI.
• Perspectivas relevantes del Mapa de Procesos ITIL
– El ITIL Process Map contiene todos los roles ITIL típicos, con sus
descripciones. Los roles que el proyecto requiere se pueden escoger de este
inventario.
– Los organigramas de la organización también se pueden usar para presentar
la asignación de roles a propietarios.
– Los diagramas de procesos detallados permiten a los propietarios de roles
supervisar intuitivamente sus tareas y responsabilidades.
ROLES ITIL
• ESTRATEGIA DEL SERVICIO
– Consejo de Dirección de TI (ISG)
• El Consejo de Dirección de TI (IT Steering Group, ISG) establece la dirección y la Estrategia del
Servicios de TI.
• Incluye a miembros de la alta dirección de la empresa y de TI.
• El ISG revisa las estrategias de la empresa y de TI para asegurar que estén en concordancia.
• También establece prioridades para el desarrollo de servicios y proyectos.
– Gestor del Portfolio de Servicios
• El Gestor del Portafolio de Servicios determina la Estrategia del Servicio al cliente en coordinación con
el Consejo de Dirección de TI (ISG), y desarrolla las ofertas y capacidades del proveedor de servicios.
– Gestor Financiero
• El Gestor Financiero se ocupa de gestionar el presupuesto, la contabilidad y los requisitos de cobro de
un proveedor de servicios de TI.
• DISEÑO DEL SERVICIO

– Analista / Arquitecto de Aplicaciones
• El Analista / Arquitecto de Aplicaciones es responsable del diseño de aplicaciones necesarias para la
prestación de un servicio.
• Esto incluye la especificación de tecnologías, la aplicación de arquitecturas y de estructuras de datos
como base para el desarrollo o la personalización de aplicaciones.
– Analista / Arquitecto Técnico
• El Analista / Arquitecto Técnico se ocupa de diseñar componentes de infraestructura y sistemas
necesarios para la prestación de un servicio.
• Esto incluye la especificación de tecnologías y productos como base para su adquisición y
personalización.
ROLES ITIL
– Arquitecto de TI
• El Arquitecto de TI establece un programa para el desarrollo futuro del panorama tecnológico, tomando
en consideración la Estrategia del Servicio y las nuevas tecnologías disponibles.
– Gestor de Cumplimiento
• La responsabilidad del Gestor de Cumplimiento es velar para que se sigan los estándares y los
manuales, o que se emplee la contabilidad y otras prácticas adecuada y consistentemente.
• Esto incluye velar por el cumplimiento de leyes o regulaciones externas.
– Gestor de Diseño del Servicio
• El Gestor de Diseño del Servicio es responsable de producir diseños seguros, sólidos y de calidad para
servicios nuevos o mejorados.
• Esto incluye la producción y el mantenimiento del diseño de toda la documentación de diseños.
– Gestor de la Capacidad
• El Gestor de la Capacitad se encarga de asegurar que los servicios y la infraestructura cumplan con los
objetivos de rendimiento propuestos de manera económicamente efectiva y puntual.
• Toma en consideración todos los recursos necesarios para la prestación de servicios, y crea planes a
corto, medio y largo plazo para cumplir con los requisitos de la empresa.
– Gestor de la Continuidad del Servicio de TI
• El Gestor de la Continuidad del Servicio de TI es responsable de gestionar aquellos riesgos que podrían
afectar severamente la prestación de servicios de TI.
• Se asegura que el desempeño del proveedor de servicios de TI cumpla los requisitos mínimos del nivel
de servicio en casos de desastre, mediante reducción del riesgo a un nivel aceptable y la planificación
de la restauración de los servicios de TI.
ROLES ITIL
– Gestor de la Disponibilidad
• El Gestor de la Disponibilidad es responsable de definir, analizar, planificar, medir y mejorar todo lo
concerniente a la disponibilidad de servicios de TI.
• Está a cargo de asegurar que toda la infraestructura, procesos, herramientas y funciones de TI sean
apropiados en el renglón de disponibilidad y según el nivel de servicio acordado.
– Gestor de la Seguridad de TI
• El Gestor de la Seguridad de TI se ocupa de salvaguardar la confidencialidad, integridad y disponibilidad
de los activos, información, datos y servicios de TI de una organización.
• Por lo general, su acercamiento a la Gestión de Seguridad tiene un alcance más amplio que el del
proveedor de servicios de TI, e incluye el manejo de papeles, la construcción de accesibilidad, llamadas
telefónicas, etc., de toda la organización.
– Gestor de Riesgos
• El Gestor de Riesgos se ocupa de identificar, evaluar y controlar riesgos. Esto incluye el análisis del
valor de activos de la empresa, la identificación de amenazas a esos activos y la evaluación de la
vulnerabilidad de cada activo ante dichas amenazas.
– Gestor de Suministradores
• El Gestor de Suministradores está a cargo de monitorizar la relación calidad-precio en toda transacción
con los suministradores externos.
• Se asegura de que los contratos a proveedores apoyen las necesidades de la empresa y de que todos
los suministradores cumplan sus compromisos contractuales.
ROLES ITIL
– Gestor del Catálogo de Servicios
• El Gestor del Catálogo de Servicios es responsable de darle mantenimiento al Catálogo de Servicios,
asegurando que toda la información contenida en el catálogo sea precisa y esté actualizada.
– Gestor del Nivel de Servicio
• El Gestor del Nivel de Servicio es responsable de negociar Acuerdos de Nivel de Servicio (SLA) y de
velar que se cumplan.
• Además, se asegura que todos los procesos de Gestión de Servicios de TI, Acuerdos de Nivel
Operacional (OLA) y Contratos de Apoyo (UC) sean adecuados para los niveles de servicio acordados.
• El Gestor del Nivel de Servicio también monitoriza e informa acerca de los niveles de servicio.
– Propietario del Servicio
• El Propietario del Servicio debe cumplir su responsabilidad dentro de los niveles de servicio acordado.
• Por lo general, actúa como contraparte del Gestor del Nivel de Servicio al negociar Acuerdos de Nivel
Operacional (OLA).
• A menudo, el Propietario del Servicio será el líder de un equipo de especialistas técnicos o de una
unidad de apoyo interno.
• TRANSICIÓN DEL SERVICIO

ROLES ITIL
– Consejo Consultor para Cambios de Emergencia (ECAB)
• Se trata de un subgrupo del Comité de Cambios que toma decisiones relacionadas con cambios de
emergencia cuyo impacto es significativo.
• La membresía en el Consejo Consultor para Cambios de Emergencia (Emergency Change Advisory
Board, ECAB) puede decidirse al convocar una reunión, y dependerá de la naturaleza y urgencia del
cambio.
– Consejo Consultor para Cambios (CAB)
• Se trata de un grupo de personas que aconseja al Gestor de Cambios en la evaluación, establecimiento
de prioridades y programación de cambios.
• El Consejo Consultor para Cambios (Change Advisory Board, CAB) se compone de representantes de
todas las áreas de la organización de TI, la empresa, y terceros como, por ejemplo, suministradores.
– Desarrollador de Aplicaciones
• El Desarrollador de Aplicaciones se ocupa de que las aplicaciones y los sistemas que proveen la
funcionalidad necesaria para los servicios de TI estén disponibles.
• Esto incluye el desarrollo y el mantenimiento de aplicaciones personalizadas, así como la
personalización de productos.
– Gestor de Cambios
• El Gestor de Cambios controla el ciclo de vida de todos los Cambios.
• Su objetivo primario es viabilizar la realización de Cambios beneficiosos con un mínimo de
interrupciones en la prestación de servicios de TI.
• En caso de Cambios de gran envergadura, el Gestor de Cambios buscará la autorización del Comité de
Cambios.
– Gestor de Configuración
• El Gestor de Configuración es responsable de dar mantenimiento a la información requerida sobre
Elementos de Configuración (CI's) y de prestar servicios de TI.
• Con esta finalidad, da mantenimiento a un modelo lógico que contiene los componentes de la
infraestructura de TI y sus respectivas asociaciones.
ROLES ITIL
• TRANSICIÓN DEL SERVICIO
– Gestor de Conocimiento
• Se asegura de que la org. de TI sea capaz de recopilar, analizar, almacenar y compartir
conocimiento e información.
• Su meta primordial es mejorar la eficiencia mediante la reducción de la necesidad de redescubrir
conocimientos.
– Gestor de Ediciones
• Se ocupa de planif, program. y controlar el movim. de Ediciones en ambientes reales y de prueba.
• Su objetivo principal es salvaguardar la integridad en el ambiente real y que se utilicen los
componentes correctos.
– Gestor de Proyecto
• Es responsable de la planificación y la coordinación de los recursos necesarios para implementar
una Edición operativa importante dentro de los márgenes de costo, tiempo y calidad preestablecidos.
– Gestor de Pruebas
• Se asegura de que las versiones implementadas y los servicios resultantes cumplan las expectativas
del cliente, y verifica que las operaciones de TI puedan brindar apoyo a los servicios nuevos.
– Propietario del Cambio
• Se trata de una persona que propone un cambio y que cuenta con una asignación presupuestaria
para su implementación.
• En la mayoría de los casos, el Propietario del Cambio coincide con quien da inicio a una Solicitud de
Cambio (RFC).
• Generalmente, los Cambios son responsabilidad de funcionarios de Gestión de Servicio (por
ejemplo, del Gestor de Problemas, o del Gestor de Capacidad) o de miembros de la dirección de TI.
ROLES ITIL
• OPERACIÓN DEL SERVICIO
– Equipo de Incidentes Graves
• Se trata de un equipo de gestores de TI y técnicos expertos establecido dinámicamente, generalmente
bajo el mando de un Gestor de Incidentes, y formulado para concentrarse en la solución de un Incidente
grave.
– Gestor de Acceso
• El Gestor de Acceso concede el derecho a usar un servicio a usuarios autorizados, mientras previene el
acceso de usuarios no autorizados.
• El Gestor de Acceso ejecuta políticas definidas por personal de Gestión de la Seguridad de TI.
– Gestor de Incidentes
• El Gestor de Incidentes es responsable de la implementación efectiva del proceso de Gestión de
Incidentes y prepara los informes correspondientes.
• Ofrece representación durante la primera fase de escalado de incidentes, cuando no se pueden
solucionar en el marco de los niveles de servicio acordados.
– Gestor de Instalaciones de TI
• El Gestor de Instalaciones de TI se ocupa de gestionar el entorno físico donde se encuentra ubicada la
infraestructura de TI.
• Esto incluye todos los aspectos de gestión del entorno, como los concernientes a fuentes de energía,
acondicionamiento del aire, la gestión de accesibilidad a los edificios y la monitorización de ambientes.
– Gestor de las Operaciones de TI
• Un Gestor de las Operaciones de TI se responsabiliza por todas las actividades de Gestión de las
Operaciones de TI.
• Además, asegura que todas las actividades operativas cotidianas se lleven a cabo puntual y
confiablemente.
• OPERACIÓN DEL SERVICIO

ROLES ITIL
– Gestor de Problemas
• El Gestor de Problemas es responsable de gestionar el ciclo de vida de todos los Problemas.
• Sus objetivos principales son la prevención de Incidentes, y la minimización del impacto de aquellos que
no se pueden evitar.
• Con esta finalidad, tiene información sobre Errores Conocidos y Soluciones Provisionales.
– Grupo Cumplimiento Solicitud Servicio
• Los Grupos de Cumplimiento de Solicitud de Servicio se especializan en la realización de ciertos tipos
de Solicitudes de Servicio.
• Por lo general, el Soporte de Primera Línea procesa los pedidos más simples, mientras que el resto es
referido a los grupos especializados de Cumplimiento de Solicitud de Servicio.
– Operador de TI
• Se trata del personal que a diario lleva a cabo las actividades operativas.
• Entre sus responsabilidades se encuentran: Preparar copias de seguridad, velar para que se realicen las
tareas programadas, instalar equipos comunes en el centro de datos.
– Soporte de Primera Línea
• La responsabilidad del Soporte de Primera Línea es registrar y clasificar los Incidentes reportados y llevar a cabo
esfuerzos inmediatos para restaurar lo antes posible un servicio de TI que ha fallado.
• Si no se encuentra una solución adecuada a estos fines, el Soporte de Primera Línea refiere el incidente a grupos
de apoyo técnico especializado (Soporte de Segunda Línea).
• El Soporte de Primera Línea también mantiene informados a los usuarios acerca del estatus de los Incidentes
cada cierto tiempo.
– Soporte de Segunda Línea
• El Soporte de Segunda Línea se hace cargo de los Incidentes que no pueden ser resueltos con los
recursos del Soporte de Primera Línea.
• De ser necesario, requerirá apoyo externo de manufactureros de programados y de hardware.
• La meta es restaurar un servicio de TI fallido en el menor tiempo posible. Si no se encuentra solución, el
Incidente debe ser referido a Gestión de Problemas.
ROLES ITIL
• PERFECCIONAMIENTO CONTINUO DEL SERVICIO (CSI)
– Gestor de Perfeccionamiento Continuo del Servicio
• El Gestor de Perfeccionamiento Continuo del Servicio está a cargo de gestionar mejoras a los procesos
y servicios de Gestión de Servicios de TI y a Servicios de TI.
• Tomará medidas continuamente del rendimiento del proveedor de servicios y diseñará mejoras a los
procesos, servicios e infraestructura, de manera que se aumenten la eficiencia, la efectividad y la
rentabilidad.
– Gestor de Procesos
• El Gestor de Procesos es responsable de planificar y coordinar todas las actividades de Evaluación de
Procesos.
• Brinda apoyo a las partes involucradas en la gestión y mejoramiento de los procesos, especialmente a
los Propietarios de Proceso.
• Este funcionario también coordina los Cambios a procesos, y por tanto se asegura de que todos los
procesos cooperan perfectamente.
– Propietario de Proceso
• Es la función de quien se asegura que un proceso es adecuado a los fines. Las responsabilidades del
Propietario de Proceso incluyen el patrocinio, diseño y mejoramiento continuo del proceso y sus
mediciones.
• A menudo, esta función se le asigna a un miembro de personal que ejerza una función principal en el
renglón de Gestión de Servicio (por ejemplo, el Gestor de Incidentes puede ser el Propietario de
Proceso de Gestión de Incidentes).
4: ANÁLISIS DE PROCESOS EXISTENTES
(AUTOEVALUACIÓN)
• OBJETIVO
– Reconocer los puntos débiles y las oportunidades dentro de los procesos
existentes
• DESCRIPCIÓN
– Suele conllevar documentar laboriosamente estos procesos con mucho detalle.
No compensa el esfuerzo, pues es el pasado y se cambiarán.
– Mejor evaluar los procesos existentes usando una serie de criterios objetivos,
para identificar los puntos débiles y oportunidades sin un esfuerzo laborioso.
– La Autoevaluación ITIL es ideal para esta tarea.
• CATÁLOGO DE AUTOEVALUACIÓN ITIL (ITIL SELF ASSESSMENT
CATALOGUE)
– Recomendable si se va a presentar ITIL por primera vez.
– Cuestionarios en la página de Axelos
– La auto evaluación refleja:
• Niveles de madurez logrados en las disciplinas individuales de ITIL
• Desviaciones en el juicio de los participantes en entrevistas individuales sobre la calidad de
distintos procesos
• Identificación tanto de los puntos débiles en los procesos existentes y sus causas
adyacentes, como de las oportunidades
4: ANÁLISIS DE PROCESOS EXISTENTES
(AUTOEVALUACIÓN)
– Clasificación de la organización de TI dentro de las disciplinas individuales de ITIL
– Lista de puntos débiles y oportunidades con respecto a las recomendaciones de
ITIL
– El análisis debe cubrir todas las áreas principales de la organización de TI
– Es necesario que la mayoría del personal de la Gestión de TI participen en la
encuesta.
– El entrevistador ya debe estar familiarizado con los principios de ITIL, para poder
contestar preguntas de los participantes en las entrevistas.
5: DEFINICIÓN DE LA ESTRUCTURA DE PROCESOS ITIL
• OBJETIVOS
– Determinación de procesos de Gestión de Servicios que se deban introducir
– Desglose de procesos y subprocesos
• DESCRIPCIÓN
– Los procesos por introducir a menudo son resultado de los objetivos del
proyecto:
– Ejemplo: Si el proyecto tiene como objetivo mejorar el apoyo al usuario, el
proceso de "Gestión de Incidentes" se establece o se mejora.
– Debido a su enlace con Gestión de Incidentes, los procesos de "Gestión de
Problemas" y "Activos de Servicio y Gestión de la Configuración" también
deben ser incluidos en el proyecto.
– La meta de este paso del proyecto es, primordialmente, escoger los proceso
y subprocesos ITIL.
– La estructura por hacer no contiene descripciones detalladas de los procesos,
éstos se desarrollan en una etapa posterior.
5: DEFINICIÓN DE LA ESTRUCTURA DE PROCESOS ITIL
– El hecho de que el ITIL Process Map contenga una estructura genérica, ayuda
en la tarea actual de definir la estructura de procesos.
– En la mayoría de los casos se puede usar el mapa, solamente, con cambios
menores.
• PREREQUISITOS
– Resultados de la evaluación de procesos ITIL existentes
– Objetivos del proyecto (¿Cuál es la motivación para introducir las mejores
prácticas de ITIL?)
– Desglose estructurado de los procesos ITIL por introducir
– La definición de la estructura de procesos no debe tratar de anticipar los
pasos subsiguientes del proyecto
– La meta de este paso es identificar los procesos y subprocesos por introducir,
sin especificar los procesos con mucho detalle.
6: DEFINICIÓN DE INTERFACES DE PROCESOS ITIL
– El próximo paso determina qué entradas (inputs) debe recibir cada proceso
de los otros, y qué salidas (outputs) debe producir cada uno para que los
subsiguientes puedan funcionar.
• OBJETIVO
– Definir las interfaces de todos los procesos ITIL por introducir
• DESCRIPCIÓN
– Los puntos débiles en los procesos aparecen, con frecuencia, en las
interfaces, allí donde termina un proceso y empieza otro.
– En muchos casos, se producen interrupciones en el flujo de información o en
los medios, lo que no permite intercambiar la información deseada.
– Antes de poder definir las actividades detalladas, debe estar claro qué inputs
puede esperar un proceso de los anteriores, y qué resultado debe producir.
– El ITIL Process Map aplica un enfoque riguroso a la definición de interfaces:
• los objetos de información se pueden seleccionar de un glosario ITIL central, para
definir las inputs y los outputs de manera precisa.
• Cada objeto de información contiene una breve definición para evitar
ambigüedades sobre los resultados de los procesos esperados.
• DESCRIPCIÓN
– No todos los procesos ITIL se implementan a la vez, lo que a conlleva el que
falten algunos de los inputs necesarios para el proceso.
• Es posible, por ejemplo, que no haya un proceso de Gestión de la Seguridad de TI,
aunque el Service Desk requiera inputs de Gestión de la Seguridad, como Alertas de
Seguridad.
– Un modelo de procesos como el Mapa de Procesos ITIL ayuda a resolver este
problema:
• Ofrece un marco estructurado de procesos que permite la definición de enlaces
completos, aunque al principio sólo una subserie de procesos ITIL esté definida en
detalle.
• De esta manera, otros procesos ITIL adicionales se pueden añadir posteriormente al
modelo del proceso, según sea necesario.
• PREREQUISITOS
– Estructura de los procesos ITIL por introducir
– Objetos de información ITIL (términos del glosario ITIL) como inputs y
outputs de procesos
– Interfaces de los procesos ITIL por introducir:
• unos con otros
• con otros procesos ITIL
• con clientes y suministradores
– Los procesos nuevos no deben representar soluciones aisladas y deben considerarse
las interfaces a los otros procesos en la organización de TI.
– La documentación de las interfaces debe estar claramente estructurada, mostrando
todos los detalles cuando sea necesario.
– Esto requiere diagramas de visiones generales, que presentan el cuadro completo, y
diagramas separados, con detalles, de las interfaces para cada proceso.
• PERSPECTIVAS RELEVANTES DEL MAPA DE PROCESOS ITIL
– El ITIL Process Map contiene dos tipos de modelos que, combinados entre sí,
se utilizan para definir las interfaces de procesos:
• Perspectivas generales de procesos que ilustran las interrelaciones de varios
procesos en una sola página
• Diagramas detallados de interfaces de procesos, con todas las inputs y las
outputs.
7: ESTABLECIENDO CONTROLES DE PROCESOS ITIL
• Una vez que están claras la estructura de procesos y sus interfaces, se debe
definir un enfoque para asegurar que estos procesos fluyan según las
expectativas ("Controlling de Procesos").
• OBJETIVOS
– Determinar métricas de CSI (KPIs) de los procesos por introducir
– Definir los procedimientos de medición para los KPIs
– Definir los procedimientos de informes
• DESCRIPCIÓN
– Una estrategia coherente de control de los procesos ayuda a evaluar si se logran los
objetivos que se buscan y tiene unos beneficios a largo plazo, ya que presenta los
datos necesarios para un proceso de mejora continua.
– Los KPI deben ayudar a saber si el proceso funciona bien.
– Cuando estén claros los niveles de calidad que debe lograr un proceso, se pueden
diseñar con confianza sus detalles, teniendo en cuenta esas metas.
– Determinar los propietarios de procesos
• El éxito de un proceso depende de que los propietarios de procesos que se identifiquen de
cerca con su tarea, y que tengan suficiente autorización y los medios necesarios.
• Es importante tener a los propietarios de procesos como participantes activos en el proyecto
de implementación.
• En la mayoría de los casos es sencillo (por ejemplo, el Gestor de Problemas es el propietario
del proceso de Gestión de Problemas).
• DESCRIPCIÓN
– Definir métricas y procedimientos de medición de TI
• Los propietarios de procesos usan criterios objetivos de calidad para evaluar si sus procesos
fluyen "bien". Esto los coloca en posición para decidir cuándo es necesario mejorar los
procesos.
• El primer paso al seleccionar KPIs adecuados siempre debe ser decidir los objetivos
generales del proceso (por ejemplo, la tasa de resoluciones de primera instancia en el
Service Desk).
• El propietario de proceso también utiliza métricas cuantitativas para enfocar recursos dentro
de un proceso (por ejemplo, el número de incidentes recibidos por el Service Desk en el
transcurso del tiempo).
• Qué KPIs se seleccionarán eventualmente depende de la disponibilidad de posibilidades para
medirlos. En el caso ideal, los KPIs pueden ser computados automáticamente, por ejemplo,
en un sistema de Service Desk. Los procedimientos de métricas definidos aquí son, por ende,
requisitos para los sistemas a implementarse.
• El control de los Procesos no significa tener un arsenal de KPIs lo más extenso posible.
• Se deben definir pocas mediciones significativas, para que la función de medir e informar
sobre los KPIs se pueda llevar a cabo en un tiempo y con un esfuerzo que puedan
justificarse.
• DESCRIPCIÓN
– Fijar metas KPI
• Los objetivos de valores de los KPI’s definen el “éxito” de manera objetiva, y fijan
metas para el propietario de proceso.
• Hay que tener en cuenta que los objetivos de valores (como tasas de resoluciones
por primera vez) no se transfieren fácilmente de negocio a negocio sin ciertas
precauciones.
• Inicialmente, se recomienda no definir metas fijas KPI’s, sino meramente
seleccionar KPI’s adecuados y comenzar a medir.
• Cuando haya un número estadísticamente significativo de medidas, y después de
un cierto tiempo, habrá una base más sólida para fijar metas.
– Definir los procedimientos de informes
• Informar sobre la calidad de los procesos es el elemento final dentro del Control
de Procesos.
• Los procedimientos para los informes se deben definir especificando qué KPIs se
reportarán, de qué manera, y quién recibirá los informes.
• DESCRIPCIÓN
– Prerrequisitos
• La estructura de los procesos ITIL por introducir
• Objetivos de los procesos ITIL
– Resultados / Entregables
• Asignación de propietarios de procesos
• Métricas de CSI (KPIs)
• Procedimientos de medición para KPIs
• Especificación de los procedimientos de informes
– Solamente se deben usar KPIs que realmente se puedan medir
– La Gestión de TI debe enfatizar que el uso de KPIs tiene como propósito mejorar los procesos,
pero no penalizar empleados.
– De lo contrario, puede darse la situación de que el personal de TI altere las estadísticas a su
favor, lo que va en contra de los intereses de toda la organización de TI.
– Las metas para los KPIs (especialmente en la fase inicial, tras presentar los nuevos procesos) se
deben revisar regularmente; no siempre es necesario tratar de alcanzar la máxima puntuación;
por ejemplo, en ciertas circunstancias, es aceptable tener una tasa de resolución más baja en el
Service Desk si muchas de las consultas requieren conocimientos de un especialista. 33
8: DISEÑANDO LOS PROCESOS EN DETALLE
• Determinar las secuencias de actividades individuales dentro de cada proceso es
relativamente laborioso. Por eso es muy importante concentrarse en las áreas
que realmente cuentan.
• OBJETIVOS
– Definición detallada de actividades individuales dentro de los procesos ITIL
– Definición de guías/ listas de control que apoyen la ejecución del proyecto
– Definición detallada de los outputs de procesos
• DESCRIPCIÓN
– Las actividades detalladas dentro de cada proceso se deben discutir con
todas las partes relevantes, para poder incluir en su diseño toda la
experiencia y los conocimientos posibles. El propietario de proceso es
responsable por esta tarea.
– Como resultado, se llega a un consenso, el cual se documenta en un
"flujograma" detallado del proceso.
– Se puede añadir información adicional (como documentos relacionados) que
describa los procedimientos y outputs en detalle, para facilitar la ejecución
del proceso.
– Por ejemplo, puede haber unas páginas extra que describan qué tipo de
información se recopilará durante el registro inicial de un incidente.
8: DISEÑANDO LOS PROCESOS EN DETALLE
• PRERREQUISITOS
– Estructura de procesos de Gestión de Servicios de TI por introducir
– Perspectivas generales de los procesos (desglose de procesos)
– Interfaces de los procesos ITIL por introducir
– Métricas de CSI (KPIs) de los procesos por introducir
– Descripciones detalladas de los procesos (secuencias de actividades)
– Guías/ listas de control
– Definiciones de outputs de procesos
– Preparase bien es esencial en este punto, para evitar el riesgo de producir un gran
número de documentos, demasiado extensos y que no guarden relación.
– Importante el hecho de establecer un marco de estructuras e interfaces de procesos
durante los primeros pasos del proyecto. Respetando la definición de las interfaces de
proyectos, ya queda establecida la información necesaria para el proceso, y qué
resultados debe producir en procesos sucesivos.
– Con esta información claramente especificada, es mucho más fácil definir el flujo de
un proceso de manera sencilla y directa.
9: SELECCIÓN E IMPLEMENTACIÓN DE SIST.DE APLICACIONES
• OBJETIVOS
– Definir los requisitos para sistemas de aplicaciones nuevos o cambiados
– Seleccionar sistema(s) y proveedor(es) adecuados para el sistema de
aplicaciones que vaya a obtenerse
– Implementar sistemas de aplicaciones nuevos / cambiados para que
puedan apoyar los procesos por introducir
• DEFINIR LOS REQUISITOS DE SISTEMAS
– Descripción
• Los requisitos funcionales de los sistemas de aplicaciones se derivan
mayormente de las descripciones detalladas de los procesos; éstos
ilustran qué actividades apoyará el sistema de aplicación.
• Se pueden añadir más requisitos (ejemplo: "Crear un Incidente nuevo
debe ser posible desde el libro de direcciones de Outlook").
• Las definiciones de las outputs de procesos describen qué datos son
procesados dentro del sistema.
• Por ejemplo, el proceso "Registro y Categorización de Incidentes" genera
un "Registro de Incidente". El sistema debe poder manejar una estructura
de estos datos, y ofrecer interfaces adecuadas para que los usuarios los
puedan ver y editar.
– Descripción
• Finalmente, se deben identificar todos los requisitos no funcionales para que
resulte, como un todo, la siguiente estructura para el documento de requisitos:
• Requisitos funcionales
– Referencia a modelos detallados de procesos
– Requisitos adicionales relacionados con la funcionalidad
– Definiciones de las outputs de procesos (estructura de datos)
– Requisitos de informes
• Requisitos no funcionales
– Requisitos relacionados con capacidades y cantidades
– Ejecución y rendimiento
– Escalabilidad/ expansión
– Disponibilidad
• Requisitos desde un punto de vista operacional
• Requisitos desde un punto de vista de Seguridad de TI
• Interfaces con otros sistemas
• Anejo
– Modelos de procesos
– Datos que se importarán de sistemas previos
– Descripción
• Una vez que estén completos los requisitos, se extrae una lista detallada y con
prioridades del documento de requisitos.
• Esta lista se utiliza como una matriz para evaluar a los proveedores. Los requisitos
se deben categorizar como en el siguiente ejemplo:
– Criterios decisivos (Prio 1)
– Requisitos importantes (Prio 2)
– Requisitos deseables (Prio 3)
– Objetivo de este paso del proyecto
• Definir los requisitos para sistemas de aplicaciones nuevos o cambiados
– Prerrequisitos
• Descripciones detalladas de procesos ITIL expresados en forma de secuencias de
actividades
• Guías/ listas de control
• Definiciones de outputs de procesos
• Documento de requisitos para aplicaciones que se cambiarán o se obtendrán
• Lista de prioridades de requisitos
– Factores de éxito
• Es importante no limitarse a los aspectos funcionales cuando se especifiquen los
requisitos del sistema. Los aspectos operacionales son de igual importancia, como
lo son las posibilidades de expandir el sistema; especialmente si luego se
implementan otros procesos de ITIL.
• SELECCIONAR SISTEMA(S) DE APOYO PARA LOS PROCESOS POR
HACER
– Descripción
• Una evaluación sistemática de los sistemas adecuados se consigue basándose en
la lista de requisitos.
• Se ha comprobado que un enfoque de tres partes es lo más eficiente para este
propósito:
– Primero se puede hacer un acercamiento por escrito a una gran cantidad de
proveedores para encontrar los que puedan cumplir los requisitos más
importantes.
– Se prevé que con este paso se obtenga una lista corta de proveedores, con el fin de
solicitarles que presenten una oferta sólida que también incluya información sobre
cuotas para licencias y costos de implementación.
– La decisión final se toma después de haber visitado a los clientes de referencia, y
posiblemente haber realizado una instalación de prueba del proveedor de sistemas
considerado.
• Seleccionar sistema(s) y proveedor(es) adecuados para el sistema de
aplicaciones que vaya a obtenerse
• SELECCIONAR SISTEMA(S) DE APOYO PARA LOS PROCESOS POR
HACER
– Prerrequisitos
• Documento de requisitos de las aplicaciones que se cambien u obtengan
• Lista de prioridades de requisitos
• Evaluar los sistemas y los proveedores
– Factores de éxito
• El número de proveedores incluidos en el proceso de selección no debe ser
demasiado grande; las encuestas de productos publicados por los Grupos Gartner
o Forrester proveen asistencia excelente al recopilar una primera lista de posibles
candidatos (verificar en Internet en www.gartner.com ó www.forrester.com).
• IMPLEMENTAR LOS SISTEMAS
– Descripción
• Los pasos individuales que debe tomarse para implementar el sistema
dependerán en gran medida del tipo de aplicación y su ambiente operacional.
• Generalmente es más eficiente usar los conocimientos de los proveedores del
sistema a la hora de adaptar e implementar las nuevas aplicaciones.
• Implementar sistemas de aplicaciones nuevos / cambiados para que puedan
apoyar los procesos por introducir
– Prerrequisitos
• Seleccionar los proveedores de sistemas
• Descripciones detalladas de los procesos ITIL expresados como secuencias de
actividades
• Guías/ listas de control
• Definir las outputs de los procesos
• Sistemas de aplicaciones completamente implementados y operacionales
10: IMPLEMENTACIÓN DE PROCESOS ITIL Y ADIESTRAMIENTO
• IMPLEMENTAR LOS SISTEMAS
– Si los participantes se enteran de los nuevos procesos solamente en esta
etapa, es inevitable que haya una falta de aceptación.
– Es fundamental que la mayor cantidad de empleados posible participe en el
diseño de procesos durante las etapas tempranas del proyecto.
– Objetivos
• Reforzar conocimientos básicos de ITIL
• Adiestrar empleados participando en los nuevos procesos en el uso de sistemas de
aplicación nuevos o cambiados
• Poner a disposición de los clientes informaciones sobre el servicio
• Hacer que los nuevos procesos sean parte de las prácticas laborales diarias
• DESCRIPCIÓN
• Las personas se deben familiarizar con los nuevos procesos.
• Importante que los participantes estén involucrados en el diseño del proceso
desde fases tempranas, de modo que, en la mayoría de los casos, no sea
necesario explicar cómo cambiarán los procesos.
• Puede haber una formación adicional en diferentes niveles:
– Un trasfondo de conocimientos de ITIL es decisivo para el éxito de los nuevos
procesos, y debe ser provisto a todas las partes involucradas;
– El adiestramiento básico de ITIL se puede llevar a cabo al comienzo del proyecto para
personal clave, para que pueda comunicar los principios de ITIL a los otros
participantes del proyecto.
– Miembros específicos del personal de TI necesitarán un adiestramiento más
intensivo, dependiendo de sus roles ITIL
– Tras la implementación de un sistema nuevo o cambiado, pueden ser necesarios
adiestramientos sobre su operación
– Como suplemento, se pueden considerar adiestramientos que contribuyan a mejorar
la imagen pública de la Organización de TI ("¿Cómo actúo con clientes críticos?")
– Al final, se informa a los clientes si, por ejemplo, se estableció un Service Desk nuevo
y, como resultado, cambió el procedimiento para las solicitudes de servicio.
• PRERREQUISITOS
– Perspectivas generales de los procesos (desglose de los procesos)
– Interfaces de los procesos ITIL por introducir
– detalladas de los procesos ITIL expresadas como secuencias de actividades
– Guías/ listas de control
– Métricas de CSI (KPIs) para los procesos por introducir
– Definiciones de las inputs y outputs de procesos
– Personal de TI informado
– Clientes informados
– Como ya se dijo, se debe invitar a todas las partes involucradas para que
cooperen y presenten sus experiencias durante el transcurso del proyecto.
6.5.Bibliografía
Implementando ITIL
6. BIBLIOGRAFÍA
6.5.Bibliografía
Implementando ITIL
BIBLIOGRAFÍA
• http://wiki.es.it-processmaps.com/index.php/Portada Wiki ITIL

• Fundamentos de ITL V3 2011 Van Haren Publishing
• Preparación Para La Certificación ITIL Foundation V3 2011 Jean-Luc Baud
• ITIL 2011 Fundamentos: Basado en el programa de estudio oficial Ana Cecilia Delgado

Manual ITIL Última Versión PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Manual ITIL Última Versión PDF

Hochgeladen von

Copyright:

Verfügbare Formate

FUNDAMENTOS

Profesor: Angel Caro Amián www.avante.es avante@avante.es

ITIL da descripciones detalladas de un extenso conjunto de

Estos procedimientos son independientes del proveedor y han sido

VENTAJAS PARA MI ORGANIZACIÓN APLICANDO ITIL

2. Gestión por Procesos

3.1 Estrategia del Servicio

3.2 Diseño del Servicio

3.3 Transición del Servicio

3.4 Operación del Servicio

3.5 Mejora Continua del Servicio

• La gestión de servicios tiene dos columnas

• ITIL da descripciones detalladas de un extenso conjunto

• Estos procedimientos son independientes del proveedor

¿Cuál suele ser el principal

• GARANTÍA: y lo hace como quiero que lo haga (“fit for use”).

• En v2 los servicios aparecían “mágicamente” listos para su entrega,

Gestión de la Demanda Coordinador del Diseño Evaluación del Cambio Gestión de Eventos

Gestión de la Cartera de Validación y Pruebas de Servicio Gestión de Accesos

Gestión de la Disponibilidad Gestión de Cambios Gestión de Problemas

• Aquí se expone el cómo transformar la Gestión

• Se utilizan los principios y métodos de diseño para Gestión de la Seguridad de la

continuidad de todos los servicios.

relacionada con los cambios a servicios y

• Desde el punto de vista del cliente, la

• Se preocupa de crear y mantener el valor para

• ITIL está orientado a la gestión del ciclo de vida de

• Un proceso está diseñado para cumplir un objetivo

• Los procesos recogen actividades que se

• Debe ser medible: enfocado al rendimiento

Rol 1 Rol 2 Rol 3

• En ITIL se diferencia claramente entre el concepto de proceso y función:

DUEÑO DEL PROCESO

GESTOR DEL PROCESO

₋ ¿Cómo facilito resultados?

PAQUETE DE NIVEL DE SERVICIO (SERVICE LEVEL

Servicio Core : Acceso a Servicio Core : Acceso a

1.1 ¿Para qué se utiliza el modelo RACI?

1.4 ¿Cuáles de los siguientes conceptos son características de

1.6 ¿Cuál de las siguientes afirmaciones acerca de los clientes internos y

1.7 ¿Cuál de los siguientes atributos debe entregar un servicio de TI a los

1.8 ¿Cuál de los siguientes podrían ser considerados parte interesada

A. Definen funciones como parte de su diseño.

1.10 ¿Cuáles de los siguientes roles están definidos en el modelo RACI?

1.11 ¿Cuáles de las siguientes actividades debería emprender el dueño

2.1 ¿Cuál de las siguientes frases acerca de la creación de valor a través

A. La percepción que el cliente tiene acerca del servicio es un factor importante

2.2 ¿Qué significa “Garantía de un servicio”?

A. El servicio se ajusta al propósito

A. Mejora continua del servicio

2.4 ¿Cuál de los siguientes sujetos es el MAS apropiado para definir el

A. Llevar a cabo actividades operacionales para dar soporte de servicios

3.1 ¿Cuál de las siguientes afirmaciones es la MEJOR descripción de

A. Un acuerdo entre un proveedor de servicios de TI y otra parte de la misma

3.2 ¿Cuál es el propósito PRINCIPAL de la gestión de disponibilidad?

A. Monitorizar e informar la disponibilidad de los componentes

3.3 ¿Cuáles son los tres sub-procesos de gestión de la capacidad?

A. Gestión de capacidad del negocio, gestión de capacidad del servicio y gestión

3.5 ¿Quiénes deben tener acceso a la política de seguridad de

A. Altos ejecutivos del negocio y el personal de TI

3.6 ¿Cuál de los siguientes elementos son válidos en un paquete de

3.7 ¿Cuál de las siguientes actividades es parte del proceso de gestión de

A. El diseño del sistema de gestión de la configuración desde una perspectiva