Libro 2 Diseno Del Servicio

Libro 2 – Diseño del Servicio
1. Definición y Objetivos
La principal misión de la fase de Diseño del Servicio es la de diseñar nuevos

servicios o modificar los ya existentes para su incorporación al catálogo de
servicios y su paso al entorno de producción.
El Diseño del Servicio debe seguir las directrices establecidas en la fase de

Estrategia y debe a su vez colaborar con ella para que los servicios diseñados:
• Se adecuen a las necesidades del negocio.

• Sean eficientes en costes y rentables.
• Cumplan los estándares de calidad adoptados.
• Aporten valor a clientes y usuarios.
El Diseño del Servicio debe tener en cuenta tanto los requisitos del servicio
como los recursos y capacidades disponibles en la organización TI. Un
desequilibrio entre ambos lados de la balanza puede resultar en servicios
donde se vean comprometidas bien la funcionalidad o bien la garantía.
El proceso de diseño del servicio debe tener en cuenta que los procesos y
actividades involucrados incumben a todas las fases del ciclo de vida.
Una correcta implementación del Diseño del Servicio debe ayudar a responder
cuestiones tales como:
• ¿Cuáles son los requisitos y necesidades de nuestros clientes?

• ¿Cuáles son los recursos y capacidades necesarias para prestar los
servicios propuestos?
• ¿Los servicios son seguros, ofrecen la disponibilidad necesaria y se
garantiza la continuidad del servicio?
• ¿Son necesarias nuevas inversiones para prestar los servicios con los
niveles de calidad propuestos?
• ¿Están todos los agentes involucrados correctamente informados sobre
los objetivos y alcance de los nuevos servicios o de las modificaciones a
realizar en los ya existentes?
• ¿Se necesita la colaboración de proveedores externos?
Página 1
2. Conceptos Básicos / Aspectos del Diseño
Para conseguir la máxima calidad posible con un enfoque de mejora continua,

la organización necesita un planteamiento estructurado y orientado a
resultados en cada uno de los cinco aspectos de diseño. En este caso, la
orientación a resultados implica satisfacer los deseos de los clientes/usuarios.
Los cinco aspectos de diseño son los siguientes:
1. Solución del servicio (incluyendo requisitos funcionales, recursos y

capacidades)
2. Portafolio de Servicios (herramientas y sistemas de apoyo)
3. Arquitectura (tecnológica y de gestión)
4. Procesos
5. Métricas y sistemas de medición
Diseño de soluciones de servicio
Debe incluir de forma estructurada todos los elementos clave del nuevo o
modificado servicio:
• Requisitos de negocio
• Requisitos de servicio (SLR)
• Adecuación a la estrategia del servicio
• Análisis funcional
• Estudios de los servicios prestados para ver si existen módulos
reutilizables de otros servicios en cartera
• Análisis de costes (TCO) y retorno a la inversión
• Estudio de los recursos y capacidades involucradas
• Estrategias de contratación con los proveedores externos (si estos se
consideraran necesarios)
Diseño del Portafolio de Servicios
El Portafolio de Servicios es una de las principales herramientas para la gestión

del servicio a través de todas las fases del ciclo de vida. Debe incluir
Página 2
información sobre todos los servicios ofrecidos, los servicios en fase de

desarrollo y los servicios retirados en términos de valor para el negocio.
La fase de Diseño del Servicio es responsable de determinar su contenido

específico así como sus permisos de acceso.
El Portafolio de Servicios debe contener información sobre:
• Los objetivos del servicio

• Su valor: funcionalidad y garantía
• Su estado
• Los SLAs asociados
• Capacidades y recursos utilizados
• Sus costes y retorno esperado
• Los controles o métricas de calidad asociados
• Los responsables del mismo
• Servicios relacionados
• Proveedores externos involucrados (OLAs y UCs)
Página 3
Diseño de la arquitectura del servicio
La arquitectura debe tener en cuenta todos los elementos necesarios para la

Gestión del Servicio así como la interrelación entre ellos y el mercado. Debe
ofrecer una guía para el diseño y evolución del servicio teniendo en cuenta:
• La alineación entre la tecnología y el negocio.

• La infraestructura TI necesaria.
• La Gestión de las aplicaciones.
• La Gestión de los datos y la información.
• La Documentación y Gestión del Conocimiento.
• Los Planes de Despliegue del servicio.
Y toda aquella otra información que se pueda considerar de interés referente a

la prestación del servicio.
Diseño de procesos
La gestión basada en procesos es una de las señas de identidad de ITIL. En la

fase de diseño del servicio se han de definir los procesos involucrados con una
descripción detallada de sus actividades, funciones, organización, entradas y
salidas.
En particular deben establecerse los procesos de control para asegurar que los
procesos se realizan de forma eficiente y cumplen los objetivos establecidos.
Los procesos no deben ser un fin en sí mismo sino que deben tener como
principal objetivo que la organización TI ofrezca servicios de valor al cliente de
forma eficiente.
Diseño de métricas y sistemas de monitorización
Es imprescindible diseñar sistemas de medición y seguimiento que permitan

evaluar tanto la calidad de los servicios prestados como la eficiencia de los
procesos involucrados.
Los resultados recopilados mediante estos sistemas de seguimiento y su

análisis posterior, basado en métricas y métodos preestablecidos, deben de ser
la principal entrada para la fase de Mejora del Servicio.
Existen cuatro tipos principales de métricas a considerar:
Página 4
• Progreso: cumplimiento de los calendarios previstos

• Cumplimiento: adecuación a las políticas y requisitos predefinidos.
• Eficacia: calidad de los resultados obtenidos.
• Rendimiento: productividad de los procesos y gestión de los recursos
utilizados.
Página 5
2. Conceptos Básicos / Valor del Diseño
Con un buen diseño del Servicio será posible entregar servicios de calidad y
efectivos en coste, y asegurar que los requisitos del negocio están siendo
cubiertos. Los beneficios de las buenas prácticas del diseño del servicio son:
• Coste total reducido de propiedad (TCO): el coste de propiedad puede

ser minimizado solo si todos los aspectos de servicios, procesos y la
tecnología son diseñados apropiadamente e implementados según el
diseño.
• Mejora con la alineación, calidad y la consistencia del servicio: se

mejorará la calidad si los nuevos o modificados servicios se alinean con
las necesidades del negocio, con el diseño del servicio orientado a sus
requerimientos, con servicios y operaciones de calidad.
• Implementación más sencilla de los servicios nuevos o modificados:

tanto integrados como completados.
• El Diseño del Servicio y la producción de Paquetes de Diseño del

Servicio exhaustivos.
• Rendimiento del servicio más eficaz: con la incorporación y

reconocimiento de la Capacidad, la Disponibilidad Financiera y los
planes de Continuidad del Servicio de TI.
• Mejora en el Gobierno de TI: ayudar con la puesta en práctica y la

comunicación de un conjunto de controles para el gobierno eficaz de la
TI.
• Gestión del Servicio y procesos de TI más eficaces: los procesos serán

diseñados con calidad óptima y eficacia de costes.
• Mejora en la información y la toma de decisiones: las medidas y métricas

exhaustivas y eficaces permitirán la mejora constante de la toma de
decisiones en las prácticas de la gestión del servicio en el escenario
ciclo de vida del diseño del servicio.
Página 6
2. Conceptos Básicos / Modelos de Diseño del Servicio
La opción del modelo de desarrollo del servicio puede ser determinante para el
éxito o fracaso del mismo.
Existen tres opciones principales: Tradicional, Ágil y Empaquetado que

describimos brevemente a continuación.
Modelo tradicional
Presupone una mayor estabilidad del servicio. El servicio requiere de un

detallado estudio previo de todos los aspectos técnicos y de negocio que evite,
en la medida de lo posible, la necesidad de cambios, ya sea por errores o por
una funcionalidad incompleta.
Su principal problema es que las escalas de tiempo involucradas en el

desarrollo tradicional pueden ser incompatibles con las escalas de tiempo
asociadas naturalmente al mercado.
El servicio o producto puede ser técnica y funcionalmente estable pero puede

resultar obsoleto antes de su entrada en producción.
Modelo ágil o RAD
El modelo Rápido de Desarrollo es un modelo principalmente incremental e

iterativo que se basa en la creación de prototipos.
La funcionalidad tiende a ser modular de forma que ésta se pueda ir integrando

incrementalmente aportando las siguientes ventajas:
• Los módulos pueden ser reutilizables.

• El cliente tiene acceso más rápido a la funcionalidad aunque ésta pueda
ser reducida lo que facilita su feedback desde las primeras fases de
desarrollo.
• Permite un desarrollo distribuido que facilite la incorporación de
proveedores externos en el proceso.
El concepto de prototipo implica que el proceso será por naturaleza iterativo y

existirán múltiples versiones que irán incorporando progresivamente los
requisitos del cliente.
Página 7
Su principal problema reside en que al no estar completamente cerrada desde

un principio su arquitectura se puede entrar en un proceso inacabable de
prototipos que no culmine en un servicio adecuado para su paso a producción.
Soluciones empaquetadas
Existen en la actualidad muchas soluciones TI empaquetadas que simplifican el

proceso de diseño del servicio.
Sus ventajas se resumen en:
• Disponible rápidamente.
• Configurable.
• Costes (iniciales) reducidos.
• Actualizaciones periódicas.
Sus principales inconvenientes suelen residir en:
• Dificultades de integración con otros servicios/plataformas.

• Insuficiente funcionalidad debida a necesidades muy específicas.
• Potenciales altos costes de personalización y posibles
incompatibilidades con las actualizaciones.
La elección de uno u otro modelo de desarrollo para cada servicio es una de

las principales decisiones del Diseño del Servicio y se optará por una u otra
dependiendo de múltiples factores tales como:
• Decisiones estratégicas basadas en la criticidad del servicio.

• Cuestiones financieras.
• Requisitos del cliente.
• Generación de valor.
• Condiciones del mercado.
• Perspectivas de negocio.
Página 8
2. Conceptos Básicos / Opciones de Modelos de Entrega
Estrategia de Características Ventajas Inconvenientes

provisión
Internalización Se utilizan capacidades - Control directo - Coste y tiempo para
(Insourcing) internas para el diseño, la provisión de
desarrollo, mantenimiento, - Libertad de servicios
ejecución y/u oferta de elección
soporte para el servicio. - Dependencia de
- Familiaridad con recursos y
los procesos competencias
internos internas
Externalización Se recurre a una - Enfoque a - Menos control
(Outsourcing) organización externa para competencias directo
el diseño, desarrollo, esenciales
mantenimiento, ejecución - Desconocimiento de
y/u oferta de soporte para - Reducción de las capacidades del
el servicio. costes a largo plazo suministrador
Co- Una combinación de - Tiempo de - Complejidad de
aprovisionamie internalización y provisión de proyectos
nto (Co- externalización en la que servicios
sourcing) diversas organizaciones - Protección de
cooperan a lo largo del - Mejor control copyright y propiedad
Ciclo de Vida. intelectual
Multi- Múltiples organizaciones - Más oportunidades- Complejidad de
aprovisionamie alcanzan acuerdos de mercado proyectos
nto formales orientados a la
(Multisourcing creación de asociaciones - Oportunidades de - Choque de culturas
o Partnership) estratégicas (nuevas respuesta
oportunidades de competitiva
mercado).
Externalización Una organización externa - “Ventanilla única” - Pérdida de
de Procesos de se hace cargo de un conocimiento
Negocio (BPO) proceso de negocio (en - Acceso a
todo o en parte) en un capacidades - Pérdida de relación
lugar más barato, como un especializadas con el negocio
centro de llamadas.
Provisión de Se ofrecen servicios - Acceso a - Acceso sólo a
Servicios de informáticos al cliente a soluciones instalaciones, no a
Aplicación través de la red. complejas y conocimiento
(ASP) costosas
- Choque de culturas
- Incluye soporte y
actualizaciones
Externalización Va un paso más allá de - Conocimiento y - Pérdida de
del Proceso de BPO, ofreciendo experiencia conocimiento interno
Conocimiento conocimiento de un campo
(KPO) de trabajo completo en - Recorte de costes - Pérdida de relación
Página 9
lugar de conocimiento de
un proceso (en todo o en con el negocio
parte).
Página 10
2. Conceptos Básicos / Las 4 P’s
Muchos diseños, planes y proyectos fallan por una falta de preparativos y

dirección. La puesta en práctica de la gestión del servicio ITIL como un práctica
trata sobre cómo preparar y planificar el uso eficaz y eficiente de las cuatro Ps:
Personas: usuarios, clientes, personal de TI y gestores. Es esencial la

comunicación, el entrenamiento y la clara definición de responsabilidades para
todas las partes involucradas.
Procesos: aquí es donde entra ITIL. Los procesos de ITIL son cubiertos como
un ciclo de vida por fases:
Estrategia del Servicio
Diseño del Servicio
Transición del Servicio
Operación del Servicio
Productos: las herramientas y la tecnología han tenido un largo camino desde

la evolución de ITIL. Ahora hay varias herramientas asequibles a las
organizaciones de TI consideradas "compatibles ITIL". Esto quiere decir que
han sido desarrolladas en base a procedimientos de Gestión del Servicio de TI.
Página 11
Estas herramientas pueden ayudar con la puesta en práctica y la ejecución de

servicios de TI.
Proveedores (partners) : los proveedores, la gestión de proveedores, socios,

fabricantes y distribuidores son esenciales para la provisión de servicios de TI
de calidad.
Página 12
2. Conceptos Básicos / RACI
Para que la fase de diseño resulte exitosa es imprescindible organizar

adecuadamente todos los procesos y actividades implicados.
Un modelo útil para la asignación de responsabilidades en la ejecución de

tareas o actividades asignadas a un proyecto es el llamado modelo RACI
(también llamado matriz de asignación de responsabilidades) que es el
acrónimo de:
• Responsible (Encargado): es la persona encargada de hacer la tarea

en cuestión.
• Accountable (Responsable): es el único responsable de la correcta
ejecución de la tarea.
• Consulted (Consultado): las personas que deben ser consultadas para
la realización de la tarea.
• Informed (Informado): Las personas que deben ser informadas sobre el
progreso de ejecución de la tarea.
En cada tarea debe haber un único R y A. Si esto no fuera así la tarea se

subdividirá hasta que así sea. Por supuesto una persona puede ser, a priori, R
o A en múltiples tareas.
Página 13
Una matriz RACI típicamente tiene un eje vertical donde se describen las
tareas o entregables en orden cronológico y en el eje horizontal los perfiles o
personas implicadas en los mismos.
Existen variaciones menores de este modelo que incluyen nuevos roles.
Por ejemplo en RASCI se incluye:
• Support (Soporte): que se corresponde con las personas encargadas

de facilitar el soporte necesario para la realización de la tarea.
Y el RACI-VS que introduce los roles de:
• Verify (Vericador): encargado de supervisar la tarea y su adecuación a

los estándares preestablecidos.
• Sign (Signatario o firmante): encargado de dar la aprobación.
Página 14
3. Procesos
Las funciones y procesos asociados directamente a la fase de Diseño son:
• Gestión del Catálogo de Servicios: responsable de crear y mantener

un catálogo de servicios de la organización TI que incluya toda la
información relevante: gestores, estatus, proveedores, etcétera.
• Gestión de Niveles de Servicio: responsable de acordar y garantizar
los niveles de calidad de los servicios TI prestados.
• Gestión de la Capacidad: responsable de garantizar que la
organización TI dispone de la capacidad suficiente para prestar los
servicios acordados.
• Gestión de la Disponibilidad: responsable de garantizar que se
cumplen los niveles de disponibilidad acordados en los SLA.
• Gestión de la Continuidad de los Servicios TI: responsable de
establecer planes de contingencia que aseguren la continuidad del
servicio en un tiempo predeterminado con el menor impacto posible en
los servicios de carácter crítico.
• Gestión de la Seguridad de la Información: responsable de establecer
las políticas de integridad, confidencialidad y disponibilidad de la
información.
• Gestión de Proveedores: responsable de la relación con los
proveedores y el cumplimiento de los UCs.
Página 15
3. Procesos / Gestión del Catálogo de Servicios
INTRODUCCIÓN
El propósito de la Gestión del Catálogo de Servicios (SCM) es proporcionar una

fuente única de información consistente sobre todos los servicios acordados, y
garantizar su completa disponibilidad para aquellos que hayan sido autorizados
a su acceso.
La meta de la Gestión del Catálogo de Servicos es el desarrollo y

mantenimiento de un Catálogo de Servicios que contenga todos los detalles, el
estado, las posibles interacciones y las dependencias mutuas de todos los
servicios actuales y de aquellos que estén siendo preparados para su
funcionamiento operacional.
Página 16
3. Procesos / Gestión del Catálogo de Servicios / Objetivos
El objetivo principal del Catálogo de Servicios es comprender toda la

información referente a los servicios que los clientes deben conocer para
asegurar un buen entendimiento entre éstos y la organización TI.
Para cumplir ese cometido, el Catálogo de Servicios debe:
• Describir los servicios ofrecidos de manera comprensible para personal

no especializado, poniendo especial cuidado en evitar el lenguaje
técnico.
• Ser utilizado como guía para orientar y dirigir a los clientes.
• Incluir, en líneas generales, los Acuerdos de Nivel de Servicio y los
precios en vigor. Ha de recoger también otras políticas y condiciones de
prestación de los servicios, así como las responsabilidades asociadas a
cada uno de éstos.
• Registrar los clientes actuales de cada servicio.
• Encontrarse a disposición del Centro de Servicios y de todo el personal
que se halle en contacto directo con los clientes.
Página 17
3. Procesos / Gestión Catálogo Servicios / Conceptos básicos
Cartera de Servicios
La Cartera contiene información sobre cada servicio y su estado. Esto quiere

decir que describe todo el proceso, comenzando con los requisitos del cliente
para el desarrollo, construcción y ejecución del servicio. La Cartera de
Servicios representa todos los servicios activos e inactivos en las distintas
fases del Ciclo de Vida.
Catálogo de Servicios
El Catálogo es un subconjunto de la Cartera de Servicios que incluye sólo los

servicios activos y aprobados (a nivel comercial) en la Operación del Servicio.
Divide los servicios en componentes y contiene políticas, directrices y
responsabilidades, así como precios, acuerdos de nivel de servicio y
condiciones de entrega.
Sistema de Gestión de la Configuración
Muchas organizaciones integran el Portafolio y el Catálogo de servicios en una

herramienta que recibe el nombre de Sistema de Gestión de la
Configuración (CMS). De este modo, la información contenida en ellos puede
ser utilizada por otras herramientas de gestión.
El Catálogo de Servicios de Negocio
Se denomina Catálogo de Servicios de Negocio a la información contenida

en el Catálogo de Servicios que se refiere a los procesos de negocio, las
relaciones entre unidades de negocio, etc.
El Catálogo de Servicios Técnico
Se denomina Catálogo de Servicios Técnico a aquellos aspectos del

Catálogo de Servicios que abordan los propios servicios TI: distinción entre
servicios de apoyo, servicios compartidos, componentes, elementos de
configuración, etc.
Página 18
3. Procesos / Gestión Catálogo Servicios / Definición de servicios
El primer paso a la hora de definir el Catálogo de Servicios consiste en tomar

los servicios recogidos en el Portfolio de Servicios y discriminar la parte
“histórica”, es decir, los registros que se refieren a servicios que ya no están en
activo.
El siguiente punto consiste en trazar las líneas de servicio o familias principales

en las que éstos se van a agrupar. Generalmente, las familias de servicios
están relacionadas con las áreas funcionales en las que se desarrollan éstos.
Esto aporta una visión de conjunto sobre los servicios que presta la
organización, lo cual es un arma de doble filo. Si la estrategia es clara y se ha
puesto en práctica con rigor a la hora de definir los servicios, de un solo vistazo
al Catálogo quedarán patentes los fines de la organización. Sin embargo, si ha
habido improvisación también quedará al descubierto al no existir
denominadores comunes claros entre unos servicios y otros.
Una vez establecido el primer nivel, el de las familias, se van detallando los
servicios existentes en cada una de ellas, así como los clientes que los han
contratado y la demanda prevista para cada servicio.
A continuación, ofrecemos un listado resumido de los datos que debe contener

el Catálogo para cada servicio:
• Nombre y descripción.
• Propietario del servicio.
• Cliente.
• Otras partes implicadas (proveedores, instituciones, etc.)
• Fechas de versión y revisión.
• Niveles de servicio acordados (tiempos de respuesta, disponibilidad,
continuidad, horarios, etc.) en losOLAs y SLAs.
• Condiciones de prestación del servicio. Precios.
• Cambios y excepciones.
Es importante insistir en que el lenguaje empleado debe ser comprensible para

aquellos que no están familiarizados con la jerga técnica.
Página 19
Sin embargo, en la mayoría de los casos, por muy detallado y completo que
sea el Catálogo de Servicios, la complejidad de los servicios ofrecidos requiere
un largo y extenso periodo de negociación con el cliente.
Página 20
3. Procesos / Gest. Cat. Serv. / Actividades, métodos y técnicas
El Catálogo de Servicios es el único recurso que contiene la información

constante sobre todos los servicios del proveedor de servicios. Sólo las
personas autorizadas deben acceder al catálogo. Este proceso incluye las
siguientes actividades:
• Acuerdo y documentación de una definición del servicio con todas las

partes relevantes.
• Interacción con la gestión de la Cartera de Servicios para acordar los

contenidos de la Cartera de Servicios y el Catálogo de Servicios.
• Producción y mantenimiento de un Catálogo de Servicios, con contenido

preciso y vinculación a la Cartera de Servicios.
• Interacción con la gestión de la continuidad del negocio y de los

servicios de TI, sobre las dependencias de las unidades de negocio, y
sus procesos de negocio, de los servicios de TI que los apoyan, que se
recogen en el Catálogo de Servicios de negocio.
• Interacción con los equipos de soporte, los proveedores de servicios y la

gestión de la configuración, sobre relaciones y dependencias entre los
servicios de TI y los servicios de apoyo, como componentes y CIs
contenidos en el Catálogo de Servicios técnico.
• Interacción con la gestión de relaciones con el negocio y la gestión de

niveles de servicio para garantizar que la información está alineada con
el negocio y sus procesos.
Página 21
3. Procesos / Gestión Catálogo Servicios / Interfaces
Entradas:
• Información de negocio de la organización empresarial, estrategia y

planes de TI, planes financieros, etc
• Análisis de Impacto sobre el Negocio
• Cartera de Servicios
• Sistema de Gestión de la Configuración (CMS)
• Retroalimentación desde otros procesos
Salidas:
• Documentación y acuerdo de una "definición del servicio"
• Actualizaciones de la Cartera de Servicios
• Actualizaciones del Catálogo de Servicios
Página 22
3. Procesos / Gestión Catálogo Servicios / Métricas
Indicadores Clave de Rendimiento (KPI)
• Número de servicios registrados y mantenidos en el Catálogo de

Servicios, como porcentaje de aquellos que se entregan y se llevan al
entorno de producción
• Número de diferencias detectadas entre la información del Catálogo de

Servicios y la realidad
• Porcentaje de mejora de la completitud del Catálogo de Servicios de

negocio, comparado con los servicios operativos
• Porcentaje de mejora de la completitud del Catálogo de Servicios

técnico, comparado con los componentes de TI que soportan a los
servicios
• Acceso del Centro de Servicio al Usuario a información de apoyo a los

servicios, expresado como el porcentaje de incidencias sin la
información adecuada relativa al servicio
Página 23
3. Procesos / Gestión Catálogo Servicios / Implementación
La principal dificultad en el proceso de Gestión del Catálogo de Servicios es el

mantenimiento sin errores de un Catálogo de Servicios como parte de la
Cartera de Servicios. Esta dificultad se puede superar desarrollando bases de
datos antes de integrar el Catálogo o la Cartera en el Sistema de Gestión de la
Configuración (CMS) y en el Sistema de Gestión del Conocimiento del Servicio
(SKMS).
Por otra parte, es importante que todas las partes implicadas sean conscientes
de la importancia de ambos catálogos como fuentes de información que todos
en la organización deben usar y mantener.
Factores críticos de éxito
• Catálogo de Servicios preciso
• Familiaridad de los usuarios de negocio con los servicios proporcionados
• Familiaridad de la organización TI con las tecnologías que soportan los

servicios
Riesgos
• Información inexacta en el catálogo, y que éste no esté bajo control de

Gestión de Cambios
• Baja aceptación del Catálogo y su uso en los procesos operativos
• Inexactitud de la información proporcionada por el negocio, la

organización TI y la Cartera de Servicios
• Herramientas y recursos necesarios para mantener actualizada la

información
• Acceso deficiente a procesos e información exacta sobre Gestión de

Cambios
• Que se evite utilizar la Cartera de Servicios y el Catálogo de Servicios
Página 24
• Información demasiado detallada para poderla mantener de modo

preciso, o a un nivel demasiado alto para que pueda aportar algún valor
Página 25
3. Procesos / Gestión de Niveles de Servicio
INTRODUCCIÓN
El objetivo último de la Gestión de Niveles de Servicio es poner la tecnología

al servicio del cliente.
La tecnología, al menos en lo que respecta a la gestión de servicios TI, no es

un fin en sí misma sino un medio para aportar valor a los usuarios y clientes.
La Gestión de Niveles de Servicio debe velar por la calidad de los servicios TI

alineando tecnología con procesos de negocio y todo ello a unos costes
razonables.
Para cumplir sus objetivos es imprescindible que la Gestión de Niveles de

Servicio:
• Conozca las necesidades de sus clientes.

• Defina correctamente los servicios ofrecidos.
• Monitorice la calidad del servicio respecto a los objetivos establecidos en
los SLAs.
Página 26
3. Procesos / Gestión de Niveles de Servicio / Objetivos
La Gestión de Niveles de Servicio es responsable de buscar un compromiso

realista entre las necesidades y expectativas del cliente y los costes de los
servicios asociados, de forma que estos sean asumibles tanto por el cliente
como por la organización TI.
La Gestión de Niveles de Servicio debe:
• Documentar todos los servicios TI ofrecidos.

• Presentar los servicios de forma comprensible para el cliente.
• Centrarse en el cliente y su negocio y no en la tecnología.
• Colaborar estrechamente con el cliente para proponer servicios TI
realistas y ajustados a sus necesidades.
• Establecer los acuerdos necesarios con clientes y proveedores para
ofrecer los servicios requeridos. (SLAs)
• Establecer los indicadores claves de rendimiento del servicio TI.
• Monitorizar la calidad de los servicios acordados con el objetivo último
de mejorarlos a un coste aceptable por el cliente.
• Elaborar los informes sobre la calidad del servicio y los Planes de Mejora
del Servicio (SIP).
Página 27
3. Procesos / Gestión de Niveles de Servicio / Conceptos básicos
Requisitos de Nivel de Servicio (SLR)
Los Requisitos de Nivel de Servicio (SLR) deben recoger información detallada

sobre las necesidades del cliente y sus expectativas de rendimiento y nivel de
servicios.
El documento de SLR constituye el elemento base para desarrollar los SLA y

posibles OLAs correspondientes.
Hojas de Especificación
Las Hojas de Especificación son, primordialmente, documentos técnicos de

ámbito interno que delimitan y precisan los servicios ofrecidos al cliente.
Las Hojas de Especificación deben evaluar los recursos necesarios para

ofrecer el servicio requerido con un nivel de calidad suficiente y determinar si
es necesario el outsourcing de determinados procesos, sirviendo de documento
de base para la elaboración de los OLAs y UCs correspondientes.
Plan de Calidad del Servicio (SQP)
El Plan de Calidad del Servicio (SQP) debe incorporar toda la información

necesaria para posibilitar una gestión eficiente de los niveles de calidad del
servicio:
• Objetivos de cada servicio.

• Estimación de recursos.
• Indicadores clave de rendimiento.
• Procedimientos de monitorización de proveedores.
En resumen, el SQP debe contener la información necesaria para que la

organización TI conozca los procesos y procedimientos involucrados en el
suministro de los servicios prestados, asegurando que estos se alineen con los
procesos de negocio y mantengan unos niveles de calidad adecuados.
Acuerdo de Nivel de Servicio (SLA)
Página 28
El SLA debe recoger en un lenguaje no técnico, o cuando menos comprensible

para el cliente, todos los detalles de los servicios brindados.
Tras su firma, el SLA debe considerarse el documento de referencia para la

relación con el cliente en todo lo que respecta a la provisión de los servicios
acordados, por tanto, es imprescindible que contenga claramente definidos los
aspectos esenciales del servicio tales como su descripción, disponibilidad,
niveles de calidad, tiempos de recuperación, etc.
Acuerdo de Nivel de Operación (OLA)
El Acuerdo de Nivel de Operación (OLA) es un documento interno de la

organización donde se especifican las responsabilidades y compromisos de los
diferentes departamentos de la organización TI en la prestación de un
determinado servicio.
Contrato de Soporte (UC)
Un UC es un acuerdo con un proveedor externo para la prestación de servicios

no cubiertos por la propia organización TI.
Programa de Mejora del Servicio (SIP)
El Programa de Mejora del Servicio (SIP) debe recoger tanto medidas

correctivas a fallos detectados en los niveles de servicio como propuestas de
mejora basadas en el avance de la tecnología.
El SIP debe formar parte de la documentación de base para la renovación de

los SLAs y debe estar internamente a disposición de los gestores de los otros
procesos TI.
Página 29
3. Procesos / Gestión de Niveles de Servicio / Actividades
Las principales actividades de la Gestión de Niveles de Servicio se resumen

en:
• Planificación:
o Asignación de recursos.
o Elaboración de un catálogo de servicios.
o Desarrollo de SLAs tipo.
o Herramientas para la monitorización de la calidad del servicio.
o Análisis e identificación de las necesidades del cliente.
o Elaboración del los Requisitos de Nivel de servicio (SLR), Hojas
de Especificación del Servicio y Plan de Calidad del Servicio
(SQP).
• Implementación de los Acuerdos de Niveles de Servicio:
o Negociación.
o Acuerdos de Nivel de Operación.
o Contratos de Soporte.
• Supervisión y revisión de los Acuerdos de Nivel de Servicio:
o Elaboración de informes de rendimiento.
o Control de los proveedores externos.
o Elaboración de Programas de Mejora del Servicio (SIP).
Página 30
3. Procesos / Gestión Niveles Servicio / Planificación de la Gestión
Planificación de la Gestión
La correcta planificación de la Gestión de Niveles de Servicio requiere la

implicación de prácticamente todos los estamentos de la organización TI. Y, si
esto no fuera ya de por sí una labor lo suficientemente compleja, resulta
imprescindible la colaboración activa de los clientes y usuarios de los servicios
TI.
El objetivo primordial de la Gestión de Niveles de Servicio es definir, negociar y

monitorizar la calidad de los servicios TI ofrecidos. Si los servicios no se
adecuan a las necesidades del cliente, la calidad de los mismos es deficiente o
sus costes son desproporcionados, tendremos clientes insatisfechos y la
organización TI será responsable de las consecuencias que se deriven de ello.
Todo el proceso de planificación previo debe estar orientado a dar respuesta a

las siguientes preguntas:
• ¿Qué servicios debemos ofrecer a nuestros clientes?

• ¿Cuáles son las necesidades de nuestros clientes?
• ¿Cuál es el nivel adecuado de calidad de servicio?
• ¿Quiénes y cómo se van a suministrar esos servicios?
• ¿Cuáles serán los indicadores clave de rendimiento para los servicios
prestados?
• ¿Disponemos de los recursos necesarios para proveer los servicios
propuestos con los niveles de calidad acordados?
La respuesta a cada una de estas preguntas debe darse en forma de

documentos, algunos de carácter interno y otros accesibles a los clientes, que
pasamos a describir sucintamente a continuación.
Los resultados de esta interacción/negociación deben ser incorporados al

documento de Requisitos de Nivel de Servicio (SLR), que debe reflejar las
necesidades del cliente y sus expectativas respecto a:
• La funcionalidad y características del servicio.

• La disponibilidad del servicio.
• La interacción del servicio con su infraestructura TI o de otro tipo.
Página 31
• La continuidad del servicio.

• Los niveles de calidad del servicio.
• Tiempo y procedimientos de implantación del servicio.
• La escalabilidad del servicio ofrecido.
• Etc.
La información contenida en el SLR debe servir de base para elaborar la

documentación interna que permita determinar "cómo" se prestara el servicio y
"quién o quiénes" serán responsables del mismo.
Las Hojas de Especificación del Servicio deben contener:
• Una descripción detallada, con todos los detalles técnicos necesarios,

sobre como se prestará el servicio.
• Cuáles serán los indicadores internos de rendimiento y calidad del
servicio.
• Cómo se implementará el servicio.
Si la prestación del servicio requiere la interacción con los servicios TI del

cliente o presentas exigencias técnicas a su infraestructura, esta información
deberá reflejarse en una Hoja de Especificaciones "externa" que habrá de
acordarse con el cliente y sus responsables técnicos.
El Plan de Calidad del Servicio (SQP) debe ser el documento maestro para la
gestión interna de los servicios prestados y contener información detallada
sobre todos los procesos TI involucrados en la prestación de los servicios.
En función de los requisitos plasmados en las Hojas de Especificación del

Servicio, se elabora un plan global que permita asignar los recursos a la
organización TI, establecer metas claras basadas en los indicadores de
rendimiento elegidos y asegurar que los niveles de calidad ofrecidos se
adaptan a las necesidades de los clientes y a los compromisos asumidos por la
organización.
En caso de que se estimen insuficientes los recursos internos o sencillamente

se considere oportuno externalizar parte de los servicios, el SQP servirá de
documento guía para el establecimiento de los contratos con los proveedores
externos.
Página 32
3. Procesos / Gestión de Niveles de Servicio / Implementación
La fase de planificación debe concluir con la elaboración y aceptación de los

acuerdos necesarios para la prestación del servicio.
Estos acuerdos incluyen los Acuerdos de Nivel de Servicio, Niveles de

Operación y Contratos de Soporte.
Acuerdos de Nivel de Servicio
Los Acuerdos de Nivel de Servicio (SLAs) deben contener una descripción del
servicio que abarque desde los aspectos más generales hasta los detalles más
específicos del servicio.
Es conveniente estructurar los SLAs más complejos en diversos documentos,

de forma que cada grupo involucrado reciba exclusivamente la información
correspondiente al nivel en que se integra, ya sea en el lado del cliente o en el
del proveedor.
La elaboración de un SLA requiere tomar en cuenta aspectos no tecnológicos

entre los que se encuentran:
• La naturaleza del negocio del cliente.

• Aspectos organizativos del proveedor y cliente.
• Aspectos culturales locales.
Acuerdos de Nivel de Operación
Los Acuerdos de Nivel de Operación (OLAs) son documentos de carácter

interno de la propia organización TI que determinan los procesos y
procedimiento necesarios para ofrecer los niveles de servicio acordados con
los clientes.
El OLA, por su naturaleza, involucra detalles sobre la prestación del servicio

que deben ser opacos para el cliente pero que resultan imprescindibles a la
organización TI para desarrollar y coordinar su labor.
Contratos de Soporte
Página 33
Los Contratos de Soporte (UCs) determinan las responsabilidades de los

proveedores externos en el proceso de prestación de servicios.
Mientras que los OLAs son documentos internos susceptibles de cierto

dinamismo, los Contratos de Soporte deben representar compromisos claros y
perfectamente delimitados. A pesar de esta diferencia crucial, los UCspueden
considerarse como una extensión "externa" de los OLAs, en el sentido de que
persiguen el mismo fin: organizar los procesos y procedimientos necesarios
para la correcta provisión del servicio.
Página 34
3. Procesos / Gest.Niv.Serv. / Monitorización de Niveles de Servicio
El proceso de monitorización de Niveles de Servicio es imprescindible si

queremos mejorar progresivamente la calidad del servicio ofrecido, su
rentabilidad y la satisfacción de los clientes y usuarios.
La monitorización de la calidad del servicio requiere el seguimiento tanto de

procedimientos y parámetros internos de la organización como los relacionados
con la percepción de los usuarios.
Para llevar a cabo esta tarea de manera eficiente es necesario haber

establecido con anterioridad unos baremos de calidad del servicio que han de
servir de guía en la elaboración de los informes correspondientes.
Las principales fuentes de información las constituyen:
• La documentación disponible: SLAs, SLRs, OLAs, SQP, SIP, UCs, etc.

• La Gestión de Incidencias y la Gestión de Problemas, que deben
informar de las incidencias en el servicio y los tiempos de recuperación.
• La Gestión de la Continuidad y la Gestión de la Disponibilidad, que
deben proporcionar la información sobre la infraestructura utilizada para
satisfacer la calidad de servicios acordada.
• El Centro de Servicios (Service Desk), que mediante su trato diario con
los clientes, usuarios y organización TI supervisa la calidad de los
servicios y conoce la percepción del cliente respecto a los mismos.
Los informes de rendimiento elaborados deben cubrir factores clave tales

como:
• Cumplimiento de los SLAs, con información sobre la frecuencia y el

impacto de los incidentes responsables de la degradación del servicio.
• Quejas, justificadas o no, de los clientes y usuarios.
• Utilización de la capacidad predefinida.
• Disponibilidad del servicio.
• Tiempos de respuesta.
• Costes reales del servicio ofrecido.
• Problemas detectados y cambios realizados para restaurar la calidad del
servicio.
Página 35
• Calidad del servicio de los proveedores externos: nivel de cumplimiento

de los OLAs.
Página 36
3. Procesos / Gest.Niv.Serv. / Revisión de la calidad de los servicios
La correcta Gestión de Niveles de Servicio es un proceso continuo que

requiere la continua revisión de la calidad de los servicios ofrecidos.
En este último tramo del proceso se trata de revisar aquellos SLAs que se han
incumplido buscando las razones para, a partir de este análisis, elaborar un
Programa Mejora del Servicio (SIP). Esta función entronca con la última fase
del ciclo de vida, la de Mejora Continua del Servicio.
Página 37
3. Procesos / Gestión de Niveles de Servicio / Interfaces
Entradas:
• Información de negocio procedente de los planes y estrategias de

negocio de la empresa y los planes financieros
• Requisitos de negocio
• Cartera de Servicios y Catálogo de Servicios
• Información de cambios
• Sistema de Gestión de la Configuración (CMS)
Salidas:
• Informes de servicio
• Plan de Mejora del Servicio (SIP)
• Plan de Calidad del Servicio (SQP)
• Plantillas de documentos estándar
• SLA, SLR y OLAs
Página 38
3. Procesos / Gestión de Niveles de Servicio / Implementación
Posibles disparadores para las actividades de SLM:
• Cambios en la Cartera de Servicios
• Acuerdos nuevos o modificados
• Cambios de estrategia o política
• Cumplimientos y quejas
• Reuniones y acciones de revisión del servicio
Página 39
3. Procesos / Gestión de la Capacidad
La Gestión de la Capacidad es la encargada de que todos los servicios TI se

vean respaldados por una capacidad de proceso y almacenamiento suficiente y
correctamente dimensionada.
Sin una correcta Gestión de la Capacidad, los recursos no se aprovechan

adecuadamente y se realizan inversiones innecesarias que acarrean gastos
adicionales de mantenimiento y administración. O aún peor, los recursos son
insuficientes con la consecuente degradación de la calidad del servicio.
Entre las responsabilidades de la Gestión de la Capacidad se encuentran:
• Asegurar que se cubren las necesidades de capacidad TI tanto

presentes como futuras.
• Controlar el rendimiento de la infraestructura TI.
• Desarrollar planes de capacidad asociados a los niveles de servicio
acordados.
• Gestionar y racionalizar la demanda de servicios TI.
Página 40
3. Procesos / Gestión de la Capacidad / Objetivos
El objetivo primordial de la Gestión de la Capacidad es poner a disposición de

clientes, usuarios y del propio departamento TI los recursos informáticos
necesarios para desempeñar de una manera eficiente sus tareas y todo ello sin
incurrir en costes desproporcionados.
Para ello, la Gestión de la Capacidad debe:
• Conocer el estado actual de la tecnología y previsibles futuros

desarrollos.
• Conocer los planes de negocio y acuerdos de nivel de servicio para
prever la capacidad necesaria.
• Analizar el rendimiento de la infraestructura para monitorizar el uso de la
capacidad existente.
• Realizar modelos y simulaciones de capacidad para diferentes
escenarios futuros previsibles.
• Dimensionar adecuadamente los servicios y aplicaciones alineándolos a
los procesos de negocio y necesidades reales del cliente.
• Gestionar la demanda de servicios informáticos racionalizando su uso.
Página 41
3. Procesos / Gestión de la Capacidad / Actividades
Las principales actividades de la Gestión de la Capacidad se resumen en:
• Desarrollo del Plan de Capacidad y modelado de diferentes escenarios

de capacidad.
• Monitorización de los recursos de la infraestructura TI.
• Supervisión de la capacidad y administración de la Base de Datos de la
Capacidad (CDB) contenida en el Sistema de Información de Gestión de
la Capacidad (CMIS).
El proceso de Gestión de la Capacidad puede segmentarse en subprocesos

que analizan las necesidades de capacidad TI desde diferentes puntos de
vista:
• Gestión de la Capacidad del Negocio (BCM, del inglés Business

Capacity Management): que centra su objeto de atención en las
necesidades futuras de usuarios y clientes.
• Gestión de la Capacidad del Servicio (SCM, del inglés Service Capacity
Management): que analiza el rendimiento de los servicios TI con el
objetivo de garantizar los niveles de servicio acordados.
• Gestión de la Capacidad de Recursos (CCM, del inglés Component
Capacity Management): que estudia tanto el uso de la infraestructura TI
como sus tendencias para asegurar que se dispone de los recursos
suficientes y que estos se utilizan eficazmente.
Página 42
3. Procesos / Gestión Cap. / Planificación de la Capacidad
Plan de Capacidad
La elaboración del Plan de Capacidad es la tarea principal de la Gestión de

Capacidad.
El Plan de Capacidad recoge:
• Toda la información relativa a la capacidad de la infraestructura TI.

• Las previsiones sobre necesidades futuras basadas en tendencias,
previsiones de negocio y SLAsexistentes.
• Los cambios necesarios para adaptar la capacidad TI a las novedades
tecnológicas y las necesidades emergentes de usuarios y clientes.
El Plan de Capacidad debe incluir información sobre los costes de la capacidad

actual y prevista. Esta información es indispensable para que la Gestión
Financiera pueda elaborar los presupuestos y previsiones financieras de
manera realista.
Aunque, en principio, el Plan de Capacidad puede tener una vigencia anual o

bianual es importante que se monitorice su cumplimiento para adoptar medidas
correctivas en cuanto se detecten desviaciones importantes del mismo.
Modelado y Benchmarking
Cuanto más compleja sea una infraestructura informática más difícil es prever
las necesidades de capacidad futura. En esos casos, es imprescindible realizar
modelos y simulaciones sobre posibles escenarios de desarrollo futuro que
aseguren la correcta escalabilidad de las aplicaciones y hardware.
El nivel de detalle al que se lleve este modelado dependerá de varios factores:
• Costes asociados al incremento de la capacidad.

• Costes inherentes al proceso mismo de modelado y simulación.
• Alcance de los incrementos de capacidad previstos.
• La "criticalidad" de los sistemas implicados.
Sopesando los anteriores factores podemos optar por:
Página 43
• Un simple análisis de tendencias que permita evaluar la carga de

proceso esperada en la infraestructura informática y escalar
consecuentemente su capacidad actual.
• Realizar modelos y simulaciones sobre diferentes escenarios para llevar
a cabo previsiones de carga y repuesta de la infraestructura informática.
• Realizar benchmarks (pruebas de rendimiento comparativas) con
prototipos reales para asegurar la capacidad y el rendimiento de la futura
infraestructura.
Página 44
3. Procesos / Gestión Cap. / Recursos de gestión de la Capacidad
Un aspecto esencial de la Gestión de la Capacidad es el de asignar recursos

adecuados de hardware, software y personal a cada servicio y aplicación.
El correcto dimensionamiento requiere que la Gestión de la Capacidad

disponga de información fiable sobre:
• Los niveles de servicio acordados y/o previstos (SLAs).

• Niveles de rendimiento esperados.
• Impacto de la aplicación o servicio en los procesos de negocio del
cliente.
• Márgenes de seguridad y disponibilidad.
• Informes de monitorización de los niveles de servicio.
• Costes asociados a los equipos de hardware y otros recursos TI
necesarios.
En la fase de diseño de un servicio, la Gestión de la Capacidad asegura que se

dispondrá de la capacidad necesaria para llevar el proyecto a buen término.
Una vez se ha puesto en marcha el servicio, también es la encargada de
analizar las tendencias de uso y prever las necesidades futuras.
Es relativamente frecuente que se obvien aspectos relativos al correcto

dimensionamiento de una aplicación debido a expectativas injustificadas sobre
la tecnología. Se puede caer en el equívoco de que los costes asociados a la
capacidad se limitan a la compra de más servidores, o más espacio de
almacenamiento, etcétera, olvidando que sistemas más complejos implican
unos mayores gastos de mantenimiento y administración, o ignorando los
problemas que pueden conllevar dichos cambios.
Página 45
3. Procesos / Gestión de la Capacidad / Supervisión de la Capacidad
La Gestión de la Capacidad es un proceso continuo e iterativo que monitoriza,

analiza y evalúa el rendimiento y capacidad de la infraestructura TI y con los
datos obtenidos optimiza los servicios o eleva una RFC a laGestión de
Cambios.
Tanto la información obtenida en estas actividades como la generada a partir

de ella por la Gestión de la Capacidad se almacena y registra en la Base de
Datos de la Capacidad (CDB).
Monitorización
Su objetivo principal es asegurar que el rendimiento de la infraestructura

informática se adecua a los requisitos de los SLAs.
La monitorización debe incluir, además de aspectos técnicos, todos aquellos

relativos a licencias y otras cuestiones de carácter administrativo.
Análisis y Evaluación
Los datos recogidos deben ser analizados para evaluar la conveniencia de

adoptar acciones correctivas tales como petición de aumento de la capacidad o
una mejor Gestión de la Demanda.
Optimización y cambios
Si se ha optado por solicitar un aumento de la capacidad, se elevará una

petición de cambio (RFC) a la Gestión de Cambios para que se desencadene
todo el proceso necesario para la implementación del cambio. La Gestión de la
Capacidad prestará su apoyo en todo el proceso y será corresponsable, junto a
la Gestión de Cambios y Versiones, de asegurar que el cambio solicitado
cumpla los objetivos previstos.
En el caso de que una simple racionalización de la demanda sea suficiente

para solventar las posibles deficiencias o incumplimientos de los SLAs, será la
propia Gestión de la Capacidad la responsable de gestionar ese subproceso.
Base de Datos de la Capacidad
Página 46
La Base de Datos de la Capacidad (CDB) debe cubrir toda la información de

negocio, financiera, técnica y de servicio que reciba y genere la Gestión de la
Capacidad relativas a la capacidad de la infraestructura y sus elementos.
Idealmente la CDB debe estar interrelacionada con la CMDB para que esta
última ofrezca una imagen integral de los sistemas y aplicaciones con
información relativa a su capacidad. Esto no es óbice para que ambas bases
de datos puedan ser "físicamente independientes".
Página 47
3. Procesos / Gestión de la Capacidad / Interfaces
Entradas:
• Información de negocio procedente de los planes y estrategias de

negocio de la empresa y los planes financieros, así como información de
sus requisitos actuales y futuros.
• Información de servicios y de TI procedente de los planes y estrategias

de TI.
• Información de rendimiento y capacidad de los componentes
• Aspectos de rendimiento de los servicios, desde gestión de incidencias y

gestión de problemas
• Información financiera
• Información de cambios y rendimiento
• Sistema de Información para la Gestión de la Capacidad (CMIS)
• Información de carga de trabajo, desde el equipo de Operaciones
Salidas:
• Sistema de Información para la Gestión de la Capacidad (CMIS)
• Plan de capacidad, con información del uso actual de los servicios y

componentes, así como planes para satisfacer el crecimiento de los
servicios y los nuevos servicios
• Información e informes de rendimiento de los servicios
• Análisis e informes de la carga de trabajo
• Previsiones e informes de predicción
• Umbrales, alertas y eventos
Página 48
3. Procesos / Gestión de la Capacidad / Métricas
Porcentaje 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
Reducción del uso de tecnologías obsoletas
Reducción de incidencias y problemas relativos a capacidad inadecuada
Página 49
3. Procesos / Gestión de la Capacidad / Implementación
Una de las principales dificultades reside en convencer al cliente para que

suministre más información estratégica que permita al proveedor de servicios
garantizar la eficacia de la gestión de la continuidad del negocio.
Entre los factores críticos de éxito se incluyen:
Exactitud de las predicciones de negocio
Conocimiento de tecnologías actuales y futuras
Habilidad para demostrar la eficiencia en costes
Habilidad para planificar e implementar la capacidad de TI adecuada para

satisfacer las necesidades de negocio
Riesgos:
Falta de compromiso del negocio
Falta de información precisa sobre la estrategia y los planes de la organización
Creación de procesos burocráticos o intensivos en mano de obra
Página 50
3. Procesos / Gestión de la Disponibilidad
Nuestras vidas, tanto personales como profesionales, dependen cada vez más
de la tecnología. Ésta nos permite acceder a la información y a los servicios a
una velocidad que ni siquiera podríamos haber soñado hace unos pocos años.
Nuestro ritmo de vida se acelera y exigimos como clientes una disponibilidad

absoluta de nuestros proveedores tecnológicos. Con frecuencia una oferta
diferente sólo se encuentra a un par de clics de distancia.
Por otro lado, el rápido desarrollo tecnológico implica una constante renovación
de equipos y servicios. Como proveedores de servicios TI nos enfrentamos al
reto de evolucionar sin apenas margen para el error pues nuestros sistemas
han de encontrarse a disposición del cliente prácticamente 24/7.
La Gestión de la Disponibilidad es responsable de optimizar y monitorizar los

servicios TI para que estos funcionen ininterrumpidamente y de manera fiable,
cumpliendo los SLAs y todo ello a un coste razonable. La satisfacción del
cliente y la rentabilidad de los servicios TI dependen en gran medida de su
éxito.
Página 51
3. Procesos / Gestión de la Disponibilidad / Objetivos
El objetivo primordial de la Gestión de la Disponibilidad es asegurar que los

servicios TI estén disponibles y funcionen correctamente siempre que los
clientes y usuarios deseen hacer uso de ellos en el marco de los SLAsen vigor.
Las responsabilidades de la Gestión de la Disponibilidad incluyen:
• Determinar los requisitos de disponibilidad en estrecha colaboración con

los clientes.
• Garantizar el nivel de disponibilidad establecido para los servicios TI.
• Monitorizar la disponibilidad de los sistemas TI.
• Proponer mejoras en la infraestructura y servicios TI con el objetivo de
aumentar los niveles de disponibilidad.
• Supervisar el cumplimiento de los OLAs y UCs acordados con
proveedores internos y externos.
Página 52
3. Procesos / Gestión de la Disponibilidad / Actividades
Entre las actividades que la Gestión de la Disponibilidad se encuentran:
• Determinar cuáles son los requisitos de disponibilidad reales del

negocio.
• Desarrollar un plan de disponibilidad donde se estimen las futuras a
corto y medio plazo.
• Mantenimiento del servicio en operación y recuperación del mismo en
caso de fallo.
• Realizar diagnósticos periódicos sobre la disponibilidad de los sistemas
y servicios.
• Evaluar la capacidad de servicio de los proveedores internos y externos.
• Monitorizar la disponibilidad de los servicios TI.
• Elaborar informes de seguimiento con la información recopilada sobre
disponibilidad, fiabilidad, capacidad de mantenimiento y cumplimiento de
OLAs y UCs.
• Evaluar el impacto de las políticas de seguridad en la disponibilidad.
• Asesorar a la Gestión de Cambios sobre el posible impacto de un
cambio en la disponibilidad.
Página 53
3. Procesos / Gestión Disponib. / Requisitos de disponibilidad
Es indispensable cuantificar los requisitos de disponibilidad para la correcta

elaboración de los SLAs.
La disponibilidad propuesta debe encontrase en línea tanto con las

necesidades reales del negocio como con las posibilidades de la organización
TI.
Aunque en principio todos los clientes estarán de acuerdo con unas elevadas
cotas de disponibilidad es importante hacerles ver que una alta disponibilidad
puede generar unos costes injustificados dadas sus necesidades reales. Quizá
unas pocas horas sin un determinado servicio pueden representar poco más
allá de una pequeña inconveniencia mientras que la certeza de un servicio
prácticamente continuo y sin interrupciones puede requerir la replicación de
sistemas u otras medidas igualmente costosas que no van a tener una
repercusión real en la rentabilidad del negocio.
Para llevar a cabo eficientemente esta tarea es necesario que la Gestión de la

Disponibilidad:
• Identifique las actividades clave del negocio.

• Cuantifique los intervalos razonables de interrupción de los diferentes
servicios dependiendo de sus respectivos impactos.
• Establezca los protocolos de mantenimiento y revisión de los servicios
TI.
• Determine las franjas horarias de disponibilidad de los servicios TI (24/7,
12/5, ...).
Página 54
3. Procesos / Gestión Disponib. / Planificación de la disponibilidad
La correcta planificación de la disponibilidad permite establecer unos niveles de

disponibilidad adecuados tanto en lo que respecta a las necesidades reales del
negocio como a las posibilidades de la organización TI.
El documento que debe recoger los objetivos de disponibilidad presentes y

futuros y qué medidas son necesarias para su cumplimiento es el Plan de
Disponibilidad.
Este plan debe recoger:
• La situación actual de disponibilidad de los servicios TI. Obviamente esta

información debe ser actualizada periódicamente.
• Herramientas para la monitorización de la disponibilidad.
• Métodos y técnicas de análisis a utilizar.
• Definiciones relevantes y precisas de las métricas a utilizar.
• Planes de mejora de la disponibilidad.
• Expectativas futuras de disponibilidad.
Es imprescindible que este plan proponga los cambios necesarios para que se
cumplan los estándares previstos y colabore con la Gestión de Cambios y la
Gestión de Entregas y Despliegues en su implementación (en caso de ser
aprobados, claro está).
Para que este plan sea realista, debe contar con la colaboración de los otros
procesos TI involucrados.
Diseño para la Disponibilidad
Es crucial para una correcta Gestión de la Disponibilidad participar desde el

inicio en el desarrollo de los nuevos servicios TI de forma que éstos cumplan
los estándares plasmados en el Plan de Disponibilidad.
Un diferente nivel de disponibilidad puede requerir cambios drásticos en los

recursos utilizados o en las actividades necesarias para suministrar un
determinado servicio TI. Si éste se diseña sin tener en cuenta futuras
necesidades de disponibilidad puede ser necesario un completo rediseño al
cabo de poco tiempo, incurriendo en costes adicionales innecesarios.
Página 55
3. Procesos / Gestión Disponib. / Mantenimiento y Seguridad
Aunque hayamos realizado un correcto diseño de los servicios según el Plan

de Disponibilidad y se hayan tomado todas las medidas preventivas
necesarias, tarde o temprano, nos habremos de enfrentar a interrupciones del
servicio.
En esos casos es necesario recuperar el servicio lo antes posible para que no

tenga un efecto indeseado sobre los niveles de disponibilidad acordados.
Aunque la responsabilidad de restaurar el servicio corresponde a la Gestión de

Incidencias y las actividades de recuperación han de ser coordinadas por el
Centro de Servicios, la Gestión de la Disponibilidad debe prestar su
asesoramiento mediante planes de recuperación que tengan en cuenta:
• Las necesidades de disponibilidad del negocio.

• Las implicaciones del incidente en la infraestructura TI y los procesos
necesarios para restaurar el servicio.
Gestión de las Interrupciones de Mantenimiento
Independientemente de las interrupciones del servicio causadas por

incidencias, es habitualmente necesario interrumpir el servicio para realizar
labores de mantenimiento y/o actualización.
Estas interrupciones programadas pueden afectar a la disponibilidad del

servicio y por lo tanto han de ser cuidadosamente planificadas para minimizar
su impacto.
En aquellos casos en que los servicios no son 24/7 es obvio que, siempre que
ello sea posible, deben aprovecharse las franjas horarias de inactividad para
realizar las tareas que implican una degradación o interrupción del servicio.
Si el servicio es 24/7 y la interrupción es necesaria se debe:
• Consultar con el cliente acerca de la franja horaria en la que la

interrupción del servicio afectará menos a sus actividades de negocio.
• Informar con antelación suficiente a todos los agentes implicados.
• Incorporar dicha información a los SLAs.
Página 56
Seguridad
Uno de los aspectos esenciales para obtener altos niveles de fiabilidad y

disponibilidad es una correcta Gestión de la Seguridad.
Los aspectos relativos a la seguridad deben ser tomados en cuenta en todas

las etapas del proceso.
Es tan importante determinar cuándo el servicio estará disponible como el

"quién y cómo" va a utilizarlo. La disponibilidad y seguridad son
interdependientes y cualquier fallo en una de ellas afectará gravemente a la
otra.
Página 57
3. Procesos / Gestión Disponib. / Monitorización de la disponibilidad
La monitorización de la disponibilidad del servicio y la elaboración de los

informes correspondientes son dos de las principales actividades de la Gestión
de la Disponibilidad.
Desde el momento de la interrupción del servicio hasta su restitución o "tiempo

de parada" el incidente pasa por distintas fases que deben ser analizadas por
separado:
• Tiempo de detección: es el tiempo que transcurre desde que ocurre el

fallo hasta que la organización TI tiene constancia del mismo.
• Tiempo de respuesta: es el tiempo que transcurre desde la detección del
problema hasta que se realiza un registro y diagnóstico del incidente.
• Tiempo de reparación/recuperación: periodo de tiempo utilizado para
reparar el fallo o encontrar unworkaround o solución temporal al mismo y
devolver el sistema a la situación anterior a la interrupción del servicio.
Es importante determinar métricas que permitan medir con precisión las

diferentes fases del ciclo de vida de la interrupción del servicio. El cliente debe
conocer estas métricas y dar su conformidad a las mismas para evitar
malentendidos. En algunos casos es difícil determinar si el sistema está "caído
o en funcionamiento" y la interpretación puede diferir entre proveedores y
clientes, por lo tanto, estás métricas deben poder expresarse en términos que
el cliente pueda entender.
Algunos de los parámetros que suele utilizar la Gestión de la Disponibilidad y

que debe poner a disposición del cliente en los informes de disponibilidad
correspondientes incluyen:
• Tiempo Medio de Parada (Downtime o (MTTR): que es el tiempo

promedio de duración de una interrupción del servicio, e incluye el
tiempo de detección, respuesta y resolución.
• Tiempo Medio entre Fallos (Uptime o MTBF): es el tiempo medio
durante el cual el servicio está disponible sin interrupciones.
• Tiempo Medio entre Incidencias (MTBSI): es el tiempo medio
transcurrido entre incidentes, que es igual a la suma del Tiempo Medio
de Parada y el Tiempo Medio entre Fallos. El Tiempo Medio entre
Incidentes es una medida de la fiabilidad del sistema.
Página 58
3. Procesos / Gestión de la Disponibilidad / Métodos y Técnicas
Aunque llevamos hablando ya un buen rato de disponibilidad, aún no hemos

aportado un método para cuantificarla.
Es habitual definir la disponibilidad en tanto por ciento de la siguiente manera:
donde:
AST se corresponde con el tiempo acordado de servicio, DT es el tiempo de

interrupción del servicio durante las franjas horarias de disponibilidad
acordadas.
Por ejemplo, si el servicio es 24/7 y en el último mes el sistema ha estado caído

durante 4 horas por tareas de mantenimiento la disponibilidad real del servicio
fue:
La Gestión de la Disponibilidad tiene a su disposición un buen número de

métodos y técnicas que le permiten determinar qué factores intervienen en la
disponibilidad del servicio y que le permiten consecuentemente prever qué tipo
de recursos se deben asignar para las labores de prevención, mantenimiento y
recuperación, así como elaborar planes de mejora a partir de dichos análisis.
Entre dichas técnicas se cuentan:
Análisis del Impacto de Fallo de Componentes (CFIA)
El CFIA (siglas de Component Failure Impact Analysis) es un método mediante

el cual se identifica el impacto que tiene en la disponibilidad de los servicios TI
el fallo de cada elemento de configuración involucrado. Es evidente que este
método requiere una CMDB correctamente actualizada.
Página 59
Análisis del Árbol de Fallos (FTA)
El FTA (siglas de Failure Tree Analysis) tiene como objetivo estudiar cómo se
"propagan" los fallos a través de la infraestructura TI para comprender mejor su
impacto en la disponibilidad del servicio.
Método de Gestión y Análisis de Riesgos de la CCTA (CRAMM)
El CRAMM (siglas de CCTA Risk Analysis and Management Method) tiene

como objetivo identificar los riesgos y vulnerabilidades a los que está expuesta
la infraestructura TI, con el objetivo de adoptar contramedidas que los reduzcan
o que permitan recuperar rápidamente el servicio en caso de interrupción del
mismo.
Análisis de Interrupción del Servicio (SOA)
El SOA (siglas de Service Outage Analysis) es una técnica cuyo objetivo

consiste en analizar las causas de los fallos detectados y proponer soluciones
a los mismos.
Se diferencia de los anteriores métodos en que realiza el análisis desde el

punto de vista del cliente, haciendo especial énfasis en aspectos no
exclusivamente técnicos ligados directamente a la infraestructura TI.
Página 60
3. Procesos / Gestión de la Disponibilidad / Interfaces
Las actividades de Gestión de la Disponibilidad pueden tener como

disparadores, entre otras cosas:
• Necesidades del cliente nuevas o modificadas
• Nuevos objetivos en los acuerdos
• Fallos del servicio
• Eventos y alertas de disponibilidad
Relaciones de Gestión de la Disponibilidad con otras funciones y procesos:
• Colabora con la Gestión de Incidencias y Problemas en la resolución de

incidencias y problemas de disponibilidad
• Otorga capacidad de recuperación y capacidad de reserva para la

Gestión de la Capacidad
• Proporciona a la Gestión de la Continuidad del Servicio de TI

información sobre la evaluación del impacto y los riesgos para el
negocio, y sobre mecanismos de restauración
• Colabora con Gestión del Nivel de Servicio en la determinación de

objetivos de disponibilidad y estudia y presenta propuestas de mejora en
caso de fallos de servicios o componentes
Entradas:
• Información de negocio, como estrategias de organización, planes

financieros e información sobre requisitos actuales y futuros de servicios
de TI
• Análisis de riesgo, de impacto sobre el Negocio y estudios de funciones

vitales del proceso
• Información de servicio procedente de la Cartera de Servicios, el

Catálogo y el proceso SLM
Página 61
• Calendarios de cambios y programaciones de entregas, procedentes de

Gestión de Cambios y de Entregas
• Objetivos particulares de servicio
• Información de indisponibilidades y fallos
Salidas:
• Sistema de Información para la Gestión de la Disponibilidad (AMIS)
• Plan de disponibilidad
• Criterios de diseño para disponibilidad y recuperación
• Informes sobre disponibilidad, fiabilidad y capacidad e mantenimiento de

servicios
• Registro de riesgos actualizado
• Monitorización, gestión y reporte
• Programación de pruebas de gestión de la disponibilidad
• Programación de mantenimientos preventivos planificados
• Parada de servicio prevista (PSO)
Página 62
3. Procesos / Gestión de la Disponibilidad / Métricas
• Porcentaje de reducción de la falta de disponibilidad de servicios y

componentes
• Porcentaje de aumento de la fiabilidad de servicios y componentes
• Porcentaje de mejora de la disponibilidad del servicio, medida de

extremo a extremo
• Porcentaje de reducción de los costes de la indisponibilidad
• Porcentaje de mejora de la satisfacción de los clientes
Página 63
3. Procesos / Gestión de la Disponibilidad / Implementación
Factores críticos de éxito:
• Gestionar la disponibilidad y la fiabilidad de los servicios de TI
• Disponibilidad de la infraestructura de TI (según lo estipulado en los

SLA) con un óptimo nivel de coste
• Cumplimiento de las necesidades de negocio en cuanto a acceso a los

servicios de TI
Riesgos:
• Falta de compromiso del negocio con el proceso de Gestión de la

Disponibilidad
• Falta de información adecuada sobre planes y estrategias para el futuro
• Falta de fondos y recursos
• Énfasis excesivo en informes que requieren mucho trabajo
Página 64
3. Procesos / Gestión de la Continuidad de los Servicios de TI
La Gestión de la Continuidad del Servicio se preocupa de impedir que una

imprevista y grave interrupción de los servicios TI, debido a desastres naturales
u otras fuerzas de causa mayor, tenga consecuencias catastróficas para el
negocio.
La estrategia de la Gestión de la Continuidad del Servicio (ITSCM) debe

combinar equilibradamente procedimientos:
• Proactivos: que buscan impedir o minimizar las consecuencias de una

grave interrupción del servicio.
• Reactivos: cuyo propósito es reanudar el servicio tan pronto como sea
posible (y recomendable) tras el desastre.
La ITSCM requiere una implicación especial de los agentes involucrados pues

sus beneficios sólo se perciben a largo plazo, es costosa y carece de
rentabilidad directa. Implementar la ITSCM es como contratar un seguro
médico: cuesta dinero, parece inútil mientras uno está sano y desearíamos
nunca tener que utilizarlo, pero tarde o temprano nos alegramos de haber sido
previsores.
Página 65
3. Procesos / Gestión Continuidad Servicios TI / Objetivos
Los objetivos principales de la Gestión de la Continuidad de los Servicios TI

(ITSCM) se resumen en:
• Garantizar la pronta recuperación de los servicios (críticos) TI tras un

desastre.
• Establecer políticas y procedimientos que eviten, en la medida de lo
posible, las perniciosas consecuencias de un desastre o causa de fuerza
mayor.
Aunque, a priori, las políticas proactivas que prevean y limiten los efectos de un
desastre sobre los servicios TI son preferibles a las exclusivamente reactivas,
es importante valorar los costes relativos y la incidencia real en la continuidad
del negocio para decantarse por una de ellas o por una sabia combinación de
ambas.
Una correcta ITSCM debe formar parte integrante de la Gestión de Continuidad

del Negocio (BCM) y debe estar a su servicio. Los servicios TI no son sino una
parte, aunque a menudo muy importante, del negocio en su conjunto y no tiene
mayor sentido que, por ejemplo, un sistema de pedidos online siga funcionando
a la perfección tras un desastre si nos resulta imposible suministrar la
mercancía a nuestros clientes.
Es importante diferenciar entre desastres "de toda la vida", tales como

incendios, inundaciones, etcétera, y desastres "puramente informáticos", tales
como los producidos por ataques distribuidos de denegación de servicio
(DDOS), virus informáticos, etcétera. Aunque es responsabilidad de la ITSCM
prever los riesgos asociados en ambos casos y restaurar el servicio TI con
prontitud, es evidente que recae sobre la ITSCM una responsabilidad especial
en el último caso pues:
• Sólo afectan directamente a los servicios TI pero paralizan a toda la

organización.
• Son más previsibles y más habituales.
• La percepción del cliente es diferente: los desastres naturales son más
asumibles y no se asocian a actitudes negligentes, aunque esto no sea
siempre cierto.
Página 66
3. Procesos / Gestión Continuidad Servicios TI / Actividades
Las principales actividades de la Gestión de la Continuidad de los Servicios

TI se resumen en:
• Establecer las políticas y alcance de la ITSCM.

• Evaluar el impacto en el negocio de una interrupción de los servicios TI.
• Analizar y prever los riesgos a los que esta expuesto la infraestructura
TI.
• Establecer las estrategias de continuidad del servicio TI.
• Adoptar medidas proactivas de prevención del riesgo.
• Desarrollar los planes de contingencia.
• Poner a prueba dichos planes.
• Formar al personal sobre los procedimientos necesarios para la pronta
recuperación del servicio.
• Revisar periódicamente los planes para adaptarlos a las necesidades
reales del negocio.
Página 67
3. Procesos / Gestión Continuidad Servicios TI / Política y Alcance
El primer paso necesario para desarrollar una Gestión de la Continuidad del

Servicio coherente es establecer claramente sus objetivos generales, su
alcance y el compromiso de la organización TI: su política.
La gestión de la empresa debe demostrar su implicación con el proceso desde

un primer momento pues la implantación de la ITSCM puede resultar compleja
y costosa sin la contrapartida de un retorno obvio a la inversión.
Es imprescindible establecer el alcance de la ITSCM en función de:
• Los planes generales de Continuidad del Negocio.

• Los servicios TI estratégicos.
• Los estándares de calidad adoptados.
• El histórico de interrupciones graves de los servicios TI.
• Las expectativas de negocio.
• La disponibilidad de recursos.
La Gestión de la Continuidad del Servicio está abocada al fracaso sino se

destina una cantidad de recursos suficientes, tanto en el plano humano como
de equipamiento (software y hardware). Su dimensión depende de su alcance y
sería absurdo y contraproducente instaurar una política demasiado ambiciosa
que no dispusiera de los recursos correspondientes.
Una importante parte del esfuerzo debe destinarse a la formación del personal.
Éste debe interiorizar su papel en momentos de crisis y conocer perfectamente
las tareas que se espera desempeñe: una emergencia no es el mejor momento
para estudiar documentación y manuales.
Página 68
3. Procesos / Gestión Continuidad Servicios TI / Análisis de Impacto
Una correcta Gestión de la Continuidad del Servicio requiere en primer lugar

determinar el impacto que una interrupción de los servicios TI pueden tener en
el negocio.
En la actualidad casi todas las empresas, grandes y pequeñas, dependen en

mayor o menor medida de los servicios informáticos, por lo que cabe esperar
que un "apagón" de los servicios TI afecte a prácticamente todos los aspectos
del negocio. Sin embargo, es evidente que hay servicios TI estratégicos de
cuya continuidad puede depender la supervivencia del negocio y otros que
"simplemente" aumentan la productividad de la fuerza comercial y de trabajo.
Cuanto mayor sea el impacto asociado a la interrupción de un determinado

servicio mayor habrá de ser el esfuerzo realizado en actividades de prevención.
En aquellos casos en que la "solución puede esperar" se puede optar
exclusivamente por planes de recuperación.
Los servicios TI han de ser analizados por la ITSCM en función de diversos

parámetros:
• Consecuencias de la interrupción del servicio en el negocio:

o Pérdida de rentabilidad.
o Pérdida de cuota de mercado.
o Mala imagen de marca.
o Otros efectos secundarios.
• Cuánto se puede esperar a restaurar el servicio sin que tenga un alto
impacto en los procesos de negocio.
• Compromisos adquiridos a través de los SLAs.
Dependiendo de estos factores se buscará un balance entre las actividades de

prevención y recuperación teniendo en cuenta sus respectivos costes
financieros.
Página 69
3. Procesos / Gest. Cont. Serv. TI / Evaluación de Riesgos
Sin conocer cuáles son los riesgos reales a los que se enfrenta la
infraestructura TI es imposible realizar una política de prevención y
recuperación ante desastre mínimamente eficaz.
La Gestión de la Continuidad del Servicio debe enumerar y evaluar,

dependiendo de su probabilidad e impacto, los diferentes riesgos factores de
riesgo. Para ello la ITSCM debe:
• Conocer en profundidad la infraestructura TI y cuales son los elementos

de configuración (CIs) involucrados en la prestación de cada servicio,
especialmente los servicios TI críticos y estratégicos.
• Analizar las posibles amenazas y estimar su probabilidad.
• Detectar los puntos más vulnerables de la infraestructura TI.
Gracias a los resultados de este detallado análisis se dispondrá de información

suficiente para proponer diferentes medidas de prevención y recuperación que
se adapten a las necesidades reales del negocio.
La prevención frente a riesgos genéricos y poco probables puede ser muy cara
y no estar siempre justificada, sin embargo, las medidas preventivas o de
recuperación frente a riesgos específicos pueden resultar sencillas, de rápida
implementación y relativamente baratas.
Por ejemplo, si el riesgo de perdida de alimentación eléctrica es elevado

debido, por ejemplo, a la localización geográfica se puede optar por
deslocalizar ciertos servicios TI a través de ISPs que dispongan de sistemas de
generadores redundantes o adquirir generadores que proporcionen la energía
mínima necesaria para alimentar los CIs de los que dependen los servicios más
críticos, etcétera.
Página 70
3. Procesos / Gest. Cont. Serv. TI / Estrategias de Continuidad
La continuidad de los servicios TI puede conseguirse bien mediante medidas

preventivas, que eviten la interrupción de los servicios, o medidas reactivas,
que recuperen unos niveles aceptables de servicio en el menor tiempo posible.
Es responsabilidad de la Gestión de la Continuidad del Servicio diseñar

actividades de prevención y recuperación que ofrezcan las garantías
necesarias a unos costes razonables.
Actividades preventivas
Las medidas preventivas requieren un detallado análisis previo de riesgos y

vulnerabilidades. Algunos de ellos serán de carácter general: incendios,
desastres naturales, etcétera, mientras que otros tendrán un carácter
estrictamente informático: fallo de sistemas de almacenamiento, ataques de
hackers, virus informáticos, etcétera.
La adecuada prevención de los riesgos de carácter general dependen de una

estrecha colaboración con la Gestión de la Continuidad del Negocio (BCM) y
requieren medidas que implican a la infraestructura "física" de la organización.
La prevención de riesgos y vulnerabilidades "lógicas" o de hardware requieren

especial atención de la ITSCM. En este aspecto es esencial la estrecha
colaboración con la Gestión de la Seguridad.
Los sistemas de protección habituales son los de "Fortaleza" que ofrecen

protección perimetral a la infraestructura TI. Aunque imprescindibles no se
hallan exentos de sus propias dificultades pues aumentan la complejidad de la
infraestructura TI y pueden ser a su vez fuente de nuevas vulnerabilidades.
Actividades de recuperación
Tarde o temprano, por muy eficientes que seamos en nuestras actividades de

prevención, será necesario poner en marcha procedimientos de recuperación.
En líneas generales existen tres opciones de recuperación del servicio:
• Cold standby: que requiere un emplazamiento alternativo en el que

podamos reproducir en pocos días nuestro entorno de producción y
Página 71
servicio. Esta opción es la adecuada si los planes de recuperación

estiman que la organización puede mantener sus niveles de servicio
durante este periodo sin el apoyo de la infraestructura TI.
• Warm standby: que requiere un emplazamiento alternativo con sistemas
activos diseñados para recuperar los servicios críticos en un plazo de
entre 24 y 72 horas.
• Hot standby: que requiere un emplazamiento alternativo con una
replicación continua de datos y con todos los sistemas activos
preparados para la inmediata sustitución de la estructura de producción.
Ésta es evidentemente la opción mas costosa y debe emplearse sólo en
el caso de que la interrupción del servicio TI tuviera inmediatas
repercusiones comerciales.
Por supuesto, existe otra alternativa que consiste en hacer "poco o nada" y
esperar que las aguas vuelvan naturalmente a su cauce: una alternativa poco
recomendable para alguien que esté hojeando este curso sobreITIL y del que
suponemos que los servicios TI jugarán un papel importante en su organización
Página 72
3. Procesos / Gest. Cont. Serv. TI / Organización y Planificación
Una vez determinado el alcance de la ITSCM, analizados los riesgos y

vulnerabilidades y definidas unas estrategias de prevención y recuperación es
necesario asignar y organizar los recursos necesarios. Con ese objetivo la
Gestión de la Continuidad del Servicio debe elaborar una serie de
documentos entre los que se incluyen:
• Plan de prevención de riesgos.

• Plan de gestión de emergencias.
• Plan de recuperación.
Plan de prevención de riesgos
Cuyo objetivo principal es el de evitar o minimizar el impacto de un desastre en

la infraestructura TI.
Entre las medidas habituales se encuentran:
• Almacenamiento de datos distribuidos.

• Sistemas de alimentación eléctrica de soporte.
• Políticas de back-ups.
• Duplicación de sistemas críticos.
• Sistemas de seguridad pasivos.
Plan de gestión de emergencias
Las crisis suelen provocar "reacciones de pánico" que pueden ser

contraproducentes y a veces incluso más dañinas que las provocadas por el
incidente que las causó. Por ello es imprescindible que en caso de situación de
emergencia estén claramente determinadas las responsabilidades y funciones
del personal así como los protocolos de acción correspondientes.
En principio los planes de gestión de emergencias deben tomar en cuenta

aspectos tales como:
• Evaluación del impacto de la contingencia en la infraestructura TI.

• Asignación de funciones de emergencia al personal del servicio TI.
• Comunicación a los usuarios y clientes de una grave interrupción o
degradación del servicio.
Página 73
• Procedimientos de contacto y colaboración con los proveedores

involucrados.
• Protocolos para la puesta en marcha del plan de recuperación
correspondiente.
Plan de recuperación
Cuando la interrupción del servicio es inevitable, llega el momento de poner en

marcha los procedimientos de recuperación.
El plan de recuperación debe incluir todo lo necesario para:
• Reorganizar al personal involucrado.

• Reestablecer los sistemas de hardware y software necesarios.
• Recuperar los datos y reiniciar el servicio TI.
Los procedimientos de recuperación pueden depender de la importancia de la

contingencia y de la opción de recuperación asociada ("cold o hot stand-by"),
pero en general involucran:
• Asignación de personal y recursos.

• Instalaciones y hardware alternativos.
• Planes de seguridad que garanticen la integridad de los datos.
• Procedimientos de recuperación de datos.
• Contratos de colaboración con otras organizaciones.
• Protocolos de comunicación con los clientes.
Cuando se pone en marcha un plan de recuperación no hay espacio para la

improvisación, cualquier decisión puede tener graves consecuencias tanto en la
percepción que de nosotros tengan nuestros clientes como en los costes
asociados al proceso.
Aunque pueda resultar paradójico, un "desastre" puede ser una buena

oportunidad para demostrar a nuestros clientes la solidez de nuestra
organización TI y por tanto, incrementar la confianza que tiene depositada en
nosotros. Ya conocen el dicho: "No hay mal que por bien no venga".
Página 74
3. Procesos / Gest. Cont. Serv.TI / Supervisión de la Continuidad
Una vez establecidas las políticas, estrategias y planes de prevención y

recuperación, es indispensable que éstos no queden en papel mojado y que la
organización TI esté preparada para su correcta implementación.
Ello depende de dos factores clave: la correcta formación del personal

involucrado y la continua monitorización y evaluación de los planes para su
adecuación a las necesidades reales del negocio.
Formación
Es inútil disponer de unos completos planes de prevención y recuperación si

las personas que eventualmente deben llevarlos a cabo no están familiarizadas
con los mismos.
Es indispensable que la ITSCM:
• Dé a conocer al conjunto de la organización TI los planes de prevención

y recuperación.
• Ofrezca formación específica sobre los diferentes procedimientos de
prevención y recuperación.
• Realice periódicamente simulacros para diferentes tipos de desastres
con el fin de asegurar la capacitación del personal involucrado.
• Facilite el acceso permanente a toda la información necesaria, por
ejemplo, a través de la Intranet o portal B2E de la empresa.
Actualización y auditorías
Tanto las políticas, estrategias y planes han de ser actualizados

periódicamente para asegurar que responden a los requisitos de la
organización en su conjunto.
Cualquier cambio en la infraestructura TI o en los planes de negocio puede

requerir de una profunda revisión de los planes en vigor y una consecuente
auditoría que evalúe su adecuación a la nueva situación.
En ocasiones en que el dinamismo del negocio y los servicios TI lo haga

recomendable, estos procesos de actualización y auditoría pueden
establecerse de forma periódica.
Página 75
La Gestión de Cambios juega un papel esencial a la hora de asegurar que los

planes de recuperación y prevención están actualizados, manteniendo
informada a la ITSCM de los cambios realizados o previstos.
Página 76
3. Procesos / Gestión Continuidad Servicios TI / Interfaces
Disparadores de ITSCM:
• Necesidades del negocio nuevas o modificadas
• Objetivos particular nuevos o modificados en los acuerdos
• Aparición de una incidencia muy crítica
• Actividades periódicas, como análisis de impacto sobre el negocio o

análisis del riesgo
El proceso tiene interfaces con:
• Gestión de Incidencias y Problemas: las incidencias y los problemas

pueden evolucionar hasta convertirse en incidencias muy críticas y
desastres
• Gestión de la Disponibilidad: realizando análisis de riesgos e

implementando las medidas de respuesta ante riesgos
• Gestión de Niveles de Servicio: los requisitos de recuperación están

recogidos y documentados en los SLA
Entradas:
• Información de negocio (planes y estrategias)
• Información de TI
• Información financiera
• Planes y estrategias de BCM
• Información de cambios
• CMS
• Programación de pruebas
Salidas:
Página 77
• Políticas y estrategias de ITSCM revisadas
• Ejercicios e informes de Análisis de Impacto sobre el Negocio
• Revisiones e informes de Análisis y gestión de riesgos
• Planes de continuidad
• Escenarios de pruebas
• Revisiones e informes de pruebas
Página 78
3. Procesos / Gestión Continuidad Servicios TI / Métricas
• Resultado de las auditorías periódicas de los planes de ITSCM
• Nivel de acuerdo y documentación de los objetivos de recuperación del

servicio en el SLA
• Resultados de las pruebas de los planes de ITSCM
• Revisión periódica de los planes de ITSCM
Página 79
3. Procesos / Gestión Continuidad Servicios TI / Implementación
Factores de éxito:
Los servicios se pueden suministrar y restaurar de acuerdo con los objetivos

del cliente
Toda la organización es consciente de los planes de ITSCM y BCM
Riesgos:
Falta de compromiso del negocio y la dirección
Falta de recursos y presupuesto
Importancia excesiva de la tecnología sobre los servicios y las necesidades de

los clientes
Excesivo aislamiento del análisis y la gestión de riesgos, que no se realizan en

colaboración con la Gestión de la Disponibilidad y la Gestión de la Seguridad
Página 80
3. Procesos / Gestión de la Seguridad de la Información
La Gestión de la Seguridad de la Información se remonta al albor de los

tiempos. La criptología o la ciencia de la confidencialidad de la información
existe desde el inicio de nuestra civilización y ha ocupado algunas de las
mentes matemáticas más brillantes de la historia, especialmente (y
desafortunadamente) en tiempos de guerra.
Sin embargo, desde el advenimiento de las ubicuas redes de comunicación y,

en especial, de Internet los problemas asociados a la seguridad de la
información se han agravado considerablemente y nos afectan a todos. Que
levante la mano el que no haya sido victima de algún virus informático en su
ordenador, del spam (ya sea por correo electrónico o teléfono) por una
deficiente protección de sus datos personales o, aún peor, del robo del número
de su tarjeta de crédito.
La información es consustancial al negocio y su correcta gestión debe

apoyarse en tres pilares fundamentales:
• Confidencialidad: la información debe ser sólo accesible a sus

destinatarios predeterminados.
• Integridad: la información debe ser correcta y completa.
• Disponibilidad: debemos de tener acceso a la información cuando la
necesitamos.
La Gestión de la Seguridad debe, por tanto, velar por que la información sea
correcta y completa, esté siempre a disposición del negocio y sea utilizada sólo
por aquellos que tienen autorización para hacerlo.
Página 81
3. Procesos / Gestión de la Seguridad de la Información / Objetivos
Los principales objetivos de la Gestión de la Seguridad se resumen en:
• 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)
La Gestión de la Seguridad debe conocer en profundidad el negocio y los

servicios que presta la organización TI para establecer protocolos de seguridad
que aseguren que la información esté accesible cuando es necesaria para
aquellos que tengan autorización para utilizarla.
Una vez comprendidos cuáles son los requisitos de seguridad del negocio, la
Gestión de la Seguridad debe supervisar que estos se hallen
convenientemente plasmados en los SLAs correspondientes para garantizar su
cumplimiento.
La Gestión de la Seguridad debe asimismo tener en cuenta los riesgos

generales a los que está expuesta la infraestructura TI, y que no
necesariamente tienen por qué figurar en un SLA, para asegurar, en la medida
de lo posible, que no representan un peligro para la continuidad del servicio.
Es importante que la Gestión de la Seguridad sea proactiva y evalúe a priori los

riesgos de seguridad que pueden suponer los cambios realizados en la
infraestructura, nuevas líneas de negocio, etcétera
Página 82
3. Procesos / Gestión Seguridad Información / Actividades
La Gestión de la Seguridad está estrechamente relacionada con

prácticamente todos los otros procesos TI y necesita para su éxito la
colaboración de toda la organización.
Para que esa colaboración sea eficaz, es necesario que la Gestión de la

Seguridad:
• Establezca una clara y definida política de seguridad que sirva de guía a

todos los otros procesos.
• Elabore un Plan de Seguridad que incluya los niveles de seguridad
adecuados tanto en los servicios prestados a los clientes como en los
acuerdos de servicio firmados con proveedores internos y externos.
• Implemente el Plan de Seguridad.
• Monitorice y evalúe el cumplimiento de dicho plan.
• Supervise proactivamente los niveles de seguridad analizando
tendencias, nuevos riesgos y vulnerabilidades.
• Realice periódicamente auditorías de seguridad.
Página 83
3. Procesos / Gest. Seg. Información / Política y Plan de Seguridad
Es imprescindible disponer de un marco general en el que encuadrar todos los

subprocesos asociados a laGestión de la Seguridad. Su complejidad e
intricadas interrelaciones necesitan de una política global clara en donde se
fijen aspectos tales como los objetivos, responsabilidades y recursos.
En particular la Política de Seguridad debe determinar:
• La relación con la política general del negocio.

• La coordinación con los otros procesos TI.
• Los protocolos de acceso a la información.
• Los procedimientos de análisis de riesgos.
• Los programas de formación.
• El nivel de monitorización de la seguridad.
• Qué informes deben ser emitidos periódicamente.
• El alcance del Plan de Seguridad.
• La estructura y responsables del proceso de Gestión de la Seguridad.
• Los procesos y procedimientos empleados.
• Los responsables de cada subproceso.
• Los auditores externos e internos de seguridad.
• Los recursos necesarios: software, hardware y personal.
Plan de Seguridad
El objetivo del Plan de Seguridad es fijar los niveles de seguridad que han de
ser incluidos como parte de losSLAs, OLAs y UCs.
Este plan ha de ser desarrollado en colaboración con la Gestión del Nivel de

Servicio, que es la responsable en última instancia tanto de la calidad del
servicio prestado a los clientes como la del servicio recibido por la propia
organización TI y los proveedores externos.
El Plan de Seguridad debe ser diseñado con el fin de ofrecer un mejor y más
seguro servicio al cliente y nunca como un obstáculo para el desarrollo de sus
actividades de negocio.
Siempre que sea posible, deben definirse métricas e indicadores clave que
permitan evaluar los niveles de seguridad acordados.
Página 84
Un aspecto esencial a tener en cuenta es el establecimiento de unos protocolos

de seguridad coherentes en todas las fases del servicio y para todos los
estamentos implicados. "Una cadena es tan resistente como el más débil de
sus eslabones", por lo que carece de sentido, por ejemplo, establecer una
estrictas normas de acceso si una aplicación tiene vulnerabilidades frente a
inyecciones de SQL. Quizá con ello podamos engañar a algún cliente durante
algún tiempo ofreciendo la imagen de "fortaleza", pero esto valdrá de poco si
alguien descubre que la "puerta de atrás está abierta".
Página 85
3. Procesos / Gest. Seg. Inf. / Aplicación de las Medidas de

Seguridad
Por muy buena que sea la planificación de la seguridad resultará inútil si las
medidas previstas no se ponen en práctica.
Es responsabilidad de la Gestión de Seguridad coordinar la implementación

de los protocolos y medidas de seguridad establecidas en la Política y el Plan
de Seguridad.
En primer lugar la Gestión de la Seguridad debe verificar que:
• El personal conoce y acepta las medidas de seguridad establecidas así

como sus responsabilidades al respecto.
• Los empleados firmen los acuerdos de confidencialidad
correspondientes a su cargo y responsabilidad.
• Se imparte la formación pertinente.
Es también responsabilidad directa de la Gestión de la Seguridad:
• Asignar los recursos necesarios.

• Generar la documentación de referencia necesaria.
• Colaborar con el Centro de Servicios y la Gestión de Incidentes en el
tratamiento y resolución de incidentes relacionados con la seguridad.
• Instalar y mantener las herramientas de hardware y software necesarias
para garantizar la seguridad.
• Colaborar con la Gestión de Cambios y la de Entregas y Despliegues
para asegurar que no se introducen nuevas vulnerabilidades en los
sistemas en producción o entornos de pruebas.
• Proponer RFCs a la Gestión de Cambios que aumenten los niveles de
seguridad.
• Colaborar con la Gestión de la Continuidad del Servicio para asegurar
que no peligra la integridad y confidencialidad de los datos en caso de
desastre.
• Establecer las políticas y protocolos de acceso a la información.
• Monitorizar las redes y servicios en red para detectar intrusiones y
ataques.
Página 86
Es necesario que la gestión de la empresa reconozca la autoridad de la

Gestión de la Seguridad respecto a todas estas cuestiones y que incluso
permita que ésta proponga medidas disciplinarias vinculantes cuando los
empleados u otro personal relacionado con la seguridad de los servicios
incumplan con sus responsabilidades.
Página 87
3. Procesos / Gest. Seg. Información / Evaluación y mantenimiento
Evaluación
No es posible mejorar aquello que no se conoce, por lo que resulta

indispensable evaluar el cumplimiento de las medidas de seguridad, sus
resultados y el cumplimiento de los SLAs.
Aunque no es imprescindible, es recomendable que estas evaluaciones se

complementen con auditorías de seguridad externas y/o internas realizadas por
personal independiente de la Gestión de la Seguridad.
Estas evaluaciones/auditorias deben valorar el rendimiento del proceso y

proponer mejoras que se plasmarán en RFCs que habrán de ser evaluados por
la Gestión de Cambios.
Independientemente de estas evaluaciones de carácter periódico, se deberán

generar informes específicos cada vez que ocurra algún incidente grave
relacionado con la seguridad. De nuevo, si la Gestión de la Seguridad lo
considera oportuno, estos informes se acompañaran de las RFCs
correspondientes.
Mantenimiento
La Gestión de la Seguridad es un proceso continuo y se han de mantener al

día el Plan de Seguridad y las secciones de seguridad de los SLAs.
Los cambios en el Plan de Seguridad y los SLAs pueden ser resultado de la

evaluación arriba citada o de cambios implementados en la infraestructura o
servicios TI.
No hay nada más peligroso que la falsa sensación de seguridad que ofrecen
medidas de seguridad obsoletas.
Es asimismo importante que la Gestión de la Seguridad esté al día en lo que

respecta a nuevos riesgos y vulnerabilidades frente a virus, spyware, ataques
de denegación de servicio, etcétera, y que adopte las medidas necesarias de
actualización de equipos de hardware y software, sin olvidar el apartado de
formación: el factor humano es normalmente el eslabón más débil de la
cadena.
Página 88
3. Procesos / Gestión Seguridad Información / Interfaces
La Gestión de la Seguridad tiene interfaces con:
Gestión de Incidencias y Problemas: facilita el proceso de toma de

decisiones y la corrección de incidencias y problemas de seguridad.
ITSCM: revisión del impacto y los riesgos para la empresa, así como en la
provisión de mecanismos de recuperación.
Gestión de Niveles de Servicio: facilita la definición de requisitos y

responsabilidades de seguridad.
Gestión de Cambios: ayuda a determinar el posible impacto de los cambios

sobre la seguridad.
Entradas:
Información de negocio (planes, estrategias)

Políticas y directrices de gobierno corporativo y de seguridad del negocio
Información de servicios procedente del proceso de SLM
Procesos e informes de análisis de riesgos
Detalles de eventos e incumplimientos de seguridad
Información de cambios procedente del proceso de Gestión de Cambios
CMS
Detalles del acceso de asociados y proveedores de servicios
Salidas:
Política general de Gestión de la Seguridad de la Información

ISMS
Procesos e informes de evaluación de riesgos de seguridad, revisados
Controles, auditorías e informes de seguridad
Programación de pruebas de seguridad
Página 89
3. Procesos / Gestión Seguridad Información / Métricas

Porcentaje de disminución de incumplimientos de seguridad
Porcentaje de disminución del impacto de las incidencias e incumplimientos de
seguridad
Aumento de la concienciación sobre los procedimientos de seguridad en la
organización
Página 90
3. Procesos / Gestión Seguridad Información / Implementación
Los factores de éxito dependen en gran medida de que:
La empresa esté protegida contra violaciones de seguridad
La determinación de una política bien definida y adaptada a las necesidades de

la empresa
Existan procedimientos de seguridad justificados y apoyados por la dirección

senior
La empresa promueva y explique los requisitos de seguridad
Exista un mecanismo de mejora
Riesgos:
Más peligro de violaciones éticas y de privacidad en los sistemas de

información
Peligro de hackers
Falta de compromiso de la empresa y la dirección por no tener información

adecuada
Importancia excesiva de los aspectos técnicos sobre los servicios y las

necesidades de los clientes
Página 91
3. Procesos / Gestión de Proveedores
La Gestión de Proveedores se ocupa de gestionar la relación con los

suministradores de servicios de los que depende la organización TI. Su
principal objetivo es alcanzar la mayor calidad a un precio adecuado.
Con este fin, y teniendo siempre muy presentes las pautas marcadas desde la
Estrategia del Servicio, la Gestión de Proveedores se encarga de definir una
estrategia de suministradores según la cual orientar su labor, que abarca:
• Seleccionar nuevos suministradores para las necesidades que vayan

surgiendo en el servicio.
• Definir y negociar los nuevos contratos, garantizando que queda
constancia de los acuerdos financieros y de calidad alcanzados.
• Gestionar la relación con los proveedores, lo que incluye velar por el
cumplimiento de los contratos o actualizarlos si éstos pierden vigencia.
• Renovar y terminar contratos.
Por otro lado, también es la encargada de que toda la información relacionada

con los proveedores y los servicios que prestan (tipo, coste, contratos) esté
disponible y permanentemente actualizada.
Página 92
3. Procesos / Gestión de Proveedores / Objetivos
La ventaja principal de una adecuada Gestión de Proveedores radica en que

la organización TI obtiene mayores beneficios al contratar a aquellos
suministradores que brindan el mejor servicio al menor coste.
Los principales objetivos de la Gestión de Proveedores consisten en:
• Aportar el máximo valor añadido al menor coste en aquellos servicios

que prestan los proveedores.
• Asegurar que los contratos y acuerdos con proveedores están alineados
con la estrategia y necesidades de negocio de la organización.
• Gestionar la relación con los proveedores.
• Gestionar el rendimiento de los proveedores.
• Negociar los contratos con los proveedores y gestionarlos a lo largo de
su ciclo de vida.
• Mantener una política de proveedores y una Base de Datos de
Proveedores y Contratos (SCD).
Página 93
3. Procesos / Gestión de Proveedores / Conceptos básicos
Proveedores, clientes y usuarios
Cliente: es la empresa u organismo que contrata los servicios TI ofrecidos.
Usuarios: las personas que utilizan el servicio.
Proveedor: es la empresa u organismo que proporciona los servicios

solicitados por el cliente.
Base de Datos de Proveedores y Contratos (SCD)
La Base de Datos de Proveedores y Contratos (SCD) es un repositorio

documental donde se archiva toda la información relacionada con los
proveedores y los servicios que prestan, incluyendo por supuesto copias de los
contratos (UCs) en vigor.
Es aconsejable que la Base de Datos de Proveedores y Contratos esté

integrada en el Sistema de Gestión de la Configuración (CMS) y en el Sistema
de Gestión del Conocimiento del Servicio (SKMS).
Página 94
3. Procesos / Gestión de Proveedores / Actividades
La Gestión de Proveedores se ocupa de definir y gestionar:
• Los requisitos de contratación que se van a exigir a los proveedores.

• Los procesos de evaluación y selección de proveedores.
• La clasificación y documentación de la relación con los proveedores.
• Gestión del Rendimiento de los proveedores
• Renovación o terminación.
Página 95
3. Procesos / Gestión de Proveedores / Requisitos de contratación
La primera tarea que la Gestión de Proveedores debe llevar a cabo es

analizar las estrategias generales de la organización y los servicios que se
prestan para definir las necesidades de contratación.
Han de tenerse en cuenta, también, los informes económicos proporcionados

por la Gestión Financiera, los niveles de calidad acordados con los clientes
desde la Gestión de Niveles de Servicio, y la previsión de la capacidad
necesaria para desplegar el servicio que haya definido la Gestión de la
Demanda.
Por último, se deben estudiar a fondo en el Catálogo de Servicios las

condiciones del servicio a prestar y el papel que desempeñarán los
proveedores en el proceso.
Una vez recogidos y analizados estos inputs, la Gestión de Proveedores debe

preparar:
• Requisitos que se van a exigir a los proveedores.

• Caso de Negocio inicial sobre el que trabajar durante las negociaciones
con los proveedores.
Garantizando en todo momento que tanto los requisitos como las premisas
básicas de negociación están alineados con la estrategia general de la
organización TI.
Página 96
3. Procesos / Gest.Prov. / Evaluación y Selección de proveedores
A la hora de elegir un nuevo suministrador han de tenerse en cuenta:
• Su adecuación a los requisitos previamente definidos.

• Referencias de otros competidores.
• Disponibilidad y capacidad.
• Aspectos financieros.
Una vez elegido el proveedor, se han de negociar los términos del servicio. El
resultado debe quedar reflejado en el Contrato de Provisión del Servicio (UC),
un documento legal que atestigua la relación entre la organización TI y el
suministrador.
Es importante que en el UC queden reflejadas las metas y responsabilidades

del proveedor de cara al cumplimiento de los SLAs.
Página 97
3. Procesos / Gest.Prov. / Clasificación y Documentación de

Proveedores
Una vez que se han acordado y negociado los servicios de un determinado

proveedor, es preciso crear una Base de Datos de Proveedores y Contratos
(SCD) donde se recogerá toda la información relacionada:
• Contratos de provisión del servicio (UCs).

• El nivel de actuación del proveedor: Estratégico (directivos), táctico
(mandos intermedios), operativo (nivel ejecutor).
• Relaciones con otros elementos del ciclo de vida.
Página 98
3. Procesos / Gest. Proveedores / Gestión Rendimiento proveedores
A grandes rasgos, se trata de verificar si efectivamente se están cumpliendo los

niveles de calidad y disponibilidad acordados en los contratos:
• ¿El suministrador se integra adecuadamente a los procesos de la

organización TI?
• ¿Cuál es el procedimiento para informar al proveedor en caso de recibir
una incidencia en el Centro de Servicios?
• Si un elemento de configuración relacionado con el proveedor cambia,
¿cuál es el procedimiento a seguir para actualizar el CMS?
Página 99
3. Procesos / Gest.Prov. / Renovación o terminación de contratos
Esta actividad consiste en llevar a cabo renovaciones de contratos, asesorar a

la dirección acerca de si éstos son relevantes y terminar la relación contractual
en caso de que ya no se necesiten más los servicios del proveedor.
Los aspectos a considerar para tomar la decisión de renovar a un proveedor

incluyen:
• El buen funcionamiento del contrato y su relevancia de cara al futuro.

• Cambios que es preciso acometer: servicios, productos, contratos,
acuerdos, objetivos.
• Perspectivas futuras de la relación con el proveedor: crecimiento,
estancamiento, cambio, terminación, transferencia, etc.
• Rendimiento comercial del contrato (criterios de cobro, estructura de
precios, etc.)
• Buenas prácticas para la gestión de contratos.
• Administración de proveedores y contratos.
Página 100
3. Procesos / Gestión Proveedores / Interfaces
Relaciones con otros procesos:
Gestión de Niveles de Servicio: colabora en la determinación de objetivos,

requisitos y responsabilidades
Gestión de la Seguridad de la Información: gestiona a los suministradores y su

acceso a los servicios
Gestión de la Cartera de Servicios: garantiza que la Cartera de Servicios ofrece

una imagen precisa y detallada de todos los sistemas de soporte
Entradas:
Información de negocio (planes, estrategia)
Estrategias de proveedores
Contratos de proveedores
Detalles de planes de negocio
Información sobre rendimiento
Salidas:
Base de Datos de Proveedores y Contratos
Información sobre rendimiento
Planes de mejora
Página 101
3. Procesos / Gestión Proveedores / Métricas
El rendimiento de Gestión de Proveedores se puede medir en función de:
El aumento del número de proveedores que cumplen los acuerdos

contractuales
El aumento del número de objetivos contractuales que están alineados con

SLA y SLR
Página 102
3. Procesos / Gestión Proveedores / Implementación
El éxito de Gestión de Proveedores dependerá de:
Protección frente a bajo rendimiento del proveedor
Servicios ajustados a los requisitos del negocio
Claridad de los proveedores y los contratos
Riesgos:
Falta de compromiso del negocio y la dirección
Falta de información sobre políticas y objetivos futuros del negocio
Falta de recursos o presupuesto
Acuerdos contractuales impracticables
Página 103
4. Tecnología
Es conveniente disponer de herramientas que faciliten todo el proceso de

Diseño del Servicio.
En líneas generales se debe tener en cuenta que todas las herramientas

utilizadas deben estar al servicio de los procesos y no al contrario. Es habitual
caer en el error de adaptar los procesos a las herramientas en vez de buscar o
adaptar las herramientas para que se ajusten a nuestros requisitos, lo que
puede empañar los esfuerzos de planificación y definición previos.
A la hora de escoger las herramientas adecuadas puede servir de ayuda el uso

de un análisis MoSCoW:
• M (must have): Funcionalidades esenciales de las que debe disponer la

herramienta
• S (should have): funcionalidades importantes de las que debe disponer
la herramienta pero que “pueden esperar” y admiten soluciones
temporales.
• C (could have): funcionalidades adicionales que mejorarían el
rendimiento o usabilidad de la herramienta.
• W (will not have it now): funcionalidades accesorias que sería
interesante añadir en el futuro pero que ahora son prescindibles.
Otras variables a tener en cuenta a la hora de hacer una determinada elección

incluyen:
• Reputación del proveedor de la herramienta.

• Qué tipo de soporte se ofrece.
• Si el paquete incluye formación para los usuarios.
• Periodicidad y coste de las actualizaciones.
• Plataforma tecnológica.
• Compatibilidad con otras herramientas ya integradas en la organización
TI.
Página 104
5. Relación con otras fases
La fase de Diseño recibe sus inputs principales de la fase de Estrategia y

Mejora del Servicio y a su vez sirve de principal input a las fases de Transición
y Operación.
Un correcto diseño debe seguir de cerca las pautas estratégicas

preestablecidas y debe a su vez tomar en cuenta las restricciones provenientes
de la fase de Transición y especialmente Operación.
La fase de diseño representa la interfaz entre el mundo de las ideas y el mundo

real. De nada sirve un servicio conceptualmente bien diseñado si se ignoran
restricciones impuestas por la falta de recursos y ausencia de capacidades o si
éstas no son correctamente asignadas.
Página 105
5. Relación con otras fases / Diseño y estrategia
El principal input ofrecido a la fase de Diseño del Servicio por la fase de

Estrategia es un Portfolio de Servicios orientado a cada segmento del mercado.
La estrategia debe aportar al diseño del servicio:
• Modelos de servicio que ofrezcan una guía sobre como aportar valor a
los servicios propuestos.
• Información sobre restricciones derivadas de los clientes o política de
precios, etcétera.
Página 106
5. Relación con otras fases / Diseño y transición
La fase de transición debe disponer de toda la documentación necesaria para

elaborar los planes de cambio y realizar el despliegue del servicio:
• Planes de capacidad y disponibilidad

• Paquetes de servicio
• SLAs
• Planes de continuidad TI
A su vez la fase de Transición debe asesorar al Diseño sobre los riesgos y

posibles impactos del cambio en la calidad del servicio.
Página 107
5. Relación con otras fases / Diseño y Operación
La fase de operación es la más crítica y de ella depende la percepción final del

cliente sobre la calidad del servicio.
Por lo tanto un factor esencial en el diseño del servicio es tener en cuenta la

operativa del mismo.
El diseño debe:
• Ser usable.
• Ser sostenible y escalable.
• Ofrecer la funcionalidad requerida.
• Ser eficiente.
• Cumplir los protocolos de seguridad requeridos.
• Permitir el acceso sólo al personal autorizado.
Página 108
5. Relación con otras fases / Diseño y Mejora Continua
La fase de mejora del servicio tiene como principal objetivo generar planes de
mejora para todos los procesos, actividades y servicios…
La satisfacción de los clientes depende en gran medida de los procesos y

actividades desarrolladas en la fase de diseño:
• ¿Resulto la capacidad suficiente?

• ¿Se cumplieron los SLAs?
• ¿Se tuvieron en cuenta los requisitos del cliente?
Si esto no fuera así es necesario introducir planes de mejora que minimicen o

eliminen los problemas encontrados y aporten una guía para las mejoras
necesarias en las soluciones y arquitecturas empleadas.
Página 109
6. Ejercicios prácticos
Pregunta 1
¿Cuál de las siguientes afirmaciones definen CORRECTAMENTE las opciones de
modelos de Aprovisionamiento de Servicios Interno (Insourcing) y
Aprovisionamiento de Servicios Externo (Outsourcing)?
Aprovisionamiento de Servicios Internos (Insourcing) depende de recursos

internos; Aprovisionamiento de Servicios Externo (Outsourcing) depende de
recursos externos a la organización
Aprovisionamiento de Servicios Internos (Insourcing) depende de recursos externos
a la organización; Aprovisionamiento de Servicios Externo
(Outsourcing) depende de recursos internos.
Aprovisionamiento de Servicios Internos (Insourcing) depende de co-sourcing;
Aprovisionamiento de Servicios Externo (Outsourcing) depende de los socios
Aprovisionamiento Interno (Insourcing) depende del conocimiento del proceso de
Aprovisionamiento Externo (Outsourcing); Aprovisionamiento Externo
(Outsourcing) depende de la aplicación del aprovisionamiento de servicio.
Pregunta 2
¿Para qué grupos de personas debería estar disponible la Política de Seguridad de la
Información?
Gestores Senior del Negocio y Todo el personal TI

Gestores Senior del Negocio, Ejecutivos TI y Gestor de Seguridad
Todos los Clientes, Usuarios y personal TI
Solamente para el personal de Gestión de Seguridad de la Información
Pregunta 3
¿Cuál de los siguientes describe mejor las Cuatro Ps del Diseño del Servicio?
Un proceso para el diseño de servicios efectivos

La Planificación, Perspectiva, Posición y los aspectos de las Personas en el Diseño
del Servicio
Preguntas que deben hacerse cuando se revisan las especificaciones del diseño
Las Personas, Socios, Productos y elementos de Procesos que deben considerarse
en el diseño de los servicios
Página 110
Pregunta 4
¿Cuál de los siguientes es una actividad Principal de la Gestión de Demanda?
Incrementar el valor al cliente

Entender los patrones de actividad de negocio
Incrementar el valor de TI
Alinear el negocio con los costes de TI
Pregunta 5
¿Cuáles de los siguientes roles asegura el modelo RACI para los procesos?
Responsable, Encargado, Consultado, Informado

Responsable, Factible, Consultado, Informado
Realístico, Encargado, Consultado, Informado
Responsable, Encargado, Correcto, Informado
Pregunta 6
El Gestor de Niveles de Servicio tiene la responsabilidad de asegurarse de que los
objetivos de la gestión de Niveles de Servicio se cumplen. El Gestor de Niveles de
Servicio NO es responsable de:
Negociar y acordar Acuerdos de Nivel Operativo

Asegurarse de que todos los servicios no operativos están registrados en el Catálogo
de Servicios
Negociar y acordar Acuerdos de Nivel de Servicio
Apoyar con la producción y mantenimiento de un Catálogo de Servicio preciso
Pregunta 7
¿Cuál de los cinco aspectos principales del Diseño de Servicio no aparece en la
siguiente lista?
1. El diseño de servicios.
2. El diseño de sistemas y herramientas de gestión de servicio.
3. El diseño de la arquitectura tecnológica y sistemas de gestión.
4. El diseño del proceso.
El diseño de funciones
El diseño de los Acuerdos de Nivel de Servicios (SLA)
Página 111
El diseño de aplicaciones
El diseño de sistemas de medida, métodos y métricas
Pregunta 8
¿Cuál de las siguientes significa mejor combinación Sourcing Interno y Externo?
Internal Sourcing (Fuentes Internas)

External Sourcing (Fuentes Externas)
Co-Sourcing
Servicios Gestionados
Pregunta 9
¿La Gestión de la Disponibilidad es responsable de la disponibilidad de?
Servicios y Recursos
Servicios y Procesos de Negocio
Recursos y Procesos de Negocio
Servicios, Recursos y Procesos de Negocio
Pregunta 10
En la Gestión de Continuidad del Servicio TI toman diversas medidas de
precaución, por ejemplo, usando una disposición de energía de emergencia.
¿Cuál de los siguientes procesos de ITIL también podría iniciar este tipo de
medidas?
Gestión de la Disponibilidad
Capacidad de gestión
Gestión del Cambio
Gestión de Incidentes
Página 112

Libro 2 Diseno Del Servicio

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro 2 Diseno Del Servicio

Cargado por

Copyright:

Formatos disponibles

Libro 2 – Diseño del Servicio

La principal misión de la fase de Diseño del Servicio es la de diseñar nuevos

El Diseño del Servicio debe seguir las directrices establecidas en la fase de

• Se adecuen a las necesidades del negocio.

• ¿Cuáles son los requisitos y necesidades de nuestros clientes?

2. Conceptos Básicos / Aspectos del Diseño

Para conseguir la máxima calidad posible con un enfoque de mejora continua,

Los cinco aspectos de diseño son los siguientes:

1. Solución del servicio (incluyendo requisitos funcionales, recursos y

2. Portafolio de Servicios (herramientas y sistemas de apoyo)

3. Arquitectura (tecnológica y de gestión)

5. Métricas y sistemas de medición

Diseño de soluciones de servicio

Diseño del Portafolio de Servicios

El Portafolio de Servicios es una de las principales herramientas para la gestión

información sobre todos los servicios ofrecidos, los servicios en fase de

La fase de Diseño del Servicio es responsable de determinar su contenido

El Portafolio de Servicios debe contener información sobre:

• Los objetivos del servicio

Diseño de la arquitectura del servicio

La arquitectura debe tener en cuenta todos los elementos necesarios para la

• La alineación entre la tecnología y el negocio.

Y toda aquella otra información que se pueda considerar de interés referente a

La gestión basada en procesos es una de las señas de identidad de ITIL. En la

Diseño de métricas y sistemas de monitorización

Es imprescindible diseñar sistemas de medición y seguimiento que permitan

Los resultados recopilados mediante estos sistemas de seguimiento y su

Existen cuatro tipos principales de métricas a considerar:

• Progreso: cumplimiento de los calendarios previstos

2. Conceptos Básicos / Valor del Diseño

• Coste total reducido de propiedad (TCO): el coste de propiedad puede

• Mejora con la alineación, calidad y la consistencia del servicio: se

• Implementación más sencilla de los servicios nuevos o modificados:

• El Diseño del Servicio y la producción de Paquetes de Diseño del

• Rendimiento del servicio más eficaz: con la incorporación y

• Mejora en el Gobierno de TI: ayudar con la puesta en práctica y la

• Gestión del Servicio y procesos de TI más eficaces: los procesos serán

• Mejora en la información y la toma de decisiones: las medidas y métricas

2. Conceptos Básicos / Modelos de Diseño del Servicio

Existen tres opciones principales: Tradicional, Ágil y Empaquetado que

Presupone una mayor estabilidad del servicio. El servicio requiere de un

Su principal problema es que las escalas de tiempo involucradas en el

El servicio o producto puede ser técnica y funcionalmente estable pero puede

Modelo ágil o RAD

El modelo Rápido de Desarrollo es un modelo principalmente incremental e

La funcionalidad tiende a ser modular de forma que ésta se pueda ir integrando

• Los módulos pueden ser reutilizables.

El concepto de prototipo implica que el proceso será por naturaleza iterativo y

Su principal problema reside en que al no estar completamente cerrada desde

Existen en la actualidad muchas soluciones TI empaquetadas que simplifican el

Sus ventajas se resumen en:

Sus principales inconvenientes suelen residir en:

• Dificultades de integración con otros servicios/plataformas.

La elección de uno u otro modelo de desarrollo para cada servicio es una de

• Decisiones estratégicas basadas en la criticidad del servicio.

2. Conceptos Básicos / Opciones de Modelos de Entrega

Estrategia de Características Ventajas Inconvenientes

2. Conceptos Básicos / Las 4 P’s

Muchos diseños, planes y proyectos fallan por una falta de preparativos y

Personas: usuarios, clientes, personal de TI y gestores. Es esencial la

Estrategia del Servicio

Diseño del Servicio

Transición del Servicio