Los servicios bien diseñados desempeñan un rol esencial para

conseguir una estrategia del servicio acertada. Un diseño eficaz

contribuye a la entrega de servicios de calidad que cumplan o
superen las expectativas del cliente.

Este libro muestra cómo crear activos del servicio de TI valiosos

para su organización, aunque dentro de las limitaciones del
negocio, como son el tiempo y el dinero. Proporciona un marco
de trabajo para el diseño del servicio que tiene en cuenta los
Diseño del Servicio
requisitos del cliente, presentes y futuros, manteniendo con
firmeza la visión del negocio.

La organización itSMF International, a través de su Subcomité

Ejecutivo de Publicaciones Internacionales (IPESC), integrado por
miembros de todos los capítulos de itSMF en todo el mundo, ha
concedido la aprobación formal de itSMF International a este libro.

Diseño del Servicio

ISBN 978-0-11-331226-9

9 780113 312269
www.tso.co.uk

6403 SD SPAN COV v0_3.indd 1 21/1/10 13:02:12

6403 SD SPAN COV v0_3.indd 2 21/1/10 13:02:23
 Diseño del Servicio

London: TSO

824_001 Prelims.indd 1 22/1/10 16:15:54

 Publicado por TSO (The Stationery Office) y disponible en:
Online
www.tsoshop.co.uk

Dirección, Teléfono, Fax y Correo electrónico

TSO
PO Box 29, Norwich NR3 1GN
Teléfono para pedidos y consultas generales: 0870 6005522
Fax pedidos: 0870 600 5533
Correo electrónico: customer.services@tso.co.uk
Teléfono de texto: 0870 240 3701

TSO@Blackwell y otros Agentes Acreditados

Publicado para la Office of Government Commerce bajo licencia de la Controller of Her Majesty’s
Stationery Office.

© Crown Copyright 2009

Este es un producto con valor añadido de Crown copyright, su reutilización requiere una Click-Use
Licence para el material con valor añadido publicado por OPSI.

Las solicitudes para utilizar, reproducir o reeditar el material de esta publicación deben enviarse a
OPSI, Information Policy Team, St Clements House, 2-16 Colegate, Norwich, NR3 1BQ,

Nº Tel (01603) 621000 Nº Fax (01603) 723000, Correo electrónico:

hmsolicensing@cabinet-office.x.gsi.gov.uk , o rellene el formulario de solicitud en el sitio web de OPSI
http://www.opsi.gov.uk/click-use/value-added-licence-information/index.htm

OPSI, en colaboración con la Office of Government Commerce (OGC), puede preparar posteriormente
una Value Added Licence basada en los términos estándar adaptados a sus requisitos particulares,
incluyendo las condiciones de pago

El logo OGC (r) es una Marca Comercial Registrada de la Office of Government Commerce

ITIL (r) es una Marca Comercial Registrada, y una Registered Community Trade Mark de la Office of
Government Commerce, y está Registrada en la U.S. Patent and Trademark Office

El logo Swirl (tm) es una Marca Comercial de la Office of Government Commerce

Primera publicación en 2009

ISBN 978 0 11 331226 9

Impreso en el Reino Unido para The Stationery Office

824_001 Prelims.indd 2 22/1/10 16:15:55

 Contenido
Lista de figuras v
Lista de tablas vii
Prólogo de OGC viii
Prólogo del Arquitecto Jefe ix
Prólogo x
Agradecimientos xi
1 Introducción 3 5.1 Ingeniería de requisitos 181
1.1 Descripción general 4
1.2 Contexto 4
1.3 Propósito 8
1.4 Uso 8
2 Gestión del Servicio como una práctica 13
2.1 ¿Qué es la Gestión del Servicio? 13
2.2 ¿Qué son los servicios? 13
2.3 Funciones y procesos a lo largo del ciclo
de vida 14
2.4 Fundamentos de Diseño del Servicio 15
3 Principios de Diseño del Servicio 25
3.1 Metas 27
3.2 Diseño equilibrado 27
3.3 Identificación de los requisitos del servicio 29
3.4 Identificación y documentación de las
directrices y requisitos de negocio 30
3.5 Actividades de diseño 32
3.6 Aspectos del diseño* 33
3.7 Las actividades de diseño posteriores 49
3.8 Restricciones del diseño 50
3.9 Arquitectura Orientada a Servicios 51
3.10 Gestión del Servicio de Negocio 52
3.11 Modelos de Diseño del Servicio 52
4 Procesos de Diseño del Servicio 63
4.1 Gestión del Catálogo de Servicios 65
4.2 Gestión del Nivel de Servicio 69
4.3 Gestión de la Capacidad 85
824_001 Prelims.indd 3
4.4 Gestión de la Disponibilidad 105
4.5 Gestión de la Continuidad del Servicio
de TI 134
4.6 Gestión de la Seguridad de la
Información 151
4.7 Gestión de Suministradores 161
5 Actividades asociadas con la
tecnología de Diseño del Servicio 181
5.2 Gestión de la Información y de los Datos 191
5.3 Gestión de Aplicaciones 195
6 Organización del Diseño del Servicio 203
6.1 Análisis de roles funcionales 204
6.2 Análisis de actividades 204
6.3 Habilidades y atributos 204
6.4 Roles y responsabilidades 204
7 Consideraciones sobre la tecnología 215
7.1 Herramientas de Diseño del Servicio 215
7.2 Herramientas de Gestión del Servicio 217
8 Implementación de Diseño del
Servicio 223
8.1 Análisis de Impacto en el Negocio 223
8.2 Requerimientos de Nivel de Servicio 223
8.3 Riesgos para los servicios y procesos 224
8.4 Implementación de Diseño del Servicio 224
8.5 Medición de Diseño del Servicio 228
9 Desafíos, Factores Críticos de Éxito
y riesgos 233
9.1 Desafíos 233
9.2 Riesgos 234
Epílogo 237
Apéndice A: E
 l Paquete de Diseño
del Servicio 241
Apéndice B: C
 riterios de Aceptación del
Servicio (ejemplo) 247
22/1/10 16:15:55
 iv | Contenido

Apéndice C: P
 lantillas de documentación
del proceso (ejemplo) 251
C1 Marco de trabajo del proceso 251

Apéndice D: D
 ocumentos de diseño y
planificación y sus
contenidos 255
D1 Documentos y estándares de diseño y
arquitectura 255
D2 Planes de TI 255

Apéndice E: A
 rquitecturas y estándares
del entorno 259
Apéndice F: SLA y OLA de ejemplo 265
Apéndice G: E
 jemplo de Catálogo
de Servicios 271
Apéndice H: E
 l marco de trabajo de
madurez del proceso
Gestión del Servicio 275
Apéndice I: E
 jemplo de contenidos de
una Declaración de Requisitos
(SoR) y/o Convocatoria de
Licitación (ITT) 281
Apéndice J: L os contenidos típicos de
un Plan de Capacidad 285
Apéndice K: L os contenidos típicos de
un plan de recuperación 289
Información adicional 295
Referencias 295

Glosario 299
Lista de acrónimos 299
Lista de definiciones 302

824_001 Prelims.indd 4 22/1/10 16:15:55

 Lista de figuras
Todos los diagramas que se incluyen en esta publicación
tienen la intención de proporcionar una ilustración y
guía de los conceptos de la Práctica de la Gestión del
Servicio de ITIL. Han sido elaborados artísticamente
para reforzar visualmente los conceptos clave y no
están concebidos para cumplir con un método formal
o estándar de representación técnica. El Modelo de
Servicio Integrado de Prácticas de Gestión del Servicio
de ITIL satisface los estándares de representación
técnica y debe consultarlo si desea obtener los detalles
completos. Consulte los detalles en
www.best-management-practice.com/itil.
Figura 1.1 Los recursos y las capacidades son la base
de la creación de valor
Figura 1.2 Aprovisionamiento de Prácticas de Gestión
del Servicio
Figura 1.3 Núcleo de ITIL
Figura 2.1 Una conversación sobre la definición y el
significado de los servicios
Figura 2.2 Un proceso básico
Figura 2.3 Alcance de Diseño del Servicio
Figure 2.4 Las cuatro P
Figura 2.5 El Grupo de Estrategia/Dirección de TI
Figura 3.1 El proceso de cambio del negocio
Figura 3.2 Composición del servicio
Figura 3.3 Elementos del proyecto en una relación
triangular
Figura 3.4 Las relaciones y dependencias del servicio
Figura 3.5 Alineación de nuevos servicios con los
requisitos de negocio
Figura 3.6 El Portfolio de Servicios – un repositorio
central
Figura 3.7 El Porfolio de Servicios y sus contenidos
Figura 3.8 Arquitectura de la Empresa
Figura 3.9 Relaciones de la arquitectura
Figura 3.10 Gestión integrada de la tecnología dirigida
al negocio
Figura 3.11 Los elementos genéricos del proceso
Figura 3.12 El Árbol de Métricas
824_001 Prelims.indd 5
Figura 3.13 Restricciones de diseño dirigidas por la
estrategia
Figura 3.14 Influencias externas en el diseño de la
solución
Figura 3.15 El flujo continuo de la gestión de TI
Figura 4.1 Los vínculos, entradas y salidas clave de
Diseño del Servicio
Figura 4.2 Diseño del Servicio – visión general
Figura 4.3 El Catálogo de Servicios de Negocio y el
Catálogo de Servicios Técnicos
Figura 4.4 Ejemplo de Catálogo de Servicios
Figura 4.5 Gestión del Nivel de Servicio
Figura 4.6 El proceso de Gestión del Nivel de Servicio
Figura 4.7 SLAs multinivel
Figura 4.8 El Proceso de Gestión de la Capacidad
Figura 4.9 Subprocesos de Gestión de la Capacidad
Figura 4.10 La capacidad debe dar soporte a los
requisitos de negocio
Figura 4.11 Gestión de la Capacidad sintetiza aspectos
particulares del modelo de demanda
Figura 4.12 Acciones iterativas continuas de Gestión de
la Capacidad
Figura 4.13 El Proceso de Gestión de la Disponibilidad
Figura 4.14 Medidas y términos de la disponibilidad
Figura 4.15 El ciclo de vida expandido de la incidencia
Figura 4.16 El método estructurado para el Análisis de
Fallos del Servicio (SFA)
Figura 4.17 Relación entre niveles de disponibilidad y
costes generales
Figura 4.18 Análisis del impacto del fallo del
componente
Figura 4.19 Ejemplo de Análisis del Árbol de Fallos
Figura 4.20 Análisis y Gestión del Riesgo
Figura 4.21 Ciclo de vida de Gestión de la Continuidad
del Servicio
Figura 4.22 Representación gráfica de impactos de
negocio
Figura 4.23 Gestión del Riesgo
22/1/10 16:15:55
 vi | Lista de figuras

Figura 4.24 Ejemplo de resumen de perfil de riesgo

Figura 4.25 Ejemplo de conjunto de opciones de
recuperación
Figura 4.26 Marco de trabajo para gestionar la
seguridad de TI
Figura 4.27 Proceso de Gestión de la Seguridad de TI
Figura 4.28 Controles de seguridad para amenazas e
incidencias
Figura 4.29 Gestión de Suministradores– roles e
interfaces
Figura 4.30 Proceso de Gestión de Suministradores
Figura 4.31 Clasificación por categorías de los
suministradores
Figura 5.1 Técnicas de reuniones de trabajo de
requisitos
Figura 7.1 Proceso de evaluación de herramientas de
Gestión del Servicio
Figura 8.1 Ciclo de implementación/mejora
Figura 8.2 Evaluación de la madurez cultural
Figura 8.3 Marco de trabajo de madurez del proceso
Figura H.1 Marco de trabajo de madurez del proceso

824_001 Prelims.indd 6 22/1/10 16:15:55

 Lista de tablas
Tabla 3.1 Marcos de trabajo de la Arquitectura de la
Empresa
Tabla 3.2 Principales estrategias de entrega del
servicio
Tabla 3.3 Ventajas y desventajas de las estrategias
de entrega del servicio
Tabla 3.4 Comparativa entre métodos
convencionales (‘en cascada’) y RAD
Tabla 4.1 Ejemplos de riesgos y amenazas
Tabla 5.1 Ingeniería de requisitos – conocimiento
tácito y explícito
Tabla 5.2 Ingeniería de requisitos; ejemplos de
conocimiento tácito o explícito (Maiden y
Rugg, 1995)
Tabla 5.3 Lista de requisitos
Tabla 5.4 Plantilla de requisitos
Tabla 5.5 Ejemplo de atributos del Portfolio de
Aplicaciones
Tabla 6.1 Ejemplo de matriz RACI
Tabla A.1 Contenido del Paquete de Diseño del
Servicio
Tabla B.1 Criterio de Aceptación del Servicio
Tabla E.1 Edificio/emplazamiento
Tabla E.2 Sala de equipos principal
Tabla E.3 Centros de datos principales
Tabla E.4 Centros de datos regionales y centros de
equipos principales
Tabla E.5 Salas de servidores y equipos de red
Tabla E.6 Entornos de oficina
Tabla G1 Ejemplo de Catálogo de Servicios
Tabla H.1 PMF Nivel 1: inicial
Tabla H.2 PMF Nivel 2: repetible
Tabla H.3 PMF Nivel 3: definido
Tabla H.4 PMF Nivel 4: gestionado
Tabla H.5 PMF Nivel 5: optimización

824_001 Prelims.indd 7 22/1/10 16:15:55

 Prólogo de OGC
Desde su creación, ITIL ha crecido hasta convertirse
en el método para la Gestión del Servicio de TI más
ampliamente aceptado en el mundo. Sin embargo, a este
éxito, va unida la responsabilidad de garantizar que la guía
siga estando actualizada en un entorno de negocio global
y cambiante. Los requisitos de la Gestión del Servicio se
ven configurados inevitablemente por el desarrollo de la
tecnología, por la revisión de los modelos de negocio y
por el aumento de las expectativas de los clientes. Nuestra
última versión de ITIL ha sido elaborada como respuesta a
estos desarrollos.
Esta es una de las cinco publicaciones centrales que
describen las prácticas de la Gestión del Servicio de TI que
componen ITIL. Son el resultado de un proyecto de dos
años de revisión y actualización de la guía. El número de
profesionales de todo el mundo de la Gestión del Servicio
que han colaborado para desarrollar el contenido de estas
publicaciones es enorme. Su experiencia y conocimiento
han contribuido a la generación del contenido para
ofrecerle un conjunto coherente de guías de alta calidad.
Esto está respaldado por el desarrollo continuo de un plan
de acción integral de cualificaciones, junto con consultoría
y formación acreditadas.
Ya forme parte de una empresa global, de un
departamento gubernamental o de un pequeño negocio,
ITIL le permitirá acceder a una experiencia profesional de
la Gestión del Servicio de clase mundial. Básicamente,
sitúa a los servicios de TI en su lugar, en el corazón de las
operaciones de negocio de éxito.

Peter Fanning
Acting Chief Executive
Office of Government Commerce

824_001 Prelims.indd 8 22/1/10 16:15:55

 Prólogo del Arquitecto Jefe
Los servicios de éxito no surgen por accidente. Tienen
que planificarse y diseñarse detenidamente. Los medios
para lograr esto se encuentran en Diseño del Servicio.
La mejor Estrategia del Servicio no se puede realizar sin
servicios bien diseñados. Un Diseño del Servicio eficaz
puede hacer que las organizaciones obtengan grandes
ganancias en calidad y en coste-eficacia. Reduce el riesgo
de la compensación costosa de los defectos del diseño
en el entorno operativo y asegura que los servicios se
comportarán como se pretende y ofrecerán un valor
medible para los objetivos del negocio.
En el pasado, el mundo de las TI se ha visto dividido en
dos partes, el mundo del desarrollo y el mundo operativo.
Una falta de sinergias entre estos mundos normalmente
favorece un efecto secundario importante; los objetivos de
negocio no se cumplen.
Un objetivo principal de Diseño del Servicio es eliminar
esta antigua visión y ofrecer una visión consolidada y
única de los servicios de TI dentro de las realidades,
restricciones y oportunidades de la operación real.
La oportunidad de aprovechamiento de las nuevas
tecnologías, la maximización del uso de la infraestructura,
aplicaciones, datos y conocimientos existentes, se
encuentran en esta publicación.
Diseño del Servicio amplía nuestros horizontes y nos
ayuda a tener una visión más amplia y consistente de
Gestión del Servicio de TI.
Cualquier organización de TI que desee maximizar su
potencial para cumplir objetivos de negocio y valor para
el negocio, necesita esta publicación en su arsenal de
capacidades.
Diseño del Servicio es una guía poderosa y una piedra
angular de habilidades, herramientas y métodos prácticos
para lograr la excelencia en el servicio.

Sharon Taylor
Chief Architect,
Prácticas de Gestión del Servicio de ITIL

824_001 Prelims.indd 9 22/1/10 16:15:55

 Prólogo
‘La calidad en un producto o servicio no es lo que el Información de contacto
suministrador presenta. Es lo que el cliente obtiene y Puede encontrar todos los detalles de la gama de
está dispuesto a pagar por ello’. Peter Drucker, experto materiales publicados por ITIL en www.best-management-
americano en gestión. practice.com/itil
Las prácticas de Gestión del Servicio de ITIL se basan en Para disponer de más información sobre las cualificaciones
esta idea. Los servicios son activos desde los que el cliente y la acreditación de la formación, visite www.itil-officialsite.
obtiene valor. El grado en el que los servicios se diseñan com. De forma alternativa, puede ponerse en contacto
teniendo en cuenta las necesidades de los clientes, dará con:
una predicción del valor que se puede derivar de ellos. En
ausencia de Diseño del Servicio, el servicio evolucionará APMG Service Desk
informalmente, a menudo sin aprovecharse de una Sword House
Totteridge Road
perspectiva más amplia, la visión del negocio.
High Wycombe
La fase de Diseño del Servicio del Ciclo de Vida de ITIL Buckinghamshire
toma los requisitos de negocio y, aplicando cinco aspectos HP13 6DG
de Diseño del Servicio, crea servicios y sus prácticas de Tel.: +44 (0) 1494 452450
soporte que cumplen las exigencias de calidad, fiabilidad
y flexibilidad del negocio. Diseño del Servicio es iterativo Correo electrónico: servicedesk@apmg.co.uk
a través del Ciclo de Vida del Servicio, y comienza con
una sólida guía que permite las etapas de construcción,
prueba y liberación de Transición del Servicio a través del
Paquete de Diseño del Servicio.
Los lectores aprenderán sobre los principios del
diseño para la aplicación, infraestructura, procesos y
recursos, además de modelos de aprovisionamiento.
Los Gestores del Servicio también encontrarán una guía
sobre la ingeniería de requisitos sólidos, Gestión de
Suministradores y consideraciones clave de diseño para la
externalización del servicio.
Ya sea un proveedor de servicio externo o interno,
forma parte de una red de valor y cumple un rol crítico
en el Ciclo de Vida del Servicio, integrando las mejores
prácticas para Diseño del Servicio y para el Ciclo de Vida
del Servicio en productos innovadores para el cliente de
negocio. La publicación Diseño del Servicio proporciona el
conocimiento y habilidades necesarios para crear la mejor
combinación de activos del servicio que ofrezcan servicios
medibles, escalables e innovadores junto con la ruta a la
excelencia del servicio.
Cualquier proveedor de servicios de TI que se espera
que entregue calidad al cliente de negocio, tendrá la
capacidad de diseñar servicios que cumplan expectativas,
y a continuación ir más allá de las mismas.
La guía que se incluye en esta publicación ayudará a
lograrlo.

824_001 Prelims.indd 10 22/1/10 16:15:55

 Agradecimientos
Arquitecto Jefe y autores
Sharon Taylor (Aspect Group Inc) Chief Architect
Vernon Lloyd (Fox IT) Autor
Colin Rudd (IT Enterprise
Management Services Ltd – ITEMS) Autor
Equipo de redacción de ITIL
El equipo de redacción de ITIL contribuyó a crear esta guía
a través de comentarios sobre el contenido y la alineación
del conjunto. Extendemos nuestro agradecimiento a otros
autores de ITIL, especialmente a Jeroen Bronkhorst (HP),
David Cannon (HP), Gary Case (Pink Elephant), Ashley
Hannah (HP), Majid Iqbal (Carnegie Mellon University),
Shirley Lacy (ConnectSphere), Ivor Macfarlane (Guillemot
Rock), Michael Nieves (Accenture), Stuart Rance (HP),
George Spalding (Pink Elephant) y David Wheeldon (HP).
Tutores
Tony Jenkins
Sergio Rubinato Filho
Contribuciones adicionales
Muchas personas dedicaron generosamente su tiempo
y experiencia a esta publicación Diseño del Servicio.
Jim Clinch, como Jefe de Proyecto de OGC, agradece el
soporte proporcionado por Jenny Dugmore, Coordinador
del Grupo de Trabajo de ISO/IEC 20000, Janine Eves, Carol
Hulm, Aidan Lawes y Michiel van der Voort.
A los autores también les gustaría dar las gracias a
Tony Jenkins, DOMAINetc y Steve Rudd IT Enterprise
Management Service Limited (ITEMS).
Durante el desarrollo de la v3 de ITIL, para que ésta refleje
la mejor práctica actual y generar publicaciones de valor
duradero, OGC consultó ampliamente a diferentes grupos
interesados de todo el mundo en cada etapa del proceso.
OGC también desearía expresar su agradecimiento a
las siguientes personas y a sus organizaciones por sus
contribuciones para la renovación de la guía de ITIL:
El Grupo Asesor de ITIL
Pippa Bass, OGC; Tony Betts, Independent; Megan Byrd,
Bank of America; Alison Cartlidge, Xansa; Diane Colbeck,
DIYmonde Solutions Inc; Ivor Evans, DIYmonde Solutions
Inc; Karen Ferris, ProActive; Malcolm Fry, FRY-Consultants;
John Gibert, Independent; Colin Hamilton, RENARD
Consulting Ltd; Lex Hendriks, EXIN; Signe Marie Hernes,
824_001 Prelims.indd 11
Det Norske Veritas; Carol Hulm, British Computer Society-
ISEB; Tony Jenkins, DOMAINetc; Phil Montanaro, EDS; Alan
Nance, ITPreneurs; Christian Nissen, Itelligence; Don Page,
Marval Group; Bill Powell, IBM; Sergio Rubinato Filho, CA;
James Siminoski, SOScorp; Robert E. Stroud, CA; Jan van
Bon, Inform-IT; Ken Wendle, HP; Paul Wilkinson, Getronics
PinkRoccade; Takashi Yagi, Hitachi
Revisores
Kamal Kishore Arora, Infosys Technologies; Martin
Andenmatten, Independent; Pierre Bernard, Pink Elephant;
Wills Damasio, Quint Wellington Redwood; Catalin Danila,
GlaxoSmithKline, SRL Romania; Juergen Dierlamm,
Rechtsanwaitkanzlei Dierlamm; Thomas Dressler, EDV-
Beratung; Fouad El Sioufy, TUV Rheinland Secure iT GmbH;
Jaime Eduardo Facioli, Kalendae IT Service Management;
Juergen Feldges, DNV; Prasad Gadgil, Satyam Computer
Services Ltd; Kingshuk Ghosh, HP; Sandeep Gondhalekar,
Quint Wellington Redwood; John Graham, Educad;
Juergen Gross, Independent; Tsuyoshi Hamada, HP; Colin
Hamilton, RENARD Consulting Ltd; Christoph Herwig,
Accenture; Thomas Hess, Pluralis AG; Chris Jones, Ariston
Strategic Consulting; Daniel Keller, Swiss SUIT; Hendrikje
Kuhne, Ktp-organisationsterberatung; Jane Link, Acerit
Limited; Paul Martini, HP; Raimund Martl, HP; Alan Nance,
Itpreneurs; Christian Nissen, ITILLIGENCE; Glen Notman,
Pink Elephant; Tuomas Nurmela, TietoEnator Processing
& Network Oy; Benjamin Orazem, SRC.SI; Gerard Persoon,
E.Novation; Neil Pinkerton, Laughingtree; Christian Probst,
Quint Wellington Redwood; Rajesh Radhakrishnan, IBM;
Brian Rowlatt, LogicaCMG; Sutirtha Roy Chowdhury,
Sierra Systems ; Alexander Sapronov, HP; Frances Scarff,
OGC; Alan Shepherd, Deutsche Bank AG; Rob Stroud, CA;
Michael Tomkinson, BT; Ken Turbitt, BMC Software; Wiley
Vasquez, BMC Software; Ettiene Vermeulen, Datacentrix;
Joachim von Caron, Lufthansa Systems; Andreas
Weinberger, DekaBank; Sven Werner, Unilog Avinci GmbH;
Theresa Wright, Computacenter Services; Geoffrey Wyeth,
Independent; Rob Young, Fox IT
Equipo de Traducción al Español
La traducción de esta versión en español fue organizada
por el Comité de Publicaciones de itSMF España y su
coordinador Marlon Molina, con el apoyo de Eduardo
Méndez Polo como jefe del proyecto. Esta versión ha sido
traducida por la empresa Translatorcom y revisada por un
equipo de expertos en ITIL quienes han dedicado una gran
cantidad de su tiempo a este proyecto, y a quienes itSMF
España desea expresar su gratitud:
Jose Antonio Izquierdo López (Oesia)
Juan Carlos Vigo (Itera)
22/1/10 16:15:55
 xii | Agradecimientos

Francisco Gil Lorente (Renfe)

Javier García Arcal (Oesia)
Juan Jose Carpintero (Alcampo)
Alejandro Perez Sanchez (Telefónica)
Ricard Pons Pallares (IBM)
Raquel Paz Casteleiro (GMV)
Rafael Pastor Sáenz (Junta de Andalucia)
Juan Jose Figueiras Corzon (Xelere)
Roberto Hernandez (HP)
Ignacio Fresno (HP)
Eduardo Méndez Polo (Telefónica) (Coordinador del
Proyecto)
Marlon Molina (Tecnofor) (Coordinador de Publicaciones)

824_001 Prelims.indd 12 22/1/10 16:15:55

824_002 Chapter 01.indd 1
Introducción 1
22/1/10 13:47:39
824_002 Chapter 01.indd 2 22/1/10 13:47:39
 1 Introducción
El objetivo principal de Gestión del Servicio es garantizar
que los servicios de TI se alineen con las necesidades del
negocio y darles soporte activamente. Es muy importante
que los servicios de TI sostengan los procesos de
negocio, pero también es cada vez más importante que
TI actúe como un agente para el cambio para facilitar la
transformación del negocio.
Todas las organizaciones que hagan uso de TI dependerán
de TI para tener éxito. Si los procesos y servicios de TI se
implementan, gestionan y se les da soporte de manera
apropiada, el negocio tendrá más éxito, sufrirá menos
interrupciones y menores pérdidas de horas productivas,
reducirá costes, incrementará el beneficio, mejorará las
relaciones públicas y logrará sus objetivos de negocio.
La mayoría de las autoridades identifican ahora cuatro
tipos de activos de TI que son necesarios adquirir y
gestionar para contribuir a una provisión eficaz del servicio
de TI. Éstos son: la infraestructura de TI, aplicaciones,
información y personas. Especialmente, existe un gran
énfasis en la adquisición, gestión e integración de estos
activos a través de su ciclo de vida, desde el nacimiento
hasta la retirada. La entrega de servicios de TI de calidad
depende de la gestión eficaz y eficiente de estos activos.
Sin embargo, estos activos por sí mismos no son
suficientes para satisfacer las necesidades de Gestión del
Servicio del negocio. Las prácticas de Gestión del Servicio
de ITIL usan estos cuatro tipos de activos como parte
de un conjunto de capacidades y recursos denominados
‘activos del servicio’.
Capacidades
A1 Gestión
A2 Organización
A3 Procesos
A4 Conocimiento
Personas
Figura 1.1  Los recursos y las capacidades son la base de la creación de valor
824_002 Chapter 01.indd 3
Un servicio de TI, aplicado al soporte de los procesos de
negocio, se construye a partir de una combinación de
activos de TI y servicios de soporte que se suministran
externamente. Una vez en su lugar, un servicio de TI debe
estar respaldado a lo largo de su ‘vida’, durante la cual
podría experimentar numerosas modificaciones, a través
de la innovación tecnológica; cambiando el entorno de
negocio, el uso del servicio, los parámetros de calidad del
servio, o sus capacidades o activos de TI de soporte (p. ej.,
un cambio en un componente del software de aplicación
para proporcionar funcionalidades adicionales). El servicio
de TI se retira eventualmente cuando los procesos de
negocio ya no tienen un uso para el mismo o deja de
ser rentable. Transición del Servicio se involucra en la
construcción y despliegue del servicio y del soporte diario,
y la entrega del servicio es el rol de Operación del servicio,
mientras que Mejora Continua del Servicio implementa la
mejor práctica en las etapas de optimización y retirada.
Desde esta perspectiva, Diseño del Servicio puede verse
como una recopilación de necesidades del servicio y
una correlación de las mismas con los requisitos para
obtener servicios integrados, y como la creación de las
especificaciones del diseño para los activos del servicio
necesarios para proporcionar servicios. Una característica
particular de este método es que pone un gran énfasis en
la reutilización durante el diseño.
El objetivo principal de Diseño del Servicio es diseñar
servicios de TI junto con las prácticas, procesos y
políticas de TI vigentes para llevar a cabo la estrategia y
facilitar la introducción de estos servicios en el entorno
de producción, garantizando la entrega de un servicio
Recursos
Capital financiero A9
Infraestructura A8
Aplicaciones A7
Información A6
A5 Personas
22/1/10 13:47:41
 4 | Introducción
de calidad, la satisfacción del cliente y la provisión
rentable del servicio. Diseño del Servicio también debería
diseñar los servicios de TI de forma eficaz para que no
necesiten grandes mejoras durante su ciclo de vida. Sin
embargo, la mejora continua debería integrarse en todas
las actividades de Diseño del Servicio para asegurar
que las soluciones y diseños sean incluso más eficaces
con el tiempo y para identificar tendencias de cambio
en el negocio que pudieran ofrecer oportunidades de
mejora. Las actividades de Diseño del Servicio pueden
ser periódicas o basarse en excepciones cuando puedan
activarse debido a una necesidad o evento específico del
negocio.
Si los servicios o procesos no se diseñaran, éstos
evolucionarían orgánicamente. Si evolucionaran sin los
controles adecuados, la tendencia sería simplemente
reaccionar a las condiciones del entorno en que se
hayan producido en lugar de entender claramente la
visión general y las necesidades generales del negocio.
Diseñar con respecto a un entorno anticipado, es mucho
más eficaz y eficiente, pero a menudo imposible, de
ahí que surja la necesidad de considerar métodos
iterativos e incrementales en Diseño del Servicio. Los
métodos iterativos e incrementales son esenciales para
garantizar que los servicios introducidos en el entorno
de producción se adapten y continúen en línea con las
necesidades cambiantes del negocio. En ausencia de un
Diseño del Servicio formalizado, en muchas ocasiones
será excesivamente costoso poner en funcionamiento
los servicios, existirá una tendencia al fallo, se
desaprovecharán recursos, y los servicios no se alinearán
completamente con las necesidades del negocio. Es
improbable que cualquier programa de mejora sea capaz
de lograr lo que un diseño adecuado lograría en primer
lugar. Sin Diseño del Servicio, no será posible obtener
un servicio rentable. Los aspectos humanos de Diseño
del Servicio también son de máxima importancia, y se
analizarán con detalle más adelante en esta publicación.
1.1  Descripción general
Esta publicación forma parte de las prácticas generales de
Gestión del Servicio de ITIL y cubre el diseño de servicios
de TI adecuados e innovadores para cumplir los requisitos
de negocio acordados actuales y futuros. Describe los
principios de Diseño del Servicio y busca identificar, definir
y alinear la solución de TI con los requisitos de negocio.
También incluye el concepto del Paquete de Diseño
del Servicio y busca seleccionar el modelo de Diseño
del Servicio apropiado. La publicación también analiza
los fundamentos de los procesos de diseño y los cinco
aspectos del diseño:
824_002 Chapter 01.indd 4
■■ Servicios
■■ Diseño de los sistemas y herramientas de Gestión del
Servicio, especialmente el Porfolio de Servicios
■■ Sistemas de gestión y arquitecturas tecnológicas
■■ Procesos
■■ Métricas y métodos de medición.
La publicación incluye los métodos, prácticas y
herramientas para lograr la excelencia en Diseño del
Servicio. Implementa el principio según el cual, el Diseño
del Servicio inicial debería estar dirigido por diversos
factores, incluyendo los requisitos funcionales, los
requisitos dentro de los Acuerdos de Nivel de Servicio
(SLAs), los beneficios del negocio y las restricciones
generales de diseño.
El Capítulo 4 explica el proceso extremo a extremo de
las áreas clave para que Diseño del Servicio tenga éxito.
Estos procesos son utilizados por todas las demás etapas
del Ciclo de Vida del Servicio, además, Diseño del Servicio
tiene en cuenta otros procesos. Sin embargo, aquí es
donde se analizan con detalle Gestión del Catálogo de
Servicios, Gestión del Nivel del Servicio, Gestión de la
Capacidad, Gestión de la Disponibilidad, Gestión de la
Continuidad del Servicio de TI, Gestión de la Seguridad de
la Información y Gestión de Proveedores.
Los apéndices de esta publicación ofrecen ejemplos del
Paquete de Diseño del Servicio, Criterios de Aceptación
del Servicio, plantillas de documentación del proceso,
documentos de diseño y planificación, arquitecturas y
estándares del entorno, SLAs de muestra, OLAs y Catálogo
de Servicios y el marco de trabajo de madurez del proceso
de Gestión del Servicio.
1.2 Contexto
1.2.1 Gestión del Servicio
Tecnologías de la información (TI) es un término de
uso común cuyo significado cambia según el contexto.
Desde la primera perspectiva, los sistemas, aplicaciones e
infraestructura de TI son componentes o subconjuntos de
un producto mayor. Habilitan, o se encuentran integrados
en procesos y servicios. Desde la segunda perspectiva,
TI es una organización con su propio conjunto de
capacidades y recursos. Las organizaciones de TI pueden
ser de varios tipos como, por ejemplo, funciones de
negocio, unidades de servicios compartidos y unidades
centrales en el ámbito de la empresa.
Desde la tercera perspectiva, TI es una categoría de
servicios que utiliza el negocio. Habitualmente se
trata de aplicaciones e infraestructuras de TI que las
22/1/10 13:47:41

organizaciones de TI internas o proveedores externos
de servicios empaquetan y ofrecen como servicios. Los
costes de TI se tratan como gastos de negocio. Desde
la cuarta perspectiva, TI es una categoría de activos de
negocio que proporcionan un flujo de beneficios para sus
propietarios, que incluyen, ingresos, ganancias y beneficios
económicos, sin excluir otros. Los costes de TI se tratan
como inversiones.
1.2.2  Buena práctica en el dominio público
Las organizaciones operan en entornos dinámicos con la
necesidad de aprender y adaptarse. Existe una necesidad
de mejorar el rendimiento mientras se gestionan los pros
y contras. Sometidos a una presión similar, los clientes
buscan aprovechar las ventajas de los proveedores de
servicio. Persiguen estrategias de aprovisionamiento del
servicio que se adapten mejor a sus propios intereses de
negocio. En muchos países, las agencias gubernamentales
y las organizaciones sin ánimo de lucro tienen una
tendencia similar a la externalización en la búsqueda de la
eficacia operativa. Esto ejerce una presión adicional sobre
los proveedores de servicio para mantener una ventaja
competitiva con respecto a las alternativas que puedan
tener los clientes. El aumento de la externalización ha
Estándares
Prácticas de la industria
Fuentes
Investigación académica
(Generar)
Formación y educación
Experiencia interna
Sustitutos
Impulsores Reguladores
(Filtrar)
Clientes
Ajuste del conocimiento a los objetivos,
contexto y propósito del negocio
Figura 1.2  Aprovisionamiento de Prácticas de Gestión del Servicio
824_002 Chapter 01.indd 5
Introducción | 5
expuesto particularmente a los proveedores internos de
servicio a una competencia inusual.
Para hacer frente a la presión, las propias organizaciones
se comparan con sus homólogos y buscan cerrar los gaps
en sus capacidades. Una forma de cerrar tales gaps es la
adopción de buenas prácticas de uso generalizado en la
industria. Existen muchas fuentes de buenas   prácticas
entre las que se incluyen marcos de trabajo públicos,
estándares y el conocimiento propietario de las
organizaciones y los individuos (Figura 1.2).
Los estándares y marcos de trabajo públicos resultan
atractivos cuando se comparan con el conocimiento
propietario:
■■ El conocimiento propietario se integra profundamente
en las organizaciones y por lo tanto es difícil de
adoptar, reproducir, o transferir incluso con la
cooperación de los propietarios. Tal conocimiento
normalmente se encuentra en forma de conocimiento
tácito que es inextricable y está deficientemente
documentado.
■■ El conocimiento propietario está adaptado al contexto
local y a las necesidades de negocio específicas,
hasta el punto de ser idiosincrásico. A menos que los
Empleados
Clientes
Facilitadores
Proveedores
(Agregar)
Asesores
Tecnologías
Competencia
Conformidad Escenarios
(Filtrar)
Compromisos
22/1/10 13:47:41
 6 | Introducción
Mejora
Continua
del Servicio
Transición
del Servicio
Estrategia
del Servicio
Diseño
del Servicio
Figura 1.3  Núcleo de ITIL
receptores de tal conocimiento tengan circunstancias
coincidentes, puede que el conocimiento no resulte
tan eficaz al aplicarlo.
■■ Los propietarios de este conocimiento esperan verse
recompensados por sus inversiones a largo plazo.
Podrían poner tal conocimiento a disposición de
terceros exclusivamente bajo términos comerciales, a
través de compras y de contratos de licencia.
■■ Los marcos de trabajo y normas disponibles
públicamente, como por ejemplo ITIL, COBIT, CMMI,
eSCM-SP, PRINCE2, ISO 9000, ISO/IEC 20000 e ISO/
IEC 27001, se validan a través de un conjunto
diverso de entornos y situaciones, más que por la
experiencia limitada de una única organización.
Están sujetos a una amplia revisión a través de
múltiples organizaciones y disciplinas. Se examinan
minuciosamente a través de diversos conjuntos de
socios, proveedores y competidores.
■■ Es más probable que el conocimiento de los marcos
de trabajo públicos se distribuya ampliamente entre
una gran comunidad de profesionales, a través de una
certificación y una formación disponible públicamente.
Las organizaciones pueden adquirir tal conocimiento
con mayor facilidad a través del mercado laboral.
Ignorar los estándares y marcos de trabajo públicos
puede situar innecesariamente a una organización en
824_002 Chapter 01.indd 6
Operación
del Servicio
desventaja. Las organizaciones deben cultivar su propio
conocimiento propietario sobre la base de una estructura
de conocimiento que se derive de estándares y marcos
de trabajo públicos. La colaboración y coordinación
entre organizaciones se simplifica si se fundamentan en
estándares y prácticas compartidas.
1.2.3  ITIL y buena práctica en la Gestión del
Servicio
El contexto de esta publicación es el Marco de Trabajo de
ITIL como una fuente de buenas prácticas en la Gestión
del Servicio. ITIL se aplica en organizaciones de todo
el mundo para establecer y mejorar las capacidades en
la gestión del servicio. ISO/IEC 20000 proporciona un
estándar formal y universal para las organizaciones que
deseen auditar y certificar sus capacidades de Gestión
del Servicio. Mientras que ISO/IEC 20000 es un estándar
a cumplir y mantener, ITIL ofrece una estructura de
conocimiento útil para cumplir el estándar.
La Biblioteca ITIL incluye los siguientes componentes:
■■ El Núcleo de ITIL – Guía de la mejor práctica aplicable
a todos los tipos de organizaciones que proporcionan
servicios para un negocio.
■■ La Guía complementaria de ITIL – Un conjunto
complementario de publicaciones con una guía
específica para sectores industriales, tipos de
22/1/10 13:47:41

organizaciones, modelos operativos y arquitecturas
tecnológicas.
El Núcleo de ITIL se compone de cinco publicaciones
(Figura 1.3). Cada una de ellas proporciona la guía
necesaria para un método integrado, tal y como requiere
la especificación del estándar ISO/IEC 20000:
■■ Estrategia del Servicio.
■■ Diseño del Servicio.
■■ Transición del Servicio.
■■ Operación del Servicio.
■■ Mejora Continua del Servicio.
Cada publicación se centra en las capacidades que
representan un impacto directo en el rendimiento de
un proveedor de servicio. La estructura del núcleo se
representa en la forma de un ciclo de vida. Es iterativa
y multidimensional. Garantiza que las organizaciones se
configuren para aprovechar las capacidades en un área
y obtener aprendizaje y mejoras en otras. Se espera que
el Núcleo de ITIL proporcione estructura, estabilidad
y fortaleza a las capacidades de Gestión del Servicio
con principios, métodos y herramientas duraderas. Esto
sirve para proteger las inversiones y proporcionar el
fundamento necesario para medir, aprender y mejorar.
La guía que se incluye en ITIL puede adaptarse para que
pueda ser empleada en diversos entornos de negocio y
estrategias organizativas. La Guía Complementaria de ITIL
proporciona flexibilidad para implementar el Núcleo en
un rango diverso de entornos. Los profesionales pueden
seleccionar la Guía complementaria en función de sus
necesidades para impulsar el Núcleo en un contexto de
negocio dado, de igual forma que se seleccionan los
neumáticos según el tipo de automóvil, el propósito y
las condiciones de la carretera. Esto permite ampliar la
duración y la portabilidad de los activos del conocimiento
y proteger las inversiones en las capacidades de Gestión
del Servicio.
1.2.3.1  Estrategia del Servicio
La publicación Estrategia del Servicio proporciona la guía
para diseñar, desarrollar e implementar la Gestión del
Servicio, no sólo como una capacidad organizativa, sino
también como un activo estratégico. Se proporciona una
orientación sobre los principios que sustentan la práctica
de la Gestión del Servicio y que resultan útiles para el
desarrollo de las políticas, guías y procesos de Gestión
del Servicio durante todo el Ciclo de Vida del Servicio
de ITIL. La guía Estrategia del Servicio resulta útil en el
contexto de Diseño del Servicio, Transición del Servicio,
Operación del Servicio y Mejora Continua del Servicio.
Los temas incluidos en Estrategia del Servicio incluyen el
824_002 Chapter 01.indd 7
Introducción | 7
desarrollo de mercados internos y externos, activos del
servicio, Catálogo de Servicios y la implementación de
la estrategia a través del Ciclo de Vida del Servicio. La
Gestión Financiera, la Gestión de la Cartera de Servicios,
el Desarrollo Organizativo y los Riesgos Estratégicos son
algunos de los temas principales.
Las organizaciones utilizan la guía para establecer los
objetivos y expectativas de rendimiento para servir a
los clientes y a los mercados, e identificar, seleccionar y
priorizar oportunidades. Estrategia del Servicio trata de
garantizar que las organizaciones puedan gestionar los
costes y riesgos asociados con sus Portfolios de Servicios, y
estén preparadas no sólo para lograr la eficacia operativa,
sino para conseguir un rendimiento diferenciador. Las
decisiones que se toman con respecto a la Estrategia
del Servicio tienen consecuencias de gran repercusión,
incluyendo algunas cuyos efectos son retardados.
Las organizaciones que ya ponen en práctica ITIL utilizan
este volumen como guía para realizar una revisión
estratégica de sus capacidades de Gestión del Servicio
basadas en ITIL y mejorar el alineamiento entre esas
capacidades y sus estrategias de negocio. Este volumen
de ITIL anima a los lectores a detenerse a reflexionar por
qué se tiene que realizar algo antes de pensar en cómo
realizarlo. Las respuestas al primer tipo de preguntas
se centran más en el negocio del cliente. Estrategia del
Servicio amplía el ámbito del Marco de Trabajo de ITIL
más allá de la audiencia tradicional de los profesionales de
Gestión del Servicio de TI.
1.2.3.2  Diseño del Servicio
La publicación Diseño del Servicio proporciona una guía
para el diseño y el desarrollo de servicios y procesos de
Gestión del Servicio. Recoge los principios y métodos de
diseño que permiten transformar los objetivos estratégicos
en portfolios de servicios y activos del servicio. El ámbito
de Diseño del Servicio no se limita a nuevos servicios.
Incluye los cambios y mejoras necesarios para aumentar
o mantener el valor que se proporciona a los clientes
durante el ciclo de vida, la continuidad, y el logro de
niveles de servicio y la conformidad con los estándares
y regulaciones. Sirve de guía a las organizaciones para el
desarrollo de capacidades de diseño para la Gestión del
Servicio.
1.2.3.3  Transición del Servicio
La publicación Transición del Servicio proporciona una
guía para el desarrollo y mejora de capacidades que
permitan transformar servicios nuevos y modificados en
operaciones. Esta publicación pone a disposición una guía
sobre cómo los requisitos de la Estrategia del Servicio
22/1/10 13:47:41
 8 | Introducción
que se codifican en el Diseño del servicio se materializan
de forma eficaz en operaciones del servicio mientras
se controlan los riesgos de fallo y discontinuidad. La
publicación combina prácticas en la Gestión de la Entrega,
Gestión del Programa y gestión del riesgo y las sitúa en el
contexto práctico de la Gestión del Servicio. Proporciona
una guía sobre la gestión de la complejidad relacionada
con los cambios en los servicios y en los procesos
de Gestión del Servicio, lo que evita consecuencias
indeseadas mientras se innova. Se proporciona la guía
para transferir el control de los servicios entre clientes y
proveedores de servicios.
1.2.3.4  Operación del Servicio
La publicación contiene prácticas sobre la gestión de
Operación del Servicio. Incluye una guía para lograr
eficacia y eficiencia en la entrega y el soporte de servicios
que garanticen el valor para el cliente y el proveedor
de servicio. Los objetivos estratégicos se materializan en
última instancia a través de Operación del Servicio, por
lo que se convierte en una capacidad crítica. Se da una
orientación para saber cómo mantener la estabilidad
de las operaciones del servicio, mientras se permiten
cambios en el diseño, escala, ámbito y niveles de servicio.
Las organizaciones obtienen directrices, métodos y
herramientas detalladas del proceso para su uso en dos
perspectivas de control principales: reactiva y proactiva.
Los gestores y profesionales reciben el conocimiento que
les permita tomar las mejores decisiones en áreas como
la gestión de la disponibilidad de los servicios, el control
de la demanda, la optimización del uso de la capacidad,
la programación de las operaciones y la solución de los
problemas. Se ofrece una guía sobre las operaciones
de soporte a través de nuevos modelos y arquitecturas,
como por ejemplo servicios compartidos, cálculo de
funcionalidades, utility computing (informática bajo
demanda), servicios de Internet y comercio móvil.
1.2.3.5  Mejora Continua del Servicio
Esta publicación proporciona una guía instrumental sobre
la creación y mantenimiento del valor que se ofrece a
los clientes a través de la mejora del diseño, transición y
operación de los servicios. Combina principios, prácticas
y métodos a partir de la gestión de la calidad, Gestión
de Cambios y mejora de la capacidad. Las organizaciones
aprenden a realizar mejoras graduales y a gran escala en
la calidad del servicio, en la eficiencia operativa y en la
continuidad del negocio. Se proporciona la orientación
para vincular los esfuerzos de mejora y los resultados con
la estrategia, diseño, transición y operación del servicio.
Se establece un sistema de realimentación de bucle
cerrado basado en el modelo Planificar-Hacer-Verificar-
824_002 Chapter 01.indd 8
Actuar (PDCA) que se especifica en la ISO/IEC 20000, y
que permite recibir entradas de cambio desde cualquier
perspectiva de planificación.
1.3 Propósito
El objetivo de esta publicación es ofrecer una guía al
lector sobre el uso de prácticas recomendadas al diseñar
servicios de TI y procesos de Gestión del Servicio de TI.
Esta publicación es una continuación de la publicación
Estrategia del Servicio que da una guía sobre el
alineamiento e integración de las necesidades del negocio
con respecto a TI. Permite al lector analizar los requisitos
al diseñar un servicio, y documenta la mejor práctica de la
industria para el diseño de servicios y procesos de TI.
Aunque esta publicación se puede leer de forma aislada,
se recomienda utilizarla junto con las demás publicaciones
de ITIL. La guía en las publicaciones de ITIL es aplicable
genéricamente. No es ni burocrática ni difícil de manejar si
se utiliza de forma sensata y se identifican completamente
las necesidades de negocio de la organización. Diseño
del Servicio es importante para ajustar de forma eficaz
la etapa de la entrega de servicios con el negocio y
para cumplir la demanda de crecimiento y cambio. La
mejora es típicamente mayor en costes y recursos que en
desarrollo. Por lo tanto, debe prestarse una consideración
importante al diseño para facilitar y abaratar el soporte
durante todo el ciclo de vida, ya que no es posible realizar
la reingeniería completa de un servicio una vez esté en
producción. Podría ser posible aproximarse, pero será
imposible volver atrás en un diseño una vez se ponga en
funcionamiento. La mejora del diseño es difícil y costosa
y nunca consigue lo que podría haberse logrado si se
hubiera diseñado adecuadamente desde el principio.
1.4  Uso
Esta publicación es pertinente para todo aquel que esté
involucrado en el diseño, entrega o soporte de servicios
de TI. Tendrá relevancia para el Arquitecto de TI, gestores
de TI y practitioners a todos los niveles. Es necesario
leer todas las publicaciones de la Biblioteca Central de
Gestión del Servicio de ITIL para apreciar y entender
completamente todo el ciclo de vida de los servicios y de
Gestión del Servicio de TI.
Existen múltiples formas de entregar un servicio de TI,
como por ejemplo en el ámbito interno, externalizado
y mediante acuerdos de colaboración. Esta publicación
es relevante generalmente para todos los métodos de
provisión del servicio. Por lo tanto, aquellos implicados
en la provisión de servicios de TI, dentro de su propia
organización, en la provisión externalizada de servicios
22/1/10 13:47:41
 Introducción | 9

o que trabajen en asociación, encontrarán que esta

publicación también es aplicable a su situación.
Los gestores de negocio podrían encontrar útil esta
publicación a la hora de entender y establecer las
mejores prácticas y el soporte de los servicios de TI. Los
Gestores de las organizaciones de proveedores también
encontrarán pertinente esta publicación a la hora de
establecer acuerdos para la entrega y soporte de servicios.

824_002 Chapter 01.indd 9 22/1/10 13:47:41

824_002 Chapter 01.indd 10 22/1/10 13:47:41
824_003 Chapter 02.indd 11
Gestión del Servicio
como una práctica 2
22/1/10 14:04:27
824_003 Chapter 02.indd 12 22/1/10 14:04:27
 2 Gestión del Servicio como una práctica
2.1  ¿Qué es la Gestión del Servicio?
Gestión del Servicio es un conjunto de capacidades
organizativas especializadas empleadas para proporcionar
valor a los Clientes en forma de Servicios. Las capacidades
adoptan la forma de funciones y procesos para gestionar
servicios durante un ciclo de vida, con especializaciones en
estrategia, diseño, transición, operación y mejora continua.
Las capacidades representan la capacidad, competencia y
confianza para la acción de una organización del servicio.
El acto de transformación de recursos en servicios de
valor se encuentra en el centro de la Gestión del Servicio.
Sin estas capacidades, una organización del servicio es
simplemente un conjunto de recursos que, por sí mismos,
tienen un valor intrínseco relativamente bajo para los
clientes.
Gestión del Servicio es un conjunto de capacidades
organizativas especializadas empleadas para
proporcionar valor a los Clientes en forma de Servicios.
Las capacidades organizativas se modelan mediante
los desafíos que se espera superar. De forma similar, las
capacidades de Gestión del Servicio se ven influenciadas
por los siguientes desafíos que distinguen los servicios de
otros sistemas de creación de valor, como por ejemplo la
fabricación, la minería y la agricultura:
■■ La naturaleza intangible de los productos finales e
intermedios de los procesos del servicio: resultan ser
difíciles de medir, controlar y validar (o probar).
■■ La demanda está fuertemente vinculada con los
activos del cliente: los usuarios y otros activos del
cliente, como por ejemplo los procesos, aplicaciones,
documentos y transacciones, llegan con la demanda y
estimulan la producción del servicio.
■■ El alto nivel de contacto para los productores y
consumidores de servicios: pocos intermediarios, o
ninguno, entre el cliente, el front-office y el back-
office.
■■ La naturaleza perecedera de la salida del servicio y
de la capacidad del mismo: se genera valor para el
cliente al garantizar el suministro continuo de calidad
consistente. Los proveedores necesitan garantizar un
suministro estable de la demanda de los clientes.
Sin embargo, la Gestión del Servicio es algo más que
un conjunto de capacidades. También es una práctica
profesional que se apoya en una amplia estructura de
824_003 Chapter 02.indd 13
conocimiento, experiencia y habilidades. Una comunidad
global de individuos y organizaciones en el sector público y
privado impulsa su crecimiento y madurez. Existen esquemas
formales para la educación, formación y certificación de
organizaciones que la ponen en práctica, y los individuos
influyen en su calidad. Las mejores prácticas de la industria,
la investigación académica y los estándares formales
contribuyen a su capital intelectual y se basan en él.
Los orígenes de Gestión del Servicio se encuentran en
servicios tradicionales como los de las líneas aéreas,
bancos, hoteles y empresas de telefonía. Su práctica
ha crecido con la adopción de un método orientado
al servicio en las organizaciones de TI para gestionar
las aplicaciones, infraestructuras y procesos de TI. Las
soluciones a los problemas del negocio y el soporte
a los modelos, estrategias y operaciones de negocio
aumentan en forma de servicios. La popularidad de los
servicios compartidos y la externalización han contribuido
al incremento del número de organizaciones que son
proveedores de servicios, entre las que se incluyen
las unidades organizativas internas. A cambio, se ha
fortalecido la práctica de la Gestión del Servicio y al
mismo tiempo se han impuesto mayores retos.
2.2  ¿Qué son los servicios?
2.2.1 La propuesta de valor
Un servicio es un medio de entrega de valor a los
clientes, facilitando los resultados que los clientes
desean lograr, sin la responsabilidad sobre los costes y
riesgos específicos.
Los servicios son un medio de entrega de valor a los
clientes, facilitando los resultados que los clientes
desean lograr, sin la responsabilidad de costes y riesgos
específicos. Los servicios facilitan los resultados mejorando
el rendimiento de las tareas asociadas y reduciendo el
efecto de las restricciones. El resultado es un incremento
de las posibilidades de obtener los resultados deseados.
Con los años, las organizaciones han debatido la
definición de un ‘servicio’. La ilustración de la Figura 2.1
es un ejemplo de que el servicio entrega realmente valor a
los clientes.
22/1/10 14:04:28
 14 | Gestión del Servicio como una práctica
Debo preguntar si
tiene una definición
para los servicios.
¿Que implicaría eso en
términos operativos?
Deme alguna idea.
¿Pero sin propiedad sobre
costes y riesgos? Los clientes
no la desean de todos modos.
Gestor
¡Aha! Porque el proveedor se (Operaciones) (Estrategia)
especializa en capacidades para
gestionar esos costes y riesgos.
(Una conversación informal
en el enfriador de agua)
Y también porque el proveedor
puede distribuir esos costes y
riesgos entre más de un cliente.
Figura 2.1  Una conversación sobre la definición y el significado de los servicios
2.3  Funciones y procesos a lo largo
del ciclo de vida
2.3.1  Funciones
Las funciones son unidades de organizaciones
especializadas que realizan ciertos tipos de trabajos y son
responsables de la obtención de resultados específicos.
Son independientes, y cuentan con las capacidades y
recursos necesarios para su rendimiento y resultados. Las
capacidades incluyen métodos de trabajo internos para
las funciones. Las funciones tienen su propia estructura de
conocimiento, que se acumula a partir de la experiencia.
Proporcionan estructura y estabilidad a las organizaciones.
Las funciones son medios que facilitan a las organizaciones
la estructura para que implementen el principio de
especialización. Las funciones definen típicamente roles, la
autoridad asociada, y la responsabilidad para obtener unos
resultados y un rendimiento específicos. La coordinación
entre funciones a través de procesos compartidos es
un patrón común en el diseño de la organización. Las
funciones tienden a optimizar localmente sus métodos
de trabajo para centrarse en los resultados asignados. La
coordinación deficiente entre funciones, combinada con
un enfoque hacia dentro, genera silos funcionales que
impiden el alineamiento y la retroalimentación críticos
para el éxito de la organización como conjunto. Los
824_003 Chapter 02.indd 14
Los servicios son un medio para aportar valor
proporcionando los resultados que los clientes esperan,
sin la propiedad sobre los costes y riesgos específicos.
Los servicios proveen resultados por sus
efectos positivos sobre actividades, objetos
y tareas, para crear condiciones para un
mejor rendimiento. Así, es más probable
conseguir los resultados deseados.
No, pero pueden transferir la propiedad
Gestor al proveedor. Por eso es un servicio en
realidad. Si los clientes lo gestionaran
todo, no necesitarían un servicio,
¿verdad?
Sí, y también porque el cliente puede
centrarse a su vez en esos resultados.
¡Escribamos un libro
sobre gestión del servicio!
modelos de proceso ayudan a evitar este problema con
jerarquías funcionales que mejoran la coordinación y el
control interdisciplinario. Los procesos bien definidos
pueden mejorar la productividad dentro y entre funciones.
2.3.2  Procesos
Los procesos son ejemplos de sistemas de bucle
cerrado, debido a que proporcionan los cambios y la
transformación necesarios para lograr un objetivo, y
utilizan la retroalimentación para reforzarse y corregirse a
sí mismos (Figura 2.2). Es importante considerar todo el
proceso o cómo un proceso se adapta a otro.
Las definiciones del proceso describen acciones,
dependencias y la secuencia. Los procesos tienen las
siguientes características:
■■ Medible: Podremos medir el proceso de forma
apropiada. Está orientado al rendimiento. Los gestores
desean medir el coste, la calidad y otras variables,
mientras que los profesionales se preocupan por la
duración y la productividad.
■■ Resultados específicos: La razón que explica la
existencia de un proceso es la entrega de un resultado
específico. Este resultado debe ser identificable y
cuantificable individualmente. Aunque podemos
contabilizar los cambios, es imposible contabilizar
cuántos Centros de Servicio al Usuario se completaron.
22/1/10 14:04:28

Datos,
información Proceso
y
conocimiento
Suministradores Actividad 1
Actividad 2
Control y calidad del servicio
Disparador
Figura 2.2  Un proceso básico
■■ Clientes: Cada proceso entrega sus resultados
primarios a un cliente o interesado. El proceso debe
satisfacer sus expectativas, independientemente
de que los clientes sean internos o externos a la
organización.
■■ Responde a un evento específico: Aunque el
proceso podría ser continuo o iterativo, éste debe ser
fácil de rastrear para detectar su activación específica.
Con frecuencia existe confusión con respecto a las
funciones, procesos, roles y actividades. Las funciones se
confunden a menudo con los procesos y viceversa. Diseño
del Servicio, además de ser una etapa del ciclo de vida de
un servicio, puede ser percibido en algunas organizaciones
como una función, en otras como un rol o como un
conjunto de procesos o como una actividad. El que
sea una función, rol, actividad o conjunto de procesos,
dependerá completamente del tamaño, estructura y
cultura de una organización. Sin embargo, es importante
que se defina e implemente dentro de una organización, y
el éxito de la función, proceso, rol o actividad se mide y se
mejora continuamente.
2.3.3 Especialización y coordinación a lo
largo del ciclo de vida
La especialización y la coordinación son necesarias en
el método del ciclo de vida. Esto será posible con la
retroalimentación y control entre las funciones y procesos
dentro de y entre los elementos del ciclo de vida. El
patrón dominante en el ciclo de vida es el progreso
secuencial que comienza a partir de Estrategia del Servicio
y que continúa a través de Diseño del servicio, Transición
del servicio, Operación del Servicio y de nuevo vuelve a
824_003 Chapter 02.indd 15
Gestión del Servicio como una práctica | 15
Resultado
deseado
Cliente
Actividad 3
Estrategia del Servicio a través de CSI. Sin embargo, ese no
es el único patrón de acción. Cada elemento del ciclo de
vida proporciona puntos de retroalimentación y control.
La combinación de múltiples perspectivas permite
mejorar la flexibilidad y el control a través de entornos
y situaciones. El método del ciclo de vida imita la
realidad de la mayoría de las organizaciones, en las que
se requiere el uso de múltiples perspectivas de control
para conseguir una gestión eficaz. Los responsables del
diseño, desarrollo y mejora de los procesos para la Gestión
del Servicio pueden adoptar una perspectiva de control
basada en el proceso. Se podría proporcionar un mejor
servicio a aquellos responsables de la gestión de acuerdos,
contratos y servicios mediante una perspectiva de control
basada en el ciclo de vida con distintas fases. Ambos tipos
de perspectivas de control se benefician del enfoque
orientado a los sistemas. Cada perspectiva de control
puede revelar patrones que no tienen que ser obvios para
los demás.
2.4  Fundamentos de Diseño del
Servicio
2.4.1  Propósito/meta/objetivo
El objetivo principal de la etapa de Diseño del Servicio
del ciclo de vida es el diseño de servicios nuevos o
modificados para su introducción en el entorno de
producción. Es importante que se adopte un método
integral para todos los aspectos del diseño, y que al
modificar o cambiar cualquier elemento individual del
diseño, se consideren todos los demás aspectos. Por lo
22/1/10 14:04:28
 16 | Gestión del Servicio como una práctica

Servicio de negocio a Servicio de negocio b Servicio de negocio c El negocio

3 6 9
2 5 8
Proceso de Proceso de Proceso de
negocio 1 negocio 4 negocio 7

E F G Servicios de TI
B C D
SLAs Servicio A
TI

Estrategia Transición Operación

del Servicio del Servicio del Servicio Conocimiento del Servicio
Sistema de Gestión
Portfolio de Servicios

Diseño del Servicio

Servicios

Procesos Catálogo de Servicios

Mejora SLM SCM
del Servicio Suministrador Arquitecturas
Seguridad
Disponibilidad
Continuidad Servicio de TI Métodos
Capacidad de medida

Equipos de Soporte

Suministradores
Figura 2.3  Alcance de Diseño del Servicio

tanto, el diseño y desarrollo de una nueva aplicación
debería hacerse de forma aislada, pero también debería
considerarse el impacto sobre todo el servicio, los sistemas
de gestión y herramientas (p. ej., Porfolio de Servicios y
Catálogos de Servicios), las arquitecturas, la tecnología,
los procesos de Gestión del Servicio y todas las medias y
métricas necesarias. Esto asegurará no sólo que el diseño
aborde los elementos funcionales, sino también que se
aborden todos los requisitos operativos y de gestión como
una parte fundamental del diseño, sin que se añadan
como una idea de último momento.
Servicio. Sólo seria necesario si hubiera un cambio
‘significativo’. Cada organización deberá definir lo
que constituye ‘significativo’ para que cualquiera que
pertenezca a la organización tenga claro cuándo se
provoca una actividad de Diseño del Servicio. Por lo tanto,
deberán evaluarse todos los cambios con respecto a su
impacto en las actividades de Diseño del Servicio para
determinar si son significativos en términos de requerir la
actividad de Diseño del Servicio. Esto debería formar parte
de la evaluación del proceso Gestión de Cambios dentro
de la publicación Transición del Servicio de ITIL.

Mensaje clave
Deberá adoptarse un método integral con respecto a
todos los aspectos y áreas de Diseño del Servicio para
garantizar la consistencia e integración dentro de
todas las actividades a través de las tecnologías de TI,
proporcionando la funcionalidad y calidad asociadas
con el negocio extremo a extremo.
No todos los cambios dentro de un servicio de TI
requerirán el inicio de una actividad de Diseño del
2.4.2  Ámbito
Existen cinco aspectos fundamentales de Diseño del
Servicio que se consideran dentro de esta publicación.
Éstos son el diseño de:
■■ Nuevos servicios o servicios modificados.
■■ Sistemas y herramientas de Gestión del Servicio,
especialmente el Porfolio de Servicios, incluyendo el
Catálogo de Servicios.
■■ Arquitectura tecnológica y sistemas de gestión.

824_003 Chapter 02.indd 16 22/1/10 14:04:28


■■ Los procesos requeridos.
■■ Métricas y métodos de medición.
La etapa de Diseño del Servicio del ciclo de vida comienza
con un conjunto de requisitos de negocio nuevos o
modificados y finaliza con el desarrollo de una solución
del servicio diseñada para cumplir las necesidades
documentadas del negocio. Esta solución desarrollada,
junto con su Paquete de Diseño del Servicio (SDP - vea el
Apéndice A) pasa entonces a Transición del Servicio para
evaluar, construir, probar y desplegar el nuevo servicio
o el servicio modificado. Con la finalización de estas
actividades de transición, el control se transfiere a la etapa
de Operación del servicio del Ciclo de Vida del Servicio.
Las actividades implicadas en estas etapas se describen en
la sección 3. En la Figura 2.3 se ilustra el alcance general
y los cinco aspectos de Diseño del Servicio, y cómo
interactúan.
El objetivo principal de Diseño del Servicio es el diseño de
servicios nuevos o modificados. Los requisitos para estos
nuevos servicios se extraen del Portfolio de Servicios. Cada
requisito se analiza, documenta y acuerda, y se genera un
diseño de solución que a continuación se compara con las
estrategias y restricciones de Estrategia del Servicio para
asegurar que esté conforme con las políticas corporativas
y de TI. Cada Diseño del Servicio individual también se
considera junto con cada uno de los demás aspectos de
Diseño del Servicio:
■■ Los sistemas y herramientas de Gestión del
Servicio, especialmente el Porfolio de Servicios:
para garantizar que este servicio nuevo o modificado
sea consistente con todos los demás servicios, y que
todos los demás servicios que hacen de interfaz, que
den soporte o dependan de los servicios nuevos o
modificados sean consistentes con el nuevo servicio.
Si no fuera así, será necesario adaptar el diseño del
nuevo servicio o el de los demás servicios existentes.
Además, los sistemas y herramientas de Gestión del
Servicio deben revisarse para garantizar que sean
capaces de dar soporte al servicio nuevo o modificado.
■■ Sistemas de gestión y arquitecturas tecnológicas:
para garantizar que todos los sistemas de gestión y
arquitecturas tecnológicas sean consistentes con el
servicio nuevo o modificado y tengan la capacidad
de operar y mantener el nuevo servicio. Si no fuera
así, será necesario modificar las arquitecturas o los
sistemas de gestión o será necesario revisar el diseño
del nuevo servicio.
■■ Los procesos: para garantizar que los procesos, roles,
responsabilidades y aptitudes tengan la capacidad de
operar, dar soporte y mantener el servicio nuevo o
824_003 Chapter 02.indd 17
Gestión del Servicio como una práctica | 17
modificado. Si no fuera así, sería necesario revisar el
diseño del nuevo servicio o será necesario mejorar las
capacidades del proceso existente. Esto incluye todos
los procesos de TI y de Gestión del Servicio, no sólo
los procesos clave de Diseño del Servicio.
■■ Las métricas y métodos de medición: para
garantizar que los métodos de medición existentes
puedan proveer las métricas requeridas en el servicio
nuevo o modificado. Si no fuera así, será necesario
mejorar los métodos de medida o revisar las métricas
del servicio.
Si todas las actividades anteriores se completaran durante
la etapa de Diseño del Servicio, esto garantizará que surja
el menor número de problemas durante las siguientes
etapas del Ciclo de Vida del Servicio. Por lo tanto, Diseño
del Servicio debe consolidar los aspectos y actividades
clave del diseño de todos los procesos de TI y de Gestión
del Servicio dentro de sus propias actividades de diseño,
para asegurar que se consideren y se incluyan todos
los aspectos dentro de todos los diseños para servicios
nuevos y modificados como parte de la operación diaria
del proceso.
La capacidad de medir y demostrar valor para el negocio
requiere la capacidad de vincular resultados para el
negocio, objetivos y sus procesos y funciones de soporte
para los servicios de TI y sus activos, procesos y funciones
de soporte. Este valor debería articularse mediante:
■■ El acuerdo de niveles de servicio, SLAs y objetivos
a través de toda la empresa, garantizando que los
procesos de negocio críticos reciban la máxima
atención.
■■ Medida de la calidad de TI en términos de negocio/
usuario, informando de lo que es pertinente para los
usuarios (p. ej., satisfacción del cliente, valor para el
negocio).
■■ Correlación de procesos de negocio con
la infraestructura de TI, ya que se añaden
constantemente nuevos componentes, aumentando la
posibilidad de interrupciones provocadas por TI y por
la pérdida de enfoque en los procesos y servicios de
negocio.
■■ Correlación de procesos de negocio con medidas de
negocio y del servicio, haciendo que los servicios se
centren en las medidas de TI asociadas con aspectos
clave del rendimiento del negocio.
■■ Correlación de los recursos de la infraestructura
con los servicios para aprovechar al máximo los
componentes críticos de TI dentro del Sistema de
Gestión de la Configuración (CMS) que se vinculan
con procesos de negocio críticos. También se podría
utilizar la información del Sistema de Gestión del
22/1/10 14:04:29
 18 | Gestión del Servicio como una práctica
Conocimiento del Servicio (SKMS). Puede encontrar
más información sobre el CMS en la publicación
Transición del Servicio.
■■ Medida y monitorización periódica del rendimiento
extremo a extremo de los procesos de negocio online
con respecto a los objetivos de los SLA.
En muchas ocasiones el diseño de un servicio importante
nuevo o modificado requerirá que se consideren cambios
del diseño, y en numerosas ocasiones afectan o se ven
afectados por el resto de las cuatro fases del Ciclo de Vida
del Servicio. Por lo tanto, es esencial que los sistemas y
servicios de TI se diseñen, planifiquen, implementen y
gestionen adecuadamente para el negocio en su totalidad.
El requisito es proporcionar servicios de TI que:
■■ Estén enfocados, dirigidos y orientados al cliente y al
negocio.
■■ Sean seguros y rentables.
■■ Sean flexibles y adaptables, ajustados al propósito en
el punto de entrega.
■■ Puedan absorber una demanda cada vez mayor en el
volumen y velocidad de cambio.
■■ Satisfagan una demanda cada vez mayor del negocio
para garantizar una operación continua.
■■ Se gestionen y operen a un nivel aceptable de riesgo.
■■ Tengan capacidad de respuesta, con una
disponibilidad adecuada para que corresponda con las
necesidades del negocio.
Con todas estas presiones sobre TI y sobre el negocio, la
tentación, y desafortunadamente la realidad en algunos
casos, es ‘cortar esquinas’ en los procesos de diseño y
planificación o ignorarlos completamente. Sin embargo, en
estas situaciones las actividades de diseño y planificación
son incluso más esenciales para la entrega general de
servicios de calidad. Por lo tanto, deberá dedicarse más
tiempo a los procesos de diseño y a su implementación.
Para que se pueda lograr un diseño eficaz y de calidad,
incluso cuando las escalas de tiempo sean cortas y
la presión para la entrega de servicios sea alta, las
organizaciones deberán asegurar que la importancia de la
función de Diseño del Servicio se entienda completamente
y que se proporcione soporte para mantener Diseño
del Servicio y hacer que madure como un elemento
fundamental de Gestión del Servicio. Las organizaciones
deberán esforzarse continuamente en la revisión y mejora
de su capacidad de Diseño del Servicio, para que pueda
convertirse en una práctica consistente y repetible, que
permita a las organizaciones entregar servicios de calidad
cumpliendo plazos de ejecución exigentes. Disponer
de una práctica de Diseño del Servicio madura también
824_003 Chapter 02.indd 18
permitirá a las organizaciones reducir el riesgo en las
etapas operativas y de transición del servicio.
En general, la clave para la provisión de servicios de TI
con éxito, es un nivel apropiado de diseño y planificación
para determinar los proyectos, procesos y servicios que
tendrán el mayor impacto o beneficio para el negocio.
Con el nivel adecuado de concepto, diseño, preparación y
planificación, el esfuerzo se puede dirigir a aquellas áreas
que generen el máximo retorno. La gestión y evaluación
del riesgo son requisitos clave de todas las actividades
de diseño. Por lo tanto, los cinco aspectos de Diseño del
Servicio deben incluir la evaluación y gestión del riesgo
como una parte integrada e inherente de todas sus
actividades. Esto asegurará que los riesgos implicados en
la provisión de servicios y en la operación de los procesos,
tecnología y métodos de medida se alineen con el riesgo
e impacto en el negocio, ya que la evaluación y gestión
del riesgo se integran dentro de todos los procesos y
actividades de diseño.
Muchos diseños, planes y proyectos fallan por la falta de
preparación y gestión. La implementación de Gestión del
Servicio de ITIL como práctica trata sobre la preparación y
planificación del uso eficaz y eficiente de las cuatro P: las
Personas, los Procesos, los Productos (servicios, tecnología
y herramientas) y los Socios (Partners) (suministradores,
fabricantes y proveedores), como se ilustra en la Figura
2.4.
Sin embargo, no se obtiene ningún beneficio si se
generan diseños, planes, arquitecturas y políticas y no se
comparten. Deberán publicarse, acordarse, distribuirse y
emplearse activamente.
Para garantizar que el negocio y los servicios de TI
permanezcan sincronizados, muchas organizaciones
forman comités de gestión senior a partir del negocio
y organizaciones de TI. El comité se responsabiliza
globalmente del establecimiento del gobierno, dirección,
política y estrategia para servicios de TI. Muchas
organizaciones hacen referencia a este grupo como el
Grupo de Dirección y Estrategia de TI. (ISG). La función
Personas
Productos/
Procesos
Tecnología
Socios/
Suministradores
Figure 2.4  Las cuatro P
22/1/10 14:04:29

de un ISG es actuar como un socio entre TI y el negocio.
Debería cumplir y revisar regularmente las estrategias,
diseños, planes, Porfolio de Servicios, arquitecturas y ■■
políticas del negocio y de TI para garantizar que se
alineen estrechamente entre ellos. Debería proporcionar
la visión, establecer la dirección y determinar prioridades ■■
de programas individuales y proyectos para garantizar que
TI se alinee con, y se centre en, los objetivos y directrices
del negocio. El grupo también deberá garantizar que
el negocio o TI no impongan escalas de tiempos poco
realistas, que pudieran poner en peligro la calidad o ■■
degradar requisitos operativos normales. Vea la Figura 2.5.
El ISG incluirá el análisis de todos los aspectos del
negocio que afecten al servicio de TI, además del cambio ■■
propuesto o posible a nivel estratégico. Las materias a
analizar por el ISG podrían incluir:
■■ Revisión de los planes de negocio y de TI: para
identificar cualquier cambio en cualquier área que ■■
pudiera impulsar la necesidad de crear, refinar o
mejorar servicios.
■■ Planificación de la demanda: para identificar
cualquier cambio en la demanda para horizontes
de planificación a corto y largo plazo; tales cambios ■■
Estrategias y planes corporativos
Estrategias y planes de negocios
Planes de la Planes de la
Planes de Unidad de Unidad de
negocio de TI Negocio 1 Negocio 2
Estrategias y planes funcionales
Planes Planes de Planes de
de TI la Unidad 1 la Unidad 2 la Unidad 3
Estrategias y planes operativos
Planes Planes de Planes de
de TI la Unidad 1 la Unidad 2 la Unidad 3
Figura 2.5  El Grupo de Estrategia/Dirección de TI
824_003 Chapter 02.indd 19
Gestión del Servicio como una práctica | 19
podrían aumentar o disminuir la demanda, y afectar a
los proyectos y actividades habituales del negocio.
Priorización y autorización de los proyectos: para
garantizar que los proyectos se autoricen y prioricen
para la satisfacción mutua del negocio y TI.
Revisión de proyectos: para garantizar que los
beneficios de negocio esperados se estén logrando
de acuerdo con los casos de negocio del proyecto,
e identificar si los proyectos están dentro de la
programación.
Externalización potencial: para identificar la
necesidad y el contenido de las estrategias de
aprovisionamiento del servicio de TI.
Revisión de la estrategia del negocio/TI: para
analizar cambios importantes en la estrategia de
negocio y de TI y en la tecnología para garantizar el
alineamiento continuo.
Continuidad del Negocio y Continuidad del
Servicio de TI: para que el grupo, o una parte del
mismo, sea responsable de alinear las estrategias de
Continuidad del Negocio y de Continuidad del Servicio
de TI.
Políticas y estándares: el ISG es responsable de
garantizar que las políticas y estándares de TI,
Metas
Objetivos
Planes de la
Unidad de
Negocio 3
Consejo
de
Dirección
Planes de de TI
Planes de
Porfolio de Servicios
22/1/10 14:04:29
 20 | Gestión del Servicio como una práctica
particularmente en relación con la estrategia financiera
y con la gestión del rendimiento, estén alineados con
los objetivos y la visión corporativa general.
El Grupo de Dirección de TI establece la dirección de las
políticas y planes desde los niveles corporativos hasta los
niveles operativos de la organización de TI y garantiza que
sean consistentes con las estrategias de nivel corporativo.
Vea la Figura 2.5.
El ISG tiene que desempeñar un rol importante en el
alineamiento de las estrategias y planes de negocio y de
TI, como se ilustra en la Figura 2.5. Como puede verse, el
Portfolio de Servicios es una fuente clave de entrada en el
ISG en su rol de toma de decisiones que permite al ISG:
■■ Dirigir y guiar la selección de la inversión en aquellas
áreas que generen el mayor valor para el negocio y el
máximo Retorno de la Inversión.
■■ Realizar un programa eficaz y la selección, priorización
y planificación de proyectos.
■■ Ejercer un gobierno continuo eficaz y una gestión
activa del flujo de creación de los requisitos de
negocio.
■■ Garantizar que se logren los beneficios de negocio
proyectados de los programas y proyectos.
2.4.3 Valor para el negocio
Con un buen Diseño del Servicio es posible entregar
servicios rentables y de calidad y garantizar que se
cumplan los requisitos de negocio.
A continuación se indican los beneficios que resultarán de
una buena práctica de Diseño del Servicio:
■■ Reducción del Coste Total de Propiedad (TCO): el
coste de propiedad sólo se puede minimizar si todos
los aspectos de los servicios, procesos y tecnología se
diseñan e implementan adecuadamente con respecto
al diseño.
■■ Mejora de la calidad del servicio: se mejorará la
calidad del servicio y la calidad operativa.
■■ Mejora de la consistencia del servicio: dado que
los servicios se diseñan dentro de la estrategia,
arquitecturas y restricciones corporativas.
■■ Mejora de la facilidad de implementación de
servicios nuevos o modificados: dado que existe
un Diseño del Servicio completo e integrado y la
producción de SDPs integrales.
■■ Mejora del alineamiento del servicio: implicación
desde la concepción del servicio, garantizando que
los servicios nuevos o modificados se correspondan
con las necesidades del negocio, y que los servicios
diseñados cumplan los Requisitos de Nivel de Servicio.
824_003 Chapter 02.indd 20
■■ Rendimiento del servicio más eficaz: con la
incorporación e identificación de la Capacidad,
Disponibilidad Financiera y Planes de Continuidad del
Servicio de TI.
■■ Mejora del gobierno de TI: ayudar a la
implementación y comunicación de un conjunto de
controles para el gobierno eficaz de TI.
■■ Procesos de Gestión del Servicio y de TI más
eficaces: los procesos se diseñarán con la rentabilidad
y calidad óptimas.
■■ Mejora de la información y de la toma de
decisiones: medidas y métricas más integrales y
eficaces permitirán una mejor toma de decisiones y
una mejora continua de las prácticas de Gestión del
Servicio en la etapa de diseño del Ciclo de Vida del
Servicio.
2.4.4 Optimización del rendimiento  
del diseño
La optimización de las actividades de diseño requiere
la implementación de procesos documentados, junto
con la modificación del sistema de gestión de la calidad
(como por ejemplo ISO 9001) para su medición y mejora
continua. Es importante que al considerar la mejora y
optimización de las actividades de Diseño del Servicio,
se mida el impacto de las actividades en todas las etapas
del ciclo de vida y no sólo el impacto en la etapa de
diseño. Por lo tanto, las medidas y métricas de Diseño
del Servicio deben ver el nivel de actividad de puesta
al día y de mejora que es necesario en las actividades
de transición, operación y mejora como resultado de
una inadaptabilidad dentro del diseño de soluciones del
servicio nuevas y modificadas. En la sección 8.5 se puede
encontrar más información sobre la medición de Diseño
del Servicio.
2.4.5  Procesos dentro de Diseño  
del Servicio
Esta publicación detalla los procesos que se requieren
en la fase de diseño del Ciclo de Vida del Servicio. Estos
procesos no se pueden considerar de forma aislada,
ya que su valor real sólo se hará evidente cuando se
identifiquen y se accionen las interfaces entre los procesos.
En esta publicación se detallan los siguientes procesos:
■■ Gestión del Catálogo de Servicios: para garantizar
que se genere y mantenga un Catálogo de Servicios
que contenga información detallada sobre todos los
servicios operativos y sobre aquellos que se estén
preparando para que funcionen operativamente.
22/1/10 14:04:29
 Gestión del Servicio como una práctica | 21

■■ Gestión del Nivel de Servicio: negocia, acuerda y tomar las decisiones correctas rápidamente y ejecutarlas
documenta objetivos de servicio de TI apropiados de igual forma. Si la decisión implicara una decisión
con representantes del negocio, y a continuación estratégica o una operación crítica, es importante tener
monitoriza y genera informes sobre la capacidad del claro quién introduce, quién decide y quién toma las
proveedor de servicio a la hora de entregar el nivel de acciones que permitirán a la organización seguir adelante
servicio acordado. rápidamente.
■■ Gestión de la Capacidad: para garantizar que siempre
exista capacidad de TI con costes justificables en
todas las áreas de TI y que se corresponda con las
necesidades actuales y futuras acordadas del negocio.
■■ Gestión de la Disponibilidad: para garantizar que
la disponibilidad del nivel de servicio en todos los
servicios corresponda o supere las necesidades
actuales y futuras acordadas del negocio, y de forma
rentable.
■■ Gestión de la Continuidad del Servicio de TI: para
garantizar que las instalaciones técnicas y del
servicio de TI (que incluyen sistemas informáticos,
redes, aplicaciones, repositorios de datos,
telecomunicaciones, entorno, soporte técnico y Centro
de Servicio al Usuario) puedan renovarse según los
plazos de tiempo de negocio requeridos y acordados.
■■ Gestión de la Seguridad de la Información: para alinear
la seguridad de TI con la seguridad del negocio, y
para garantizar que la seguridad de la información se
gestione de forma eficaz en todas las actividades del
servicio y de Gestión del Servicio.
■■ Gestión de Suministradores: para gestionar
proveedores y los servicios que suministran para
proporcionar la calidad continua del servicio de TI
para el negocio, asegurando que se obtenga valor por
el dinero.
Éstos son sólo algunos de los procesos descritos en la guía
práctica de Gestión del Servicio de ITIL. Todos los procesos
dentro el ciclo de vida de Gestión del Servicio se deben
vincular estrechamente con la gestión, diseño, soporte
y mantenimiento de los servicios, infraestructura de TI,
entorno, aplicaciones y datos. Otros procesos se describen
con detalle en otras publicaciones de la biblioteca central
de prácticas de Gestión del Servicio de ITIL. Es necesario
definir claramente las interfaces entre todos los procesos
al definir un servicio o al mejorar o implementar un
proceso. Estas interfaces se describen con detalle en la
sección 4 e incluyen no sólo las interfaces de cada uno
de los procesos de Diseño del Servicio, sino también las
interfaces con procesos dentro de otras etapas del ciclo de
vida.
Al diseñar un servicio o proceso, es imperativo que se
definan claramente todos los roles. Un indicativo de
organizaciones de alto rendimiento es la capacidad de

824_003 Chapter 02.indd 21 22/1/10 14:04:29

824_003 Chapter 02.indd 22 22/1/10 14:04:29
824_004 Chapter 03.indd 23
Principios de Diseñ̃o
del Servicio 3
22/1/10 14:09:33
824_004 Chapter 03.indd 24 22/1/10 14:09:33
 3 Principios de Diseño del Servicio
“Primero asegúrate de que tu meta es sabia y justa: cuando
lo hayas comprobado, persíguela con determinación; nunca,
ni una sola vez, pierdas de vista la meta que te propusiste
alcanzar.”
William Shakespeare (1564–1616)
“El error habitual que las personas cometen cuando
intentan diseñar algo completamente infalible es
menospreciar la ingenuidad de los tontos.”
Douglas Adams
Diseño del Servicio de TI forma parte de todo el proceso
de cambio del negocio. Este proceso de cambio del
negocio y el rol de TI se ilustran en la Figura 3.1.
Cuando se haya obtenido información precisa sobre lo
que se requiere y aprueba en relación con el cambio de
las necesidades del negocio, se puede desarrollar el plan
de entrega de un servicio para satisfacer la necesidad
acordada.
El rol de la etapa de Diseño del Servicio dentro de este
proceso general de cambio del negocio se puede definir
como:
‘El diseño de servicios de TI adecuados e innovadores,
incluyendo sus arquitecturas, procesos, políticas y
documentación, para satisfacer los requisitos de
negocio actuales y futuros acordados’.
Cambio Requisitos Desarrollo
del Proceso de Negocio del Proceso
de Negocio y Viabilidad de Negocio
Requisito
del Servicio de TI
Figura 3.1  El proceso de cambio del negocio
824_004 Chapter 03.indd 25
Es importante que existan las interfaces y vínculos
correctos para las actividades de diseño. Al diseñar
servicios nuevos o modificados, es vital que todo el Ciclo
de Vida del Servicio y procesos de ITSM se impliquen
desde el principio. Normalmente las dificultades se
producen en operaciones cuando se maneja un servicio
diseñado recientemente para que pase a estar activo en el
último minuto. A continuación se muestran acciones que
necesitan emprenderse desde el principio de un Diseño
del Servicio para garantizar que la solución cumpla los
requisitos del negocio:
■■ La nueva solución del servicio deberá añadirse
al Porfolio de Servicios general desde la fase de
concepto, y el Porfolio de Servicios deberá actualizarse
para reflejar el estado actual a través de cualquier
desarrollo incremental o iterativo. Esto será beneficioso
no sólo desde la perspectiva financiera, sino también
desde todas las demás áreas durante el diseño.
■■ Dentro del análisis inicial del servicio/sistema, existirá
la necesidad de entender los Requisitos de Nivel del
Servicio (SLRs) del servicio cuando pase a estar activo.
■■ A partir de los SLR, el equipo de Gestión de la
Capacidad puede modelar esto dentro de la
infraestructura actual hasta cerciorarse de que podrá
dar soporte al nuevo servicio. Si el tiempo lo permite,
los resultados de las actividades de modelado podrán
formar parte del Plan de Capacidad.
■■ Si se requiriera una nueva infraestructura para
el nuevo servicio, o ampliar el soporte, Gestión
Financiera necesitará implicarse para establecer el
presupuesto.
Implement. Realización
del Proceso del Proceso
de Negocio de Negocio
Servicio de TI
Ciclo de Vida del Servicio de TI
22/1/10 14:09:33
 26 | Principios de Diseñ̃o del Servicio

■■ Deberá realizarse un Análisis de Impacto en el Negocio
y una evaluación del riesgo sobre los servicios antes
de la implementación como entrada inestimable en
Estrategia de la Continuidad del Servicio de TI, Diseño
de Disponibilidad y Planificación de la Capacidad.
■■ El Centro de Servicio al Usuario necesitará ser
consciente de los nuevos servicios antes de la
operación real para preparar y formar al Centro de
Servicio al Usuario y potencialmente al personal del
cliente de TI.
■■ Transición del Servicio puede iniciar la planificación
de la implementación e incorporar la planificación de
cambios.
■■ Gestión de Suministradores necesitará implicarse si
fuera necesario involucrar a Compras para el nuevo
servicio.
La composición de un servicio y las partes que lo forman
se ilustra en la Figura 3.2.
Diseño del Servicio debe considerar todos estos
aspectos al diseñar soluciones del servicio para satisfacer
necesidades del negocio nuevas y evolucionadas:
■■ Proceso de negocio: para definir las necesidades
funcionales del servicio que se está proporcionando,
por ejemplo, telemarketing, facturación, pedidos,
comprobación de crédito.
■■ Servicio: el propio servicio que se está entregando
a los clientes y al negocio mediante el proveedor de
servicio, por ejemplo, correo electrónico, facturación.
■■ SLAs/SLRs: los documentos acordados con los clientes
que especifican el nivel, ámbito y calidad del servicio
a proveer.
■■ Infraestructura: todos los equipos de TI necesarios
para entregar el servicio a los clientes y usuarios,
incluyendo servidores, circuitos de red, switches, PCs,
teléfonos.
■■ Entorno: el entorno requerido para asegurar y operar
la infraestructura, por ejemplo, centros de datos,
alimentación, aire acondicionado.
■■ Datos: los datos necesarios para dar soporte al
servicio y proporcionar la información requerida por
los procesos de negocio, por ejemplo, registros de
clientes, libro mayor de contabilidad.

Servicio de negocio A
Gestión del Servicio
de Negocio
Proceso de Proceso de Proceso de
Requisitos/demanda: Negocio 1 Negocio 2 Negocio 3

Conformidad con
Servicio de TI la politica/estrategia
de gobierno
Utilidad:
Nombre, descripción, Servicio
propósito, impacto,
contactos
Garantía: SLAs/SLRs
Niveles de servicio, objetivos, incluyendo
horario de servicio, aseguramiento, coste/precio
responsabilidades

Activos/recursos:
Sistemas, activos, Infraestructura Entorno Datos Aplicaciones
componentes

Activos/capacidades: Contratos Servicios Procesos

Proceso, objetivos de soporte, OLAs de soporte
recursos de TI

Activos/capacidades: Equipos Suminis-

Recursos, personal, habilidades de soporte tradores

Figura 3.2  Composición del servicio

824_004 Chapter 03.indd 26 22/1/10 14:09:34


■■ Aplicaciones: todas las aplicaciones de software
requeridas para manipular los datos y proporcionar los
requisitos funcionales de los procesos de negocio, por
ejemplo, ERM, Financieros, CRM.
■■ Servicios de Soporte: cualquier servicio que sea
necesario para dar soporte a la operación del servicio
entregado, por ejemplo, un servicio compartido, un
servicio de red gestionado.
■■ Acuerdos de Nivel Operativo (OLA) y contratos:
cualquier acuerdo de soporte necesario para entregar
la calidad del servicio acordada dentro del SLA.
■■ Equipos de Soporte: cualquier equipo de soporte
interno que proporciona soporte de segunda y tercera
línea para cualquiera de los componentes requeridos
para proporcionar el servicio, por ejemplo, Unix,
mainframe, redes.
■■ Suministradores: cualquier tercero externo necesario
para proveer soporte de tercera y cuarta línea para
cualquier componente requerido para proveer el
servicio, por ejemplo, redes, hardware, software.
Las actividades de diseño no sólo deberán considerar
cada uno de los componentes anteriores de forma aislada,
también deberá considerar las relaciones entre cada uno
de ellos y sus iteraciones y dependencias con cualquier
otro componente y servicio, para proporcionar una
solución eficaz e integral que satisfaga las necesidades del
negocio.
3.1  Metas
Las metas y objetivos principales de Diseño del Servicio
son:
■■ Diseñar servicios para satisfacer objetivos de negocio,
basándose en los requisitos de calidad, conformidad,
riesgo y seguridad; entregando soluciones y servicios
de negocio y de TI más eficaces y eficientes alineados
con las necesidades del negocio, coordinando todas
las actividades de diseño de servicios de TI para
asegurar la consistencia y el enfoque en el negocio.
■■ Diseñar servicios que puedan desarrollarse y mejorarse
de forma fácil y eficiente dentro de las escalas de
tiempo y costes adecuados, y siempre que sea posible,
reducir, minimizar o limitar los costes a largo plazo de
la provisión del servicio.
■■ Diseñar procesos eficientes y eficaces para el diseño,
transición, operación y mejora de servicios de TI de
alta calidad, junto con las herramientas, sistemas e
información de soporte, especialmente el Porfolio de
Servicios, para gestionar servicios a través de su ciclo
de vida.
824_004 Chapter 03.indd 27
Principios de Diseñ̃o del Servicio | 27
■■ Identificar y gestionar riesgos para que puedan
retirarse o mitigarse antes de que los servicios pasen a
estar activos.
■■ Diseñar infraestructuras de TI con capacidad de
recuperación, entornos, aplicaciones y fuentes de
datos/información y capacidad que satisfagan las
necesidades actuales y futuras del negocio y de los
clientes.
■■ Diseñar métodos de medida y métricas para evaluar la
eficacia y eficiencia de los procesos de diseño y de sus
entregables.
■■ Generar y mantener planes, procesos, políticas,
arquitecturas, marcos de trabajo y documentos de TI
para el diseño de soluciones de TI de calidad, para
satisfacer las necesidades del negocio actuales y
futuras acordadas.
■■ Ayudar al desarrollo de políticas y estándares
en todas las áreas de diseño y planificación de
procesos y servicios de TI, recibir y actuar sobre la
retroalimentación con respecto a los procesos de
diseño desde todas las demás áreas, e incorporar las
acciones en un proceso continuo de mejora.
■■ Desarrollar las habilidades y capacidad dentro de TI
convirtiendo actividades de estrategia y diseño en
tareas operativas, haciendo un uso eficaz y eficiente
de todos los recursos del servicio de TI.
■■ Contribuir a la mejora de la calidad general del
servicio de TI dentro de las restricciones impuestas por
el diseño, especialmente reduciendo la necesidad de
volver a poner al día y mejorar servicios una vez se
hayan implementado en el entorno de producción.
3.2  Diseño equilibrado
Para cualquier requisito de negocio, el diseño de servicios
es un acto de equilibrio delicado, garantizando que
se cumplan los requisitos funcionales además de los
objetivos de rendimiento. Todo esto deberá equilibrarse en
relación con los recursos disponibles dentro de los plazos
de tiempo requeridos y de los costes para los nuevos
servicios. Jim McCarthy, autor de Dynamics of Software
Development, establece: ‘Como gestor de desarrollo, está
trabajando únicamente con tres aspectos’:
■■ Funcionalidad: el servicio o producto y sus
instalaciones, funcionalidad y calidad, incluyendo todas
las funcionalidades operativas y de gestión requeridas.
■■ Recursos: las personas, tecnología y dinero
disponibles.
■■ Programa: los plazos de tiempo.
Éstos se analizan en la Figura 3.3.
22/1/10 14:09:34
 28 | Principios de Diseñ̃o del Servicio

Estrategia Gobierno

Pla
os

nifi
urs

cac
Rec

Funcionalidad ión

Funcionalidad de negocio
Requisitos de gestión
Requisitos legislativos
Requisitos regulatorios
etc...

Figura 3.3  Elementos del proyecto en una relación triangular

Este concepto es extremadamente importante para las
actividades de Diseño del Servicio y para el equilibrio
entre el esfuerzo que se dedica en el diseño, desarrollo
y entrega de servicios como respuesta a los requisitos
de negocio. Diseño del Servicio es un acto de delicado
equilibrio de los tres elementos y de ajuste dinámico
constante de éstos para satisfacer las necesidades
cambiantes del negocio. Invariablemente, el cambio
de un lado del triángulo tendrá impacto en al menos
uno de los demás lados, si no en ambos. Por lo tanto,
es muy importante que las directrices y necesidades
del negocio se entiendan perfectamente para que se
diseñen y entreguen las soluciones de negocio más
eficaces, usando el equilibrio más apropiado de estos tres
elementos. Es probable que las directrices y necesidades
del negocio cambien durante el diseño y entrega debido
a las presiones del mercado. Deberán considerarse la
funcionalidad y los recursos para todas las etapas del
Ciclo de Vida del Servicio para que los servicios no sólo se
diseñen y desarrollen de forma eficaz y eficiente, sino que
se mantenga la eficacia y eficiencia del servicio a través de
todas las etapas de su ciclo de vida.
Se debe prestar la debida consideración dentro de Diseño
del Servicio a todas las etapas siguientes dentro del Ciclo
de Vida del Servicio. En muchas ocasiones los diseñadores
y arquitectos sólo consideran el desarrollo de un nuevo
servicio hasta el momento de la implementación del
servicio en el entorno de producción. Deberá adoptarse
un método integral en el diseño de servicios de TI para
asegurar que se diseñe una solución completamente
integrada y global para satisfacer los requisitos acordados
del negocio. Este método también deberá garantizar que
se implementen todos los mecanismos y funcionalidades
necesarios dentro del nuevo servicio para que pueda
ser gestionado y mejorado de forma eficaz a lo largo
de su vida útil operativa para lograr todos los objetivos
del servicio acordados. Deberá adoptarse un método
estructurado y formal para garantizar que se aborden
todos los aspectos del servicio y para garantizar su
adecuada introducción y operación dentro del entorno de
producción.
Los proveedores de servicios de TI más eficaces integran
los cinco aspectos del diseño en lugar de diseñarlos
de forma aislada. Esto garantiza que se genere una
Arquitectura de la Empresa integrada, consistente

824_004 Chapter 03.indd 28 22/1/10 14:09:34

 Principios de Diseñ̃o del Servicio | 29

con respecto a un conjunto de estándares, diseños y
arquitecturas que satisfagan todos los requisitos operativos
y de gestión de los servicios, además de la funcionalidad
requerida por el negocio. Este diseño integrado
garantiza que cuando se implemente un servicio nuevo
o modificado, éste no sólo proporcione la funcionalidad
requerida por el negocio, sino también satisfaga y
continúe satisfaciendo todos los niveles de servicio y
objetivos en todas las áreas. Esto asegura que no sea
necesario abordar ninguna debilidad (o mínimo absoluto)
retrospectivamente.
Para lograr esto, la gestión general de estas actividades de
diseño necesita asegurar:
■■ Una buena comunicación entre las diferentes
actividades de diseño y todas las demás partes,
incluyendo los planificadores y estrategas del negocio
y de TI.
■■ Que las últimas versiones de todos los planes y
estrategias adecuadas del negocio y de TI estén
disponibles para todos los diseñadores.
■■ Que todos los documentos de arquitectura y diseño
sean consistentes con todas las políticas y planes del
negocio y de TI.
■■ Que las arquitecturas y diseños:
●● Sean flexibles y permitan a TI responder
rápidamente a las nuevas necesidades.
●● Se integren con todas las estratégicas y políticas.
●● Respalden las necesidades de otras etapas del Ciclo
de Vida del Servicio.
●● Faciliten soluciones y servicios nuevos o
modificados de calidad, alineados con las
necesidades y plazos de tiempo del negocio.
3.3  Identificación de los requisitos
del servicio
Diseño del Servicio deberá considerar todos los elementos
del mismo asumiendo un método integral para el diseño
de un nuevo servicio. Este método debería considerar
el servicio y sus componentes y sus interrelaciones,

Unidad de Negocio A Unidad de Negocio B Unidad de Negocio C

El negocio
3 6 9
2 5 8
Proceso Proceso Proceso
de negocio 1 de negocio 4 de negocio 7

Servicios de TI

B C
Servicio A SLAs
TI

Infraestructura

Sistema Sistema
DBMS Redes Entorno Datos Aplicaciones
H/W S/W

OLAs Servicios
de soporte

Equipos
Servicios Contratos
de soportes
(iii)
(ii) Suministradores
Equipo
de soporte (i)
(iii)
(ii)
Suministrador (i)

Figura 3.4  Las relaciones y dependencias del servicio

824_004 Chapter 03.indd 29 22/1/10 14:09:35

 30 | Principios de Diseñ̃o del Servicio
garantizando que los servicios entregados cumplan la
funcionalidad y calidad esperadas por el negocio en todas
las áreas:
■■ La escalabilidad del servicio para cumplir futuros
requisitos con respecto al soporte de los objetivos de
negocio a largo plazo.
■■ Los procesos de negocio y unidades de negocio a los
que da soporte el servicio.
■■ El servicio de TI y los requisitos y funcionalidades
acordados del negocio.
■■ El propio servicio y su Requisito de Nivel de Servicio
(SLR) o Acuerdo de Nivel de Servicio (SLA).
■■ Los componentes tecnológicos usados para desplegar
y entregar el servicio, incluyendo la infraestructura, el
entorno, los datos y las aplicaciones.
■■ Los servicios y componentes a los que se les da
soporte internamente y sus Acuerdos de Nivel
Operativo (OLA) asociados.
■■ Los servicios y componentes a los que se les da
soporte externamente y sus contratos de soporte
asociados, que con frecuencia tienen sus propios
acuerdos y/o programaciones asociados.
■■ Las medidas y métricas de rendimiento requeridas.
■■ Los niveles de seguridad requeridos o legislados.
Las relaciones y dependencias entre estos elementos se
ilustran en la Figura 3.4.
Ningún servicio se puede diseñar, pasar por transición
ni operarse de forma aislada. Todas las personas de la
organización del proveedor de servicio deberán entender
e identificar claramente la relación de cada uno, con sus
servicios y componentes de soporte. También es esencial
que todos los objetivos contenidos dentro de los acuerdos
de soporte, como por ejemplo OLAs y contratos, soporten
aquellos acordados entre el proveedor y sus clientes.
Algunos de estos conceptos se analizan con más detalle
en secciones posteriores de la publicación, con respecto
a los aspectos individuales de Diseño del Servicio. Sin
embargo, cuando se modifica un aspecto individual de un
servicio, también deberían considerarse todas las demás
áreas del mismo para garantizar que se incluyan en el
diseño general todas las modificaciones necesarias para
dar soporte al cambio. Los servicios son cada vez más
complejos y se entregan mediante varias organizaciones
suministradoras o asociadas. Si estuvieran implicados
múltiples proveedores en la entrega de un servicio, es
muy importante que se establezca una autoridad central
de Diseño del Servicio para asegurar que los servicios y
procesos se integren completamente a través de todas las
partes.
824_004 Chapter 03.indd 30
Dentro del área específica de tecnología, existen cuatro
dominios tecnológicos independientes que será necesario
abordar ya que son los componentes de soporte de todo
servicio y contribuyen a su rendimiento general:
■■ Infraestructura: la gestión y control de todos
los elementos de la infraestructura, incluyendo
mainframes, servidores, equipo de red, sistemas de
bases de datos, redes de área de almacenamiento
(SANs), almacenamiento acoplado a la red (NAS),
software de sistemas, utilidades, sistemas de
backup, firewalls, entornos de desarrollo y prueba,
herramientas de gestión, etc.
■■ Entorno: la gestión y control de todos los
aspectos del entorno de todas las salas de equipos
principales, incluyendo el espacio físico y distribución,
alimentación, aire acondicionado, cableado, seguridad
física, etc.
■■ Datos: la gestión y control de todos los datos e
información y su acceso asociado, incluyendo datos de
prueba si fuera aplicable.
■■ Aplicaciones: la gestión y control de todo el software
de aplicaciones, incluyendo aplicaciones compradas y
software de aplicaciones desarrolladas internamente.
3.4  Identificación y documentación
de las directrices y requisitos de
negocio
TI debe incluir información precisa sobre directrices y
requisitos de negocio para proporcionar el catálogo de
servicios más apropiado con un nivel aceptable de calidad
del servicio que se alinee con las necesidades del negocio.
Las directrices de negocio son las personas, información y
tareas que dan soporte al cumplimiento de los objetivos
de negocio. Esto requiere que TI desarrolle y mantenga
relaciones estrechas, regulares y apropiadas e intercambie
información para entender los requisitos operativos,
tácticos y estratégicos del negocio. Esta información
necesita obtenerse y acordarse en dos áreas principales
para mantener el alineamiento del servicio:
■■ Información sobre los requisitos de servicios
existentes – qué cambios se requerirán para los
servicios existentes en relación con:
●● Requisitos funcionales y nuevas instalaciones.
●● Cambios en procesos, dependencias, prioridades,
criticidad e impacto en el negocio.
●● Cambios en los volúmenes de transacciones del
servicio.
●● Aumento de los niveles de servicio y objetivos
de nivel de servicio debido a nuevas directrices
22/1/10 14:09:35

de negocio, o reducción de éstos para servicios
antiguos, reduciendo la prioridad para aquellos que
se sustituirán.
●● Necesidades adicionales para la información de
Gestión del Servicio.
■■ Información sobre los requisitos de nuevos
servicios:
●● Instalaciones y funcionalidades requeridas.
●● Información de gestión requerida y necesidades de
gestión.
●● Procesos soportados, dependencias, prioridades,
criticidad e impacto en el negocio.
●● Ciclos de negocio y variaciones estacionales.
●● Requerimientos de Nivel de Servicio y objetivos de
nivel de servicio.
●● Niveles de transacción del negocio, niveles de
transacción del servicio, números y tipos de
usuarios y crecimiento futuro anticipado.
●● Los resultados financieros y no financieros del caso
de negocio.
●● Nivel previsto de cambio, por ejemplo, futuros
requisitos conocidos del negocio o mejora.
●● Nivel de capacidad del negocio o soporte a
proveer, por ejemplo, soporte local basado en el
negocio.
Esta recopilación de información es la primera etapa y
más importante para el diseño y entrega de servicios
nuevos o modificados o cambios importantes en servicios
existentes. Es primordial obtener información precisa
y representativa del negocio. Esto debe acordarse y
concluirse con representantes senior del negocio. Si en
esta etapa se obtuviera y usara información incorrecta o
engañosa, entonces todas las etapas siguientes entregarán
servicios que no correspondan con las necesidades del
negocio. Además, deberá haber algún proceso formal
para el acuerdo y aceptación de cambios en los requisitos
de negocio, ya que éstos en muchas ocasiones cambian
y evolucionan durante el Ciclo de Vida del Servicio. Los
requisitos y el diseño deberán evolucionar con el entorno
cambiante del negocio para garantizar que se cumplan las
expectativas del negocio. Sin embargo, este debe ser un
proceso gestionado con precisión para garantizar que la
velocidad de cambio se mantenga en un nivel acordado y
gestionable, y que no ‘contamine’ y retrase excesivamente
el proyecto o su implementación.
Para diseñar y entregar servicios de TI que satisfagan
las necesidades de los clientes y del negocio, deberán
documentarse y acordarse especificaciones de los
requisitos de forma clara, concisa y sin ambigüedades. El
tiempo dedicado a estas actividades evitará problemas
824_004 Chapter 03.indd 31
Principios de Diseñ̃o del Servicio | 31
y discusiones que pudieran surgir posteriormente en
relación con las variaciones con respecto a las expectativas
del cliente y del negocio. Esta etapa de requisitos de
negocio deberán consistir en lo siguiente:
■■ Nombramiento de un jefe de proyecto, creación de un
equipo de proyecto y acuerdo de gobierno del mismo
con la aplicación de una metodología de proyecto
formal y estructurada.
■■ Identificación de todos los interesados, incluyendo
la documentación de todos sus requisitos y
los beneficios de éstos que se obtendrán de la
implementación.
■■ Análisis de requisitos, priorización, acuerdo y
documentación.
■■ Determinación y acuerdo de presupuestos detallados
y de los beneficios para el negocio. La dirección
deberá comprometerse con el presupuesto ya que es
una práctica normal decidir el presupuesto del año
siguiente en el último trimestre del año anterior, por
lo que cualquier plan deberá enviarse dentro de este
ciclo.
■■ Resolución de conflictos potenciales entre unidades de
negocio y acuerdo delos requisitos corporativos.
■■ Procesos aprobados para los requisitos acordados y
un método para acordar y aceptar cambios en los
mismos. En muchas ocasiones el proceso de desarrollo
de requisitos es un método iterativo o incremental
que necesita controlarse detenidamente para gestionar
el aumento imprevisto del alcance.
■■ Desarrollo de un plan de compromiso que describa
las relaciones principales entre TI y el negocio y cómo
se gestionarán estas relaciones y la comunicación
necesaria para ampliar el número de interesados.
Si se vieran afectados los requisitos del servicio, algunas
veces irán acompañados con una etiqueta de precio (que
puede que no se conozca completamente en esta etapa),
por lo que siempre será necesario que haya un equilibrio
entre el servicio disponible y el coste. Esto podría significar
que algunos requisitos podrían ser demasiado costosos
para incluirlos y podrían tener que eliminarse durante la
evaluación financiera correspondiente dentro del proceso
de diseño. Si esto fuera necesario, todas las decisiones
de omitir cualquier requisito del servicio del diseño
del mismo deberán documentarse y acordarse con los
representantes del negocio. En muchas ocasiones es difícil
cuando lo que desea el negocio y el presupuesto asignado
para la solución no tiene en cuenta todos los costes del
servicio, incluyendo los costes corrientes.
22/1/10 14:09:35
 32 | Principios de Diseñ̃o del Servicio
3.5  Actividades de diseño
Todas las actividades de diseño se activan mediante
cambios en las necesidades del negocio o por mejoras
en el servicio. Deberá adoptarse un método estructurado
e integral en las actividades de diseño para que se
considere toda la información disponible para garantizar
que se logre consistencia e integración a través de la
organización del proveedor de servicios de TI, en todas las
actividades de diseño.
Mensaje clave
Las arquitecturas y diseños deberán ser claros, concisos,
simples y pertinentes. Con suma frecuencia, los diseños
y arquitecturas son complejos y teóricos y no se
corresponden con el mundo real.
El principal problema a día de hoy es que, con frecuencia,
las organizaciones sólo se centran en los requisitos
funcionales. Por definición, un diseño o arquitectura
necesita considerar todos los aspectos del diseño. No
significa que sea una organización más pequeña la que
combina estos aspectos, significa que es una organización
sensible.
Las actividades de los procesos de diseño son:
■■ Recopilación de requisitos, análisis e ingeniería
para garantizar que los requisitos de negocio se
documenten y acuerden claramente.
■■ Diseño adecuado de servicios, tecnología, procesos,
información y medidas de procesos para satisfacer
requisitos de negocio.
■■ Revisión de todos los procesos y documentos
implicados en Diseño del Servicio, incluyendo diseños,
planes, arquitecturas y políticas.
■■ Vinculación con los demás roles y actividades de
planificación y diseño, por ejemplo, diseño de
solución.
■■ Producción y mantenimiento de políticas de TI y
documentos de diseño, incluyendo diseños, planos,
arquitecturas y políticas.
■■ Revisión de todos los documentos de diseño, y
planificación para el despliegue e implementación
de estrategias de TI con el uso de ‘hojas de ruta’,
programas y planes de proyecto.
■■ Evaluación del riesgo y gestión de todos los procesos
y entregables del diseño.
■■ Garantizar el alineamiento con todas las estrategias y
políticas corporativas y de TI.
824_004 Chapter 03.indd 32
Las entradas a las diversas actividades de diseño son:
■■ Visiones, estrategias, objetivos, políticas y planes, tanto
corporativos, como del negocio, incluyendo Planes de
Continuidad del Negocio (BCPs).
■■ Restricciones y requisitos para adecuarse a las
regulaciones y estándares legislados.
■■ Estrategias de TI y documentos estratégicos (desde
Estrategia del Servicio):
●● Todas las estrategias, políticas y planes estratégicos
de TI.
●● Detalles de los requisitos de negocio.
●● Todas las restricciones, presupuestos financieros y
planes.
●● El Porfolio de Servicios.
●● Visiones, estrategias, políticas, objetivos y planes de
Gestión del Servicio.
●● Procesos, riesgos y registros de problemas de TI y
de Gestión del Servicio.
●● Planes de Transición del Servicio (Planes de
Cambios, Configuración y Gestión de Versiones y
Despliegues).
●● Políticas de seguridad, manuales y planes.
●● La política de compras y de contratos, estrategia
de proveedores y procesos de Gestión de
Suministradores.
●● Conocimiento, habilidades y capacidad del
personal actual.
●● Planes de negocio de TI, Planes y políticas de
Calidad de TI y del Negocio.
●● Planes de Gestión del Servicio, incluyendo Planes
de Gestión del Nivel de Servicio, SLAs y SLRs,
Programa de Mejora de Servicio (SIP), Planes de
Capacidad, Planes de Disponibilidad, Planes de
Continuidad del Servicio de TI.
■■ Herramientas y técnicas de medida.
Los entregables a partir de las actividades de diseño son:
■■ Revisiones sugeridas para estrategias y políticas de TI.
■■ Diseños revisados, planes y tecnología, y arquitecturas
de gestión que incluyen:
●● La infraestructura de TI y gestión de la
infraestructura, y estrategia, diseños, planes,
arquitecturas y políticas del entorno.
●● Las estrategias, diseños, planes, arquitecturas y
políticas de aplicaciones y datos.
■■ Diseños para servicios, procesos y tecnologías nuevos
o modificados.
■■ Informes de revisión y análisis del proyecto, con
procesos y procedimientos revisados y mejorados.
22/1/10 14:09:35

■■ Procesos y métodos revisados de medición.
■■ Niveles gestionados de riesgo, e informes de
evaluación y gestión del mismo.
■■ Casos de negocio y estudios de viabilidad, junto con
Declaración de Requisitos (SORs) y Convocatorias de
Licitación (ITTs).
■■ Comentarios y retroalimentación sobre los demás
planes.
■■ Beneficio para el negocio y realización de revisiones e
informes.
3.6  Aspectos del diseño
Deberá adoptarse un método integrado general para
las actividades de diseño documentadas en la sección
anterior y deberá incluir el diseño de:
■■ Soluciones del servicio, incluyendo todos los requisitos
funcionales, recursos y capacidades necesarios y
acordados.
■■ Sistemas y herramientas de Gestión del Servicio,
especialmente el Porfolio de Servicios para la gestión y
control de servicios a lo largo de su ciclo de vida.
■■ Arquitecturas tecnológicas, y herramientas y
arquitecturas de gestión requeridas para proveer los
servicios.
■■ Procesos necesarios para el diseño, transición,
operación y mejora de los servicios.
■■ Métricas, métodos y sistemas de medida para los
servicios, las arquitecturas y sus componentes y
procesos.
El aspecto clave es el diseño de soluciones, nuevas o
modificadas del servicio para satisfacer las necesidades del
negocio. Cada vez que se produce una nueva solución del
servicio, es necesario verificarla con respecto a todos los
demás aspectos para garantizar que se integre y haga de
interfaz con todos los demás servicios ya existentes. Estos
cinco aspectos de Diseño del Servicio se analizan con más
detalle en las siguientes secciones. Los planes generados
por Diseño del Servicio para el diseño, transición y
posterior operación de estos cinco aspectos diferentes
deberán incluir:
■■ El método adoptado y los plazos de tiempo asociados.
■■ El impacto organizativo de la solución nueva o
modificada en el negocio y en TI.
■■ El impacto comercial de la solución en la
organización, incluyendo la financiación, costes y
presupuestos requeridos.
■■ El impacto técnico de la solución y el personal y sus
roles, responsabilidades, habilidades, conocimiento,
formación y competencias requeridos para desplegar,
824_004 Chapter 03.indd 33
Principios de Diseñ̃o del Servicio | 33
operar, mantener y optimizar la nueva solución para el
negocio.
■■ La evaluación de la justificación comercial del impacto
de la solución en el negocio existente. Este impacto
deberá evaluarse desde el punto de vista de procesos
de TI y de Gestión del Servicio, incluyendo su
capacidad y rendimiento.
■■ La evaluación y atenuación de los riesgos en los
servicios, procesos y actividades de Gestión del
Servicio.
■■ Planificación de la comunicación y todos los aspectos
de la comunicación con todas las partes interesadas.
■■ El impacto de la solución en contratos o acuerdos
existentes o nuevos.
■■ Los resultados esperados de la operación del
servicio nuevo o modificado en términos medibles,
generalmente expresados dentro de Acuerdos de
Nivel de Servicio (SLAs) nuevos o existentes, niveles de
servicio y satisfacción del cliente.
■■ La generación de un Paquete de Diseño del Servicio
(vea el Apéndice A) que contenga todo lo necesario
para la prueba, introducción y operación posteriores
de la solución o servicio.
■■ La generación de un conjunto de Criterios de
Aceptación del Servicio (SAC) (vea el Apéndice B) que
se usará para garantizar que el proveedor de servicio
esté preparado para entregar y dar soporte al servicio
nuevo o modificado en el entorno de producción.
3.6.1  Diseño de soluciones del servicio
Existen muchas actividades que tienen que completarse
dentro de la etapa de Diseño del Servicio para un servicio
nuevo o modificado. Se requiere un método formal y
estructurado para generar un nuevo servicio al coste,
funcionalidad y calidad adecuados y dentro de la franja de
tiempo correcta. Este proceso y sus etapas se ilustran en
la Figura 3.5, junto con las demás áreas principales que
es necesario que se impliquen dentro del proceso. Este
proceso deberá ser iterativo/incremental para garantizar
que el servicio entregado cumpla las necesidades de
evolución y cambio del negocio durante el desarrollo
del proceso de negocio y durante el Ciclo de Vida del
Servicio de TI. Podría ser necesario que jefes de proyectos
y equipos de proyectos adicionales colaborasen para la
gestión de las etapas dentro del ciclo de vida para el
despliegue de un nuevo servicio.
En la Figura 3.5 se ilustra el rol del equipo de proyecto
dentro de esta actividad de entrega de servicios de TI
nuevos o modificados para el negocio y su relación con
las actividades de diseño.
22/1/10 14:09:35
 34 | Principios de Diseñ̃o del Servicio

Requisitos Requisitos Requisitos Requisitos

de negocio de negocio de negocio de negocio
Piloto o período Operación
de garantía real

Diseño y desarrollo
Proyecto (Equipo de Proyecto)

SAC SAC SAC SAC SAC SAC

Documentar y Diseñar Desarrollar Construir Probar

acordar los solución solución solución solución
requisitos de negocio de servicio de servicio de servicio de servicio
(Estrategia y Diseño) (Diseño) (Diseño) (Transición) (Transición)

Estrategia
SDP
Diseño Mejora

Transición

Implicación de Transición y Operación Operación

SLR SLR SLR SLR SLR SLA SLA

Piloto SLM Real

Gestión de la Construcción, Prueba, Entrega y Desarrollo

Gestión de Cambios:
RFC Aprobado para Aprobado para Aprobado para Aprobado para Aprobado para Aprobado para Revisión y
entregada diseño desarrollo construcción prueba garantía entrega real cierre

Figura 3.5  Alineación de nuevos servicios con los requisitos de negocio

La Figura 3.5 muestra el ciclo de vida de un servicio desde
el requisito de negocio inicial o modificado a través de
las etapas de diseño, transición y operación del ciclo de
vida. Es importante que haya una transferencia eficaz
de conocimiento en todas las etapas entre el personal
operativo y el personal del proyecto para garantizar una
progresión adecuada a través de cada una de las etapas
ilustradas.
Las áreas que es necesario considerar dentro del diseño de
la solución del servicio deberán incluir:
■■ Analizar los requisitos de negocio acordados.
■■ Revisar los servicios e infraestructura de TI existentes
y generar soluciones del servicio alternativas con
una visión dirigida a la reutilización y explotación de
componentes y servicios existentes siempre que sea
posible.
■■ Diseñar las soluciones del servicio para los nuevos
requisitos, incluyendo sus componentes, en los
términos siguientes, documentando este diseño:
●● Las instalaciones y funcionalidades requeridas, e
información necesaria para la monitorización del
rendimiento del servicio o proceso.
●● Los procesos de negocio soportados,
dependencias, prioridades, criticidad e impacto del
servicio, junto con los beneficios para el negocio
que entregará el servicio.
●● Ciclos del negocio y variaciones estacionales, y
los niveles asociados de transacción del negocio,
niveles de transacción del servicio, los números y
tipos de usuarios y futuro crecimiento anticipado, y
los requisitos de continuidad del negocio.

824_004 Chapter 03.indd 34 22/1/10 14:09:35


●● Requerimientos de Nivel de Servicio y objetivos
de nivel de servicio y las actividades necesarias de
medición, información y revisión del servicio.
●● Los plazos de tiempo implicados y los resultados
planificados a partir del nuevo servicio, y el
impacto en cualquier servicio existente.
●● Los requisitos para las pruebas, incluyendo
cualquier Prueba de Aceptación del Usuario (UAT)
y las responsabilidades para la gestión de los
resultados de las pruebas.
■■ Garantizar que se incorporen los contenidos de los
Criterios de Aceptación del Servicio (SAC) y que los
logros requeridos se planifiquen en el diseño inicial.
■■ Evaluar y calcular el coste de diseños alternativos,
resaltando las ventajas además de las desventajas de
las alternativas.
■■ Acordar el gasto y los presupuestos.
■■ Reevaluar y confirmar los beneficios para el negocio,
incluyendo el Retorno de la Inversión (Rol) del servicio,
incluyendo la identificación y cuantificación de todos
los costes del servicio y de todos los beneficios para
el negocio y aumento de los ingresos. Los costes
deberán incluir el Coste Total de Propiedad (TCO) del
servicio e incluir costes de arranque como por ejemplo
costes de diseño, costes de transición, presupuesto
del proyecto, y todos los costes operativos corrientes
incluyendo la gestión, soporte y mantenimiento.
■■ Acordar la solución elegida y sus resultados y objetivos
planificados (Requisito de Nivel de Servicio (SLR)).
■■ Comprobar que la solución está equilibrada con
todas las estrategias, políticas, planes y documentos
de arquitectura corporativos y de TI. Si no fuera así,
revisar la solución o la documentación estratégica
(teniendo en cuenta el efecto en otros documentos,
servicios y componentes estratégicos) siempre que
sea posible reutilizando o explotando componentes
existentes (por ejemplo, objetos de software, datos
corporativos, hardware), a menos que la estrategia
dicte lo contrario. El cambio de la estrategia implicará
una cantidad significativa de trabajo y se realizaría
junto con Estrategia del Servicio.
■■ Garantizar que se incluyan con la solución todos
los controles adecuados de seguridad y gobierno
corporativos y de TI.
■■ Completar una ‘evaluación de la buena disposición
organizativa’ de TI para garantizar que el servicio
pueda operarse eficazmente para que cumpla los
objetivos acordados y para que la organización
tenga la capacidad adecuada para entregar el nivel
acordado. Esto incluirá:
●● El impacto comercial en la organización desde la
824_004 Chapter 03.indd 35
Principios de Diseñ̃o del Servicio | 35
perspectiva del negocio y de TI, incluyendo todos
los beneficios para el negocio y todos los costes
(los costes extraordinarios del proyecto y los costes
corrientes de operación anuales) implicados en el
diseño, desarrollo y operación y soporte continuos
del servicio.
●● Evaluación y atenuación de los riesgos
asociados con el servicio nuevo o modificado,
particularmente con respecto a la operación,
seguridad, disponibilidad y continuidad del
servicio.
●● La capacidad y madurez del negocio. Esta actividad
deberá realizarla el propio negocio para garantizar
que todos los procesos, estructuras, personas, roles,
responsabilidades e instalaciones correctos estén
preparados para operar el nuevo servicio.
●● La capacidad y madurez de TI:
− El entorno y todas las áreas tecnológicas,
habiendo considerado el impacto sobre los
componentes de la infraestructura y de los
servicios existentes.
− La estructura organizativa de TI, y los roles y
responsabilidades.
− Los procesos de TI y su documentación.
− Las habilidades, conocimiento y competencia
del personal.
− Los procesos de gestión de TI y herramientas de
soporte.
■■ Los acuerdos de suministradores y de soporte
necesarios para mantener y entregar el servicio
■■ El montaje de un Paquete de Diseño del Servicio
(SDP) para la posterior transición, operación y mejora
de la solución del servicio nueva o modificada.
3.6.2 Diseño de sistemas de soporte,
especialmente el Portfolio de Servicios
La forma más eficaz de gestión de todos los aspectos
de los servicios a través de su ciclo de vida es utilizar los
sistemas de gestión y herramientas apropiados para dar
soporte y automatizar los procesos eficientemente. El
Portfolio de Servicios es el sistema de gestión más esencial
que se utiliza para dar soporte a todos los procesos y
describe los servicios del proveedor en términos de valor
para el negocio. Articula las necesidades del negocio y la
respuesta del proveedor a esas necesidades. Por definición,
los términos del valor para el negocio se corresponden
con términos del mercado, que proporcionan un
medio para comparar la competitividad del servicio
entre proveedores alternativos. Al actuar como la base
fundamental para un marco de trabajo, un Portfolio
22/1/10 14:09:35
 36 | Principios de Diseñ̃o del Servicio

Unidad de Negocio A Unidad de Negocio B Unidad de Negocio C

El Negocio
3 6 9
2 5 8
Proceso Proceso Proceso
de negocio 1 de negocio 4 de negocio 7

Servicios de TI
F G
D E
Service A B C
SLAs
TI

Infraestructura

Sistema Sistema
DBMS Redes Entorno Data Applications
H/W S/W

OLAs Servicios
de soporte El Portfolio de Servicios
Servicio Estado Propiet. ..............
Equipos Servicio A
Servicios Servicio B
Contracts
de soporte
(iii) Servicio C
(ii) Suministradores ‘
Equipo
de soporte (i) ’
(iii)
(ii)
Suministrador (i)

Figura 3.6  El Portfolio de Servicios – un repositorio central

de Servicios clarifica o ayuda a clarificar las siguientes
preguntas estratégicas:
■■ ¿Por qué debería adquirir un cliente estos servicios?
■■ ¿Por qué deberían comprar estos servicios?
■■ ¿Cuáles son los modelos de establecimiento de precios
o reintegro?
■■ ¿Cuáles son mis fortalezas y debilidades, prioridades y
riesgo?
■■ ¿Cómo deberían asignarse mis recursos y capacidades?
Vea la Figura 3.6. Idealmente, el Portfolio de Servicios
debería formar parte de un Sistema de Gestión del
Conocimiento del Servicio (SKMS) y registrarse como
un documento en la Gestión de la Configuración (CMS).
Puede encontrar más información sobre el CMS y el SKMS
dentro de la publicación Transición del Servicio.
La Figura 3.6 es una descripción de la relación del Porfolio
de Servicios con el SKMS.
Cuando se tome una decisión estratégica de crear un
servicio, esta es la etapa del Ciclo de Vida del mismo
en la que Diseño del Servicio inicia su arquitectura, que
eventualmente formará parte del Catálogo de Servicios.
El Porfolio de Servicios deberá contener información
relacionada con cada uno y su estado actual dentro de la
organización. Las opciones de estado dentro del Porfolio
de Servicios deberán incluir:
■■ Requisitos: se ha recibido un conjunto de requisitos
descritos del negocio o de TI para un servicio nuevo o
modificado.
■■ Definido: se está evaluando, definiendo y
documentando el conjunto de requisitos para el
nuevo servicio, y se está generando el SLR.
■■ Analizado: se está analizando y priorizando el
conjunto de requisitos para el nuevo servicio.
■■ Aprobado: se están finalizando y autorizando el
conjunto de requisitos para el nuevo servicio.
■■ Instituidos: se está comunicando los requisitos del
nuevo servicio y se están asignando los recursos y
presupuestos.
■■ Diseñado: se está diseñando el nuevo servicio y sus
componentes, y aprovisionando si fuera necesario.

824_004 Chapter 03.indd 36 22/1/10 14:09:36

 Principios de Diseñ̃o del Servicio | 37

■■ Desarrollado: se está desarrollando o recopilando el a un subconjunto permitido de los registros dentro del
servicio y sus componentes, si fuera aplicable. Porfolio de Servicios. Aunque Diseño del Servicio diseñó
■■ Construido: se está construyendo el servicio y sus el Portfolio de Servicios, éste es de propiedad y está
componentes. gestionado por Estrategia del Servicio dentro del proceso
■■ Probado: se está probando el servicio y sus de Gestión del Portfolio de Servicios. Todos los detalles
componentes. de Gestión del Portfolio de Servicios se analizan en la
■■ Entregado: se está entregando el servicio y sus publicación Estrategia del Servicio.
componentes. El Flujo de Creación de Servicios es un subconjunto del
■■ Operativo: el servicio y sus componentes están Portfolio de Servicios general y contiene detalles de
operativos dentro del entorno de producción. todos los requisitos de negocio que todavía no se han
■■ Retirado: el servicio y sus componentes se están convertido en servicios entregados al entorno operativo.
retirando. Se utiliza como una base para la definición, análisis,
priorización y aprobación, mediante ISG y Estrategia del
Por lo tanto, el Porfolio de Servicios contendrá detalles
Servicio, de todas las peticiones de servicios nuevos o
de todos los servicios y su estado con respecto a la etapa
modificados, para asegurar que éstos se alineen con los
actual dentro del Ciclo de Vida del Servicio, como se
requisitos de negocio. Esto se utilizará principalmente
ilustra en la Figura 3.7.
como entrada en las actividades de las etapas Estrategia
del Servicio y Diseño del Servicio del Ciclo de Vida del
Sistema de Gestión del Conocimiento del Servicio Servicio. También proporciona entrada de valor en las
actividades de la etapa de Transición del Servicio del ciclo
de vida para determinar los servicios a entregar. El proceso
Portfolio de Servicios Gestión del Catálogo de Servicios debe garantizar que
todos los detalles del Porfolio del Servicio sean precisos
Ciclo de Vida del Servicio
y estén actualizados cuando el requisito y su servicio
Servicio nuevo o modificado pase al entorno de producción.
Estado: Esto implicará una colaboración estrecha con todas las
Requisitos
actividades de Transición del Servicio.
Definido
Analizado Flujo de Creación Varios elementos del mismo servicio pueden tener
de Servicios
Aprobado diferentes estados al mismo tiempo. De lo contrario,
Instituido el Porfolio de Servicios sería incapaz de dar soporte al
Sección del Portfolio
Diseñado de Servicios visible
desarrollo ‘incremental e iterativo’. Las organizaciones
Desarrollado para el cliente/ deberían diseñar con detenimiento su Porfolio de
Construido equipo de soporte
(el Catálogo de
Servicios, el contenido y el acceso permitido al mismo. El
Prueba Servicios, con contenido debería incluir:
Entregado campos seleccionados
Catálogo visibles) ■■ Nombre del servicio.
Operativo de Servicios
Retirado ■■ Descripción del servicio.
Servicios Retirados
■■ Estado del Servicio.
■■ Clasificación del servicio y criticidad.
■■ Aplicaciones usadas.
Figura 3.7  El Porfolio de Servicios y sus contenidos
■■ Datos y/o esquema de datos usados.
A los clientes y usuarios sólo se les permitiría el acceso a ■■ Procesos de negocio soportados.
aquellos servicios del Porfolio de Servicios que tuvieran
■■ Propietarios del negocio.
un estado entre ‘instituido’ y ‘operativo’, como se
■■ Usuarios del negocio.
ilustra por el cuadro en la Figura 3.7, es decir, aquellos
■■ Propietarios de TI.
servicios incluidos dentro del Catálogo de Servicios. El
personal de Estrategia del Servicio y Diseño del Servicio ■■ Referencias al Nivel de Garantía del Servicio, SLA y SLR.
necesitaría acceso a todos los registros del Portfolio de ■■ Servicios de soporte.
Servicios, además de otras importantes áreas como por ■■ Recursos de soporte.
ejemplo Gestión de Cambios. Otros miembros de la ■■ Servicios dependientes.
organización del proveedor de servicio tendrían acceso ■■ OLAs, contratos y acuerdos de soporte.

824_004 Chapter 03.indd 37 22/1/10 14:09:36

 38 | Principios de Diseñ̃o del Servicio
■■ Costes del servicio.
■■ Cargos del servicio (si fuera aplicable).
■■ Ingresos del servicio (si fuera aplicable).
■■ Métricas del servicio.
El Porfolio de Servicios es la fuente principal de
información para que los requisitos y servicios y
necesidades se diseñen con precisión para satisfacer
todas las necesidades de todos sus usuarios. El diseño del
Porfolio de Servicios necesitará considerarse de la misma
forma que el diseño de cualquier otro servicio de TI para
garantizar que satisfaga todas estas necesidades. Este
método también debería usarse para todos los sistemas de
información de Gestión del Servicio, incluyendo:
■■ Sistema de Gestión del Conocimiento del Servicio
(SKMS).
■■ Gestión de la Configuración (CMS).
■■ Sistema del Centro de Servicio al Usuario.
■■ Sistema de Información de Gestión de la Capacidad
(CMIS).
■■ Sistema de Información de Gestión de la
Disponibilidad (AMIS).
■■ Sistema de Información para la Gestión de la
Seguridad (ISMS).
■■ Base de datos de Contratos y Proveedores (SCD).
3.6.3  Definición de las arquitecturas
tecnológicas
Las actividades de diseño de la arquitectura dentro de
una organización de TI están implicadas con la provisión
de las ‘guías’ estratégicas generales para el desarrollo
y despliegue de una infraestructura de TI, un conjunto
de aplicaciones y datos que satisfacen las necesidades
actuales y futuras del negocio. Aunque estos aspectos
dan soporte a la entrega de servicios de TI de calidad,
ellos solos no pueden entregar servicios de TI de calidad,
y es esencial que también se consideren los aspectos de
las personas, del proceso y del socio/suministrador que
rodean a estos componentes tecnológicos (productos):
‘Arquitectura’ es un término usado en muchos contextos
diferentes. En este contexto, se define como:
La organización fundamental de un sistema,
materializado en sus componentes, en sus relaciones
con los demás y con el entorno, y en los principios que
guían su diseño y evolución.
‘Sistema’ en esta definición se utiliza en el sentido más
general, no necesariamente en el ámbito de TI:
824_004 Chapter 03.indd 38
‘un conjunto de componentes organizado para llevar a
cabo una función especial o conjunto de funciones’.
Por lo tanto, el sistema podría ser, por ejemplo, toda
una organización, una función del negocio, una línea
de producto o un sistema de información. Cada uno de
estos sistemas tendrá una ‘arquitectura’ como se definió
anteriormente, compuesta por componentes del sistema,
las relaciones entre ellos (como por ejemplo interfaces de
control e intercambios de datos), las relaciones entre el
sistema y su entorno (político, organizativo, tecnológico,
etc.) y los principios de diseño que informan, guían y
restringen su estructura y operación, además de su futuro
desarrollo.
En esencia, el diseño de la arquitectura puede definirse
como:
‘El desarrollo y mantenimiento de políticas, estrategias,
arquitecturas, diseños, documentos, planes y procesos
de TI para el despliegue y posterior operación y mejora
de servicios y soluciones adecuados de TI a través de
una organización’.
Es necesario que el trabajo de diseño de la arquitectura
analice y reconcilie muchos tipos de necesidades, algunas
de las cuales podrían entrar en conflicto con otras. El
trabajo debería asegurar que:
■■ Las infraestructuras, entornos, datos, aplicaciones y
servicios externos de TI satisfagan las necesidades
del negocio, sus productos y servicios. Esta actividad
no sólo incluye los componentes tecnológicos, sino
también su gestión.
■■ El equilibrio correcto se logra entre los aspectos de
innovación, riesgo y coste mientras se busca una
ventaja competitiva.
■■ Haya conformidad con marcos de trabajo, estrategias,
políticas, regulaciones y estándares de la arquitectura.
■■ Se provee una interfaz coordinada entre diseñadores
y planificadores de TI, estrategas, diseñadores de
negocio y planificadores.
Las actividades de diseño de la arquitectura deberán usar
entradas procedentes del negocio, Estrategia del Servicio,
sus planes, diseñadores y planificadores para desarrollar
los diseños, planes, arquitecturas y políticas adecuadas
para todas las áreas de TI. Estos diseños, planes,
arquitecturas y políticas deberán incluir todos los aspectos
de TI, incluyendo roles y responsabilidades, servicios,
tecnología, arquitectura y marcos de trabajo, procesos y
procedimientos, socios y suministradores y métodos de
gestión. El proceso de diseño de la arquitectura también
22/1/10 14:09:36
 Principios de Diseñ̃o del Servicio | 39

Arquitectura de la Empresa

Arquitectura del Negocio/Organización

Arquitectura de la Empresa

Arquitectura
del Servicio

Arquitectura de Arquitectura de la
la Aplicación Información/Datos

Arquitectura del Entorno

Arquitectura de la
Infraestructura
de TI Arquitectura
de Gestión

Arquitectura
del Producto

Figura 3.8  Arquitectura de la Empresa

debe incluir todas las áreas tecnológicas, incluyendo la
infraestructura, entorno, aplicaciones y datos, y vincularse
estrechamente con los procesos generales de planificación
y diseño del negocio.
Cualquier empresa es un sistema complejo con muchos
tipos de componentes que incluyen su personal,
funciones y procesos de negocio, estructura organizativa
y distribución física, fuentes de información y sistemas
de información, recursos financieros y otros recursos que
incluyen la tecnología, y las estrategias, planes, gestión,
políticas y estructuras de gobierno que dirigen la empresa.
Una Arquitectura de la Empresa debe mostrar cómo se
integran todos estos componentes (y otros) para lograr los
objetivos de negocio, ahora y en el futuro.
La Arquitectura de la Empresa puede ser grande
y compleja. Aquí estamos interesados en aquellas
arquitecturas implicadas con el negocio de la organización
y con los sistemas de información que les dan soporte.
Cada una de estas arquitecturas exige distintas disciplinas
de arquitecturas y áreas de experiencia, como se ilustra en
la Figura 3.8.
La Arquitectura de la Empresa es definida por Gartner
como:
‘el proceso de traducción de la visión y estrategia del
negocio en un cambio empresarial eficaz, creando,
comunicando y mejorando principios y modelos clave
que describen los futuros estados de la empresa y que
permiten su evolución’.
Existen muchos marcos de trabajo propietarios y no
propietarios para el desarrollo de una Arquitectura de la
Empresa, como se ilustra en la Tabla 3.1.
Estos marcos de trabajo incluyen descripciones de la
estructura organizativa, procesos de negocio, sistemas de
planificación y control, mecanismos de gestión y gobierno,
políticas y procedimientos de la empresa. Muestran cómo
estos componentes operan entre sí contribuyendo al
logro de metas y objetivos del negocio, y proporcionando
la base para identificar los requisitos para sistemas de
información que soportan estos procesos de negocio.
La Arquitectura de la Empresa deberá ser un elemento
integrado de la Arquitectura del Negocio y deberá incluir
las siguientes áreas importantes:
■■ Arquitectura del Servicio, que traduce aplicaciones,
infraestructura, organización y actividades de soporte
en un conjunto de servicios. La Arquitectura del
Servicio proporciona el método integrado del negocio
independiente para entregar servicios al negocio.
Proporciona el modelo para realizar una distinción
entre la Arquitectura del Servicio, la Arquitectura de
Aplicaciones, la Arquitectura de Datos y la Arquitectura
de la Infraestructura. También proporciona tolerancia
a fallos, futuras revisiones y controles de seguridad.
Esto significa que, potencialmente, los cambios
que se produzcan dentro de cualquier arquitectura
tecnológica serán transparentes a los usuarios del
servicio, por ejemplo, mecanismos de autoservicio
basados en web. Deberá incluir no sólo los propios

824_004 Chapter 03.indd 39 22/1/10 14:09:37

 40 | Principios de Diseñ̃o del Servicio

Tabla 3.1  Marcos de trabajo de la Arquitectura de la Empresa

Nombre completo del marco de trabajo Acrónimo del marco de trabajo
Marco de Trabajo Arquitectura de Sistemas de Información Integrados ARIS
Marco de Trabajo Bredemeyer Bredemeyer
Marco de Trabajo de Transformación y su Programa de Implementación en el Negocio BTEP
Comando, Control, Comunicaciones, Ordenadores, Vigilancia y Reconocimiento Inteligente C4ISR
CSC Catalyst Catalyst
Arquitectura de Sistemas Abiertos de Fabricación Integrada por Ordenador CIMOSA
Marco de Trabajo Arquitectura de la Empresa Gartner
Planificación de la Arquitectura de la Empresa EAP
Marco de Trabajo Ampliado Arquitectura de la Empresa E2AF
Modelos de Referencia FEA FEA
Metodología y Arquitectura Generalizada de Referencia de la Empresa GERAM
Marco de Trabajo Arquitectura Integrada IAF
Pilares de EA Forrester
Modelo de Referencia para el Procesamiento Distribuido Abierto RM-ODP
Gestión de la Información del Marco de Trabajo Técnico de la Arquitectura TAFIM
Marco de Trabajo Arquitectura de la Empresa del Ministerio de Hacienda. TEAF
Modelo de Referencia Técnica TOGAF TOGAF
Marco de Trabajo Zachman Zachman

servicios y su integración general, sino también la ■■ Arquitectura de la Infraestructura de TI, que

gestión de tales servicios.
■■ Arquitectura de Aplicaciones, que proporciona una
guía para el desarrollo y despliegue de aplicaciones
individuales. Hace corresponder los requisitos
de negocio y funcionales en las aplicaciones, y
muestra las interrelaciones entre aplicaciones. Las
Arquitecturas de Aplicaciones Emergentes se basan
normalmente en componentes. Tal método maximiza
la reutilización y ayuda a mantener la flexibilidad
a la hora de acomodar cambios en la política de
aprovisionamiento.
■■ Arquitectura de Datos/Información, que describe
los activos de datos lógicos y físicos de la empresa
y los recursos de gestión de datos. Muestra cómo se
gestionan y comparten los recursos de la información
para el beneficio de la empresa. Una estrategia
sobre datos centralizados comparado con datos
distribuidos casi con toda seguridad se habrá ideado
como parte de tal arquitectura. La Arquitectura de
Datos/Información incluirá la consideración de las
tecnologías de almacenamiento de datos que faciliten
la explotación de activos corporativos de información.
Incluirá progresivamente la gestión del contenido y
las instalaciones para la entrega de información sobre
múltiples canales.
describe la estructura, funcionalidad y distribución
geográfica de los componentes de hardware, software
y comunicaciones que apoyan y dan soporte a toda
la arquitectura, junto con los estándares técnicos
que se les aplican. Esto también debería incluir
una ‘Arquitectura del Producto’ que describa los
productos propietarios particulares y los estándares de
la industria que usa la empresa para implementar la
infraestructura de conformidad con los principios de la
Arquitectura de la Infraestructura de TI
■■ Arquitectura del Entorno, que describe todos los
aspectos, tipos y niveles de los controles del entorno y
su gestión. En el Apéndice E se incluye un ejemplo del
tipo requerido de información del entorno.
Las relaciones entre estas perspectivas de la
arquitectura pueden verse en la Figura 3.9. El desarrollo,
documentación y mantenimiento de las arquitecturas
del negocio y de TI normalmente formarán parte de los
procesos del pensamiento estratégico y del desarrollo de
la estrategia en la organización.
Dentro del marco de trabajo descrito anteriormente, es
posible identificar al menos tres roles relacionados con la
arquitectura. Todos estos podrían informar a un ‘Arquitecto
de la Empresa’ senior:

824_004 Chapter 03.indd 40 22/1/10 14:09:37


Arquitectura del Negocio/Organización
Entrega,
retroalimentación
y monitorización
Arquitectura del Servicio
Soportado
por
Arquitectura de
la Aplicación
Utiliza
Arquitectura del Entorno
Arquitectura de la
Infraestructura de TI
Arquitectura
de Gestión
Arquitectura
del Producto
Figura 3.9  Relaciones de la arquitectura
■■ Arquitecto del Negocio/Organizativo: implicado
en los modelos de negocio, procesos de negocio y
diseño organizativo, los componentes estructurales y
funcionales de la organización y su relación, y cómo
se distribuyen las funciones y actividades del negocio
de la organización entre ellos; también el gobierno
de la organización y los roles y responsabilidades
requeridos.
■■ Arquitecto del Servicio (con roles diferentes a
los del Arquitecto de Aplicaciones y Arquitecto de
Información/Datos): implicado con las Arquitecturas
del Servicio, de Datos y de Aplicaciones, las
arquitecturas lógicas que dan soporte al negocio y las
relaciones entre ellas
■■ Arquitecto de la Infraestructura de TI: implicado
con el modelo tecnológico físico, los componentes de
la infraestructura y sus relaciones, incluyendo opciones
tecnológicas, interfaces y protocolos, y la selección de
productos para implementar la infraestructura.
824_004 Chapter 03.indd 41
Principios de Diseñ̃o del Servicio | 41
Portfolio
de Servicios
Influenciado Arquitectura de la
por Información/Datos
Sistema de
Gestión del
Conocimiento
del Servicio
En algunas organizaciones, los roles del Arquitecto
del Negocio/Organizativo, Arquitecto de Sistemas de
Información (o posiblemente roles independientes de
Arquitecto de Aplicaciones y Arquitecto de Datos) y
Arquitecto de la Infraestructura de TI, serán funciones
separadas. En otras, se podrían combinar algunos o
todos los roles. Los roles podrían residir en partes
independientes de la organización o incluso fuera de ella.
Por ejemplo:
■■ El rol del Arquitecto del Negocio/Organizativo podría
residir dentro la Estrategia del Negocio y de la función
de Planificación en la sede central corporativa.
■■ El rol del Arquitecto del Servicio podría formar parte
de una función interna con la responsabilidad de
gestionar relaciones entre el negocio, proveedores
externos y socios de TI en relación con los asuntos
relacionados con el Servicio. Una responsabilidad clave
de tal función es el mantenimiento de la Arquitectura
del Servicio. Esta función podría estar incluida dentro
22/1/10 14:09:37
 42 | Principios de Diseñ̃o del Servicio
de una función de TI o en el ámbito del negocio de la
organización.
■■ El rol del Arquitecto de la Infraestructura de TI
podría residir en el socio/proveedor de servicio que
es responsable de generar una Arquitectura de la
Infraestructura de TI usada para la entrega de servicios
de TI a la organización.
Si las arquitecturas necesarias ya estuvieran establecidas,
entonces el rol de Diseño del Servicio se vería afectado de
la siguiente forma:
■■ Debe trabajar dentro de los estándares y marco de
trabajo acordados de la arquitectura.
■■ Será capaz de reutilizar muchos de los activos creados
como parte de la arquitectura.
■■ Debe trabajar estrechamente con todos y cada uno
de los tres roles de la arquitectura para garantizar el
máximo beneficio del trabajo realizado a la hora de
crear la arquitectura.
Si la arquitectura del diseño se consiguiera de forma eficaz
y económica, los documentos, procesos y actividades
del negocio y del diseño de la arquitectura deberán
estar estrechamente coordinados y sincronizados. En los
Apéndices C y D se incluye una lista de estos documentos
de diseño y su contenido. En las siguientes secciones
se consideran los detalles individuales de la tecnología
incluida dentro del diseño de la arquitectura.
Mensaje clave
El beneficio real y el RoI de la Arquitectura de la
Empresa no surge de la propia arquitectura, sino que
procede de la capacidad de una organización para
diseñar e implementar proyectos y soluciones de forma
rápida y consistente.
3.6.3.1  Gestión de la Tecnología
Deberá adoptarse un método estratégico en relación
con la planificación y gestión de una tecnología de la
información. Esto implica la creación de ‘arquitecturas’
o ‘guías’ para el marco de trabajo a largo plazo de
la tecnología usada y planificada. Los planificadores,
diseñadores y arquitectos de TI necesitan entender
el negocio, los requisitos y la tecnología actual para
desarrollar las arquitecturas de TI apropiadas para el
corto, medio y largo plazo. El diseño tecnológico también
necesita tener en cuenta los servicios de TI a los que se
dará soporte, o al menos los tipos de servicio desde un
entendimiento del negocio y su futura dirección, ya que
el negocio demandará servicios de TI, y necesitarán una
tecnología apropiada para proporcionar y entregar esos
824_004 Chapter 03.indd 42
servicios. Si fuera posible proveer una tecnología a largo
plazo que pueda dar apoyo a un número de servicios
de TI, entonces un método estratégico proporcionará
beneficio a largo plazo.
Será necesario desarrollar arquitecturas dentro de las áreas
principales de tecnología.
Arquitecturas tecnológicas
Las Arquitecturas son necesarias en todas las áreas de la
infraestructura de TI. Cuando sea pertinente, será necesario
desarrollarlas en las siguientes áreas:
■■ Aplicaciones y software de sistemas.
■■ Información, datos y base de datos incluyendo
confidencialidad y seguridad de la información,
almacenamiento y “minería” de los mismos.
■■ Arquitectura y diseño de la infraestructura:
●● Servidor central, arquitecturas de mainframe,
servidores regionales distribuidos, incluyendo
archivo local y servidores de impresión.
●● Redes de datos (LANs, MANs, WANs, protocolos,
etc.), Internet, Intranet y sistemas de Extranet.
●● Tecnologías de redes convergentes, incluyendo
redes de voz (PABXs, Centrex, terminales, móviles,
faxes, etc.).
●● Sistemas cliente (PCs de sobremesa, portátiles,
dispositivos de acceso móvil (dispositivos manos
libres, teléfonos móviles, microordenadores
portátiles, PDAs, escáneres, etc.).
●● Dispositivos de almacenamiento, Redes de Área de
Almacenamiento (SANs), Almacenamiento Acoplado
a la Red (NAS) incluyendo sistemas y servicios de
backup y de recuperación (servidores, robots, etc.).
●● Almacenamiento, tratamiento y gestión de
documentos.
●● Áreas especialistas de tecnología como EPOS,
ATMs, dispositivos de escaneado, sistemas GPS, etc.
■■ Equipos y sistemas del entorno, incluyendo su
monitorización y gestión.
Esto dará como resultado una jerarquía de arquitecturas
que será necesario ensamblar para construir un
conjunto integrado de arquitecturas tecnológicas para
la organización. La Arquitectura de la Infraestructura
deberá intentar proveer plataformas relativamente poco
estandarizadas para albergar aplicaciones. También deberá
establecer estándares para arquitecturas de aplicaciones
que se alojen en centros de procesos de datos controlados
para que se adapten a los requisitos estandarizados de
operación, monitorización y seguridad.
22/1/10 14:09:37

Arquitecturas de gestión
TI debe gestionar costes, entregar los servicios correctos
en el momento oportuno, asegurar activos de la
información, proporcionar servicios estables y dirigir
al negocio en el aprovechamiento de las tecnologías.
Esto requiere herramientas de gestión y procedimientos
automatizados para lograr eficiencia y eficacia. La
selección de una arquitectura de gestión apropiada es
clave para establecer el nivel de control y automatización
requerido. Existen dos métodos independientes para
desarrollar una arquitectura de gestión:
■■ Selección de una arquitectura de gestión
propietaria: esto se basa en la selección de un
único conjunto de productos y herramientas de
gestión a partir de un único proveedor de soluciones
propietarias de gestión. Este método normalmente
requerirá menos esfuerzo, dará soporte y se integrará
dentro de una arquitectura global de herramientas,
pero a menudo significará que tendrá que haber un
compromiso con la funcionalidad e instalaciones de
gestión, lo que podría generar brechas.
■■ Selección de una arquitectura ‘de la mejor clase’:
este método implica la selección de un conjunto de
herramientas y productos de gestión ‘de la mejor
clase’ de varios proveedores de soluciones de gestión
y a continuación integrarlas para proveer una solución
de gestión integral. Esto normalmente requerirá más
esfuerzo en la integración de las herramientas en una
única solución de gestión integral pero con frecuencia
proveerá mejores instalaciones y funcionalidades de
gestión, lo que implicará ahorros de costes a largo
plazo.
Los desafíos de gestión de TI son coordinar y trabajar en
asociación con el negocio en la construcción de estas
soluciones de gestión, dando soporte a los procesos
apropiados y proporcionado las métricas y medidas
requeridas. Esto tiene que lograrse a la vez que se
reducen u optimizan los costes, particularmente los costes
corrientes anuales. La mejor forma de minimizar costes es
diseñar hábilmente y con precisión, por ejemplo, haciendo
el mejor uso de la capacidad para que no sea necesario
comprar capacidad adicional (con sus costes corrientes
asociados), o diseñar una solución de backup/recuperación
que no requiera un establecimiento completo adicional de
la infraestructura. Se pueden ahorrar costes considerables
mediante un diseño inteligente y detenido usando una
tecnología a la que se puede dar soporte y que provoque
pocos problemas en el entorno operativo.
824_004 Chapter 03.indd 43
Principios de Diseñ̃o del Servicio | 43
El método principal para materializar estas metas es
diseñar soluciones que ofrezcan una reducción en los
costes generales de soporte y gestión de red, mientras
se mantiene o incluso se mejora la calidad del servicio
entregado al negocio.
Para obtener el mayor beneficio del uso de las cuatro P,
las organizaciones deberán determinar los roles de los
procesos y las personas, y a continuación implementar las
herramientas para automatizar los procesos, facilitando
los roles y tareas de las personas. La mejor forma de
lograr esto es desarrollar un modelo o arquitectura basada
en estos principios. Esta arquitectura deberá facilitar
la implementación de un conjunto de herramientas y
procesos integrados que den soporte a la gestión ‘extremo
a extremo’ de todas las áreas de la tecnología usada,
garantizando que no haya brechas ni ‘silos técnicos’.
Sin embargo, TI se enfrenta a un gran reto con respecto al
desarrollo y mantenimiento de las habilidades requeridas
para llevar a cabo estos roles y procesos de gestión de
forma eficiente. En las organizaciones realmente eficientes,
estos roles y procesos se alinean con los del negocio. Esto
garantiza que la información y procesos de Gestión de
TI y del negocio tengan objetivos y metas similares. Sin
embargo, con demasiada frecuencia, las organizaciones no
dedican tiempo y esfuerzo suficientes para el desarrollo
de las habilidades adecuadas (por ejemplo, habilidades
interpersonales, habilidades de comunicación, habilidades
en las reuniones) necesarias para los procesos y para el
alineamiento eficaz con el negocio.
Existen cinco áreas que es necesario considerar en relación
con el diseño de una arquitectura de gestión, como se
ilustra en la Figura 3.10.
Las relaciones entre estas perspectivas de la arquitectura
pueden verse en el diagrama anterior. El desarrollo,
documentación y mantenimiento de las arquitecturas
del negocio y de TI normalmente formarán parte de los
procesos del pensamiento estratégico y del desarrollo de
la estrategia en la organización.
Estas cinco áreas de gestión a considerar pueden definirse
brevemente como:
■■ Negocio: las necesidades, requisitos, procesos,
objetivos y metas de las unidades de negocio y
gestores dentro de la organización.
■■ Personas: el ámbito, tareas y actividades de los
gestores y del personal implicado en la gestión de la
provisión de servicios de TI.
■■ Procesos: los procesos y procedimientos usados para
gestionar servicios de TI para el negocio y para sus
clientes.
22/1/10 14:09:37
 44 | Principios de Diseñ̃o del Servicio

Requisitos de negocio

Implementación de abajo a arriba

Diseño de arriba a abajo
Personas, roles y actividades

Procesos y procedimientos

Herramientas de gestión

Tecnología

Integrado de extremo a extremo

Figura 3.10  Gestión integrada de la tecnología dirigida al negocio

■■ Herramientas: las herramientas de gestión y soporte
requeridas para gestionar de forma eficiente la
infraestructura de TI.
■■ Tecnología: los productos y tecnología de TI usados
para entregar el servicio e información a la persona
correcta, en el lugar y momento adecuados.
Tal arquitectura puede utilizarse para diseñar e
implementar soluciones de gestión eficientes, eficaces e
integradas que se alineen con los requisitos de negocio
de la organización y de sus Gestores de Negocio. Esta
arquitectura de gestión puede aplicarse dentro de una
organización para:
■■ Diseño de arriba a abajo, garantizando que los
procesos, herramientas e información de Gestión del
Servicio y de gestión de la tecnología se alineen con
las necesidades y metas del negocio.
■■ Implementación de abajo a arriba, garantizando
que procesos eficientes y eficaces de Gestión del
Servicio y de gestión de la tecnología se integren
completamente con las herramientas y la tecnología
en uso dentro de la organización.
■■ Integrar procesos y herramientas, asegurando la
máxima explotación de las herramientas en la gestión
y soporte de la tecnología y de los procesos extremo
a extremo.
Estas directrices también se ilustran en la Figura 3.10.
La clave para el desarrollo de una arquitectura de gestión
es garantizar que la dirijan las necesidades del negocio y
no se desarrolle únicamente para las necesidades de TI:
Las arquitecturas de gestión necesitan:
‘… alinearse con el negocio, NO estar dirigidas por la
tecnología’.
Dentro de su estructura general, será necesario una
arquitectura de gestión que pueda aplicarse a todas las
áreas de Gestión de TI y no sólo a áreas individuales
aisladas. Esto puede implementarse en un programa
coordinado de funcionamiento conjunto para proveer
una Gestión de la Empresa extremo a extremo global, tan
esencial para la gestión eficaz de la infraestructura de TI
en la actualidad. Si sólo se apoyaran áreas individuales
en la arquitectura, entonces se desarrollarán las ‘islas
de excelencia’ y será imposible proveer las soluciones
completas extremo a extremo requeridas para dar soporte
a las soluciones del negocio de hoy en día.
Además de asegurar que se integren todas las áreas de TI,
es vital que la arquitectura de gestión se desarrolle desde
la perspectiva del negocio y del servicio (es decir, ‘de
arriba a abajo’). Por lo tanto, los elementos clave a acordar

824_004 Chapter 03.indd 44 22/1/10 14:09:37


y definir antes de desarrollar la arquitectura de gestión
son:
■■ Gestión de los procesos de negocio: ¿Qué son los
procesos de negocio y cómo se relacionan con la red
y los servicios y componentes de TI?
■■ Gestión de la calidad del servicio: ¿Qué es la calidad
del servicio? ¿Cómo y dónde se medirá?
Éstos son elementos clave que deben determinar SLM
y Gestión de TI. Proporcionan una entrada crucial
para el desarrollo de las arquitecturas de gestión
centradas en el negocio. Con demasiada frecuencia las
herramientas y procesos de gestión se han centrado en
los componentes y en la gestión de componentes más
que en los servicios y procesos de negocio. Es necesario
cambiar esto poniendo énfasis claramente en el diseño
de sistemas, procesos y herramientas de gestión dirigidos
por necesidades del negocio y centrados en la gestión de
procesos de negocio y de servicios de TI. Si se diseñara
e implementara la arquitectura de gestión apropiada,
se permitirá que los procesos de Gestión del Servicio
se centren en la gestión de servicios y en la calidad del
servicio, y operen de extremo a extremo a través de toda
la empresa de TI, proporcionando una Gestión del Servicio
real en la Empresa. Esto facilitará realmente la gestión de
los servicios para garantizar que los servicios y la calidad
del servicio se alineen estrechamente con las necesidades
del negocio.
Las arquitecturas descritas sugieren que el futuro de la
gestión de red y de los sistemas estará menos centrada en
la tecnología y más integrada con los requisitos generales
del negocio y de la Gestión de TI. Estos nuevos sistemas
y procesos ya están empezando a evolucionar debido
a que organizaciones como, por ejemplo, Distributed
Management Task Force (DMTF) están definiendo cada vez
más los estándares para el intercambio de información de
gestión entre herramientas. En esencia, los sistemas de
gestión estarán cada vez:
■■ Más centrados en las necesidades del negocio.
■■ Más estrechamente alineados con los procesos de
negocio.
■■ Menos dependientes de la tecnología específica y más
centrados en el servicio.
■■ Más integrados con otras herramientas y procesos de
gestión cuando los estándares de gestión evolucionen.
Esto implicará la integración de herramientas y
procesos de Gestión del Servicio, gestión operativa y
gestión de sistemas, con menos ‘silos de tecnología’ e
‘islas de excelencia’.
824_004 Chapter 03.indd 45
Principios de Diseñ̃o del Servicio | 45
■■ Con Sistemas y procesos de gestión extremo a
extremo más centrados en la provisión de calidad y
de servicios al cliente.
■■ Más flexibles. Habrá un alejamiento con respecto a
marcos de trabajo de suministradores únicos más
rígidos hacia un método mejor y más abierto.
3.6.4  Diseño de procesos
Esta sección proporciona una introducción general para
procesar teoría y práctica, que es la base para el diseño
de los procesos de ITIL que se utilizan en el Ciclo de Vida
del Servicio. Un modelo de proceso permite entender
y ayudar a articular las operaciones distintivas de un
proceso.
Un proceso es un conjunto estructurado de actividades
diseñadas para cumplir un objetivo determinado. Toma
una o más entradas y las convierte en salidas definidas.
Un proceso incluye todos los roles, responsabilidades,
herramientas y controles de gestión necesarios para
entregar las salidas de forma eficaz. Un proceso también
podría definir o revisar políticas, estándares, directrices,
actividades, procesos, procedimientos e instrucciones de
trabajo si se requirieran.
El control de procesos puede definirse como:
La actividad de planificación y regulación de un
proceso, con el objetivo de garantizar el desarrollo de
un proceso de forma eficiente, eficaz y coherente.
Los procesos, una vez definidos, deberán documentarse
y controlarse. Una vez bajo control, pueden repetirse y es
posible gestionarlos. Se pueden definir grados de control
sobre los procesos, y a continuación se pueden integrar
las métricas y medidas del proceso en el propio proceso
para controlar y mejorar el proceso, como se ilustra en la
Figura 3.11.
Los elementos genéricos del proceso muestran cómo los
datos entran en el proceso, se procesan, salen y se mide
y revisa la salida. Esta descripción tan básica sustenta
cualquier descripción de proceso. Un proceso siempre
se organiza alrededor de un conjunto de objetivos.
Las entradas principales de los procesos deberán estar
dirigidas por los objetivos y siempre deberán incluir
medidas (métricas) de proceso, informes y mejora del
proceso.
Cada proceso deberá contar con un propietario del
proceso que será responsable del proceso y de su mejora
y asegurará que el proceso cumpla sus objetivos. Los
objetivos de cualquier proceso de TI deberán definirse
en términos medibles y deberán expresarse en términos
de beneficios para el negocio y sustentar los objetivos y
22/1/10 14:09:37
 46 | Principios de Diseñ̃o del Servicio
Control del Proceso
Política del Proceso
Propietario
del Proceso
Disparadores Documentación
del Proceso
Proceso
Actividades Métrica del Proceso
del Proceso
Entradas Procedimientos
del Proceso del Proceso
Instrucciones de
Trabajo del Proceso
Facilitadores del Proceso
Recursos del Proceso
Figura 3.11  Los elementos genéricos del proceso
estrategia del negocio. Diseño del Servicio debería ayudar
a cada propietario del proceso en el diseño de procesos,
para garantizar que todos los procesos usen términos y
plantillas estándar, que sean consistentes y se integren
con los demás para proveer una integración extremo a
extremo en todas las áreas.
La salida generada por un proceso tiene que cumplir las
normas operativas que se deriven de los objetivos de
negocio. Si los productos cumplen la norma establecida, el
proceso podrá considerarse eficaz (ya que puede repetirse,
medirse y gestionarse). Si las actividades se llevaran a
cabo con un uso mínimo de recursos, el proceso también
se puede considerar eficiente. El análisis, resultados y
métricas del proceso deberán incorporarse en informes
regulares de gestión y en mejoras del proceso.
Todas estas áreas deberán incluirse dentro del diseño de
cualquier proceso. Estas nuevas publicaciones de ITIL se
han escrito en torno a ‘conjuntos de procesos’ que reflejan
las etapas en el ciclo de vida de un servicio. El conjunto
de procesos detallados de Diseño del Servicio de esta
publicación cubre los procesos asociados principalmente
con todos los aspectos del diseño.
824_004 Chapter 03.indd 46
Objetivos
del Proceso
Retroalimentación
del Proceso
Roles
del Proceso
Mejoras Salidas
del Proceso del Proceso
incluye informes
y revisiones del proceso
Capacidades
del Proceso
El trabajo con procesos definidos ha sido la base de
ITIL desde el principio. Con la definición de cuáles son
las actividades de la organización, qué entradas son
necesarias y qué salidas resultarán del proceso, es posible
trabajar de una forma más eficiente y eficaz. La medición
y dirección de las actividades incrementa esta eficacia.
Finalmente, si se añaden normas al proceso será posible
añadir medidas de calidad a la salida.
Este método sustenta el ciclo Planificar–Hacer–Verificar–
Actuar de la mejora continua para cualquier sistema de
gestión de la calidad. Planifique el propósito del proceso
de tal forma que se puedan revisar, evaluar o auditar las
acciones del proceso para lograr mejoras y el éxito.
Las normas definen ciertas condiciones que los resultados
deberían cumplir. Las normas de definición introducen
aspectos de calidad en el proceso. Incluso antes de
empezar, es importante pensar en las salidas del
proceso. Deberá medirse la eficacia de forma regular
para identificar si las actividades del proceso están
contribuyendo de forma óptima a la meta y objetivos de
negocio del proceso, y si se alinean con las metas del
negocio. Las mediciones permiten comparar lo que se ha
realizado realmente con lo que la organización determina
22/1/10 14:09:38

hacer, e identificar e implementar mejoras dentro del
proceso.
Cada organización deberá adoptar un método formalizado
para el diseño e implementación de procesos de Gestión
del Servicio. El objetivo no deberá ser el diseño de
‘procesos perfectos’, sino diseñar procesos prácticos y
adecuados con mecanismos de mejora ‘integrados’ para
mejorar la eficacia y eficiencia de los procesos de la forma
más adecuada para la organización. Deberán utilizarse
estándares, procesos y plantillas de documentación
para que los procesos se adopten fácilmente en toda
la organización. En el Apéndice C se incluyen algunas
plantillas de ejemplo de documentación de procesos.
La meta actual y futura es diseñar procesos y ofrecerles
soporte con herramientas que puedan proporcionar
integración entre organizaciones. Esto es posible en
la actualidad gracias a herramientas de gestión que
proporcionan soporte a estándares abiertos, como por
ejemplo Distributed Management Task Force (DMTF),
que da soporte al intercambio de información basándose
en conceptos de ITIL, como incidencias, problemas y
cambios con formatos y contenidos estándar. Esto permite
a los proveedores de servicios dar soporte a interfaces
de proceso eficaces y eficientes con sus suministradores
principales con el intercambio automatizado de
información operativa en tiempo real.
3.6.5  Diseño de métricas y sistemas de
medición
‘Si no puede medirlo entonces no puede gestionarlo’.
Para gestionar y controlar los procesos de diseño, éstos
tienen que monitorizarse y medirse. Esto es válido para
todos sus aspectos. Las medidas y métricas se tratan con
detalle en la publicación Mejora Continua del Servicio. Esta
sección incluye aquellos aspectos que son particularmente
relevantes y apropiados para medir la calidad de los
procesos de diseño y sus entregables.
Deben tomarse las debidas precauciones al seleccionar
las medidas y métricas, y los métodos que se empleen
para generarlas. Esto se debe a que las métricas y
medidas elegidas afectarán y cambiarán realmente el
comportamiento de las personas que trabajarán dentro
de las actividades y procesos que se están midiendo,
particularmente cuando esto se relaciona con los
objetivos, el rendimiento del personal y del equipo y con
los planes de remuneración asociados con el rendimiento.
Por lo tanto, sólo deberán seleccionarse medidas que
promuevan la progresión hacia el cumplimiento de
objetivos de negocio o el cambio de comportamiento
deseado.
824_004 Chapter 03.indd 47
Principios de Diseñ̃o del Servicio | 47
En todas las actividades de diseño, el requisito debería ser:
■■ Diseñar soluciones que se ‘ajusten al propósito’.
■■ Diseñar según el nivel adecuado de calidad, no con
exceso o defecto de diseño.
■■ Diseñar soluciones que sean ‘acertadas la primera vez’
y cumplan sus objetivos esperados.
■■ Diseñar soluciones que minimicen la cantidad de
‘mejoras’ o ‘añadidos’ que tienen que desarrollarse
rápidamente después de que se hayan desplegado las
soluciones.
■■ Diseñar soluciones que sean eficaces y eficientes
desde la perspectiva del negocio y de los clientes. El
énfasis deberá ponerse sobre todo en soluciones que
sean eficaces y sean eficientes dentro de la restricción
de la eficacia continua.
Las métricas y métodos de medida deberán reflejar estos
requisitos y diseñarse para medir la capacidad de diseño
de procesos para que correspondan con estos requisitos.
Todas las medidas y métricas usadas deberán reflejar
la calidad y éxito de los procesos de diseño desde las
perspectivas del negocio, los clientes y los usuarios. Deben
reflejar la capacidad que las soluciones entregadas tienen
para cumplir los requisitos del negocio identificados y
acordados.
Es necesario que las medidas del proceso seleccionadas
sean adecuadas para la capacidad y madurez de los
procesos que se están midiendo. Los procesos inmaduros
no pueden dar soporte a medidas, métricas y métodos de
medida sofisticados. Existen cuatro tipos de métricas que
se pueden usar para medir la capacidad y rendimiento de
los procesos:
■■ Progreso: hitos y entregables en la capacidad del
proceso.
■■ Conformidad: conformidad del proceso con requisitos
de gobierno, requisitos regulatorios y conformidad de
las personas con respecto al uso del proceso.
■■ Eficacia: la precisión y exactitud del proceso y su
capacidad para entregar el ‘resultado correcto’.
■■ Eficiencia: la productividad de los procesos, su
velocidad, rendimiento y utilización de recursos.
Las medidas y métricas deberán desarrollarse y modificarse
con los desarrollos de la madurez y capacidad de un
proceso. Inicialmente, con procesos inmaduros, deberán
usarse los dos primeros niveles de métricas para medir
el progreso y conformidad del proceso cuando aumente
su madurez. A medida que se desarrolle la madurez del
proceso, deberá hacerse un mayor uso de las métricas de
la eficacia y eficiencia pero sin detrimento del compromiso
de progreso o conformidad del proceso.
22/1/10 14:09:38
 48 | Principios de Diseñ̃o del Servicio

Perspectiva Perspectiva Perspectiva Perspectiva Métricas y

del cliente del negocio innovadora financiera objetivos
de negocio

Perspectiva Perspectiva Perspectiva Perspectiva Objetivos y

del cliente del negocio innovadora financiera métricas de TI

(Satisfacción (Rendimiento (Respuesta (Rendimiento

del cliente) del proceso) e innovación) financiero)
Métricas generales
del cliente y del servicio Métricas del
proceso individual
Calidad Retroalimen. Quejas del Funcionalidad Proceso 3
del servicio del cliente cliente del servicio
Proceso 2
Proceso 1
progreso conformidad eficacia eficiencia

ServicioD
Servicio Cliente Cliente Servicio
Servicio C
Servicio Cliente Cliente Servicio
Servicio B Servicio Cliente Cliente Servicio

Servicio A Calidad Encuestas Quejas Funcionalidad

del servicio de clientes del clientes del servicio
Métricas del componente individual
Componente 3
Componente 2
Componente 1
Métricas individuales Disponibilidad Rendimiento Capacidad Fallos Cambios
del servicio y delcliente

Figura 3.12  El Árbol de Métricas

La selección de las métricas, el punto de medida y los ■■ No hay una visibilidad general de la imagen de ‘nivel
métodos de medición, cálculo e información sobre superior’.
las métricas, deberán diseñarse y planificarse con ■■ Existen brechas en áreas en las que no se registran las
detenimiento. Las métricas principales siempre deberán medidas.
centrarse en la determinación de la eficacia y calidad de ■■ Algunas áreas individuales se miden adecuadamente
las soluciones suministradas. Las métricas secundarias mientras que otras se miden deficientemente o no se
pueden medir la eficiencia de los procesos usados para miden.
generar y gestionar la solución. La prioridad siempre ■■ No hay consistencia en el método, presentación y
deberá ser asegurar que los procesos proporcionen cálculo de las medidas.
los resultados correctos para el negocio. Por lo tanto,
■■ Las decisiones y acciones de mejora se basan en
los métodos y métricas de medición siempre deberán
información incompleta o imprecisa.
proporcionar, sobre todo, esta medición centrada en el
negocio. Por lo tanto, las organizaciones deben intentar desarrollar
sistemas de medida automatizados basados en una forma
El método más eficaz de medida consiste en establecer
de ‘Árbol de Métricas’, como el que se ilustra en la Figura
un ‘Árbol de Métricas’ o un ‘Árbol de KPIs’. Demasiadas
3.12.
organizaciones recopilan medidas en áreas individuales,
pero fallan a la hora de añadirlas en conjunto y obtener El árbol de la Figura 3.12 muestra un ejemplo de un
el máximo beneficio de las mismas, y por lo tanto se ven Árbol de Métricas basado en un Cuadro de Mando
perjudicadas porque: Integral. Los Cuadros de Mando Integrales representan
un sistema de gestión que permite cada vez a un
■■ Las medidas no se alinean con los objetivos y
mayor número de organizaciones clarificar su visión y
necesidades del negocio.
estrategia. Proporcionan retroalimentación sobre los

824_004 Chapter 03.indd 48 22/1/10 14:09:38


procesos de negocio internos y los resultados externos
para mejorar de forma continua el rendimiento y los
resultados estratégicos. Esto permite a todos dentro de la
organización obtener una imagen del rendimiento de la
organización al nivel apropiado:
■■ Los gestores del negocio y los clientes pueden
obtener un ‘panel de control’ del negocio de ‘alto
nivel’, alineado con las necesidades y procesos de
negocio.
■■ Los directores de TI senior y los clientes se pueden
centrar en el panel de control de gestión de TI de alto
nivel.
■■ Los Gestores del Servicio y clientes pueden centrarse
en el rendimiento de servicios particulares.
■■ Los Propietarios del proceso y gestores pueden ver el
rendimiento de sus procesos.
■■ Los especialistas técnicos pueden ver el rendimiento
de componentes individuales.
■■ El panel de control también presenta la oportunidad
de analizar tendencias a lo largo del tiempo en
lugar de meros datos estáticos, por lo que se podrá
identificar la potencial degradación del rendimiento y
rectificar este hecho en una etapa anterior.
Esto significa que dentro de un sistema jerárquico de
métricas, cada persona de la organización puede obtener
acceso a un nivel apropiado de información y medida
que se ajuste a sus necesidades particulares. Ofrece a la
gestión senior la oportunidad de monitorizar un panel
de control de alto nivel para garantizar que los servicios
continúen entregándose con sus niveles adecuados, y
también provee la capacidad de que especialistas técnicos
y propietarios de procesos desciendan hasta el detalle para
analizar la variación con respecto al rendimiento acordado
del servicio, componente o proceso.
Evidentemente, la recopilación, análisis y presentación
de estos datos puede ser una actividad muy laboriosa
y por lo tanto deberá automatizarse siempre que sea
posible. Esto se puede lograr empleando herramientas
de análisis basadas en macros, scripts, hojas de cálculo,
o preferiblemente en soluciones específicas basadas en
la web. Las medidas en cada uno de los niveles deberán
definirse específicamente para satisfacer las necesidades
del negocio, clientes y usuarios de la información.
En la publicación Mejora Continua del Servicio se incluye
información más detallada sobre medidas, métricas y
métodos de medida.
824_004 Chapter 03.indd 49
Principios de Diseñ̃o del Servicio | 49
3.7  Las actividades de diseño
posteriores
Cuando se haya diseñado la solución del servicio deseada,
más tarde deberán completarse las actividades posteriores
con la etapa Diseño del Servicio antes de que la solución
pase a la etapa de Transición del Servicio.
3.7.1  Evaluación de soluciones alternativas
Podría ser necesaria una evaluación adicional si se vieran
implicadas soluciones y servicios de proveedores externos.
Esto implica lo siguiente:
■■ Seleccionar un conjunto de proveedores y completar
el proceso de oferta. Esto requerirá la producción y
finalización de:
●● Documentación del ámbito del servicio y
generación de una Declaración de Requisitos (SoR)
y/o un documento de Términos de referencia
(ToR).
●● Documentos de Petición De Información (RFI),
Petición de Propuestas (RFP), Petición de
Cotización (RFQ), y Convocatoria de Licitación (ITT).
●● Generación y acuerdo de un conjunto de criterios
de soluciones y de evaluación de proveedores y un
proceso de calificación.
■■ Evaluación y revisión de respuestas de proveedores
y selección de proveedores elegidos y sus soluciones
propuestas. Esto también podría implicar la ejecución
de pruebas o incluso creación de prototipos o
actividades de pruebas de conceptos si se vieran
implicados nuevos conceptos o tecnologías
importantes en el nuevo servicio para garantizar que
los nuevos componentes cumplan sus expectativas.
■■ La evaluación y el coste de diseños alternativos,
incluyendo posiblemente la identificación de
proveedores potenciales y la evaluación de sus
propuestas, tecnologías, soluciones y contratos
alternativos. Existe la necesidad de garantizar que
los costes cubran los costes puntuales y los costes
continuos de operación y propiedad, incluyendo el
soporte y mantenimiento.
3.7.2  Aprovisionamiento de la solución
elegida
Es posible que no se requiera ningún elemento externo
para la solución. Sin embargo, esto es inusual ya que es
muy probable que se vean implicados proveedores de
software. Si se vieran implicados proveedores externos en
la solución elegida, las etapas consisten en:
22/1/10 14:09:38
 50 | Principios de Diseñ̃o del Servicio

■■ Completar todas las comprobaciones necesarias con
respecto al proveedor elegido.
■■ Firmar los términos y condiciones de cualquier nuevo
contrato, garantizando que se implementen todas las
políticas corporativas
■■ La compra de la solución seleccionada.
3.7.3  Desarrollo de la solución del servicio
La etapa de desarrollo consiste en la traducción del Diseño
del Servicio en un plan para el desarrollo, reutilización
o renovación de los componentes requeridos para
entregar el servicio y la posterior implementación del
servicio desarrollado. Esto podría tener que desarrollarse
en un programa de planes, si supusiera un cambio
importante del servicio. Cada plan o proyecto dentro del
programa será responsable de la entrega de uno o más
componentes del servicio e incluirá:
■■ Las necesidades del negocio
■■ La estrategia a adoptar para el desarrollo y/o compra
de la solución
■■ Los plazos de tiempo implicados
■■ Los recursos requeridos, teniendo en cuenta
instalaciones, infraestructura de TI y las habilidades
adecuadas del personal para garantizar que la entrega
del servicio satisfaga las necesidades del cliente
■■ El desarrollo del servicio y sus componentes,
incluyendo la gestión y otros mecanismos operativos,
como por ejemplo, monitorización y generación de
informes
■■ Planes de prueba de servicios y componentes.
Se necesitará usar una gestión de proyectos esmerada
para garantizar que se eviten conflictos y que los
componentes compatibles se desarrollen desde las
diferentes actividades de desarrollo.
3.8  Restricciones del diseño
Todas las actividades de diseño se encuentran sometidas
a muchas restricciones. Estas restricciones proceden del
negocio y de la Estrategia del Servicio y cubren muchas
áreas diferentes, como se ilustra en la Figura 3.13.
Esto significa que los diseñadores no siempre tienen
libertad para diseñar la solución más apropiada para el
negocio ya que están sometidos a restricciones impuestas,
como se ilustra en la Figura 3.13. La restricción más
obvia es la financiera. Puede que no haya suficiente
presupuesto para la solución más apropiada, por lo que
tendría que identificarse y acordarse con el negocio
un servicio alternativo más barato. El diseñador sólo
puede proporcionar la solución que se ajuste a todas las
restricciones conocidas actualmente, o también intentar

Nivel
‘Diseño es el arte de aplicar Solución
de garantía
gradualmente restricciones de servicio
Restricciones de recursos,
hasta que sólo queda una deseada
incluyendo planificaciones
solución’
Valor y
Compromisos ética
existentes
Costes unitarios
comparativos
Solución Restricciones
de Servicio tecnológicas
Aceptable

Espacio de la solución
o el conjunto de
diseños permitidos Conformidad con
Copyright, patentes
con el conjunto de estándares y regulaciones
y marcas
restricciones dado
comerciales

Otras
restricciones:
Restricciones política, gobierno, etc.
de capacidad Utilidad a
proveer

Figura 3.13  Restricciones de diseño dirigidas por la estrategia

824_004 Chapter 03.indd 50 22/1/10 14:09:39

 Principios de Diseñ̃o del Servicio | 51

IS O

1
00
90

27
01

ISO
Mejora

ISO
/IE 70
C2
00 Diseño 197
0 ISO

Estrategia
e-TOM COBIT

Operación
Transición

II CM
sel M
I
Ba
8ª D
irec
X
SO

tiva
Eu

Figura 3.14  Influencias externas en el diseño de la solución

elevar o renegociar algunas de las restricciones, por 3.9  Arquitectura Orientada a

ejemplo, obteniendo un presupuesto mayor. En la Figura
3.13, no sólo se necesitará obtener más presupuesto
para implementar la solución deseada, sino que además
no estaría conforme con algunos de los estándares y
regulaciones aplicables. Por lo que en este caso, es
probable que se requiera una solución alternativa más
barata.
Por lo tanto, los procesos de Diseño del Servicio deberán
reconocer el hecho de que tienen libertad para diseñar
soluciones, pero que también están trabajando en un
entorno donde muchos factores externos pueden influir
en el diseño.
Muchas de estas influencias externas proceden de la
necesidad de un buen gobierno corporativo y de TI, y
otras proceden de los requisitos de conformidad con las
regulaciones, legislación y estándares internacionales,
como se ilustra en la Figura 3.14. Por lo tanto, es
fundamental que todos los diseñadores reconozcan esto y
se aseguren que los diseños y soluciones que propongan
tengan todos los controles y capacidad necesarios.
Servicios
El proceso de negocio y las soluciones deberán
diseñarse y desarrollarse utilizando un método de
Arquitectura Orientada a Servicios (SOA). El método
SOA está considerado como mejor práctica y muchas
organizaciones lo utilizan para mejorar su eficacia y
eficiencia en la provisión de servicios de TI.
SOA se define por OASIS (www.oasis-open.org) como:
‘Un estándar para organizar y utilizar capacidades
distribuidas que pudieran estar bajo el control de
diferentes dominios propietarios. Proporciona un
medio uniforme para ofrecer, descubrir, interactuar
y usar capacidades para producir efectos deseados
consistentes con las condiciones previas y las
expectativas medibles’.
OASIS (Organization for the Advancement of Structured
Information Standards) es un consorcio internacional sin
ánimo de lucro que dirige el desarrollo, convergencia y

824_004 Chapter 03.indd 51 22/1/10 14:09:39

 52 | Principios de Diseñ̃o del Servicio
adopción de estándares de e-business. SOA ofrece valor
y agilidad a una organización para afrontar el desarrollo
de servicios compactos que sean reutilizables. Esto, a
su vez, promueve un método flexible y modular para el
desarrollo de ‘servicios compartidos’ que se puede utilizar
en muchas áreas diferentes del negocio. Cada vez hay
más organizaciones que están convirtiendo los procesos
de negocio en ‘servicios empaquetados’ comunes que
se pueden utilizar y compartir entre muchas áreas del
negocio.
Siempre que sea posible, las organizaciones del proveedor
de servicios de TI deberán utilizar SOA y sus fundamentes
para desarrollar servicios de TI flexibles y reutilizables que
sean comunes y puedan compartirse y explotarse entre
muchas áreas diferentes del negocio. Cuando se utiliza
este método, es fundamental que TI:
■■ Defina y determine lo que es un servicio
■■ Entienda y defina claramente interfaces y
dependencias entre servicios
■■ Utilice estándares para el desarrollo y definición de
servicios
■■ Use tecnología y conjuntos de herramientas comunes
■■ Investigue y entienda el impacto de los cambios en
los ‘servicios compartidos’
■■ Asegure que se haya planificado y llevado a cabo la
formación asociada con SOA para las personas de TI
con el objetivo de establecer un lenguaje común y
mejorar la implementación y soporte de los servicios
nuevos o modificados.
Cuando la organización del proveedor de servicios de
TI utiliza los fundamentos de SOA, es crítico que se
mantenga un Catálogo de Servicios preciso como parte de
un Porfolio de Servicios global y de un Sistema de Gestión
de la Configuración (CMS). La adopción de este método
puede reducir significativamente el tiempo dedicado
en la entrega de nuevas soluciones al negocio y para
avanzar hacia una capacidad de Gestión del Servicio de
Negocio (BSM). El Catálogo de Servicios también mostrará
la relación entre servicios y aplicaciones. Una única
aplicación podría formar parte de más de un servicio, y un
único servicio podría utilizar más de una aplicación.
3.10 Gestión del Servicio de Negocio
Gestión del Servicio de Negocio (BSM) es una estrategia
y un método que permite que los componentes de TI se
vinculen con los objetivos del negocio. Podría predecirse
la forma en la que la tecnología afecta al negocio y cómo
el cambio en el negocio podría afectar a la tecnología.
La creación de un Catálogo de Servicios totalmente
integrado, incluyendo unidades de negocio, procesos
824_004 Chapter 03.indd 52
y servicios, y sus relaciones y dependencias con los
servicios, tecnología y componentes de TI, es crucial para
mejorar la capacidad del proveedor de servicios de TI para
entregar BSM. Todos los aspectos de Diseño del Servicio
son elementos fundamentales a la hora de dar soporte y
mejorar la capacidad de la Gestión del Servicio de Negocio
del proveedor de servicios de TI, particularmente el
diseño del Portfolio de Servicios, el Catálogo de Servicios
y los servicios de TI individuales. Todas estas actividades
también mejorarán el alineamiento de la provisión del
servicio de TI con el negocio y con la evolución de sus
necesidades. Véase la Figura 3.15.
BSM permite a la organización de un proveedor de
servicios de TI:
■■ Alinear la provisión del servicio de TI con las metas y
objetivos del negocio.
■■ Priorizar todas las actividades de TI con respecto a la
urgencia e impacto del negocio, garantizando que
los procesos de negocio y servicios críticos reciban la
máxima atención.
■■ Aumentar la productividad y la rentabilidad del
negocio a través de la mejora de la eficiencia y
eficacia de los procesos de TI.
■■ Dar soporte a los requisitos para el gobierno
corporativo con el gobierno y controles de TI
apropiados.
■■ Crear ventajas competitivas a través de la explotación
e innovación de la totalidad de la infraestructura de TI.
■■ Mejorar la calidad del servicio, la satisfacción del
cliente y la percepción del usuario.
■■ Asegurar la conformidad regulatoria y legislativa.
■■ Asegurar los niveles apropiados de protección a todos
los activos relacionados con la información de TI.
■■ Asegurar que los servicios de TI se alineen y continúen
alineados con las necesidades cambiantes del negocio
La Figura 3.15 ilustra la relación de las actividades del
servicio y Gestión del Servicio, y el alcance y rango que
ofrecen en forma de valor para el negocio y TI.
3.11  Modelos de Diseño del Servicio
El modelo seleccionado para el diseño de servicios de
TI dependerá principalmente del modelo seleccionado
para la provisión de servicios de TI. Antes de adoptar un
modelo de diseño para un nuevo servicio importante,
deberá realizarse una revisión de la capacidad y de las
provisiones actuales con respecto a todos los aspectos
de la entrega de servicios de TI. Esta revisión deberá
considerar todos los aspectos del nuevo servicio,
incluyendo:
22/1/10 14:09:39

ITIL
Gestión
del Servicio
del Negocio
Gestión del
Valor para el negocio Servicio de TI
Gestión de
Sistemas de TI
Recursos
tecnológicos
Valor para TI
Figura 3.15  El flujo continuo de la gestión de TI
■■ Directrices y requisitos de negocio.
■■ Ámbito y capacidad del proveedor de servicio
existente.
■■ Demandas, objetivos y requisitos del nuevo servicio.
■■ Ámbito y capacidad de proveedores externos.
■■ Madurez de las organizaciones que están actualmente
implicadas en sus procesos.
■■ Cultura de las organizaciones implicadas.
■■ Infraestructura de TI, aplicaciones, datos, servicios y
otros componentes implicados.
■■ Grado de gobierno corporativo y de TI y el nivel de
propiedad y control requerido.
■■ Presupuestos y recursos disponibles.
■■ Habilidades y capacidades del personal.
Esta revisión/evaluación ofrece un mecanismo
estructurado para determinar las capacidades de una
organización y el estado de predisposición para la entrega
de servicios nuevos o revisados a la hora de dar soporte
a directrices y requisitos de negocio. La información
obtenida para tal evaluación puede usarse para determinar
la estrategia de entrega para un servicio o sistema de
TI en particular. La estrategia de entrega es el método
adoptado para que una organización pase de un estado
conocido, basado en la evaluación de la predisposición,
hasta un estado deseado, determinado por las directrices
y necesidades de negocio. Existen muchas formas de
preparar a una organización para desplegar un nuevo
servicio. El método y estrategia seleccionados deberán
basarse en la solución que la organización elija para
824_004 Chapter 03.indd 53
Principios de Diseñ̃o del Servicio | 53
Actividad de negocio
Actividad de TI
Actividad de la
infraestructura
satisfacer sus directrices clave de negocio, además de
las capacidades de la organización de TI y sus socios. La
escala de las opciones disponibles es bastante amplia, y
a veces no es necesario considerar todas las opciones en
todos los casos. Sin embargo, mantener todas las opciones
disponibles para su consideración es clave para diseñar y
operar soluciones innovadoras para los retos más difíciles
del negocio. Al final, esto podría ser la diferencia entre un
proyecto fallido, o incluso el fracaso de una compañía, y
un proyecto que culmina con éxito.
Estos dos modelos, para el diseño y entrega de servicios
de TI, están estrechamente relacionados y se consideran
en las dos secciones siguientes.
3.11.1 Opciones de modelos de entrega
Aunque la evaluación de la predisposición determina
el desfase entre las capacidades actuales y deseadas,
no sería necesario que una organización de TI intentara
solucionar ese desfase por sí misma. Existen muchas
estrategias de entrega diferentes que se pueden usar.
Cada una de ellas tiene su propio conjunto de ventajas
y desventajas, pero todas requieren algún nivel de
adaptación y personalización a la situación en cuestión. La
Tabla 3.2 presenta una lista de las categorías principales
de estrategias de aprovisionamiento del servicio con una
breve descripción de cada una de ellas. Las prácticas de
entrega tienden a encontrarse en una de estas categorías
o en alguna variante de ellas.
22/1/10 14:09:39
 54 | Principios de Diseñ̃o del Servicio

Tabla 3.2  Principales estrategias de entrega del servicio

Estrategia de entrega Descripción
Internalización Este método se basa en el uso de recursos organizativos internos en el disen~o, desarrollo,
transición, mantenimiento, operación y/o soporte de servicios nuevos, modificados o revisados o
en operaciones del centro de proceso de datos
Externalización Este método utiliza los recursos de una organización u organizaciones externas en un acuerdo
formal para proveer una parte bien definida del disen~o, desarrollo, mantenimiento, operaciones
y/o soporte de un servicio. Esto incluye el consumo de servicios de Proveedores de Servicios de
Aplicación (ASP), que se describen más adelante
Subcontratación En muchas ocasiones se trata de una combinación de internalización y externalización,
empleando diversas organizaciones que colaboran para subcontratar elementos clave del ciclo de
vida. Esto generalmente implica el uso de varias organizaciones externas que trabajan juntas en
el disen~o, desarrollo, transición, mantenimiento, operación y/o soporte de una parte del servicio
Asociación y aprovisionamiento Acuerdos formales entre dos o más organizaciones para trabajar juntas en el disen~o, desarrollo,
múltiple transición, mantenimiento, operación y/o soporte de servicios de TI. El enfoque aquí tiende a
estar en asociaciones estratégicas que se aprovechan de experiencia crítica u oportunidades del
mercado.
Outsourcing de Procesos de Negocio La tendencia creciente de reubicación de todas las funciones de negocio con acuerdos formales
(BPO) entre organizaciones, en los que una organización proporciona y gestiona los procesos o
funciones de negocio de la otra organización en una ubicación de bajo coste. Los ejemplos
habituales son contabilidad de costes, nóminas y operaciones del centro de llamadas
Provisión de Servicios de Aplicación Implica acuerdos formales con la organización de un Proveedor de Servicios de Aplicación
(ASP) que proveerá servicios basados en equipos compartidos a organizaciones del cliente a
través de una red. A las aplicaciones ofrecidas de esta forma también se las denomina software/
aplicaciones bajo demanda. A través de las ASP, las complejidades y costes del software
compartido pueden reducirse y proveerse a organizaciones que, de lo contrario, no podrían
justificar la inversión.
Outsourcing del Proceso de KPO, la forma más novedosa de externalización, es un paso adelante de BPO en un aspecto.
Conocimiento (KPO) Las organizaciones de KPO ofrecen experiencia de negocio y procesos basados en dominios en
lugar de únicamente experiencia de proceso, y requieren habilidades especializadas y analíticas
avanzadas de la empresa de outsourcing.

La Tabla 3.2 resalta un punto clave: el conjunto de
estrategias de provisión varía ampliamente e incluye
desde una situación relativamente directa, gestionada
únicamente dentro de los límites de una compañía en
todo momento, hasta una situación completa de KPO. Este
amplio margen de alternativas proporciona una flexibilidad
significativa, pero con frecuencia añade complejidad,
y en algunos casos riesgos adicionales. Las ventajas y
desventajas de cada tipo de estrategia de entrega se
analizan en la Tabla 3.3 que se muestra más abajo.
Todos los acuerdos anteriores se pueden proveer en
una situación off-shore u on-shore. En el caso on-shore,
ambas organizaciones se encuentran en el mismo país/
continente, mientras que en la situación off-shore, las
organizaciones están en diferentes países/continentes.
Existen acuerdos de aprovisionamiento muy complejos
dentro de la industria de TI y es imposible cubrir aquí
todas las combinaciones y sus implicaciones. La Serie
Complementaria de la Práctica de Gestión del Servicio de
ITIL proporcionará una guía adicional sobre las estrategias
de aprovisionamiento del servicio.
Las fusiones y adquisiciones también pueden complicar
estas cuestiones. Estas situaciones se producen cuando
una compañía adquiere o se fusiona con otra para la
permuta de acciones y/o caja del accionariado de la
compañía. Nuevamente, esto se produce generalmente
como respuesta a consolidaciones de la industria,
ampliaciones del mercado, o a la respuesta indirecta a
presiones competitivas. Si se adquirieran o fusionaran
compañías que tienen diferentes estrategias de entrega
del servicio, normalmente se requiere un periodo de
revisión y consolidación para determinar la estrategia de
aprovisionamiento más adecuada para la organización
recién fusionada. Sin embargo, las fusiones y adquisiciones
con frecuencia ofrecen a las organizaciones la oportunidad
de consolidar la mejor práctica de cada organización, con
lo que se mejoraría la capacidad general del servicio y
se lograrían sinergias en toda la organización. También
existirán oportunidades para proveer mejores opciones

824_004 Chapter 03.indd 54 22/1/10 14:09:39


de desarrollo profesional para el personal de Gestión del
Servicio y para consolidar la contratación de proveedores
de servicios.
3.11.2 Opciones de diseño y desarrollo
Las estrategias de entrega son aplicables para las etapas
de diseño y transición del Ciclo de Vida del Servicio
así como para la etapa de operación. Debe ponerse un
cuidado extremo al seleccionar diferentes estrategias para
diferentes etapas del ciclo de vida para asegurar que todas
las organizaciones implicadas entiendan claramente los
roles y responsabilidades individuales, y también todos los
demás roles y responsabilidades de la organización para
asegurar que se definan, acuerden y acepten claramente
los procesos aceptación y traspaso.
Ejemplo
Un banco de tamaño medio se fusionó con otro
banco que tenía una portfolio de productos
complementarios. Por lo tanto, la integración de
las aplicaciones fue sencilla. Aunque los dos bancos
consideraban que la consolidación de operaciones sería
beneficiosa, consideraron que no podían aprovecharse
suficientemente de las economías de escala. La
externalización también era una opción, pero en
cambio, los dos bancos eligieron asociarse con una
empresa externa. Los bancos ofrecieron el conocimiento
bancario específico para convertir los servicios de
TI de su organización en un centro de proceso de
datos atractivo para bancos más pequeños. El socio
externo ofreció la experiencia tecnológica necesaria y la
posibilidad de que los nuevos clientes se beneficiaran
de las economías de escala.
¿Cómo una organización determina la estrategia de
entrega óptima? No existe una respuesta única o sencilla
a esta cuestión. Depende demasiado de la situación
específica y única a tomar en consideración. Por esta
razón, la guía más apropiada que se puede proporcionar
es describir ventajas y desventajas clave de cada estrategia
de entrega. Esto, a su vez, se puede usar como una
lista de comprobación para determinar qué método de
entrega deberá evaluarse posteriormente y obtener el
máximo beneficio del proyecto específico o iniciativa de
negocio. La Tabla 3.3 incluye una lista de las estrategias
y sus ventajas y desventajas clave para la entrega de una
aplicación o servicio de TI.
La estrategia seleccionada dependerá de la capacidad
y necesidades de la organización específica, de su
negocio y de las personas, cultura y capacidades.
Independientemente de la estrategia seleccionada,
824_004 Chapter 03.indd 55
Principios de Diseñ̃o del Servicio | 55
su éxito y operación deberán medirse y revisarse
regularmente con respecto a la eficacia y eficiencia, y
adaptarse para satisfacer las necesidades cambiantes
del negocio. La selección adoptada con respecto a la
provisión del servicio de TI en muchas ocasiones se puede
ver influenciada por la cultura global del negocio y por su
método de externalización y asociación.
3.11.3  Métodos de diseño y desarrollo
También es importante entender los tipos, métodos
y estrategias del ciclo de vida genérico actual para el
desarrollo del servicio de TI con el objetivo de decidir
los estándares para la etapa de Diseño del Servicio del
ciclo de vida. Para lograr esto, es necesario entender
perfectamente los siguientes aspectos de los diversos
métodos del Ciclo de Vida de Desarrollo del Servicio
(SDLC):
■■ La estructura (por ejemplo, hitos/etapas/fases)
■■ Las actividades (por ejemplo, los flujos de trabajo o
pasos/tareas detalladas descritas en un método)
■■ Los modelos principales asociados con el método
elegido y que normalmente ofrecen una perspectiva
del proceso, una perspectiva de los datos, una
perspectiva de los eventos y, en muchas ocasiones,
una perspectiva del usuario. Los ejemplos incluyen
diagramas de caso de uso, diagramas de clases y
diagramas de gráficos de estado a partir del Lenguaje
de Modelado Unificado (UML).
Consulte el Capítulo 5 para disponer de más detalles sobre
SDLC.
3.11.3.1  Desarrollo Rápido de Aplicaciones
Es necesario entender las diferencias entre desarrollo de
sistemas orientados a objetos y sistemas estructurados,
los principios básicos del movimiento ‘Ágil’ (en este área
también se utilizan otros términos como Desarrollo Rápido
de Aplicaciones (RAD) o desarrollo acelerado) y reconocer
cómo un compromiso con una solución de paquete de
software cambia la estructura del método.
Estos métodos, que por defecto sólo abordan un
único sistema (y los servicios asociados), pueden
complementarse con métodos de arquitecturas, como
por ejemplo aquellos basados en la reutilización de
componentes (consulte la sección sobre la arquitectura si
desea ver un análisis más detallado).
El modelo del ciclo de vida de la aplicación descrito en
la sección sobre Gestión de Aplicaciones (sección 5.1.3)
puede verse como un ejemplo de método lineal o en
‘cascada’ (o modelo en ‘V’), y no se analizará con detalle
22/1/10 14:09:39
 56 | Principios de Diseñ̃o del Servicio

Tabla 3.3 Ventajas y desventajas de las estrategias de entrega del servicio

Estrategia de la entrega Ventajas
Internalización Control directo
Libertad de elección
Creación rápida de prototipos de servicios de
vanguardia
Familiarizarse con políticas y procesos
Conocimiento especificado de la compan~ía
Externalización Economías de escala
Compra de experiencia
El soporte se centra en las competencias
centrales de la compan~ía
Suporte para necesidades transitorias
Dirección de pruebas/ensayos de nuevos
servicios
Subcontratación Tiempo de comercialización
Aprovechamiento de la experiencia
Control
Uso de proveedores especializados
Asociación y aprovisionamiento Tiempo de comercialización
múltiple Expansión/entrada en el mercado
Respuesta competitiva
Aprovechamiento de la experiencia
Confianza, alineamiento y beneficio mutuo
Acuerdos de ‘Riesgo y reconocimiento’
Outsourcing de Procesos de Punto único de responsabilidad
Negocio (BPO) Acceso a habilidades de especialistas
Riesgo transferido a la empresa externa
Ubicación de bajo coste
Provisión de Servicios de Acceso a soluciones caras y complejas
Aplicaciones Ubicación de bajo coste
Soporte y actualizaciones incluidos
Opciones de seguridad e ITSCM incluidas
Outsourcing del Proceso de Acceso a habilidades, conocimiento y
Conocimiento (KPO) experiencia de especialistas
Ubicación de bajo coste
Ahorros significativos de costes
Desventajas
Limitaciones de escala
Coste y tiempo de comercialización para
servicios ya disponibles
Dependiente de recursos internos y de sus
habilidades y competencias
Control menos directo
Barreras de salida
Riesgo de solvencia de los proveedores
Habilidades y competencias de proveedores
desconocidos
Integración de procesos de negocio más
desafiantes
Aumento de la necesidad de gobierno y
verificación
Complejidad del proyecto
Propiedad intelectual y protección del copyright
Conflicto cultural entre empresas
Complejidad del proyecto
Propiedad intelectual y protección del copyright
Conflicto cultural entre empresas
Choque cultural entre empresas
Pérdida de conocimiento del negocio
Pérdida de relación con el negocio
Choque cultural entre empresas
Acceso sólo a instalaciones, no a conocimiento
Modelos de imputación de costes normalmente
basados en el uso
Choque cultural entre empresas
Pérdida de experiencia interna
Pérdida de relación con el negocio

aquí. Sólo se hará para propósitos de comparación con
otros métodos.
La funcionalidad principal de RAD es la introducción de
incrementos e iteraciones en el proceso de desarrollo
para la gestión de los riesgos asociados con requisitos
cambiantes y ambiguos. Los métodos tradicionales han
asumido que podría definirse anticipadamente en el ciclo
de vida un conjunto completo de requisitos y que los
costes de desarrollo podrían controlarse gestionando el
cambio. Sin embargo, es necesario afrontar el cambio
ya que, de no hacerse, podría significar una actitud
irresponsable con respecto a las condiciones del negocio.
Los métodos RAD aceptan que el cambio es inevitable e
intentan minimizar los costes a la hora de responder al
mismo, a la vez que se mantiene la calidad requerida.
El uso de incrementos implica que un servicio se desarrolla
pieza a pieza, donde cada pieza podría dar soporte a una
de las funciones de negocio que la totalidad del servicio
necesita. La entrega incremental podría acortar el tiempo
de comercialización en funciones de negocio específicas.
El desarrollo de cada incremento requiere atravesar todas
las etapas del ciclo de vida.
El desarrollo iterativo implica que el diseño atravesará más
de una vez el ciclo de vida. Se emplean técnicas como la

824_004 Chapter 03.indd 56 22/1/10 14:09:39


creación de prototipos para entender mejor los requisitos
(mediante actividades de prueba, funcionales, de gestión y
operativas y a través de la comunicación con los usuarios).
También sería posible aplicar combinaciones de métodos
iterativos e incrementales. Es posible empezar con la
especificación de requisitos para todo el servicio, seguido
por el diseño y desarrollo incremental de la aplicación.
Los métodos de desarrollo RAD, incluyendo el Proceso
Unificado y el Método de Desarrollo de Sistemas
Dinámicos (DSDM) se ven como una respuesta a las
expectativas del negocio, con el objetivo de reducir el
coste del cambio a lo largo de un proyecto de desarrollo.
DSDM utiliza la implicación continua del usuario en un
método incremental y de desarrollo iterativo, que es
responsable de los requisitos de cambio para desarrollar
un sistema de software que satisfaga los requisitos
de negocio a tiempo y dentro del presupuesto. Otro
ejemplo, Programación Extrema (XP), demanda de los
desarrolladores:
■■ Generar una primera entrega del servicio en semanas
para lograr una retroalimentación rápida y anticipada
■■ Inventar soluciones simples para que haya menos
aspectos a modificar y también para facilitar el cambio
■■ Mejorar continuamente la calidad del diseño
■■ Probar con anticipación para lograr una detección de
fallos menos costosa
■■ Usar disciplinas básicas como por ejemplo revisiones,
configuración y gestión de cambios para mantener el
control.
Para hacer un buen uso de un método incremental,
es necesario que el proceso de diseño se base en una
separación de asuntos agrupando funciones dentro
de incrementos de tal forma que se minimice su
interdependencia.
En términos generales, los métodos de desarrollo
acelerado de aplicaciones adoptan un modelo de ciclo de
vida de tres fases: análisis y diseño acelerado, desarrollo
encuadrado en tiempos y producción e implementación.
Los métodos normalmente están apoyados por tecnología
de ingeniería de software, y se basan en el trabajo
conjunto (usuario de TI) y en la creación de prototipos
para definir rápidamente requisitos y crear un prototipo de
trabajo.
Desde una perspectiva de negocio, el uso del desarrollo
y entrega incremental por parte de los desarrolladores
implica que una parte diferenciable y válida del servicio
global se puede entregar antes de que el equipo de
desarrollo tenga la capacidad de completar todo el
proyecto. Este método ofrece beneficios anticipados al
824_004 Chapter 03.indd 57
Principios de Diseñ̃o del Servicio | 57
negocio, y ofrece una oportunidad para que el negocio
y el equipo de desarrollo descubran propiedades
emergentes del servicio y aprendan de su experiencia.
Sin embargo, en muchas ocasiones es difícil encontrar un
primer incremento suficientemente pequeño que pueda
proporcionar un servicio significativo al negocio.
Los métodos RAD que implican una iteración y entrega
incremental pueden servir para reducir riesgos de
desarrollo e implementación. Puede que los proyectos
reales no sean necesariamente fáciles de gestionar, pero
pueden facilitar la implementación y aceptación. Ofrecen
más opciones para evitar eventualidades y permiten que
los desarrolladores aborden requisitos cambiantes de
negocio y condiciones del entorno. También proporcionan
hitos y puntos de decisión para el control del proyecto.
Estos métodos pueden emplearse también para:
■■ Alcanzar o converger en un diseño aceptable para el
cliente y factible para el equipo de desarrollo
■■ Limitar la exposición del proyecto a elementos
impredecibles de cambio en el negocio y en el
entorno
■■ Ahorrar tiempo de desarrollo, aunque para que un
proyecto RAD tenga éxito, deberá negociarse algo más
que la planificación. (RAD tiene más oportunidades
de éxito si el negocio está dispuesto a negociar la
funcionalidad y la calidad).
Las restricciones importantes del Desarrollo Rápido de
Aplicaciones (RAD) o los Factores Críticos de Éxito (CSFs)
incluyen:
■■ ‘Idoneidad para el propósito de negocio’ como el
criterio para la aceptación de entregables
■■ Representación de todas las partes que puedan influir
en los requisitos de la ampliación a lo largo del
proceso de desarrollo
■■ Aceptación de entregables informales por parte de
clientes, desarrolladores y dirección, p. ej., notas
de reuniones de trabajo del usuario, en lugar de
documentos formales de requisitos
■■ Creación de la documentación mínima necesaria para
facilitar el futuro desarrollo y mantenimiento
■■ Delegar a los equipos de desarrollo la toma de
decisiones que tradicionalmente se dejaba a la
dirección
■■ Aplicación de la iteración para converger hacia una
solución de negocio aceptable
■■ Prototipos que pueden incorporar requisitos que
evolucionen rápidamente para obtener un consenso lo
antes posible en el ciclo de vida.
22/1/10 14:09:40
 58 | Principios de Diseñ̃o del Servicio

Tabla 3.4 Comparativa entre métodos convencionales (‘en cascada’) y RAD

Categoría
Método general
Compromiso con los recursos del
usuario
Riesgo
Patrocinio ejecutivo
Uso de técnicas de sesión conjunta,
iteración y creación de prototipos
Habilidades del desarrollador
Uso de tecnología de soporte del
proceso, p. ej., herramientas CASE
Estructura del equipo
Gestión rigurosa del alcance
Estructura por fases
Responsabilidad individual
Desarrollo convencional Desarrollo acelerado
Fases secuenciales Evolutivo
±15% a lo largo del proyecto 100% a lo largo del proyecto para el
patrocinador del proyecto, ±30% para otros
seleccionados
Alto – puede que los problemas del proyecto Bajo – los problemas surgen anticipadamente
a largo plazo no surjan hasta bien entrado el en el proceso de desarrollo, lo que requiere una
proyecto de desarrollo resolución rápida
Tiene la autoridad de la aprobación, pero no Alta participación – establece el ámbito, revisa el
se implica activamente progreso y resuelve problemas
Opcional Requerido
Especialistas, algunos con experiencia limitada Se requieren profesionales multidisciplinares
aceptable altamente experimentados
Opcional Requerido
Normalmente grande con conjuntos de Normalmente pequeño con conjuntos de
habilidades especializadas habilidades generales, complementadas por
especialistas cuando sea necesario
Necesario Crítico
4–5 fases 3 fases
Difícil de evaluar Responsabilidad precisa

El uso de los métodos RAD requiere equipos
multidisciplinares y experimentados que sean capaces de
indicar cuándo aplicar tales métodos.
3.11.3.2  Soluciones de software empaquetado
Actualmente muchas organizaciones deciden cumplir
sus requisitos del servicio de TI mediante la compra e
implementación de soluciones de paquetes de software
de Producto Software Empaquetado (COTS). Es necesario
un marco de trabajo para seleccionar, personalizar e
implementar estas soluciones de software empaquetado e
implica la necesidad de:
■■ Entender completamente las ventajas y desventajas del
método de software empaquetado
■■ Definir un marco de trabajo para la selección eficaz
del paquete de software
■■ Definir un marco para la personalización e integración
eficaz
■■ Definir los requisitos funcionales al nivel apropiado
■■ Desarrollar una lista de comprobación de requisitos de
gestión y operativos
■■ Definir requisitos del producto y de proveedores
■■ Definir los requisitos de integración del servicio
■■ Identificar e investigar posibles soluciones de paquete
de software empaquetado
■■ Presentar recomendaciones sobre la idoneidad de un
paquete de software empaquetado con respecto a
los requisitos acordados, y definir las implicaciones de
ello.
Serán necesarios estándares detallados:
■■ En paquetes y en la creación de prototipos
■■ En la definición de la estructura de matrices
ponderadas de evaluación
■■ Iteración en la selección del paquete.
Adicionalmente, serán necesarios procedimientos para
evaluar y comparar paquetes competidores en términos
de requisitos de personalización/integración, y deberán
incluir:
■■ Evaluación de la correspondencia funcional
■■ Demostraciones programadas y evaluación dirigida por
el usuario
■■ Evaluación de la correspondencia operativa y de
gestión
■■ Evaluación de la correspondencia de los requisitos de
implementación.
Los estándares para documentar requisitos antes de la
investigación de paquetes del mercado incluirán aquellos
que muestren específicamente:

824_004 Chapter 03.indd 58 22/1/10 14:09:40

 Principios de Diseñ̃o del Servicio | 59

■■ Funciones de alto nivel (para propósitos de alcance)

■■ Funciones de negocio y eventos significativos
■■ Entrada significativa y requisitos de salida
■■ Estructuras de datos (estáticos)
■■ Identificación de relaciones entre esas estructuras,
funciones y eventos
■■ Requisitos operativos y de gestión de todo el servicio
■■ Requisitos no funcionales como por ejemplo
rendimiento, comportamiento, capacidades de
recuperación ante desastres, infraestructura y
estándares de seguridad.
Al evaluar soluciones de COTS, considere los tres
siguientes procedimientos con los que se puede cumplir
un requisito:
■■ Paquete de software disponible
■■ Se puede configurar. Estime el esfuerzo necesario para
realizar la configuración. Esto sólo es necesario hacerlo
una vez y se conservará durante las actualizaciones
del producto
■■ Debe personalizarse. Estime el esfuerzo necesario
para realizar la personalización inicialmente y para
repetirla en cada actualización del producto, teniendo
en cuenta que es posible que el concepto de
personalización no sea aplicable a futuras versiones.
Además, investigue la estrategia y el plan de entrega del
proveedor del paquete y asegúrese de que se alineen
con los suyos, y hasta qué punto puede esperar que el
paquete cumpla sus futuros requisitos.

824_004 Chapter 03.indd 59 22/1/10 14:09:40

824_004 Chapter 03.indd 60 22/1/10 14:09:40
824_005 Chapter 04.indd 61
Procesos de Diseñ̃o
del Servicio 4
22/1/10 13:49:26
824_005 Chapter 04.indd 62 22/1/10 13:49:27
 4 Procesos de Diseño del Servicio

Este capítulo describe y explica los fundamentos de los
procesos de soporte clave de Diseño del Servicio. Estos
procesos son responsables principalmente de proporcionar
información clave para el diseño de soluciones del servicio
nuevas o modificadas. Existen cinco aspectos del diseño
que es necesario considerar:
■■ El diseño de los servicios, que incluye todos los
requisitos funcionales, recursos y capacidades
necesarios y acordados
■■ El diseño de sistemas y herramientas de Gestión del
Servicio, especialmente el Porfolio de Servicios para la
gestión y control de servicios a lo largo de su ciclo de
vida
■■ El diseño de las arquitecturas tecnológicas y sistemas
de gestión requeridos para proveer los servicios
■■ El diseño de los procesos necesarios para el diseño,
transición, operación y mejora de los servicios, las
arquitecturas y los propios procesos
■■ El diseño de los métodos de medida y métricas de los
servicios, las arquitecturas y sus componentes y los
procesos.
Deberá adoptarse un método orientado por resultados
para cada uno de los cinco aspectos anteriores. En cada
uno de ellos, las salidas deseadas del negocio y los
resultados planificados deberán definirse para que lo
que se entregue cumpla las expectativas de los clientes y

Requisitos El negocio/clientes

Estrategia Objetivos
del Servicio Resursos y de los
requisitos
Políticas restricciones
Estrategias

Diseño
del Servicio SDPs
Estándares
Diseños de Arquitecturas
Catálogo de Servicios
Portfolio de Servicios

la Solución

Transición
del Servicio
Soluciones SKMS
Planes Probadas
de Transición

Operación Servicios
del Servicio operativos

Mejora
Continua
del Servicio Acciones y
planes de mejora

Figura 4.1  Los vínculos, entradas y salidas clave de Diseño del Servicio

824_005 Chapter 04.indd 63 22/1/10 13:49:28

 64 | Procesos de Diseñ̃o del Servicio

usuarios. Por lo tanto, este método estructurado deberá contexto, también deberán reflejar las necesidades de las
adoptarse dentro de cada uno de los cinco aspectos para estrategias, planes y políticas generadas por los procesos
entregar calidad, consistencia repetible y mejora continua de Estrategia del Servicio, como se ilustra en la Figura 4.1.
en toda la organización. No existen situaciones dentro
La Figura 4.1 ofrece una buena descripción general de
de la provisión del servicio de TI con suministradores
los vínculos, entradas y salidas implicadas en cada etapa
externos o internos de servicios donde no haya procesos
del Ciclo de Vida del Servicio. Ilustra las salidas clave
en el área de Diseño del Servicio. Todas las organizaciones
generadas por cada etapa, que se usan como entradas
de proveedores de servicios de TI ya tienen algunos
para las etapas siguientes. El Porfolio de Servicios actúa
elementos de su método para estos cinco aspectos
como ‘la columna vertebral’ del Ciclo de Vida del Servicio.
establecidos, independientemente de lo básicos que sean.
Esta es la fuente integrada y única de información sobre
Antes de empezar con la implementación de la mejora de
el estado de cada servicio, junto con otros detalles del
actividades y procesos, deberá realizarse una revisión de
servicio y las interfaces y dependencias entre servicios. Las
los elementos que ya están establecidos y que funcionan
actividades de cada etapa del Ciclo de Vida del Servicio
satisfactoriamente. Muchas organizaciones de proveedores
utilizan la información que se incluye en el Porfolio de
de servicios ya disponen de procesos maduros
Servicios.
establecidos para diseñar soluciones y servicios de TI.
La salida clave de la etapa Diseño del Servicio es el
Todos los diseños y actividades de diseño necesitan
diseño de soluciones del servicio para cumplir los
orientarse principalmente en función de las necesidades y
requisitos cambiantes del negocio. Sin embargo, al diseñar
requisitos de negocio de la organización. Dentro de este

Nuevos Nuevos ser-

requisitos vicios operativos

Estrategia del Estrategias y Paquete de Transición Operación

Servicio restricciones Diseño del Servicio del Servicio del Servicio

Diseño
Analizar requisitos,
documentar y Diseñar solución Evaluar soluciones Comprar la solución Desarrollar la del Servicio
acordar del servicio alternativas preferida solución

Arquitecturas

Portfolio de Métodos de
Servicios medida

Procesos Clave de
Diseño del Servicio
Disponibilidad: ITSCM: Seguridad:
Catálogo SLM: Capacidad: política, planes, plítica, planes, BIA, política, planes, Suministrador:
de Servicios política, planes, SIP, políticas, planes, criterios de diseño, BCPs, IT SCPs, riesgo, análisis, política, planes,
SLRs, SLAs, CMIS, informes, análisis del riesgo, análisis del riesgo, informes, informes, SCD,
OLAs, informes dimensionamiento, AMIS, informes, informes y clasificación, contratos
previsiones planificaciones planificaciones controles

Gestión del Cat. Gestión del Gestión de Gestión de la G. Continuidad Seguridad de Gestión de
de Servicios Nivel de Servicio la Capacidad Disponibilidad Servicio de TI la Información Suministradores

Entradas de proceso desde otras áreas, incluyendo: Evento, Incidencia, Problema, Gestión de Peticiones, Acceso,
Cambio, Configuración, Conocimiento, Entrega y Despliegue (planificación, evaluación del riesgo, construcción y
prueba, aceptación), Financiero, Portfolio de Servicios, Gestión de la Demanda

Figura 4.2  Diseño del Servicio – visión general

824_005 Chapter 04.indd 64 22/1/10 13:49:28


estas soluciones, es necesario considerar la entrada de
muchas áreas diferentes dentro de varias actividades
implicadas en el diseño de la solución del servicio, desde
la identificación y análisis de requisitos, a través de la
construcción de una solución y SDP, hasta el traspaso a
Transición del Servicio.
Para desarrollar soluciones de servicio eficaces y eficientes
que cumplan y continúen cumpliendo los requisitos
del negocio y las necesidades de TI, es esencial que se
reconsideren todas las entradas y necesidades de todas
las demás áreas y procesos dentro de las actividades
de Diseño del Servicio, como se ilustra en la Figura 4.2.
Esto asegurará que todas las soluciones del servicio sean
consistentes y compatibles con las soluciones existentes
y que cumplan las expectativas de los clientes y usuarios.
Esto se logrará de forma más eficaz consolidando estas
facetas de los procesos clave en todas estas actividades de
Diseño del Servicio, por lo que se hará referencia a todas
las entradas automáticamente cada vez que se genere una
solución del servicio nueva o modificada.
4.1  Gestión del Catálogo de Servicios
4.1.1  Propósito/meta/objetivo
El propósito de Gestión del Catálogo de Servicios es
proporcionar una única fuente de información consistente
sobre todos los servicios acordados, y asegurar que ésta
esté completamente disponible para aquellos a los que se
les haya autorizado el acceso a la misma.
El objetivo del proceso de Gestión del Catálogo de
Servicios es garantizar que se genere y mantenga un
Catálogo de Servicios que contenga información detallada
sobre todos los servicios operativos y sobre aquellos que
se estén preparando para que funcionen operativamente.
El objetivo de Gestión del Catálogo de Servicios es
gestionar la información contenida dentro del Catálogo
de Servicios, y garantizar que sea preciso y refleje los
detalles, estado, interfaces y dependencias actuales de
todos los servicios que están empezando a funcionar, o
que se estén preparando para tal efecto, en el entorno de
producción.
4.1.2 Ámbito
El alcance del proceso de Gestión del Catálogo de
Servicios es proporcionar y mantener información precisa
sobre todos los servicios que estén en transición o que
hayan pasado por la transición hasta el entorno de
producción.
824_005 Chapter 04.indd 65
Procesos de Diseñ̃o del Servicio | 65
Las actividades de Gestión del Catálogo de Servicios
deberán incluir:
■■ Definición del servicio
■■ Producción y mantenimiento de un Catálogo de
Servicios preciso
■■ Interfaces, dependencias y consistencia entre el
Catálogo de Servicios y el Portfolio de Servicios
■■ Interfaces y dependencias entre todos los servicios
y los servicios de soporte dentro del Catálogo de
Servicios y del CMS
■■ Interfaces y dependencias entre todos los servicios,
y componentes de soporte y Elementos de
Configuración (CIs) dentro del Catálogo de Servicios y
del CMS.
4.1.3  Valor para el negocio
El Catálogo de Servicios proporciona una fuente central
de información sobre los servicios de TI entregados por
la organización del proveedor de servicios. Esto garantiza
que todas las áreas del negocio puedan ver una imagen
consistente y precisa de los servicios de TI, sus detalles
y estado. Contiene una visión dirigida al cliente de los
servicios de TI en uso, cómo se pretende que se utilicen,
los procesos de negocio que habilitan, y los niveles y
calidad que el cliente puede esperar de cada servicio.
4.1.4  Políticas, principios y conceptos
básicos
Con los años, las infraestructuras de TI de las
organizaciones han crecido y se han desarrollado, y es
posible que no exista una imagen clara de todos los
servicios que se están suministrando y de los clientes
de cada servicio. Para establecer una imagen precisa, se
recomienda generar y mantener un Porfolio de Servicios
de TI que contenga un Catálogo de Servicios que
proporcione una información precisa y centralizada sobre
todos los servicios y que desarrolle una cultura centrada
en el servicio.
El Porfolio de Servicios deberá contener todos los futuros
requisitos de los servicios y el Catálogo de Servicios
deberá contener detalles de todos los servicios que se
están proporcionando actualmente o aquellos que se
están preparando para la transición hasta el entorno de
producción, un resumen de sus características, y detalles
de los clientes y personas encargadas del mantenimiento
de cada uno. Podría ser necesario un cierto nivel de
‘trabajo de detección’ para compilar esta lista y acordarla
con los clientes (entresacándola de documentación
antigua, buscando en bibliotecas del programa, hablando
con personal de TI y clientes, mirando registros de
22/1/10 13:49:28
 66 | Procesos de Diseñ̃o del Servicio
compras y hablando con proveedores y contratistas, etc.).
Si existiera un CMS o cualquier tipo de base de datos
de los activos, éstos podrían proporcionar fuentes de
información valiosas, aunque deberían verificarse antes de
su inclusión dentro de l Portfolio de Servicios o Catálogo
de Servicios. El Porfolio de Servicios se proporciona como
parte de la Estrategia del Servicio y deberá incluir la
participación de aquellos implicados y/o afectados por
el Diseño, Transición, Operación y Mejora del Servicio.
Una vez que se establece un servicio (en desarrollo para
el uso de los clientes), Diseño del Servicio genera las
especificaciones para el mismo, y es en este punto cuando
deberá añadirse al Catálogo de Servicios.
Cada organización deberá desarrollar y mantener una
política asociada con el Porfolio y el Catálogo en relación
con los servicios registrados en ellos, qué detalles y qué
estados se registran para cada uno de los servicios. La
política deberá contener detalles de las responsabilidades
para cada sección del Porfolio de Servicios general y el
ámbito de cada una de las secciones que lo forman.
El proceso Gestión del Catálogo de Servicios genera y
mantiene el Catálogo de Servicios, garantizando que
se proporcione una fuente de datos central, precisa y
consistente, y registra el estado de todos los servicios
operativos y de todos los servicios que están en transición
hasta el entorno activo, junto con los detalles apropiados
para cada servicio.
¿Qué es un servicio? Esta pregunta no es tan fácil de
responder como puede parecer a primera vista, y muchas
organizaciones han fallado a la hora de ofrecer una
definición clara en un contexto de TI. El personal de TI
confunde en muchas ocasiones un ‘servicio’ como lo
que percibe un cliente relacionado con un sistema de
TI. En muchos casos un ‘servicio’ puede estar constituido
por otros ‘servicios’ (y así sucesivamente), que también
pueden estar constituidos por uno o más sistemas de
TI dentro de una infraestructura general que incluya
hardware, software, redes, junto con entornos, datos y
aplicaciones. En muchas ocasiones un buen punto de
inicio es preguntar a los clientes qué servicios de TI usan
y cómo esos servicios se corresponden y dan soporte a
sus procesos de negocio. Los clientes a menudo tienen
más claro lo que creen que debe ser un servicio. Cada
organización necesita desarrollar una política que defina
qué es un servicio y cómo se define y acuerda dentro de
su propia organización.
Para evitar confusión, podría ser una buena idea definir
una jerarquía de servicios dentro del Catálogo de Servicios
determinando exactamente qué tipo de servicio son
registrados en la misma, p. ej., servicio del negocio (lo que
ve el cliente). De forma alternativa, también será necesario
824_005 Chapter 04.indd 66
registrar servicios de soporte, como por ejemplo servicios
de la infraestructura, servicios de red, servicios de la
aplicación (todo transparente para el cliente, pero esencial
para la entrega de servicios de TI). A menudo esto deriva
en una jerarquía de servicios que incorporan servicios del
cliente y otros servicios asociados, incluyendo servicios de
soporte, servicios compartidos y servicios commodity, cada
uno con niveles de servicio definidos y acordados.
Cuando se completa inicialmente, el Catálogo de Servicios
podría consistir en una matriz, tabla u hoja de cálculo.
Muchas organizaciones integran y mantienen su Porfolio
de Servicios y Catálogo de Servicios como parte de
su CMS. Con la definición de cada servicio como un
Elemento de Configuración (CI) y, cuando sea apropiado,
su asociación para formar una jerarquía de servicios, la
organización podrá asociar eventos como por ejemplo
incidencias y RFCs con los servicios afectados, y obtener la
base para la monitorización y generación de informes del
servicio usando una herramienta integrada (p. ej., ‘listar o
proporcionar el número de incidencias que afectan a este
servicio en particular’). Por lo tanto, es esencial que los
cambios en el Porfolio de Servicios y en el Catálogo de
servicios estén sujetos al proceso de Gestión de Cambios.
El Catálogo de Servicios también se puede utilizar para
otros propósitos de Gestión del Servicio (p. ej., para realizar
un Análisis de Impacto en el Negocio (BIA) como parte de
la Planificación de la Continuidad de los Servicios de TI, o
como punto de inicio para redistribuir cargas de trabajo,
como parte de Gestión de Capacidad. Por lo tanto, el
coste y esfuerzo de generar y mantener el catálogo, con
sus relaciones para ser sustentado por componentes de
la tecnología, es fácilmente ajustable. Si se realiza junto
con la priorización del BIA, entonces es posible garantizar
que se cubran primero los servicios más importantes. En
el Apéndice G se ofrece un ejemplo de un Catálogo de
Servicios simple que se pueda usar como un punto de inicio.
El Catálogo de Servicios presenta dos aspectos:
■■ El Catálogo de Servicios de Negocio: que contiene
detalles de todos los servicios de TI entregados al
cliente, junto con las relaciones con las unidades de
negocio y con el proceso de negocio que se basan
en los servicios de TI. Esta es la visión del cliente del
Catálogo de Servicios.
■■ El Catálogo de Servicios Técnicos: que contiene
detalles de todos los servicios de TI entregados al
cliente, junto con las relaciones con los servicios de
soporte, servicios compartidos, componentes y CIs
necesarios para dar soporte a la provisión del servicio
al negocio. Esto deberá apoyar al Catálogo de Servicios
de Negocio y no forma parte de la visión del cliente.
22/1/10 13:49:29
 Procesos de Diseñ̃o del Servicio | 67

El Catálogo de Servicios

Proceso de Proceso de Proceso de

Negocio 1 Negocio 2 Negocio 3

Catálogo de Servicios del Negocio

Servicio A Servicio B Servicio C Servicio D Servicio E

Catálogo de Servicios Técnicos

Servicios
Hardware Software Aplicaciones Datos
de Soporte

Figura 4.3  El Catálogo de Servicios de Negocio y el Catálogo de Servicios Técnicos

La relación entre estos dos aspectos se ilustra en la Figura 4.3. ■■ Acordar y documentar una definición del servicio con
todas las partes relevantes implicadas y/o afectadas
Algunas organizaciones sólo mantienen un Catálogo de
■■ Hacer de interfaz con Gestión del Porfolio de Servicios
Servicios de Negocio o un Catálogo de Servicios Técnicos.
La situación preferida adoptada por las organizaciones más para acordar los contenidos del Porfolio de Servicios y
maduras mantiene ambos aspectos dentro de un único del Catálogo de Servicios
Catálogo de Servicios, que forma parte de una actividad
de Gestión del Servicio totalmente integrada y del Porfolio
SLA de nivel específico de servicio
de Servicios. En el Apéndice G se incluye más información
sobre el diseño y contenido de un Catálogo de Servicios. El
Catálogo de Servicios de Negocio facilita el desarrollo de un
proceso de SLM mucho más proactivo o incluso preventivo, SLA de nivel de cliente o
lo que le permite desarrollarse más en el campo de Gestión SLA de nivel de Unidad de Negocio
de Servicios de Negocio. El Catálogo de Servicios Técnicos es
extremadamente beneficioso al establecer la relación entre
servicios, SLAs, OLAs y otros acuerdos y componentes de
apoyo, ya que identificará la tecnología requerida para dar
soporte a un servicio y a los grupos de servicios que dan SLA de nivel corporativo
soporte a los componentes. La combinación de un Catálogo
de Servicios de Negocio y un Catálogo de Servicios Técnicos
es inestimable para evaluar rápidamente el impacto de las
incidencias y los cambios en el negocio. En la Figura 4.4 se
muestra un ejemplo de relaciones entre la partes Técnicas y
de Negocio de un Catálogo de Servicios.

4.1.5 Actividades, métodos y técnicas del

proceso
Las actividades clave del proceso de Gestión del Catálogo
de Servicios deberán incluir:
Figura 4.4  Ejemplo de Catálogo de Servicios

824_005 Chapter 04.indd 67 22/1/10 13:49:29

 68 | Procesos de Diseñ̃o del Servicio
■■ Generar y mantener un Catálogo de Servicios y sus
contenidos, junto con el Portfolio de Servicios
■■ Hacer de interfaz con el negocio y con Gestión
de la Continuidad del Servicio de TI con respecto
a las dependencias de las unidades de negocio y
sus procesos de negocio con los servicios de TI de
soporte, incluidos dentro del Catálogo de Servicios de
Negocio
■■ Hacer de interfaz con equipos de soporte, proveedores
y Gestión de la Configuración con respecto a
interfaces y dependencias entre servicios de TI y los
servicios de soporte, componentes y CIs contenidos
dentro del Catálogo de Servicios Técnicos
■■ Hacer de interfaz con Gestión de las Relaciones con el
Negocio y Gestión del Nivel de Servicio para garantizar
que la información se alinee con el negocio y con el
proceso de negocio.
4.1.6  Disparadores, entradas, salidas e
interfaces
Existen varias fuentes de información que son relevantes
para el proceso de Gestión del Catálogo de Servicios. Éstas
incluyen:
■■ Información del negocio procedente de la estrategia
de negocio y de TI, de los planes generales y
financieros de la organización, e información sobre sus
requisitos actuales y futuros a partir del Porfolio de
Servicios
■■ Análisis de Impacto en el Negocio, que proporciona
información sobre el impacto, prioridad y riesgos
asociados con cada servicio o cambio de los requisitos
del servicio
■■ Requisitos de negocio: detalles de cualquier requisito
de negocio acordado, nuevo o modificado a partir del
Porfolio de Servicios
■■ El Porfolio de Servicios
■■ El CMS
■■ Retroalimentación procedente de otros procesos.
Los disparadores para el proceso de Gestión del Catálogo
de Servicios se modifican en los servicios y requisitos de
negocio, y por lo tanto uno de los disparadores principales
es Solicitud de Cambios (RFCS) y el proceso de Gestión
de Cambios. Esto incluirá nuevos servicios, cambios en los
servicios existentes o servicios que se están retirando.
Las salidas del proceso de SCM son:
■■ La documentación y acuerdo de una ‘definición del
servicio’
824_005 Chapter 04.indd 68
■■ Actualizaciones en el Porfolio de Servicios: deberá
contener el estado actual de todos los servicios y
requisitos de los servicios
■■ El Catálogo de Servicios: deberá contener los detalles
y el estado actual de cada servicio real suministrado
por el proveedor de servicio o del servicio que está en
transición hasta el entorno de producción junto con
las interfaces y dependencias. El Apéndice G incluye
un ejemplo de Catálogo de Servicios.
4.1.7  Gestión de la información
La información clave dentro del proceso de Gestión
del Catálogo de Servicios es aquella contenida dentro
del Catálogo de Servicios. La entrada principal para
esta información procede del Portfolio de Servicios y
del negocio a través de los procesos de Gestión de las
Relaciones con el Negocio (BRM) o de Gestión del Nivel de
Servicio (SLM). Es necesario verificar esta información para
determinar su precisión antes de registrarla en el Catálogo
de Servicios. Es necesario mantener la información y
el propio Catálogo de Servicios usando el proceso de
Gestión de Cambios.
4.1.8 Indicadores Clave de Rendimiento
Los dos Indicadores Clave de Rendimiento (KPIs) asociados
con el Catálogo de Servicios y con su gestión son:
■■ El número de servicios registrados y gestionados
dentro del Catálogo de Servicios como un porcentaje
de aquellos que se están entregando y están en
transición hasta el entorno de producción
■■ El número de variaciones detectadas entre la
información contenida dentro del Catálogo de
Servicios y la situación del ‘mundo real’.
Otras medidas y KPIs que se podrían utilizar son:
■■ Concienciación de los usuarios del negocio con
respecto a los servicios que se están suministrando, es
decir, incremento en porcentaje de la integridad del
Catálogo de Servicios de Negocio con respecto a los
servicios operativos
■■ Concienciación del personal de TI de la tecnología que
da soporte a los servicios:
●● Incremento del porcentaje de la integridad del
Catálogo de Servicios Técnicos con respecto a los
componentes de TI que dan soporte a los servicios
●● Centro de Servicio al Usuario con acceso a
información para dar soporte a todos los servicios
reales, medidos por el porcentaje de incidencias sin
la información apropiada asociada con el servicio.
22/1/10 13:49:29

4.1.9  Desafíos, Factores Críticos de Éxito y
riesgos
El reto principal a la hora de afrontar el proceso de
Gestión del Catálogo de Servicios es el de mantener un
Catálogo de Servicios preciso como parte de un Porfolio
de Servicios, incorporando el Catálogo de Servicios de
Negocio y el Catálogo de Servicios Técnicos como parte
de un CMS y SKMS generales. Este es el mejor método a
la hora de desarrollar hojas de cálculo o bases de datos
independientes antes de intentar el Catálogo de Servicios
y el Portfolio de Servicios con el CMS o SKMS. Para
lograrlo, es necesario que la cultura de la organización
acepte que el Catálogo y Porfolio sean fuentes esenciales
de información que toda la organización de TI necesita
usar y ayudar a mantener. En muchas ocasiones esto
ayudará a la estandarización del Catálogo de Servicios y el
Porfolio de Servicios y permitirá mejorar el rendimiento de
los costes a través de economías de escala.
Los Factores Críticos de Éxito del proceso de Gestión del
Catálogo de Servicios son:
■■ Un Catálogo de Servicios preciso y sin ambiguedades
■■ Concienciación de los usuarios del negocio de los
servicios que se están suministrando
■■ Concienciación del personal de TI de la tecnología que
da soporte a los servicios.
Los riesgos asociados con la provisión de un Catálogo de
Servicios preciso son:
■■ Imprecisión de los datos en el catálogo y que no
estén sometidos a un control de cambios riguroso
■■ Deficiente aceptación del Catálogo de Servicios y
su uso en todos los procesos operativos. Mientras
más activo sea el catálogo, más probable es que sea
preciso en su contenido
■■ Imprecisión en la información recibida del negocio,
de TI y del Porfolio de Servicios en relación con la
información del servicio
■■ Las herramientas y recursos requeridos para mantener
la información
■■ Acceso deficiente a información y procesos precisos de
Gestión de Cambios
■■ Acceso y soporte deficiente de CMS y SKMS
actualizados y apropiados
■■ Elusión del uso del Porfolio de Servicios y del Catálogo
de Servicios
■■ La información es o demasiado detallada para
mantenerla de forma precisa o está a un nivel
demasiado alto para tener algún valor. Debería ser
consistente con el nivel de detalle dentro del CMS y
del SKMS.
824_005 Chapter 04.indd 69
Procesos de Diseñ̃o del Servicio | 69
4.2  Gestión del Nivel de Servicio
Gestión del Nivel de Servicio (SLM) negocia, acuerda
y documenta objetivos apropiados del servicio de
TI con representantes del negocio, y a continuación
monitoriza y genera informes sobre la capacidad del
proveedor de servicio a la hora de entregar el nivel de
servicio acordado. SLM es un proceso vital para toda
organización del proveedor de servicios de TI en la que
es responsable de acordar y documentar objetivos de
nivel de servicio y responsabilidades dentro de SLAs y
SLRs para cada actividad dentro de TI. Si estos objetivos
fueran apropiados y reflejaran con precisión los requisitos
del negocio, entonces el servicio entregado por los
proveedores de servicio se alineará con los requisitos
de negocio y cumplirá las expectativas de los clientes
y usuarios en términos de calidad del servicio. Si estos
objetivos no se alinearan con las necesidades del negocio,
entonces las actividades del proveedor de servicio y los
niveles de servicio no se alinearán con las expectativas
del negocio y se generarán problemas. El SLA es un nivel
de aseguramiento o garantía en relación con el nivel de
calidad del servicio entregado por el proveedor de servicio
para cada uno de los servicios entregados al negocio. El
éxito de SLM depende en gran medida de la calidad del
Porfolio de Servicios y del Catálogo de Servicios y sus
contenidos, ya que proporcionan la información necesaria
sobre los servicios a gestionar dentro del proceso de SLM.
4.2.1  Propósito/meta/objetivo
El objetivo del proceso Gestión del Nivel de Servicio
es garantizar que se proporcione un nivel acordado de
servicio de TI para todos los servicios de TI actuales, y
que los futuros servicios se entreguen según los objetivos
alcanzables acordados. Las medidas proactivas también
tienen que buscar e implementar mejoras para el nivel de
servicio entregado.
El propósito del proceso de SLM es garantizar que todos
los servicios operativos y su rendimiento se midan de
forma profesional y consistente en toda la organización de
TI, y que los servicios y los informes generados satisfagan
las necesidades del negocio y de los clientes.
Los objetivos de SLM son:
■■ Definir, documentar, acordar, monitorizar, medir,
informar y revisar el nivel de los servicios de TI
proporcionados
■■ Proporcionar y mejorar la relación y comunicación con
el negocio y con los clientes
■■ Garantizar que los objetivos específicos y medibles se
desarrollen para todos los servicios de TI
22/1/10 13:49:29
 70 | Procesos de Diseñ̃o del Servicio
■■ Monitorizar y mejorar la satisfacción del cliente con la
calidad del servicio entregada
■■ Garantizar que TI y los clientes tengan una expectativa
clara y sin ambigüedades del nivel de servicio a
entregar
■■ Asegurar que se implementen medidas proactivas para
mejorar los niveles de servicio entregados siempre que
tengan un coste justificable.
4.2.2 Ámbito
SLM debería proporcionar una comunicación y punto de
contacto regular con los clientes y gestores de negocio
de una organización. Deberá representar al proveedor de
servicios de TI en el negocio, y al negocio en el proveedor
de servicios de TI. Esta actividad deberá abarcar el uso de
servicios existentes y los posibles futuros requisitos para
servicios nuevos o modificados. SLM necesita gestionar
la expectativa y percepción del negocio, clientes y
usuarios y garantizar que la calidad del servicio entregada
por el proveedor de servicio se corresponda con esas
expectativas y necesidades. Para hacerlo de forma
eficiente, SLM deberá establecer y mantener SLAs para
todos los servicios reales actuales y gestionar el nivel de
servicio suministrado para cumplir los objetivos y medidas
de calidad contenidos dentro de los SLAs. SLM también
deberá generar y acordar SLRs para todos los servicios
nuevos o modificados.
Esto permitirá a SLM asegurar que todos los servicios y
componentes se diseñen y entreguen para cumplir sus
objetivos en términos de necesidades del negocio. Los
procesos de SLM deben incluir:
■■ Desarrollo de relaciones con el negocio
■■ Negociación y acuerdo de requisitos y objetivos
actuales, y la documentación y gestión de SLAs para
todos los servicios operativos
■■ Negociación y acuerdo de requisitos y objetivos
actuales, y la documentación y gestión de SLRs para
todos los servicios nuevos o modificados propuestos
■■ Desarrollo y gestión de Acuerdos de Nivel Operativo
(OLAs) apropiados para asegurar que los objetivos se
alineen con los objetivos de los SLA
■■ Revisión de todos los contratos y acuerdos de
proveedores con Gestión de Suministradores para
asegurar que los objetivos se alineen con los objetivos
de los SLA
■■ Prevención proactiva de fallos del servicio, reducción
de riesgos del servicio y mejora de la calidad del
servicio, junto con todos los demás procesos
■■ Informe y gestión de todos los servicios y revisión de
todos los incumplimientos y debilidades de los SLA
824_005 Chapter 04.indd 70
■■ Instigación y coordinación de un Programa de Mejora
de Servicio (SIP) para la gestión, planificación e
implementación de todas las mejoras del servicio y del
proceso.
4.2.3  Valor para el negocio
SLM proporciona una interfaz consistente con el negocio
para todos los aspectos asociados con el servicio.
Proporciona al negocio objetivos acordados del servicio y
la información de gestión requerida para garantizar que
esos objetivos se hayan cumplido. Si se incumplieran los
objetivos, SLM deberá proporcionar retroalimentación
sobre la causa del incumplimiento y los detalles de las
acciones tomadas para evitar que se vuelva a producir
el incumplimiento. Por lo tanto, SLM proporciona un
canal de comunicación fiable y una relación de confianza
con los clientes adecuados y con los representantes del
negocio.
4.2.4  Políticas/principios/conceptos básicos
SLM es el nombre dado a los procesos de planificación,
coordinación, redacción, acuerdo, monitorización y
generación de informes de SLAs, y a la revisión continua
de los logros del servicio para asegurar que la calidad del
servicio requerida y justificable en costes se mantenga y
se mejore gradualmente. Sin embargo, el proceso SLM
no sólo está implicado a la hora de garantizar que se
gestionen los servicios actuales y SLAs, sino también
está implicado a la hora de asegurar que se capturen los
nuevos requisitos y que los servicios nuevos o modificados
y SLAs se desarrollen para que se correspondan con
las necesidades y expectativas del negocio. Los SLAs
proporcionan la base para gestionar la relación entre el
proveedor de servicio y el cliente, y SLM proporciona
ese punto central de enfoque para un grupo de clientes,
unidades de negocio o líneas de negocio.
Un SLA es un acuerdo escrito entre un proveedor de
servicios de TI y los clientes de TI, definiendo los objetivos
y responsabilidades clave del servicio para ambas partes.
El énfasis deberá ponerse en alcanzar un acuerdo, y los
SLAs no deberán usarse como un tipo de chantaje. Deberá
desarrollarse una asociación fiable entre el proveedor de
servicios de TI y el cliente para que se alcance un acuerdo
mutuamente beneficioso, de lo contrario, el SLA podría
caer rápidamente en descrédito y se podría generar una
‘cultura del resentimiento’ que evitaría cualquier mejora
real de la calidad del servicio.
SLM también es responsable de asegurar que todos
los objetivos y medidas acordados en los SLA con el
negocio estén respaldados por OLAs o contratos de apoyo
22/1/10 13:49:29
 Procesos de Diseñ̃o del Servicio | 71

Unidad de Negocio A Unidad de Negocio B Unidad de Negocio C

El negocio
3 6 9
2 5 8
Proceso Proceso Proceso
de negocio 1 de negocio 4 de negocio 7

Servicios de TI
F G
D E
Servicio A B C
SLAs
TI

Infraestructura

Sistema Sistema
DBMS Redes Entorno Datos Aplicaciones
H/W S/W

OLAs Servicios
de soporte

Equipos
Servicios Contratos
de soporte
(iii)
Equipo
(ii) Suministradores
de soporte (i)
(iii)
(ii)
Suministrador (i)

Figura 4.5  Gestión del Nivel de Servicio

adecuados, con unidades de soporte internas y con socios
y proveedores externos. Esto se ilustra en la Figura 4.5.
La Figura 4.5 muestra la relación entre el negocio, sus
procesos y los servicios, y la tecnología asociada, servicios
de soporte, equipos y proveedores requeridos para
cumplir sus necesidades. Demuestra la importancia de los
SLAs, OLAs y contratos a la hora de definir y lograr el nivel
de servicio requerido por el negocio.
Un OLA es un acuerdo entre un proveedor de servicios de
TI y otra parte de la misma organización que ayuda con
la provisión de servicios. Por ejemplo, un departamento
de instalaciones que mantiene el aire acondicionado, o el
equipo de soporte de red que da soporte al servicio de
red. Un OLA debería contener objetivos que den apoyo
a aquellos incluidos en un SLA para garantizar que no se
incumplan los objetivos por un fallo de la actividad de
soporte.
4.2.5 Actividades, métodos y técnicas del
proceso
Las actividades clave del proceso de SLM deberán incluir:
■■ Determinar, negociar, documentar y acordar requisitos
para servicios nuevos o modificados en SLRs, y
gestionar y revisarlos a lo largo del Ciclo de Vida del
Servicio en SLAs para servicios operativos
■■ Monitorizar y medir el rendimiento del servicio para
todos los servicios operativos con respecto a los
objetivos de los SLAs
■■ Cotejar, medir y mejorar la satisfacción del cliente
■■ Generar informes del servicio
■■ Dirigir mejoras de revisión e investigación del servicio
dentro de un Programa de Mejora de Servicio (SIP)
■■ Revisar y volver a examinar SLAs, OLAs dentro del
ámbito del servicio, contratos, y cualquier otro
acuerdo de soporte
■■ Desarrollar y documentar contactos y relaciones con el
negocio, clientes y accionistas
■■ Desarrollar, mantener y operar procedimientos
para registrar, accionar y resolver todas las no
conformidades, y para registrar y distribuir las
conformidades
■■ Registrar y gestionar todas las conformidades y no
conformidades

824_005 Chapter 04.indd 71 22/1/10 13:49:30

 72 | Procesos de Diseñ̃o del Servicio

Unidad de Negocio A Unidad de Negocio B

El negocio
3 6
2 5
Proceso Proceso
de negocio 1 de negocio 4
SLM

G
D F
Servicio A B C Documentar
SLR(s) SLA(s) SLA(s)
estándares
y plantillas
Determinar, Monitorizar el Dirigir revisiones
documentar y acordar rendimiento del servicio del servicio e instigar
requisitos para SLRs de frente al SLA y elaborar mejoras dentro de Asistir con el
nuevos servicios y informes del servicio un SIP Catálogo de Servicios
elaborar SLAs y mantener plantillas
de documentos

Desarrollar contactos
Recopilar, medir
y relaciones,
y mejorar la
registrar y gestionar Catálogo
satisfacción del
quejas felicitaciones de Servicios
cliente
Informes
del servicio

Revisar y volver a
analizar los SLAs,
ámbito de servicio y Contratos
acuerdos de apoyo
OLAs

Equipos Gestión de
suministradores Suministradores
de soporte

Figura 4.6  El proceso de Gestión del Nivel de Servicio

■■ Proporcionar la información de gestión apropiada para
ayudar a gestión del rendimiento y demostrar el éxito
del servicio
■■ Generar y mantener plantillas y estándares de
documentos actualizados de SLM.
Las interfaces entre las actividades principales se ilustran
en la Figura 4.6.
4.2.5.1  Diseño de los marcos de trabajo del SLA
Con el uso del Catálogo de Servicios como ayuda, SLM
deberá diseñar la estructura del SLA más apropiada para
garantizar que todos los servicios y clientes se incluyan
de la forma que mejor se adecue a las necesidades de la
organización. Existen varias opciones posibles, incluyendo
las siguientes.

Aunque la Figura 4.6 ilustra todas las actividades
principales de SLM como actividades independientes,
éstas deberán implementarse como un proceso de SLM
integrado que se pueda aplicar consistentemente en
todas las áreas de negocio y para todos los clientes. Estas
actividades se describen en las siguientes secciones.
SLA basado en el servicio
Aquí un SLA cubre un servicio para todos los clientes de
ese servicio. Por ejemplo, podría establecerse un SLA para
el servicio de correo electrónico de una organización
que incluya a todos los clientes de ese servicio. Esto
podría parecer bastante sencillo. Sin embargo, podrían
surgir dificultades si los requisitos específicos de
diferentes clientes variaran para el mismo servicio, o si las

824_005 Chapter 04.indd 72 22/1/10 13:49:30

 Procesos de Diseñ̃o del Servicio | 73

características de la infraestructura implicaran diferentes SLA de nivel específico de servicio

niveles de servicio (p. ej., el personal de la sede principal
podría conectarse a través de una LAN de alta velocidad,
mientras que puede que las oficinas locales tengan que
usar una línea WAN de baja velocidad). En tales casos,
es posible que sea necesario disponer de objetivos
SLA de nivel de cliente o
independientes dentro de un acuerdo. También podrían SLA de nivel de Unidad de Negocio
surgir dificultades a la hora de determinar quién debe
autorizar tal acuerdo. Sin embargo, en el caso de que se
proporcionen niveles comunes de servicio en todas las
áreas del negocio, p. ej., correo electrónico o telefonía, el
SLA de nivel corporativo
SLA basado en el servicio puede representar un método
eficiente a utilizar. También se pueden utilizar múltiples
clases de servicio, p. ej., oro, plata y bronce, para mejorar
la eficacia de los SLAs basados en servicios.

SLA basado en el cliente

Representa un acuerdo con un grupo de clientes
individuales que cubre todos los servicios que usan.
Por ejemplo, se podrían alcanzar acuerdos con un
departamento de finanzas de la organización que cubran,
por ejemplo, el sistema financiero, el sistema contable, el
sistema de nóminas, el sistema de facturación, el sistema
de compras, y cualquier otro sistema de TI que usen.
En muchas ocasiones los clientes prefieren este tipo de
acuerdos porque todos sus requisitos se recogen en un
único documento. Sólo se requiere normalmente una
firma de autorización, lo que simplifica este paso.
Sugerencias y consejos
Podría ser conveniente aplicar una combinación de
estas estructuras, especificando todos los servicios y
clientes que se cubren, sin solapes o duplicaciones.
SLAs multinivel
Algunas organizaciones han decidido adoptar una
estructura de SLA multinivel. Por ejemplo, una estructura
de tres capas es la siguiente:
■■ Nivel corporativo: que cubre todos los aspectos
genéricos de SLM apropiados para cada cliente en
toda la organización. Es probable que estos aspectos
sean menos volátiles por lo que se requieren
actualizaciones menos frecuentes
■■ Nivel del cliente: que cubre todos los aspectos de
SLM pertinentes para el grupo particular de clientes o
unidad de negocio, independientemente del servicio
que se esté usando
■■ Nivel de servicio: que cubre todos los aspectos de
SLM pertinentes para el servicio específico, en relación
Figura 4.7  SLAs multinivel
con un grupo específico de clientes (uno para cada
servicio cubierto por el SLA).
Como se muestra en la Figura 4.7, una estructura así
permite mantener los SLA en un tamaño manejable,
evita duplicaciones innecesarias, y reduce la necesidad
de realizar actualizaciones frecuentes. Sin embargo,
esto significa que se requiere un esfuerzo adicional para
mantener las relaciones y vínculos necesarios dentro del
Catálogo de Servicios y del CMS.
Muchas organizaciones lo han encontrado valioso para
generar estándares y un conjunto de proformas o plantillas
que se pueden usar como un punto de inicio para todos
los SLAs, SLRs y OLAs. En muchas ocasiones la proforma
puede desarrollarse junto con el SLA de borrador. En el
Apéndice F se proporciona una guía sobre los elementos
a incluir en un SLA. El desarrollo de estándares y de
plantillas asegurará que todos los acuerdos se desarrollen
de forma consistente y homogénea, lo que facilitará su
uso, operación y gestión posteriores.
Sugerencias y consejos
Cree roles y responsabilidades como parte del SLA.
Considere tres perspectivas, el proveedor de TI, el
cliente de TI y los usuarios finales.

824_005 Chapter 04.indd 73 22/1/10 13:49:30

 74 | Procesos de Diseñ̃o del Servicio
La redacción de los SLA deberá ser clara y concisa y no
debe dejar lugar a ambigüedades. Normalmente no hay
necesidad de escribir los acuerdos en terminología legal, y
el lenguaje sencillo favorece el entendimiento. En muchas
ocasiones es útil que una persona independiente que no
haya estado implicada en la redacción haga una lectura
final. Esto elimina con frecuencia posibles ambigüedades
y dificultades que podrán abordarse y aclararse en ese
momento. Por esta única razón, se recomienda que todos
los SLA incluyan un glosario con la definición de cualquier
término y que aclare cualquier área de ambigüedad.
También es importante recordar que los SLA podrían tener
que recoger servicios ofrecidos internacionalmente. En
tales casos, puede que el SLA tenga traducirse a varios
idiomas. Recuerde también que es posible que un SLA
redactado en un único idioma tenga que revisarse para
adecuarse a las diferentes localizaciones del mundo (es
decir, puede que una versión elaborada en Australia
tenga que revisarse para su adecuación a EE.UU. o al
Reino Unido, teniendo en cuenta las diferencias en la
terminología, estilo y cultura).
Cuando los servicios de TI se proporcionan para otra
organización a través de un suministrador externo de
servicios, algunas veces los objetivos del servicio están
contenidos en un contrato y en otras ocasiones están
contenidos en un SLA o programación adjuntos al
contrato. Independientemente del documento que se
utilice, es esencial que los objetivos se documenten y
acuerden de forma clara, específica y sin ambigüedades,
ya que proporcionarán la base requerida de la relación y
la calidad del servicio.
4.2.5.2  Determinar, documentar y acordar
requisitos para nuevos servicios y generar SLRs
Esta es una de las primeras actividades de la etapa de
Diseño del Servicio del Ciclo de Vida del Servicio. Una
vez se haya generado el Catálogo de Servicios y se haya
acordado la estructura del SLA, deberá redactarse un primer
SLR. Es aconsejable implicar a los clientes desde el principio,
pero antes de estar de acuerdo con una hoja modelo con
la que comenzar, podría ser más conveniente generar un
primer borrador con los objetivos de rendimiento y con los
requisitos operativos y de gestión, como punto de inicio
para llevar a cabo un análisis en profundidad y detallado.
Sin embargo, tenga cuidado de no ir demasiado lejos y
presentar al cliente un ‘asunto hecho’.
No se puede dejar de recalcar la dificultad de esta
actividad a la hora de determinar los objetivos iniciales
para su inclusión en un SLR o SLA. Es necesario implicar a
todos los demás procesos para conocer su opinión sobre
824_005 Chapter 04.indd 74
los objetivos que se pueden alcanzar de forma realista,
como por ejemplo Gestión de Incidencias con respecto
a objetivos de incidencias. Los procesos de Gestión de la
Disponibilidad y Capacidad tendrán valor particularmente
a la hora de determinar la disponibilidad adecuada del
servicio y los objetivos de rendimiento. Si hubiera alguna
duda, deberán incluirse objetivos provisionales en un SLA
piloto que se monitorice y ajuste a lo largo de un periodo
de garantía del servicio, como se ilustra en la Figura 3.5.
Aunque muchas organizaciones tienen que dar
prioridad inicialmente a la introducción de SLAs para
servicios existentes, también es importante establecer
procedimientos para acordar Requisitos de Nivel de
Servicio (SLR) para los nuevos servicios que se están
desarrollando o comprando.
Los SLR deberán ser parte integral de los criterios de Diseño
del Servicio, de los cuales forma parte la especificación
funcional. Los SLR deberán, desde el principio, formar
parte de los criterios de prueba/ensayo ya que el servicio
progresa a través de las etapas de diseño y desarrollo o
compras. Este SLR volverá a definirse gradualmente, puesto
que el servicio progresa a través de las etapas de su ciclo
de vida, hasta que eventualmente se convierta en un SLA
piloto durante el periodo de soporte post implantación.
Este piloto o borrador de SLA deberá desarrollarse junto con
el propio servicio, y deberá firmarse y formalizarse antes de
que el servicio se introduzca en el uso real.
Puede ser difícil extraer requisitos, ya que es posible que el
negocio no sepa lo que quiere, especialmente si no se le
pregunta previamente, y podría necesitar ayuda a la hora
de entender y definir sus necesidades, particularmente
en términos de capacidad, seguridad, disponibilidad y
continuidad del servicio de TI. Sea consciente de que cabe
la posibilidad de que los requisitos expresados inicialmente
no sean aquellos acordados en última instancia. Podrían
requerirse múltiples iteraciones de negociaciones antes de
se alcance un equilibrio asequible entre lo que se busca
y lo que es alcanzable y asequible. Este proceso podría
implicar un rediseño de la solución del servicio.
Si los nuevos servicios se introdujeran de forma
homogénea en el entorno de producción, otra área que
requerirá atención será la planificación y formalización
de los acuerdos de soporte para el servicio y sus
componentes. Deberá buscarse asesoramiento de Gestión
de Cambios y en Gestión de la Configuración para
garantizar que la planificación sea integral y cubra la
implementación, despliegue y soporte del servicio y
de sus componentes. Será necesario definir y agregar
responsabilidades específicas a contratos/OLAs existentes, o
a aquellos nuevos que será necesario acordar. También es
22/1/10 13:49:30

necesario agregar al CMS los acuerdos de soporte y todas
las rutas de escalado, incluyendo el Catálogo de Servicios
cuando sea apropiado, para que el Centro de Servicio al
Usuario y otro personal de soporte sean conscientes de
ellos. Cuando sea apropiado, antes de que sea necesario
el soporte real, deberá completarse la formación y
familiarización del Centro de Servicio al Usuario y de otros
grupos de soporte, y la transferencia de conocimiento.
Debe tenerse en cuenta que podrían necesitarse recursos
de soporte adicionales (p. ej., más personal) para dar
soporte a nuevos servicios. A menudo se espera que un
grupo de soporte ya sobrecargado de trabajo pueda hacer
frente mágicamente al esfuerzo adicional que impone un
nuevo servicio.
Teniendo como base un acuerdo redactado, deberán
mantenerse negociaciones con los clientes, o con sus
representantes, para dar por finalizado el contenido de
los SLA y los objetivos iniciales de nivel de servicio, y con
los proveedores de servicio para garantizar que éstos sean
alcanzables.
4.2.5.3  Monitorización del rendimiento del
servicio con respecto a los SLA
No deberá incluirse ningún elemento en un SLA a menos
que este pueda ser supervisado o monitorizado y medido
de forma eficaz. La importancia de este aspecto no puede
dejarse de recalcar ya que la inclusión de elementos que
no se pueden monitorizar de forma eficaz casi siempre
genera disputas y pérdida eventual de confianza en el
proceso de SLM. Muchas organizaciones lo han sufrido
en sus carnes, y como resultado de ello han tenido que
asumir grandes costes en el aspecto financiero, y en
términos de impactos negativos en su credibilidad.
Anécdota
Un proveedor de red global acordó objetivos de
disponibilidad para la provisión de un servicio de
red gestionado. Estos objetivos de disponibilidad se
acordaron en el punto en el que el servicio accedía a
las instalaciones del cliente. Sin embargo, el proveedor
de red global sólo podía monitorizar y medir la
disponibilidad en el punto en la que la conexión
abandonaba sus instalaciones. Los enlaces de red eran
suministrados por diferentes proveedores nacionales
de servicios de telecomunicaciones, con un amplio
rango de niveles de disponibilidad. El resultado fue
una absoluta incompatibilidad entre las cifras de
disponibilidad generadas por el proveedor de red y
el cliente, con el correspondiente debate y análisis
acalorado y prolongado.
824_005 Chapter 04.indd 75
Procesos de Diseñ̃o del Servicio | 75
Deberán revisarse y actualizarse las capacidades de
monitorización existentes cuando sea necesario.
Idealmente, esto deberá ir por delante de, o en paralelo
con, la elaboración de los SLAs, para que la monitorización
pueda establecerse para ayudar a la validación de los
objetivos propuestos.
Es esencial que los resultados de la monitorización o
supervisión se correspondan con la percepción real del
cliente del servicio. Desafortunadamente, en muchas
ocasiones esto es muy difícil de lograr. Por ejemplo, la
monitorización de componentes individuales, como por
ejemplo la red o servidor, no garantiza que el servicio
esté disponible para el cliente. En muchas ocasiones la
percepción del cliente es que, aunque un fallo pudiera
afectar a más de un servicio, lo que les molesta es no
poder acceder al servicio en el momento de la incidencia
informada, aunque esto no siempre es verdad, por lo
que será necesario tomar las debidas precauciones. No
se podrá obtener una imagen real si no se monitorizan
todos los componentes en el servicio extremo a extremo
(lo que podría ser muy difícil y costoso de lograr). De
forma similar, los usuarios deberán ser conscientes de
que deberán informar de las incidencias inmediatamente
y ayudar en el diagnóstico especialmente si están
relacionadas con el rendimiento, para que el proveedor de
servicio sea consciente de que se están incumpliendo los
objetivos.
Un número considerable de organizaciones usan su Centro
de Servicio al Usuario vinculado a un CMS integral para
monitorizar la percepción de disponibilidad del cliente.
Esto podría implicar realizar cambios específicos en las
pantallas de registro de incidencias/problemas y podría
requerir el cumplimiento estricto de los procedimientos
de registro de incidencias. Todo esto requiere análisis y el
acuerdo con el proceso de Gestión de la Disponibilidad.
El Centro de Servicio al Usuario también se utiliza para
monitorizar tiempos de respuesta y de resolución de
incidencias, pero una vez más, la pantalla de registro
podría necesitar modificaciones para adaptarse a
la captura de datos, y podría ser necesario que los
procedimientos de registro de llamadas fueran más
rigurosos y seguirse más estrictamente. Si un tercero
estuviera proporcionando soporte, esta monitorización
también podría dar apoyo a Gestión de Suministradores.
Es fundamental asegurar que los objetivos de gestión
de incidencias/problemas incluidos en los SLA, sean los
mismos que los que se incluyen en las herramientas del
Centro de Servicio al Usuario y se utilizan para el escalado
y monitorización. Las organizaciones que han fallado al
identificar lo anterior, y que probablemente han usado
22/1/10 13:49:31
 76 | Procesos de Diseñ̃o del Servicio
las opciones proporcionadas por el suministrador de
la herramienta, han terminado en una situación en la
que monitorizan algo diferente a lo que se ha acordado
en los SLA y, por lo tanto, son incapaces de decir si se
han cumplido los objetivos de los SLA sin un esfuerzo
considerable a la hora de manejar los datos. Podrían ser
necesarias algunas modificaciones en las herramientas de
soporte para incluir todos los campos necesarios para que
se puedan capturar los datos relevantes.
Otro área notablemente difícil de monitorizar son los
tiempos de respuesta de una transacción (el tiempo entre
el envío de una pantalla y la recepción de una respuesta).
En muchas ocasiones los tiempos de respuesta extremo a
extremo son muy difíciles de monitorizar técnicamente. En
tales casos, podría ser apropiado abordar la situación de la
siguiente forma:
■■ Incluir una declaración en el SLA junto con las
siguientes líneas: ‘Los servicios cubiertos por el SLA
se diseñan para ofrecer una respuesta rápida y no
deberían encontrarse retardos significativos. Si se
experimentara un retardo en el tiempo de respuesta
superior a ‘x’ segundos durante más de ‘y’ minutos,
deberá informarse de este hecho inmediatamente al
Centro de Servicio al Usuario’.
■■ Acordar e incluir en el SLA un objetivo aceptable para
que tales incidencias se puedan tolerar en el periodo
de información.
■■ Crear una categoría de incidencias de ‘respuesta
deficiente’ (o similar) y asegurar que cualquiera de
tales incidencias se registre con precisión y que se
asocie con el servicio adecuado.
■■ Generar informes regulares de las ocasiones en las
que se hayan incumplido los objetivos del tiempo
de respuesta de transacción del SLA, y promover
investigaciones a través de Gestión de Problemas para
corregir la situación.
Este método no sólo supera las dificultades técnicas
de monitorización, sino que también garantiza que se
informe de las incidencias de respuestas deficientes
en el momento en el que se produzcan. Esto es muy
importante, ya que una respuesta deficiente, normalmente
está causada por varios eventos transitorios que
interactúan y que sólo pueden detectarse si se investigan
inmediatamente.
Sin embargo, el método preferido consiste en
implementar alguna forma de monitorización
automatizada del tiempo de respuesta de cliente/servidor
en estrecha consulta con la Operación del Servicio.
Siempre que sea posible, implemente herramientas y
técnicas de muestreo o ‘robot’ para dar indicaciones de
824_005 Chapter 04.indd 76
bajo o pobre rendimiento. Estas herramientas ofrecen
la capacidad de medir o tomar muestras de tiempos
de respuesta reales o muy similares que están siendo
experimentados por una gran variedad de usuarios, y cada
vez están más disponibles y son más rentables.
Sugerencias y consejos
Algunas organizaciones se han encontrado que, en
realidad, una ‘respuesta deficiente’ es algunas veces
un problema de percepción del usuario. El usuario,
después de experimentar un nivel particular de
respuesta durante un periodo de tiempo, empieza a
expresar su disconformidad cuando ese tiempo de
respuesta empieza a ampliarse. Tenga en cuenta que
‘si el usuario piensa que el servicio es lento, entonces
lo es’.
Si el SLA incluyera objetivos para evaluar e implementar
Peticiones de Cambio (RFCs), la monitorización de
objetivos asociados con Gestión de Cambios deberá
realizarse idealmente usando cualquier herramienta de
Gestión de Cambios que esté en uso (preferiblemente
parte de una herramienta de soporte integrada de Gestión
del Servicio), y las pantallas de registro de cambios y los
procesos de escalado deberán darle soporte.
4.2.5.4  Cotejar, medir y mejorar la satisfacción
del cliente
Existe un gran número de aspectos ‘menos conflictivos’
que no se pueden monitorizar mediante medios
mecánicos o procedimentales, como por ejemplo las
sensaciones generales de los clientes (tales sensaciones
no tienen por qué coincidir con la monitorización ‘en
frío’). Por ejemplo, incluso cuando se hubieran producido
varios fallos del servicio de los que se haya informado,
los clientes todavía podrían tener una visión positiva con
respecto a algunos aspectos, ya que se podrían sentir
satisfechos por las acciones que se están tomando para
mejorar las cosas. Está claro que se podría dar el caso
contrario, y los clientes podrían sentirse insatisfechos con
algunos aspectos (p. ej., el talante de cierto personal en el
Centro de Servicio al Usuario) cuando se hayan incumplido
sólo algunos o ninguno de los objetivos del SLA.
Desde el principio, es aconsejable examinar y gestionar
las expectativas de los clientes. Esto implica determinar
en primer lugar las expectativas y objetivos apropiados,
y establecer un proceso sistemático para gestionar
las expectativas que se generen en adelante, ya que
satisfacción = percepción – expectativa (donde una
cifra de cero o positiva indica un cliente satisfecho).
22/1/10 13:49:31

Los SLA son sólo documentos, y en sí mismos no
alteran materialmente la calidad del servicio que se está
suministrando (aunque podrían afectar al comportamiento
y ayudar a concebir una cultura del servicio apropiada,
lo que puede tener un efecto beneficioso inmediato, y
lograr las mejoras posibles a largo plazo). Por lo tanto, se
necesita un grado de paciencia y deberá encajarse con las
expectativas.
Las exigencias del cliente cambiarían cuando se facturen
los servicios suministrados. (Los clientes pueden tener
cualquier cosa que pueda justificarse en costes, siempre
que se encuentre dentro de la estrategia corporativa
acordada, y tenga un presupuesto autorizado, pero no
más). Si no se hicieran cambios directos, deberá solicitarse
la ayuda de los gestores de negocio para asegurar que
grupos individuales no establezcan exigencias excesivas o
poco realistas para el proveedor de TI.
Por lo tanto, se recomienda que se hagan intentos para
monitorizar la percepción del cliente con respecto a estos
aspectos menos conflictivos. Los métodos para hacer esto
incluyen:
■■ Cuestionarios periódicos y encuestas del cliente
■■ Retroalimentación del cliente a partir de reuniones de
revisión del servicio
■■ Retroalimentación procedente de Revisiones Post
Implementación (PIR) realizada dentro del proceso
de Gestión de Cambios con respecto a cambios
importantes, versiones, servicios nuevos o modificados,
etc.
■■ Encuestas telefónicas de percepción (quizás de forma
aleatoria en el Centro de Servicio al Usuario, o con
representantes regulares vinculados con los clientes)
■■ Folletos de encuestas de satisfacción (proporcionados
a los clientes después de las instalaciones, visitas de
mantenimiento, etc.)
■■ Reuniones de foros y grupos de usuarios
■■ Análisis de las conformidades y no conformidades.
Si fuera posible, deberán establecerse objetivos para estos
métodos y monitorizarlos como parte del SLA (p. ej., el
proveedor de servicio deberá obtener una puntuación
promedio de 3,5 en los resultados dados, basada en un
sistema de puntuación de 1 a 5 donde 1 corresponde
a un rendimiento deficiente y 5 a un rendimiento
excelente). Garantice que si los usuarios proporcionan
retroalimentación recibirán algo a cambio, y demuéstreles
que sus comentarios se han incorporado a un plan de
acción, quizás un SIP. Deberán revisarse todas las medidas
de satisfacción del cliente, y cuando se identifiquen las
variaciones, éstas deberán analizarse y se llevarán a cabo
las acciones oportunas para rectificar la variación.
824_005 Chapter 04.indd 77
Procesos de Diseñ̃o del Servicio | 77
4.2.5.5  Revisar y volver a examinar los acuerdos
de apoyo y el ámbito del servicio
Los proveedores de servicios de TI dependen de alguna
forma de sus equipos internos de soporte técnico o de
socios o proveedores externos. No pueden acometer el
cumplimiento de los objetivos del SLA a menos que los
rendimientos de sus propios equipos y proveedores de
soporte den apoyo a estos objetivos. Los contratos con
los proveedores externos son obligatorios, pero muchas
organizaciones también han identificado los beneficios de
tener acuerdos simples con grupos de soporte internos,
a los que normalmente se les denomina como OLAs.
‘Acuerdos de apoyo’ es un término que hace referencia a
todos los OLAs, SLAs y contratos de apoyo.
En muchas ocasiones a estos acuerdos se les hace
referencia como acuerdos de respaldo mutuo. Reflejan la
necesidad de garantizar que todos los objetivos incluidos
en acuerdos de apoyo o de respaldo mutuo se alineen
con, y den soporte a, los objetivos acordados con el
negocio en SLAs y OLAs. Podrían existir múltiples capas
de acuerdos de apoyo o de respaldo mutuo con objetivos
alineados. Es fundamental que los objetivos de cada capa
se alineen con, y den soporte a, los objetivos contenidos
dentro de los niveles más altos (es decir, aquellos que
están más cercanos a los objetivos del negocio).
Los OLAs no necesitan ser muy complicados, pero deben
establecer objetivos específicos de respaldo mutuo para
grupos de soporte que den apoyo a los objetivos incluidos
en SLAs. Por ejemplo, si el SLA incluyera objetivos de
tiempo de respuesta total y de resolución de incidencias
(en función de los niveles de prioridad), entonces los OLAs
deberán incluir objetivos para cada uno de los elementos
de la cadena de soporte. Sin embargo, debe entenderse
que los objetivos de resolución de incidencias incluidos
en los SLA normalmente no deberán corresponderse con
los mismos objetivos incluidos en contratos u OLAs con
los proveedores. Esto se debe a que los objetivos del SLA
deben incluir un elemento para todas las etapas del ciclo
de soporte (p. ej., tiempo de detección, tiempo de registro
del Centro de Servicio al Usuario, tiempo de escalado,
tiempo de referencia entre grupos, etc., revisión del Centro
de Servicio al Usuario y tiempo de cierre, además del
tiempo real para solucionar el fallo).
El objetivo del SLA deberá cubrir el tiempo dedicado
para responder llamadas, escalar incidencias al personal
de soporte técnico, y el tiempo transcurrido para iniciar
la investigación y para resolver las incidencias que se les
asignen. Además, deberán estipularse las horas de soporte
totales para todos los grupos que den apoyo a los tiempos
requeridos de disponibilidad del servicio en el SLA. Si
22/1/10 13:49:31
 78 | Procesos de Diseñ̃o del Servicio
existieran procedimientos especiales para el personal con
el que se contacte (p. ej., soporte telefónico fuera del
horario habitual), éstos también deberán documentarse.
Los OLAs deberán monitorizarse con respecto a los
objetivos de los OLAs y SLAs, y con respecto a informes
sobre logros facilitados como retroalimentación a los
gestores o responsables apropiados de cada equipo de
soporte. Esto indica las posibles áreas problemáticas que
podría ser necesario abordar internamente o mediante
una revisión posterior del SLA u OLA. Debe prestarse
una consideración importante a la presentación formal
de OLAs a todos los equipos internos de soporte, que
contribuyen al soporte de servicios operativos.
Antes de comprometerse con SLAs nuevos o revisados, es
importante que se investiguen los acuerdos contractuales
existentes y, cuando sea necesario, se actualicen. Es
probable que se incurra en costes adicionales, que debería
absorber TI o derivarse al cliente. En el segundo caso,
el cliente debe estar de acuerdo con esto, o se deberá
acordar la inclusión en los SLAs de los objetivos menos
exigentes de contratos existentes. Es necesario completar
esta actividad en estrecha colaboración con el proceso
de Gestión de Suministradores para asegurar que no se
cumplan sólo los requisitos de SLM, sino también que
se consideren todos los demás requisitos del proceso,
particularmente las políticas y estándares contractuales y
de los proveedores.
4.2.5.6  Generar informes del servicio
Inmediatamente después de que se acuerde y acepte
el SLA, deberá impulsarse la monitorización, y deberán
generarse informes sobre los logros del servicio.
Deberán generarse informes operativos con regularidad
(semanalmente, o incluso con más frecuencia) y, si fuera
posible, deberán generarse informes de excepciones
siempre que se haya incumplido un SLA (o haya amenaza
de ello, si se hubieran establecido umbrales apropiados
para poder obtener una ‘advertencia anticipada’). Algunas
veces las dificultades se encuentran a la hora de cumplir
los objetivos de nuevos servicios durante el periodo de
soporte post implantación debido a un gran volumen de
RFCs. Si se limita el número de RFCs procesadas durante el
periodo de soporte post implantación se podrá limitar el
impacto de los cambios.
Los mecanismos de informes, intervalos y formatos de
informes del SLA deberán definirse y acordarse con los
clientes. También deberán acordarse con los clientes
la frecuencia y formato de las Reuniones de Revisión
del Servicio. Se recomiendan intervalos regulares, con
informes periódicos sincronizados con el ciclo de revisión.
824_005 Chapter 04.indd 78
Deberán generarse informes periódicos y suministrárselos
a los clientes (o a sus representantes) y a los gestores de TI
apropiados con algunos días de antelación con respecto a
las revisiones del nivel de servicio, para que de esta forma
se pueda resolver cualquier cuestión o desacuerdo antes
de la reunión de revisión. Por lo tanto, la reunión no se
desviará dedicándole tiempo a tales asuntos.
Los informes periódicos deben incorporar detalles del
rendimiento con respecto a los objetivos del SLA, junto
con detalles de cualquier tendencia o acción específica
que se esté tomando para mejorar la calidad del servicio.
Una técnica útil es incluir un gráfico de Monitorización del
SLA (SLAM) en la cabecera del informe de un servicio para
ofrecer una descripción rápida general de cómo se han
medido los logros con respecto a los objetivos. Éstos son
más eficaces si se codifican en colores (rojo, ámbar, verde,
y algunas veces se les denominan gráficos RAG). Además,
el gestor de TI también podría requerir otros informes
temporales para OLAs o revisiones internas de rendimiento
y/o gestión de contratos o proveedores. Es probable que
este sea un proceso evolutivo, un primer esfuerzo que no
es probable que sea el resultado final.
No se deberían subestimar los recursos que se requieren
para generar y verificar los informes. Puede consumir
mucho tiempo, y si los informes no reflejaran de forma
precisa la propia percepción del cliente de la calidad
del servicio, podrían generar una situación peor. Es
fundamental que se analice información precisa de todas
las áreas y procesos (p. ej., Gestión de Incidencias, Gestión
de Problemas, Gestión de la Disponibilidad, Gestión de
Capacidad, Gestión del Cambio y de la Configuración) y
que se compare en un informe integral y conciso sobre
el rendimiento del servicio, y se mida con respecto a
objetivos de negocio acordados.
SLM deberá identificar las necesidades específicas de
información, y deberá automatizar la producción de
estos informes lo máximo posible. La amplitud, precisión
y facilidad de estos informes automatizados se puede
lograr si formaran parte de los criterios de selección de
las herramientas de soporte integradas. Estos informes
del servicio no deben incluir únicamente detalles del
rendimiento actual con respecto a los objetivos, también
deberán proporcionar información histórica sobre las
tendencias y rendimientos pasados, para que el impacto
de las acciones de mejora puedan medirse y predecirse.
4.2.5.7  Realizar revisiones del servicio y
estimular mejoras dentro del SIP general
Deberán mantenerse reuniones periódicas de revisión
con los clientes (o con sus representantes) para revisar
22/1/10 13:49:31

los logros del servicio en el último periodo y abordar
previamente cualquier aspecto correspondiente al
próximo periodo. Es habitual mantener tales reuniones
mensualmente o como mínimo trimestralmente.
Las acciones deberán aplicarse al cliente y proveedor
como sea apropiado para mejorar áreas débiles donde
los objetivos no se van a cumplir. Deberá levantarse
acta de todas las acciones, y deberá revisarse el
progreso en la siguiente reunión para garantizar que se
sigan los elementos de las acciones y se implementen
adecuadamente.
Deberá prestarse una atención particular en cada
incumplimiento del nivel del servicio para determinar
exactamente qué provocó la pérdida de servicio y qué
se puede hacer para evitar cualquier recurrencia. Si se
decidiera que el nivel de servicio era o se ha convertido en
algo inalcanzable, podría ser necesario revisar o renegociar
el acuerdo de los diferentes objetivos del servicio. Si la
interrupción del servicio estuviera provocada por el fallo
de un tercero o de un grupo de soporte interno, también
podría ser necesario revisar el acuerdo de soporte u OLA. El
análisis del coste y del impacto de los incumplimientos del
servicio proporcionan una entrada valiosa y una justificación
de las acciones y actividades del SIP. Es necesario que la
constante necesidad de mejora se equilibre y se centre en
aquellas áreas que tienen más probabilidades de ofrecer el
máximo beneficio para el negocio.
También deberán generarse informes sobre el progreso y
éxito del SIP, como por ejemplo el número de acciones
del SIP que se completaron y el número de acciones que
entregaron su beneficio esperado.
Sugerencias y consejos
‘Un espía en ambos campos’ – Los Gestores de
Nivel de Servicio pueden verse con un cierto nivel
de sospecha tanto por el personal del Proveedor de
Servicios de TI como por los representantes del cliente.
Esto se debe a la doble naturaleza de su función,
donde están actuando como representantes no
oficiales del cliente cuando hablan con el personal de
TI, y como representantes del proveedor de TI cuando
hablan con los clientes. Esto se agrava normalmente
al tener que representar el punto de vista de la
‘oposición’ en cualquier reunión, etc. Para evitar esto,
el Gestor de Nivel de Servicio deberá tener la actitud
más abierta y útil posible (dentro de los límites de
cualquier propiedad comercial) cuando trate con
ambos lados, teniendo en cuenta que nunca se debe
criticar abiertamente a los colegas.
824_005 Chapter 04.indd 79
Procesos de Diseñ̃o del Servicio | 79
4.2.5.8  Revisar y volver a analizar SLAs, el
ámbito del servicio y los acuerdos de apoyo
Todos los acuerdos y contratos de soporte, incluyendo
SLAs, UC’s y OLAS, deberán mantenerse actualizados.
Deberán estar bajo el control de Gestión de Cambios
y de la Configuración y revisarse periódicamente, al
menos anualmente, para garantizar que todavía están
actualizados y son integrales, y que todavía están
alineados con las necesidades del negocio y con la
estrategia.
Estas revisiones deberán garantizar que se cubren los
servicios y que los objetivos de cada uno de ellos todavía
son pertinentes, y que no ha cambiado nada significativo
que invalide el acuerdo de algún modo (esto deberá
incluir cambios en la infraestructura, cambios en el
negocio, cambios en el proveedor, etc.). Si se hicieran
cambios, los acuerdos deberán actualizarse bajo el control
de Gestión de Cambios para reflejar la nueva situación. Si
todos los contratos se registran como CIs dentro del CMS,
es más fácil analizar el impacto e implementar los cambios
de forma controlada.
Estas revisiones también deben incluir los documentos
de la estrategia general para garantizar que todos los
servicios y acuerdos de servicio se mantengan en línea
con el negocio y con las estrategias y políticas de TI.
4.2.5.9  Desarrollo de contactos y relaciones
Es muy importante que SLM desarrolle confianza y
respeto con respecto al negocio, especialmente con los
contratos de negocio clave. El Catálogo de Servicios,
especialmente el Catálogo de Servicios de Negocio,
permite a SLM ser mucho más proactivo. El Catálogo de
Servicios proporciona la información que permite a SLM
entender las relaciones entre los servicios y las unidades
de negocio y proceso de negocio que dependen de esos
servicios. También proporciona la información de todos
los contactos clave de TI y del negocio en relación con
los servicios, su uso y su importancia. Para garantizar que
esto se haga de forma consistente, SLM deberá realizar las
siguientes actividades:
■■ Confirmar a los interesados, clientes y gestores del
negocio clave, y usuarios del servicio.
■■ Ayudar a mantener información precisa dentro del
Portfolio de Servicios y del Catálogo de Servicios.
■■ Ser flexible y responsable con respecto a las
necesidades del negocio, clientes y usuarios, y
entender procesos de negocio nuevos actuales y
planificados y sus requisitos para servicios nuevos y
modificados, documentar y comunicar estos requisitos
para todos los demás procesos además de facilitar e
22/1/10 13:49:31
 80 | Procesos de Diseñ̃o del Servicio
innovar el cambio siempre que suponga un beneficio
para el negocio.
■■ Desarrollar un completo entendimiento de las
estrategias y planes de negocio, clientes y usuarios,
necesidades del negocio y objetivos, garantizando
que TI trabaje en asociación con el negocio, clientes y
usuarios, desarrollando relaciones a largo plazo.
■■ Participar regularmente en el recorrido del cliente
y tomar muestras de la experiencia del mismo,
proporcionando retroalimentación sobre los problemas
del cliente con respecto a TI. (Esto se aplica a clientes
de TI y también a clientes externos del negocio con el
uso que realizan de servicios de TI).
■■ Garantizar que se apliquen los procesos de relación
correctos para lograr objetivos y que estén sujetos a
mejora continua.
■■ Dirigir y completar encuestas del cliente, ayudar con el
análisis de las encuestas completadas y garantizar que
se tomen acciones sobre la base de los resultados.
■■ Actuar como un representante de TI a la hora de
organizar y atender a grupos de usuarios.
■■ Comercializar y difundir proactivamente el Portfolio
de Servicios y el Catálogo de Servicios y el uso de los
servicios dentro de todas las áreas del negocio.
■■ Trabajar con el negocio, clientes y usuarios para
garantizar que TI proporciona los niveles de servicio
más adecuados para cumplir las necesidades del
negocio actuales y futuras.
■■ Promocionar la concienciación y el entendimiento del
servicio.
■■ Plantear la concienciación de los beneficios del
negocio que se obtendrán de la explotación de
nuevas tecnologías.
■■ Facilitar el desarrollo y negociación de SLRs y SLAs
adecuados, alcanzables y realistas entre el negocio y
TI.
■■ Garantizar que el negocio, clientes y usuarios
entiendan sus responsabilidades/compromisos con TI
(es decir, dependencias de TI).
■■ Ayudar con el mantenimiento de un registro de todas
las mejoras pendientes.
4.2.5.10  Conformidades y no conformidades
El proceso SLM también debe incluir actividades y
procedimientos para el registro y gestión de todas
las conformidades y no conformidades. Normalmente
el Centro de Servicio al Usuario lleva a cabo los
procedimientos de registro y son similares a aquellos
de Gestión de Incidencias y de Gestión de Peticiones.
La definición de una conformidad o no conformidad
debe acordarse con los clientes, junto con los puntos de
824_005 Chapter 04.indd 80
contacto acordados y los procedimientos para su gestión
y análisis. Todas las conformidades y no conformidades
deberán registrarse y comunicarse a las partes pertinentes.
Todas las no conformidades también deberán activarse y
resolverse para la satisfacción de los que las originen. Si no
fuera así, habría un contacto y procedimiento de escalado
para todas las no conformidades que no se accionen y
resuelvan dentro de una escala de tiempos adecuada.
Todas las no conformidades pendientes deberán revisarse
y escalarse hasta la dirección senior siempre que sea
adecuado. Deberán generarse informes con respecto a
las cifras y tipos de no conformidades, las tendencias
identificadas y las acciones tomadas para reducir las cifras
recibidas. También deben generarse informes similares
para las conformidades.
4.2.6  Disparadores, entradas, salidas e
interfaces
Existen muchos disparadores que implican la actividad de
SLM. Éstos incluyen:
■■ Cambios en el Portfolio de Servicios como por
ejemplo requisitos de negocio nuevos o modificados o
servicios nuevos o modificados
■■ Acuerdos, SLRs, SLAs, OLAs o contratos nuevos o
modificados
■■ Acciones y reuniones de revisión del servicio
■■ Roturas del servicio o amenazas de roturas
■■ Conformidades y no conformidades
■■ Actividades periódicas como por ejemplo revisión,
generación de informes y encuestas de satisfacción del
cliente
■■ Cambios en la estrategia o política.
4.2.6.1  Entradas del proceso de SLM
Existen varias fuentes de información que son relevantes
para el proceso de Gestión del Nivel de Servicio. Éstas
incluyen:
■■ Información del negocio: desde la estrategia, planes,
planes financieros e información del negocio de la
organización o sus requisitos actuales y futuros
■■ Análisis de Impacto del Negocio: proporcionando
información sobre el impacto, prioridad, riesgo y
número de usuarios asociados con cada servicio
■■ Requisitos de negocio: detalles de cualquier requisito
de negocio acordado, nuevo o modificado
■■ Las estrategias, políticas y restricciones de Estrategia
del Servicio
■■ El Portfolio de Servicios y Catálogo de Servicios
22/1/10 13:49:31

■■ Información del cambio: desde el proceso Gestión de
Cambios con una lista de cambios planificados y la
necesidad de analizar todos los cambios con respecto
a su impacto en todos los servicios
■■ CMS: que contiene información sobre las relaciones
entre los servicios de negocio, los servicios de soporte
y la tecnología
■■ Retroalimentación, conformidades y no conformidades
de clientes y usuarios
■■ Otras entradas: incluyendo asesoramiento, información
y entrada de cualquiera de los demás procesos (p.
ej., Gestión de Incidencias, Gestión de la Capacidad y
Gestión de la Disponibilidad), junto con los SLA, SLR y
OLA existentes e informes anteriores del servicio con
respecto a la calidad del servicio entregado.
4.2.6.2  Salidas del proceso de SLM
Las salidas de Gestión del Nivel de Servicio deben incluir:
■■ Informes del servicio: que proporcionan detalles de
los niveles de servicio alcanzados en relación con los
objetivos contenidos en los SLA. Estos informes deben
contener detalles de todos los aspectos del servicio
y su entrega, incluyendo el rendimiento actual e
histórico, rupturas y debilidades, eventos importantes,
cambios planificados, cargas de trabajo actuales y
planificadas, retroalimentación del cliente, y planes y
actividades de mejora
■■ Programa de Mejora de Servicio (SIP): Un programa o
plan general de acciones priorizadas de mejora que
abarquen todos los servicios y procesos, junto con los
impactos y riesgos asociados
■■ El Plan de Calidad del Servicio: que documente y
planifique la mejora general de la calidad del servicio
■■ Plantillas de documentación: plantillas, formato y
contenido de documentación estándar para SLAs, SLRs
y OLAs, alineados con los estándares corporativos
■■ Acuerdos de Nivel de Servicio (SLA): un conjunto
de objetivos y responsabilidades que deberán
documentarse y acordarse en un SLA para cada
servicio operativo
■■ Requisitos de Nivel de Servicio (SLRs): un conjunto
de objetivos y responsabilidades que deberán
documentarse y acordarse en un SLR para cada
servicio, nuevo o modificado, propuesto
■■ Acuerdos de Nivel Operativo (OLAs): un conjunto
de objetivos y responsabilidades que deberán
documentarse y acordarse en un OLA para cada
equipo de soporte interno
■■ Informes sobre OLAs y contratos de soporte
824_005 Chapter 04.indd 81
Procesos de Diseñ̃o del Servicio | 81
■■ Acciones y agendas de las reuniones de revisión del
servicio: todas las reuniones deberán programarse de
forma regular con agendas planificadas, registrando y
haciendo un seguimiento de sus análisis y acciones
■■ Agendas de reuniones de revisión del ámbito del
servicio y de revisión de los SLA: que resuman las
acciones y revisiones acordadas con respecto a SLAs y
al ámbito del servicio
■■ Contratos revisados: puede que los cambios en SLAs y
los nuevos SLR requieran la modificación de contratos
de soporte existentes, o que se negocien o acuerden
nuevos contratos.
4.2.7 Indicadores Clave de Rendimiento
Los Indicadores Clave de Rendimiento (KPIs) y las métricas
se pueden utilizar para determinar la eficiencia y eficacia
de las actividades de SLM y el progreso del SIP. Estas
métricas deberán desarrollarse a partir de la perspectiva
del servicio, cliente y negocio y deberán cubrir medidas
objetivas y subjetivas como las siguientes.
Objetivas:
■■ Número o porcentaje de objetivos del servicio que se
están cumpliendo
■■ Número y severidad de las rupturas del servicio
■■ Número de servicios con SLAs actualizados
■■ Número de servicios con informes y revisiones
puntuales del servicio activo.
Subjetivas:
■■ Mejoras de la satisfacción del cliente.
Se puede encontrar más información sobre los KPIs,
medidas y mejoras en la siguiente sección y en la
publicación Mejora Continua del Servicio.
Sugerencias y consejos
No caiga en la trampa de utilizar porcentajes como
única métrica. Es fácil quedarse atrapado cuando
existe un pequeño sistema con puntos de medición
limitados (es decir, un único fallo en una población
de 100 representa sólo el 1%; un único fallo en una
población de 50 representa el 2% – si el objetivo
fuera del 98,5%, entonces el SLA ya se ha incumplido).
Analice siempre el número de incidencias más que el
porcentaje en poblaciones menores de 100, y tenga
cuidado al aceptar los objetivos. Esto es algo que las
organizaciones han aprendido a base de cometer
errores.
22/1/10 13:49:31
 82 | Procesos de Diseñ̃o del Servicio
El proceso de SLM a menudo genera un buen punto de
inicio para un SIP, y puede que el proceso de revisión
del servicio lo impulse, pero todos los procesos y áreas
de la organización del proveedor de servicio deben estar
implicados en el SIP.
Cuando se haya identificado una dificultad subyacente
que afecte de forma adversa a la calidad del servicio,
SLM deberá, junto con Gestión de Problemas y Gestión
de la Disponibilidad, promover un SIP para identificar
e implementar cualquier acción necesaria que permita
superar las dificultades y restaurar la calidad de servicio.
Las iniciativas del SIP pueden centrarse también en
actividades como la formación del usuario, prueba del
sistema y del servicio, y documentación. En estos casos,
es necesario que se involucren las personas pertinentes
y se proporcione la retroalimentación adecuada para
realizar mejoras para el futuro. En todo momento pueden
desarrollarse en paralelo varias iniciativas separadas que
pertenezcan al SIP para abordar las dificultades con
diversos servicios.
Algunas organizaciones han establecido un presupuesto
anual por anticipado a SLM para financiar las iniciativas
SIP. Esto quiere decir que esa acción puede emprenderse
rápidamente y que SLM es manifiestamente eficaz. Esta
práctica debería ser fomentada y ampliada para permitir
que SLM se vuelva cada vez más proactivo y predictivo.
Es necesario que el SIP tenga un propietario y esté
gestionado, y que todas las acciones de mejora se analicen
con respecto al riesgo e impacto en servicios, clientes y
negocio, y que a continuación se prioricen, programen e
implementen.
Si una organización está externalizando la Provisión
de su Servicio a un suministrador externo, el problema
de la mejora del servicio debe ser comentado desde el
principio y cubierto (y presupuestado) en el contrato, de
lo contrario, no existirá ningún incentivo durante la vida
útil del contrato para que el suministrador mejore los
objetivos del servicio durante la vida útil del contrato si ya
se cumplen las obligaciones contractuales y se requiere un
gasto adicional para realizar las mejoras.
4.2.7.1  KPIs
Gestionan la calidad general necesaria del servicio
de TI con respecto al número y nivel de servicios
proporcionados y gestionados:
■■ Porcentaje de reducción de los objetivos incumplidos
de los SLA
■■ Porcentaje de reducción de los objetivos amenazados
de los SLA
824_005 Chapter 04.indd 82
■■ Porcentaje de incremento de la percepción y
satisfacción del cliente de los logros del SLA, a través
de revisiones del servicio y de respuestas a la Encuesta
de Satisfacción del Cliente
■■ Porcentaje de reducción de incumplimientos del SLA
debido a contratos de soporte de terceros (contratos
de soporte)
■■ Porcentaje de reducción de incumplimientos del SLA
debido a Acuerdos de Nivel Operativo (OLAs) internos
Entregan del servicio como se acordó previamente con
unos costes asequibles:
■■ Número total y porcentaje de incremento de SLAs
totalmente documentados que se aplican
■■ Porcentaje de incremento de SLAs acordados con
respecto a servicios operativos que se están aplicando
■■ Porcentaje de reducción de los costes asociados con la
provisión del servicio
■■ Porcentaje de reducción del coste de monitorización y
generación de informes de SLAs
■■ Porcentaje de incremento de la velocidad y del
desarrollo y acuerdo de SLAs adecuados
■■ Frecuencia de las reuniones de revisión del servicio.
Gestionan la interfaz con el negocio:
■■ Incremento del porcentaje de servicios cubierto por
SLAs
■■ Procedimientos y procesos de SLM documentados y
acordados que se están aplicando
■■ Disminución del tiempo que se tarda en la respuesta e
implementación de las peticiones de los SLA
■■ Incremento del porcentaje de revisiones de SLAs
completadas a tiempo
■■ Reducción en el porcentaje de SLAs pendientes para la
renegociación anual
■■ Reducción en el porcentaje de SLAs que requieren
cambios correctivos (por ejemplo, objetivos no
alcanzables; cambios en los niveles de uso). Es
necesario tomar precauciones al utilizar este KPI
■■ Porcentaje de incremento de la cobertura de los OLA
y de contratos de terceros que se están aplicando,
a la vez que se reduce el número real de acuerdos
(consolidación y centralización)
■■ Evidencia documental de que los problemas surgidos
en revisiones del servicio y de los SLA se están
analizando y resolviendo
■■ Reducción del número y severidad de los
incumplimientos de los SLA
■■ Revisión eficaz y seguimiento de todos los
incumplimientos de los SLA, OLA y contratos de
soporte.
22/1/10 13:49:31
 Procesos de Diseñ̃o del Servicio | 83

4.2.8  Gestión de la Información Anécdota

SLM proporciona información clave sobre todos los
servicios operativos, sus objetivos esperados y los logros
del servicio y rupturas para todos los servicios operativos.
Ayuda a Gestión del Catálogo de Servicios con la
gestión del Catálogo de Servicios y también proporciona
información y tendencias sobre la satisfacción del cliente,
incluyendo conformidades y no conformidades.
SLM es crucial a la hora de proporcionar información
sobre la calidad del servicio de TI suministrado al cliente,
y para proporcionar información sobre la expectativa del
cliente y sobre la percepción de la calidad del servicio.
Esta información deberá estar ampliamente disponible
para todas las áreas de la organización del proveedor del
servicio.
4.2.9  Desafíos, Factores Críticos de Éxito y
riesgos
Un desafío al que se enfrenta SLM es la identificación
de los representantes adecuados del cliente con quienes
poder negociar. ¿Quién ‘posee’ el servicio? En algunos
casos, esto puede ser obvio, y es deseable que un
único responsable del cliente actúe como el autorizador
del acuerdo. En otros casos, podría ser bastante difícil
encontrar un representante ‘voluntario’ (hay que tener
cuidado ya que con frecuencia los voluntarios desean
expresar su propio punto de vista más que representar un
consenso general), o podría ser necesario conseguir que
todos los clientes firmen.
Sería ideal lograr representantes de clientes que sean
capaces de representar los verdaderos puntos de vista de
la comunidad de clientes ya que a menudo representan
una amplia selección de clientes. Desafortunadamente,
con demasiada frecuencia los representantes se
encuentran en las oficinas centrales y rara vez entran en
contacto con auténticos clientes del servicio. En el caso
peor, posiblemente SLM tenga que realizar su propio
programa de discusiones y reuniones con los clientes para
garantizar que se identifiquen los requisitos reales.
En la negociación de los horarios actuales y de soporte
para un amplio servicio, una organización se encontró
con una discrepancia en el tiempo requerido de uso
entre la Oficina Principal y los clientes de la oficina
local. La Oficina Principal (con una población de
usuarios limitada) quería horarios del servicio de 8.00
a 18.00, mientras que la oficina local (con al menos
20 veces la población de usuarios) determinó que
sería mejor empezar una hora antes y, como todas
las oficinas cerraban al público a las 16.00 como muy
tarde, no se requeriría un horario del servicio más tarde
de hora. Prevaleció el argumento ‘político’ de la Oficina
Central y por lo tanto se estableció el horario de 8.00
a 18.00. Cuando el servicio empezó a utilizarse (y por
lo tanto a monitorizarse o supervisarse), se encontraron
que habitualmente se solicitaba que la oficina local
cubriera una hora adicional por la mañana, y las
cifras de uso reales demostraron que no se accedía al
servicio más tarde de las 17.00, excepto en muy raras
ocasiones. El personal de TI culpó al Gestor de Nivel de
Servicio por tener que cubrir un turno nocturno, y el
representante del cliente le culpó por imputar costes
por un servicio que no se utilizó (es decir, costes de
personal y de actividad).
Sugerencias y consejos
Se tienen que tomar precauciones a la hora de abrir
por primera vez las conversaciones sobre los niveles
de servicio, ya que es probable que se exterioricen
‘problemas actuales’ (el fallo que se produjo ayer) o
quejas que vienen de largo (esa impresora antigua
que hemos estado intentando que se sustituya desde
hace mucho tiempo). Por muy importantes que
pudieran ser, no se les debe permitir que bloqueen el
establecimiento de requisitos a más largo plazo. Sin
embargo, hay que ser conscientes de que puede ser
necesario abordar estos problemas desde el principio
antes de ganar credibilidad con el transcurso del
tiempo.

Si no hubiera habido experiencia previa de SLM, entonces

es aconsejable empezar con un borrador de SLA . Deberá
tomarse una decisión sobre el servicio o clientes que se
utilizarán para el borrador. Es útil si el cliente seleccionado
estuviera motivado y deseara participar, quizás porque
están deseando ver mejoras en la calidad del servicio.
Los resultados de una encuesta inicial sobre percepción
del cliente podrían conducir a un borrador de SLA inicial
adecuado.

824_005 Chapter 04.indd 83 22/1/10 13:49:31

 84 | Procesos de Diseñ̃o del Servicio
Sugerencias y consejos
No escoja para el primer SLA un área en la que se
produzcan problemas importantes. Intente escoger un
área que probablemente muestre rápidamente algunos
beneficios y desarrolle el proceso de SLM. Nada como
el éxito acelera la aceptación de una nueva idea.
A veces se encuentran dificultades cuando el personal
de los diferentes niveles dentro de la comunidad de
clientes puede tener diferentes objetivos y percepciones.
Por ejemplo, puede que un responsable senior utilice
raramente un servicio y puede que esté más interesado
en aspectos como el valor obtenido por el dinero y el
resultado, mientras que un miembro júnior del personal
puede que utilice el servicio de forma diaria por lo
que puede estar más interesado en aspectos como
la capacidad de respuesta, usabilidad y fiabilidad. Es
importante identificar e incorporar en los SLA todos los
requisitos apropiados y relevantes del cliente, y a todos los
niveles.
Algunas organizaciones han formado grupos de interés
de diferentes niveles a partir de los cuales la comunidad
de clientes ayuda a garantizar que se hayan abordado
correctamente todos los aspectos. Esto hace que se
utilicen recursos adicionales auque merece la pena el
esfuerzo.
El otro grupo de personas al que se tiene que
consultar durante todo este proceso está formado por
representantes del lado del proveedor de servicios de
TI (ya sea un proveedor interno, externo o un socio). Es
necesario que acuerden objetivos realistas, alcanzables y
asequibles. Si no fuera así, serían necesarias negociaciones
posteriores hasta llegar a un compromiso aceptable para
todas las partes. También deben buscarse los puntos de
vista de los proveedores, y tendrán que tomarse en cuenta
las implicaciones contractuales durante las etapas de
negociación.
Si no estuvieran disponibles datos monitorizados en
el pasado, es aconsejable dejar el contrato en formato
de borrador durante un periodo inicial, hasta que la
monitorización pueda confirmar que los objetivos iniciales
son alcanzables. Puede que los objetivos se tengan que
renegociar en algunos casos. Muchas organizaciones
negocian y acuerdan la franja de tiempo en la que TI
negocia y crean una línea de referencia para establecer
objetivos de servicio realistas. Cuando se hayan
confirmado los objetivos y las franjas de tiempo, los SLA
deberán firmarse.
824_005 Chapter 04.indd 84
Una vez se haya completado el SLA inicial, y se supere
cualquier dificultad inicial, continúe e introduzca
gradualmente los SLAs para otros servicios/clientes. Si
se decidiera desde el principio desarrollar una estructura
multinivel, es probable que tengan que cubrirse aspectos
de nivel corporativo para todos los clientes en el
momento del SLA inicial. También merece la pena poner a
prueba aspectos corporativos durante la fase inicial.
Sugerencias y consejos
No vaya por objetivos fáciles a escala corporativa.
Puede que sean fáciles de lograr, pero que no tienen
valor a la hora de mejorar la calidad o credibilidad
del servicio. Además, si los objetivos se establecen a
un nivel suficientemente alto, el SLA corporativo se
puede utilizar como el estándar que todos los nuevos
servicios deberían alcanzar.
Un aspecto que se tendrá que garantizar es que al final
del proceso de elaboración y negociación, el SLA lo
firmen realmente los responsables correspondientes del
cliente y el proveedor de servicios de TI. Esto ofrece un
compromiso firmado por ambas partes de que se harán
todos los esfuerzos necesarios para cumplir el acuerdo.
Hablando de forma general, mientras más senior sean los
firmantes de sus respectivas organizaciones, más fuerte
será el mensaje de compromiso. Cuando se acuerde
un SLA, será necesario darle una amplia difusión para
garantizar que los clientes, usuarios y el personal de TI
sean conscientes de su existencia y de los objetivos clave.
Deben acometerse los pasos adecuados para anunciar
la existencia de los nuevos SLA y OLA entre el Centro
de Servicio al Usuario y otros grupos de soporte, con
detalles de cuándo pasarán a estar operativos. Podría ser
útil poner los objetivos clave de estos acuerdos en tablas
que se puedan visualizar en áreas de soporte para que el
personal siempre sea consciente de los objetivos sobre los
que están trabajando. Si las herramientas de soporte lo
permiten, estos objetivos deben registrarse dentro de las
herramientas, como por ejemplo dentro de un Catálogo
de Servicios o CMS, para que el contenido pueda ponerse
ampliamente a disposición de todo el personal. También
deben incluirse como umbrales, y deben producirse alertas
automáticas cuando un objetivo se vea amenazado o se
incumpla realmente. Los SLA, OLA y los objetivos que
están contenidos dentro, también deben difundirse entre
la comunidad de usuarios para que éstos sean conscientes
de lo que pueden esperar de los servicios que utilizan, y
saber en qué punto comenzar a expresar su insatisfacción.
22/1/10 13:49:31

Es importante que el personal del Centro de Servicio al
Usuario se comprometa con el proceso de SLM, y que
sean embajadores proactivos de los SLA, adoptando la
cultura de servicios necesaria, ya que representan el primer
punto de contacto para las incidencias, no conformidades
y peticiones de los clientes. Si el personal del Centro de
Servicio al Usuario no fuera totalmente consciente de
los SLA que se están aplicando, y no actuara según sus
contenidos, los clientes perderían muy rápidamente la
confianza en los SLA.
4.2.9.1  Factores Críticos de Éxito
Los Factores Críticos de Éxito del proceso de Gestión del
Catálogo de Servicios son:
■■ Gestionar la calidad general de los servicios de TI
requeridos
■■ Entregar el servicio como se acordó previamente con
unos costes asequibles
■■ Gestionar la interfaz con el negocio y usuarios.
Los riesgos asociados en relación con la provisión de un
Catálogo de Servicios preciso son:
■■ Una falta de entrada precisa, implicación y
compromiso del negocio y clientes
■■ Las herramientas y recursos requeridos para acordar,
documentar, monitorizar, generar informes y revisar
contratos y niveles de servicio
■■ El proceso se convierte en un proceso administrativo
burocrático más que en un proceso activo y proactivo
de entrega de beneficios medibles al negocio
■■ Acceso y soporte de CMS y SKMS actualizados y
apropiados
■■ Derivación del uso de los procesos de SLM
■■ Las mediciones del negocio y del cliente son
demasiado difíciles de medir y mejorar por lo que no
se registran
■■ Se desarrollan relaciones y contactos inapropiados del
negocio y del cliente
■■ Altas expectativas del cliente y baja percepción
■■ Se alcanza una comunicación deficiente e inapropiada
con el negocio y los clientes.
4.3  Gestión de la Capacidad
Gestión de la Capacidad es un proceso que se extiende
a través del Ciclo de Vida del Servicio. Un factor clave
del éxito es gestionar la capacidad para garantizar que
sea incluida durante la etapa de diseño. Por esta razón
el proceso de Gestión de la Capacidad se incluye en esta
publicación. Gestión de Capacidad se apoya inicialmente
en Estrategia del Servicio donde las decisiones y el análisis
824_005 Chapter 04.indd 85
Procesos de Diseñ̃o del Servicio | 85
de los requisitos del negocio y de los resultados del cliente
influyen en el desarrollo de los modelos de actividades
de negocio (PBA), niveles de servicio (LOS) y paquete del
nivel de servicio (SLP). Esto proporciona indicadores de
capacidad predictivos y continuos necesarios para alinear
la capacidad con la demanda.
4.3.1  Propósito/meta/objetivo
‘El objetivo del proceso de Gestión de la Capacidad es
garantizar que siempre exista capacidad de TI con costes
justificables en todas las áreas de TI y que corresponda con
las necesidades actuales y futuras acordadas del negocio’.
El propósito de Gestión de la Capacidad es proporcionar
un punto de enfoque y gestión para todos los aspectos
asociados con la capacidad y el rendimiento en relación
con los servicios y recursos.
Los objetivos de Gestión de Capacidad son:
■■ Generar y mantener un Plan de Capacidad actualizado
y adecuado que refleje las necesidades actuales y
futuras del negocio
■■ Proporcionar asesoramiento y directrices para todas
las demás áreas del negocio y de TI con respecto a
todos los aspectos relacionados con la capacidad y el
rendimiento
■■ Garantizar que los logros de rendimiento del
servicio cumplan o superen todos sus objetivos de
rendimiento acordados gestionando el rendimiento y
la capacidad de servicios y recursos
■■ Colaborar con el diagnóstico y resolución de
incidencias y problemas asociados con el rendimiento
y la capacidad
■■ Evaluar el impacto de todos los cambios en el Plan de
Capacidad, y el rendimiento y capacidad de todos los
servicios y recursos
■■ Asegurar que se implementen medidas proactivas para
mejorar el rendimiento de los servicios siempre que
tengan un coste justificable.
4.3.2 Ámbito
El proceso Gestión de la Capacidad deberá ser el punto
central para todos los aspectos relacionados con el
rendimiento y capacidad de TI. Funciones de gestión de
la tecnología como por ejemplo Soporte de Red, Soporte
de Servidores o Gestión de Operaciones podrían realizar
tareas operativas masivas o diarias, aunque proporcionarán
información del rendimiento del proceso Gestión de la
Capacidad. El proceso deberá abarcar todas las áreas
de la tecnología, tanto el hardware como el software,
para todos los componentes y entornos tecnológicos de
TI. Gestión de la Capacidad también deberá considerar
22/1/10 13:49:31
 86 | Procesos de Diseñ̃o del Servicio
la capacidad de la planificación del espacio y de los
sistemas de acondicionamiento además de ciertos
aspectos asociados con los recursos humanos, pero sólo
si una falta de recursos humanos pudiera generar un
incumplimiento de objetivos de SLAs u OLAs, un retraso
en el rendimiento extremo a extremo o en el tiempo de
respuesta del servicio, o una imposibilidad para cumplir
los compromisos y planes futuros (p. ej., la planificación
de backups de datos no se completó en el tiempo porque
no había operadores para cargar las cintas).
En general, la gestión de recursos humanos es una
responsabilidad de gestión de línea, aunque el personal
de un Centro de Servicio al Usuario deberá utilizar
técnicas idénticas de Gestión de Capacidad. Por lo tanto,
la programación de los recursos humanos, niveles de
personal, niveles de habilidades y niveles de capacidad
deberá incluirse dentro de Gestión de Capacidad. La
fuerza impulsora de Gestión de Capacidad deberá ser los
requisitos de negocio de la organización y la planificación
de los recursos necesarios para proporcionar niveles de
servicio en línea con SLAs y OLAs. Gestión de la Capacidad
necesita entender todos los entornos de negocio y TI,
incluyendo:
■■ La operación actual del negocio y sus requisitos a
través de los modelos de actividad del negocio
■■ Los futuros planes y requisitos de negocio a través del
Porfolio de Servicios
■■ Los objetivos del servicio y la Operación Actual del
Servicio del TI a través de SLAs y Procedimientos de
Operación Estándar
■■ Todas las áreas de la tecnología de TI y su capacidad y
rendimiento, incluyendo infraestructura, datos, entorno
y aplicaciones.
El entendimiento de todo esto permitirá a Gestión de
la Capacidad garantizar que se proporcionen de forma
eficaz todos los aspectos actuales y futuros de capacidad y
rendimiento de los servicios.
Gestión de la Capacidad también trata sobre el
entendimiento del potencial de la entrega de nuevos
servicios. Es necesario entender la nueva tecnología y,
si fuera apropiado, usarla para innovar y entregar los
servicios requeridos por el cliente. Gestión de la Capacidad
necesita asumir que la velocidad de cambio tecnológico
probablemente se incrementará y que la nueva tecnología
se utilizará para garantizar que los servicios de TI
continúen satisfaciendo las expectativas del negocio. Será
necesario tener un vínculo directo con la Estrategia del
Servicio y el Porfolio de Servicios para garantizar que se
consideren las tecnologías emergentes en la planificación
de futuros servicios.
824_005 Chapter 04.indd 86
El proceso de Gestión de la Capacidad deberá incluir:
■■ Monitorizar modelos de actividad del negocio y
planes de nivel de servicio a través del desempeño,
utilización y rendimiento de servicios de TI y de
la infraestructura de soporte, entorno, datos y
componentes de las aplicaciones, y generación de
informes regulares y ad hoc sobre la capacidad y
rendimiento de componentes y servicios
■■ Emprender actividades de ajuste para lograr el uso
más eficiente de recursos de TI existentes
■■ Entender las demandas acordadas actuales y futuras
del cliente con respecto a los recursos de TI, y
elaborar previsiones para futuros requisitos
■■ Influir en Gestión de la Demanda, quizás en
colaboración con Gestión Financiera
■■ Elaborar un Plan de Capacidad que permita al
proveedor de servicio continuar dando servicios de la
calidad definida en los SLAs y que cubra una franja
de tiempo suficiente de planificación para cumplir los
futuros niveles de servicios requeridos como se define
en el Porfolio de Servicios y SLRs
■■ Colaborar con la identificación y resolución de
cualquier incidencia y problema asociados con el
rendimiento del servicio o componente
■■ La mejora proactiva del rendimiento del servicio o
componente siempre que sea justificable en costes y
cumpla las necesidades del negocio.
La gestión de la capacidad de grandes infraestructuras
de TI distribuidas es una tarea compleja y exigente,
especialmente cuando la capacidad de TI y la inversión
financiera requerida siempre están en aumento. Por lo
tanto, tiene aún más sentido planificar con respecto
al crecimiento. Aunque el coste de la actualización de
un componente individual en un entorno distribuido
normalmente es menor que la actualización de un
componente en un entorno de mainframe, en muchas
ocasiones será necesario actualizar más componentes en
un entorno distribuido. Además, podría haber economías
de escala ya que el coste por componente individual
podría reducirse cuando sea necesario comprar muchos
componentes. Gestión de la Capacidad deberá tener
una entrada en el Porfolio de Servicios y en el proceso
de compras para garantizar que se negocien los mejores
contratos con los proveedores.
Gestión de la Capacidad proporciona la información
necesaria con respecto a la utilización planificada y actual
de recursos de componentes individuales para permitir a
las organizaciones decidir con la debida confianza:
■■ Los componentes que se actualizarán (es decir,
más memoria, dispositivos de almacenamiento más
22/1/10 13:49:31

rápidos, procesadores más rápidos, aumento de ancho
de banda)
■■ Cuándo realizar las actualizaciones. Idealmente éstas
no se deben realizar con demasiada anticipación,
lo que generaría un exceso de capacidad cara, ni
demasiado tarde, lo que haría que se perdieran
oportunidades con las nuevas tecnologías generando
cuellos de botella, rendimiento inconsistente y, en
última estancia, insatisfacción del cliente y pérdida de
oportunidades de negocio
■■ Cuánto costará la actualización. Los elementos de
previsión y planificación de Gestión de la Capacidad
desembocan en ciclos de vida presupuestarios,
garantizando una inversión planificada.
Existen muchos otros procesos que son menos eficaces si
no tuvieran ninguna entrada del proceso de Gestión de la
Capacidad. Por ejemplo:
■■ ¿El proceso de Gestión de Cambios puede analizar
adecuadamente el efecto de cualquier cambio en la
capacidad disponible?
■■ Cuando se implemente un nuevo servicio, ¿el proceso
de SLM puede asegurar que los SLR del nuevo servicio
sean alcanzables, y que los SLA de servicios existentes
no se vean afectados?
■■ ¿El proceso Gestión de Problemas puede diagnosticar
la causa subyacente de incidencias provocadas por un
rendimiento deficiente?
■■ ¿El proceso Continuidad del Servicio de TI puede
determinar con precisión los requisitos de capacidad
de los procesos de negocio clave?
Gestión de la Capacidad es uno de los procesos más
innovadores que, cuando se lleva a cabo correctamente,
puede prever en muchas ocasiones eventos e impactos en
el negocio antes de que se produzcan. Una buena Gestión
de Capacidad garantiza que no haya sorpresas en relación
con el diseño y rendimiento de los componentes y del
servicio.
Gestión de la Capacidad tiene una estrecha relación
bidireccional con la Estrategia del Servicio y con los
procesos de planificación de una organización. De forma
regular, la estrategia a largo plazo de una organización se
encapsula en una actualización de los planes de negocio.
La Estrategia del Servicio reflejará los planes de negocio y
la estrategia, que se desarrollan a partir del entendimiento
de la organización de factores externos como por ejemplo
el mercado competitivo, la perspectiva económica y la
legislación, y de su capacidad interna en términos de
mano de obra, capacidad de entrega, etc. En muchas
ocasiones se desarrolla un plan táctico a corto plazo, o
824_005 Chapter 04.indd 87
Procesos de Diseñ̃o del Servicio | 87
plan de cambio de negocio, para implementar los cambios
necesarios de corto a medio plazo para desarrollar el plan
de negocio general y la Estrategia del Servicio. Gestión de
la Capacidad necesita entender los planes a corto, medio y
largo plazo del negocio mientras proporciona información
sobre las últimas ideas, tendencias y tecnologías que están
desarrollando los proveedores de software y hardware.
Los planes de negocio de la organización impulsan la
Estrategia del Servicio de TI específica, los contenidos
con los que Gestión de la Capacidad necesita estar
familiarizada, y a los que Gestión de Capacidad necesita
haber tenido una entrada significativa y continua. Los
planes de Estrategia del Servicio serán útiles para la
planificación de la capacidad identificando el momento
de adquirir e implementar nuevas tecnologías, hardware y
software.
4.3.3  Valor para el negocio
Gestión de la Capacidad es responsable de garantizar
que los recursos de TI se planifiquen y programen para
proporcionar un nivel consistente de servicio que se
corresponda con las necesidades actuales y futuras
del negocio, como se acordó y documentó en SLAs y
OLAs. Junto con el negocio y sus planes, Gestión de
la Capacidad proporciona un Plan de Capacidad que
describe los recursos de TI y la financiación necesaria para
dar soporte al plan de negocio, junto con una justificación
de costes de ese gasto.
4.3.4  Políticas/principios/conceptos básicos
Gestión de la Capacidad garantiza que la capacidad
y el rendimiento de los sistemas y servicios de TI se
correspondan con la evolución de las demandas del
negocio acordadas de la forma más oportuna y rentable.
Gestión de la Capacidad es esencialmente un acto de
equilibrio:
■■ Equilibrio de los costes con respecto a los recursos
necesarios: la necesidad de garantizar que la
capacidad de procesamiento que se compre sea
justificable en costes, en términos de necesidad del
negocio, y la necesidad de hacer el uso más eficiente
de esos recursos.
■■ Equilibrio del suministro con respecto a la
demanda: la necesidad de garantizar que el
suministro disponible de la potencia de procesamiento
de TI se corresponda con las demandas hechas por
el negocio, ahora y en el futuro. También podría ser
necesario gestionar o influir en la demanda para un
recurso particular.
22/1/10 13:49:32
 88 | Procesos de Diseñ̃o del Servicio
Revisar la capacidad
Sistema de Información
y rendimiento actuales de Gestión de la Capacidad
(CMIS)
Mejorar la capacidad Informes y datos
actual del servicio de capacidad y
y componente rendimiento
Evalua, acuerda y
documenta nuevos Previsiones
requisitos y capacidad
Planificar nueva Plan de Capacidad
capacidad
Figura 4.8  El Proceso de Gestión de la Capacidad
Los procesos y la planificación de Gestión de Capacidad
deben implicarse en todas las etapas del Ciclo de Vida del
Servicio desde Estrategia y Diseño, a través de Transición
y Operación hasta Mejora. Desde una perspectiva
estratégica, el Porfolio de Servicios contiene los recursos
y capacidades de TI. La llegada de una Arquitectura
Orientada al Servicio, la virtualización y el uso de redes
de valor en la provisión del servicio de TI, son factores
importantes en la gestión de la capacidad. La capacidad
y rendimiento adecuados deberán diseñarse en servicios
y componentes desde las etapas iniciales de diseño. Esto
garantizará no sólo que el rendimiento de cualquier
servicio nuevo o modificado cumpla sus objetivos
esperados, sino que también todos los servicios existentes
continúen cumpliendo todos sus objetivos. Esta es la base
de una provisión del servicio estable.
El proceso general de Gestión de Capacidad está
continuamente intentando de forma rentable que la
capacidad y recursos de TI se correspondan con las
necesidades y requisitos, en cambio permanente, del
negocio. Esto requiere el ajuste y optimización de los
recursos actuales y la estimación y planificación eficaz de
los futuros recursos, como se ilustra en la Figura 4.8.
Gestión de la Capacidad es un proceso muy técnico,
complejo y exigente, y para lograr resultados, requiere tres
subprocesos de soporte.
Una de las actividades clave de Gestión de Capacidad es
generar un plan que documente los niveles actuales de
utilización de recursos y de rendimiento del servicio y,
después de la consideración de Estrategia del Servicio,
la planificación y elaboración de previsiones de los
futuros requisitos para nuevos recursos de TI que darán
soporte a los servicios de TI que apoyarán las actividades
de negocio. El plan debe indicar claramente cualquier
824_005 Chapter 04.indd 88
suposición hecha. También debe incluir cualquier
recomendación cuantificada en términos de recursos
requeridos, coste, beneficios, impacto, etc.
La producción y mantenimiento de un Plan de Capacidad
deberán producirse a intervalos definidos previamente. Es
esencialmente un plan de inversión y por lo tanto deberá
publicarse anualmente, en línea con el negocio o con el
ciclo de vida presupuestario, y deberá completarse antes
del inicio de las negociaciones sobre futuros presupuestos.
Podría ser necesario una reedición trimestral del plan
actualizado para tener en cuenta cambios en los planes
del servicio manteniendo de esta forma la precisión de
las previsiones, y para hacer o refinar recomendaciones.
Esto implica un esfuerzo adicional, pero si se actualizara
regularmente, es más probable que el Plan de la
Capacidad sea preciso y refleje la necesidad cambiante del
negocio.
Los contenidos más comunes en un Plan de Capacidad se
describen en el Apéndice J.
4.3.4.1  Gestión de la Capacidad del Negocio
Este subproceso traduce las necesidades y planes de
negocio en requisitos para el servicio e infraestructura de
TI, garantizando que los futuros requisitos de negocio para
los servicios de TI se cuantifiquen, diseñen, planifiquen
e implementen de forma oportuna. Esto se puede lograr
utilizando los datos existentes sobre la utilización actual
de recursos por parte de los distintos servicios, y con ello
elaborar tendencias, previsiones, modelos y predicciones
de futuros requisitos. Estos futuros requisitos provienen
de la Estrategia del Servicio y del Porfolio de Servicios
que detallan nuevos procesos y requisitos del servicio,
cambios, mejoras, y también el crecimiento de los
servicios existentes.
4.3.4.2  Gestión de la Capacidad del Servicio
El enfoque de este subproceso es la gestión, control y
predicción de la capacidad y del rendimiento extremo a
extremo de las cargas de trabajo y del uso de los servicios
de TI operativos activos. Garantiza que se monitorice
y mida el rendimiento de todos los servicios, como se
detalla en los objetivos del servicio de SLAs y SLRs, y que
se registren, analicen y se transmitan los datos recopilados.
Siempre que sea necesario, deberán impulsarse acciones
proactivas y reactivas para garantizar que el rendimiento
de todos los servicios cumpla sus objetivos de negocio
acordados. Esto se realizará mediante personal con
conocimiento en todas las áreas tecnológicas utilizadas en
la entrega del servicio extremo a extremo, y en muchas
ocasiones implicará la búsqueda de asesoramiento de
especialistas implicados en Gestión de la Capacidad
22/1/10 13:49:32
 Procesos de Diseñ̃o del Servicio | 89

del Componente. Siempre que sea posible deberán
utilizarse umbrales automatizados para gestionar todos los
servicios operativos, para garantizar que se identifiquen
rápidamente las situaciones donde los objetivos del
servicio se incumplen o haya amenaza de ello, y para
identificar las acciones rentables para reducir o evitar su
posible impacto.
4.3.4.3  Gestión de la Capacidad del Componente
El enfoque de este subproceso es la gestión, control
y predicción del rendimiento, utilización y capacidad
de componentes tecnológicos de TI individuales. Esto
garantiza que se monitorice y se mida el rendimiento
de todos los componentes de la infraestructura de
TI, y que se registren, analicen y se transmitan los
datos recopilados. De nuevo, siempre que sea posible,
deberán implementarse umbrales automatizados para
gestionar todos los componentes, para garantizar que se
identifiquen rápidamente las situaciones en las que el uso
de los componentes incumpla los objetivos del servicio
o en las que haya amenaza de ello, y para identificar
las acciones rentables para reducir o evitar su posible
impacto.
Los subprocesos anteriores realizan muchas actividades
similares, pero cada subproceso tiene un enfoque muy
diferente. Gestión de la Capacidad del Negocio se centra
en los requisitos de negocio actuales y futuros, mientras
que Gestión de la Capacidad del Servicio se centra en
la entrega de los servicios existentes que dan soporte
al negocio, y Gestión de la Capacidad del Componente
se centra en la infraestructura de TI que da soporte a la
provisión del servicio. En la Figura 4.9 se muestra el rol
que desempeña cada uno de estos subprocesos en el
proceso general y el uso de herramientas de gestión.

Portfolio de Servicios

Requisitos
de negocio

Informes de la
capacidad y el
rendimiento

Gestión de la Revisar la capacidad

Capacidad del Negocio y rendimiento actuales

Diseño del Mejorar la capacidad

SLA/SLR
Servicio de TI actual del servicio
y componente
Sistema de Información
de Gestión de la Capacidad
Gestión de la Evaluar, acordar y (CMIS)
Capacidad del Servicio documentar nuevos
requisitos y capacidad

Gestión de la
Capacidad del Planificar nueva
Componente capacidad Previsiones

Plan de Capacidad
Herramientas
de Gestión
de la Capacidad

Figura 4.9  Subprocesos de Gestión de la Capacidad

824_005 Chapter 04.indd 89 22/1/10 13:49:32

 90 | Procesos de Diseñ̃o del Servicio
Es necesario que las herramientas utilizadas por Gestión
de la Capacidad sean adecuadas a la arquitectura de
gestión de la organización y se integren con las demás
herramientas utilizadas para la gestión de sistemas de TI y
para la automatización de procesos de TI. Las actividades
de monitorización y control dentro de Operación del
Servicio proporcionarán una buena base para que las
herramientas den soporte y analicen la información de
Gestión de la Capacidad.
4.3.5 Actividades, métodos y técnicas del
proceso
Algunas actividades en el proceso Gestión de la Capacidad
son reactivas, mientras que otras son proactivas. Las
actividades proactivas de Gestión de la Capacidad deberán
incluir:
■■ Evitar problemas asociados con el rendimiento
adoptando las acciones necesarias antes de que se
produzcan
■■ Elaborar tendencias de la utilización actual de
los componentes y estimar los futuros requisitos
utilizando tendencias y umbrales para planificar
actualizaciones y mejoras
■■ Modelar y elaborar la tendencia de cambios previstos
en servicios de TI, e identificar los cambios necesarios
en servicios y componentes de la infraestructura
de TI y de las aplicaciones para garantizar que esté
disponible el recurso adecuado
■■ Garantizar que las actualizaciones se presupuesten,
planifiquen e implementen antes de que se produzcan
incumplimientos de los SLA y de los objetivos del
servicio, o antes de que se produzcan problemas de
rendimiento
■■ Buscar activamente la mejora del rendimiento del
servicio siempre que se justifiquen sus costes
■■ Ajustar y optimizar el rendimiento de servicios y
componentes.
Las actividades reactivas de Gestión de la Capacidad
deberán incluir:
■■ Monitorizar, medir, transmitir y revisar el rendimiento
actual de servicios y componentes
■■ Responder a todos los eventos ‘umbrales’ asociados
con la capacidad e impulsar acciones correctivas
■■ Reaccionar ante problemas específicos de rendimiento
y ayudar en la resolución. Por ejemplo, el Centro
de Servicio al Usuario podría avisar de incidencias
debidas a un rendimiento deficiente a Gestión de la
Tecnología, que a su vez empleará técnicas de Gestión
de la Capacidad para resolverlas.
824_005 Chapter 04.indd 90
Mensaje clave
Mientras más éxito tengan las actividades proactivas
y predictivas de Gestión de la Capacidad, menos
necesidad habrá de actividades reactivas de Gestión de
la Capacidad.
4.3.5.1  Gestión de la Capacidad del Negocio
El objetivo principal del subproceso Gestión de la
Capacidad del Negocio es asegurar que se tengan en
cuenta y se entiendan los futuros requisitos de negocio
(resultados del cliente) para los servicios de TI, y que se
planifique e implemente capacidad de TI suficiente para
dar apoyo a servicios nuevos y modificados en una escala
de tiempo adecuada. La Figura 4.10 muestra que BCM
está influenciada por los modelos de actividad del negocio
y por cómo se utilizan los servicios.
El proceso Gestión de la Capacidad debe responder a
los requisitos cambiantes de la demanda de capacidad.
Se requerirán servicios nuevos o modificados para
ayudar al negocio a afrontar los cambios. Los servicios
existentes tendrán que modificarse para que incorporen
funcionalidades añadidas. Los servicios antiguos se
quedarán obsoletos, liberando capacidad. Por lo tanto, la
capacidad para satisfacer los SLA y SLR de los clientes se
verán afectados. Gestión de la Capacidad es responsable
de predecir la demanda de capacidad para tales cambios y
gestionarla.
Puede que estos nuevos requisitos lleguen a Gestión
de la Capacidad de muchas fuentes y por razones
diferentes, pero las fuentes principales de suministro
deben ser el Modelo de Actividad del Negocio de Gestión
de la Demanda y los Paquetes de Nivel de Servicio
generados por el Porfolio de Servicios. Éstos indican
una ventana de futuros pronosticadores de capacidad.
Algunos ejemplos podrían ser una recomendación de
actualización para aprovechar una nueva tecnología, o
para la implementación de una actividad de ajuste fino
Resultado Activos Patrones de
del cliente del cliente actividad del negocio
Patrón de demanda
para el servicio
Paquete de
nivel de servicio
Figura 4.10  La capacidad debe dar soporte a los
requisitos de negocio
22/1/10 13:49:33

Patrón de demanda
Patrón de Proceso
actividad de negocio
del negocio
Correa del servicio
Planificación de entrega
Incentivos y
penalizaciones para influir
en el consumo
Figura 4.11  Gestión de la Capacidad sintetiza aspectos particulares del modelo de demanda
para resolver un problema de rendimiento. La Figura 4.11
muestra el ciclo de Gestión de la Demanda.
Es necesario incluir a Gestión de la Capacidad en todas las
actividades estratégicas, de planificación y diseño que ya
se están implicando en cada proceso, como por ejemplo:
■■ Ayudar y dar soporte al desarrollo de Estrategia del
Servicio
■■ Implicación en la revisión y mejora de estrategias y
políticas de TI
■■ Implicación en la revisión y mejora de las arquitecturas
tecnológicas.
Mensaje clave
Gestión de la Capacidad no debe ser algo como
‘marcar la casilla’ en el último minuto justo antes de la
aceptación del cliente y la aceptación operativa.
Si se puede lograr la implicación anticipada de Gestión de
la Capacidad en estos procesos, entonces la planificación
y diseño de la capacidad de TI pueden alinearse
estrechamente con los requisitos de negocio y pueden
garantizar que se logren y se mantengan los objetivos del
servicio.
Ayudar en el acuerdo de Requerimientos de Nivel
de Servicio
Gestión de la Capacidad deberá ayudar a SLM a entender
la capacidad de los clientes y los requisitos de rendimiento
en términos de tiempos de respuesta requeridos del
sistema/servicio, rendimiento esperado, modelos de uso
y volumen de usuarios. Gestión de la Capacidad deberá
824_005 Chapter 04.indd 91
Procesos de Diseñ̃o del Servicio | 91
Proceso Plan de
de servicio Gestión de
la Capacidad
Gestión de
la Demanda
ayudar en el proceso de negociación proporcionando
posibles soluciones a varios escenarios. Por ejemplo, si
el volumen de usuarios fuera menor de 2.000, entonces
puede garantizarse que los tiempos de respuesta sean
inferiores a dos segundos. Si se conectaran al mismo
tiempo más de 2.000 usuarios, entonces será necesario
disponer de ancho de banda adicional para garantizar el
tiempo de respuesta requerido, o tendrá que aceptarse
un tiempo de respuesta mayor. En muchas ocasiones las
técnicas de modelado, tendencias o aplicación se emplean
aquí para garantizar que las predicciones reflejen con
precisión la situación real.
Diseñar, comprar o modificar la configuración
del servicio
Gestión de la Capacidad deberá implicarse en el diseño de
servicios nuevos o modificados y hacer recomendaciones
para la compra de hardware y software, donde el
rendimiento y/o capacidad son factores importantes.
En algunos casos Gestión de la Capacidad impulsa la
implementación del nuevo requisito a través de Gestión
de Cambios, donde también se implica como un miembro
del Comité de Cambios. Para lograr el equilibrio de coste y
capacidad, el proceso Gestión de la Capacidad obtiene el
coste de soluciones propuestas alternativas y recomienda
la solución rentable más apropiada.
Verificar SLA
El SLA deberá incluir detalles de los requisitos anticipados
de rendimiento y desempeño del servicio. Gestión de la
Capacidad aconseja a SLM sobre los objetivos alcanzables
que se pueden monitorizar y sobre los que se ha basado
22/1/10 13:49:33
 92 | Procesos de Diseñ̃o del Servicio
Diseño del Servicio. La confianza de que Diseño del
Servicio cumplirá los SLR y proporcionará la capacidad
para un futuro crecimiento se ganará usando técnicas de
modelado, tendencias y dimensionamiento.
Soporte a la negociación de SLAs
Los resultados de las técnicas predictivas proporcionan la
verificación de las capacidades de rendimiento del servicio.
Puede haber una necesidad de que SLM renegocie
SLAs basándose en estas conclusiones. Gestión de la
Capacidad proporciona soporte a SLM si fueran necesarias
renegociaciones, recomendando posibles soluciones y
ofreciendo información de los costes asociados. Cuando
se asegure que los requisitos son alcanzables, SLM será
responsable de acordar los niveles de servicio y firmar el
SLA.
Control e implementación
Todos los cambios en el servicio y en la capacidad de los
recursos deben seguir todos los procesos de TI como por
ejemplo Gestión de Cambios, Versiones, Configuración
y Proyectos para garantizar que se aplique el grado
correcto de control y coordinación en todos los cambios
y que se registre y se haga el seguimiento de cualquier
componente nuevo o modificado a través de su ciclo de
vida.
4.3.5.2  Gestión de la Capacidad del Servicio
El objetivo principal del subproceso de Gestión de la
Capacidad del Servicio es identificar y entender los
servicios de TI, su empleo de los recursos, modelos
de trabajo, picos y valles, y asegurar que los servicios
cumplan los objetivos de su SLA, es decir, garantizar
que los servicios de TI se comporten como se requiere.
En este subproceso, el énfasis se centra en la gestión
del rendimiento del servicio, según se determina en los
objetivos incluidos en los SLA o SLR acordados.
El subproceso Gestión de la Capacidad del Servicio
garantiza que los servicios cumplan los objetivos
acordados de capacidad del servicio. El servicio
monitorizado proporciona datos que pueden identificar
tendencias a partir de las cuales se pueden establecer
niveles de servicio normales. Con la monitorización y
comparación regular con estos niveles, se pueden definir,
identificar y transmitir condiciones de excepción. Por lo
tanto, Gestión de la Capacidad informa a SLM de cualquier
ruptura del servicio o cualquier posibilidad de ello.
Habrá ocasiones en las que se informe a Gestión de la
Capacidad de incidencias y problemas de otros procesos,
o se identifique la posibilidad de que un servicio incumpla
los objetivos del SLA. En algunos de estos casos, la causa
824_005 Chapter 04.indd 92
posible del fallo puede que no se resuelva mediante
Gestión de la Capacidad del Componente. Por ejemplo,
cuando se analiza el fallo, puede ser que no haya
falta de capacidad, o que no se esté sobreutilizando
ningún componente individual. Sin embargo, si
el diseño o codificación de una aplicación fueran
ineficientes, entonces puede que sea necesario gestionar
el rendimiento del servicio, además de los recursos
individuales de hardware y software. Gestión de la
Capacidad del Servicio también debe estar monitorizando
cargas de trabajo y transiciones del servicio para garantizar
que se encuentran dentro de las limitaciones y umbrales
acordados.
El éxito para una Gestión de la Capacidad del Servicio
exitosa es la previsión de problemas, siempre que sea
posible, monitorizando cambios en el rendimiento y
el impacto de los cambios. Por lo tanto, este es otro
subproceso que tiene que ser más proactivo y previsor,
incluso preventivo, que reactivo. Sin embargo, en
ocasiones tiene que reaccionar a problemas específicos
de rendimiento. En función del conocimiento y
entendimiento de los requisitos de rendimiento para
cada uno de los servicios que se están usando, pueden
estimarse los efectos de los cambios en la utilización de
los servicios, y es posible adoptar acciones para asegurar
que se pueda alcanzar el rendimiento requerido del
servicio.
4.3.5.3  Gestión de la Capacidad del Componente
El principal objetivo de Gestión de la Capacidad
del Componente (CCM) es identificar y entender el
rendimiento, capacidad y utilización de cada uno de
los componentes individuales dentro de la tecnología
utilizada para dar soporte a los servicios de TI, incluyendo
la infraestructura, el entorno, los datos y las aplicaciones.
Esto asegura el uso óptimo de los recursos hardware y
software actuales para alcanzar y mantener los niveles de
servicio acordados. Todos los componentes hardware y
muchos componentes software de la infraestructura de
TI tienen una capacidad finita que, una vez alcanzada
o superada, puede provocar posibles problemas de
rendimiento.
Este subproceso se aplica a componentes como por
ejemplo procesadores, memoria, discos, ancho de banda
y conexiones de red, etc. Por lo tanto, la información
sobre las necesidades de utilización de los recursos se
recopila continuamente. Deben instalarse monitores en
el hardware individual y en los componentes software,
y a continuación configurarlos para recopilar los datos
necesarios, que se acumulan y almacenan durante un
periodo de tiempo. Esta es una actividad normalmente
realizada a través de la monitorización y control dentro de
22/1/10 13:49:33
 Procesos de Diseñ̃o del Servicio | 93

Ajuste fino

Implementación Análisis

Monitorización

Informes Informes de
Sistema excepción de
de excepción utilización de
de Información del servicio recursos
Umbrales Umbrales de Gestión de
de recursos del servicio la Capacidad (CMIS)

Figura 4.12  Acciones iterativas continuas de Gestión de la Capacidad

Operación del Servicio. Dentro de este subproceso deberá La mayor diferencia entre los subprocesos está en los
aplicarse una retroalimentación directa a CCM. datos que se están monitorizando y recopilando, y en
la perspectiva desde la que se analizan. Por ejemplo, el
Como en Gestión de la Capacidad del Servicio, la clave
nivel de autorización de componentes individuales en la
para el éxito de CCM es la previsión de problemas,
infraestructura, como por ejemplo procesadores, discos, y
siempre que sea posible, y por lo tanto tiene que ser
vínculos de red, es de interés de Gestión de la Capacidad
proactivo y predictivo. Sin embargo, en ocasiones CCM
del Componente, mientras que las ratios de rendimiento y
tiene que reaccionar a problemas específicos provocados
los tiempos de respuesta de la transacción son de interés
por la falta de capacidad o por el uso ineficiente
de Gestión de la Capacidad del Servicio. Para Gestión de
del componente. En función del conocimiento y
la Capacidad del Negocio, es necesario traducir los ratios
entendimiento del uso de los recursos que emplea cada
de rendimiento de la transacción de un servicio on line
uno de los servicios en explotación, pueden estimarse los
en volúmenes de negocio, por ejemplo, en términos de
efectos de los cambios en la utilización de los servicios,
facturas de ventas presentadas u órdenes aceptadas. El
y las actualizaciones de hardware y software pueden
desafío más importante al que se enfrenta Gestión de la
presupuestarse y planificarse. De esta forma, los servicios
Capacidad es entender la relación entre las demandas y
pueden equilibrarse a través de recursos existentes para
requisitos del negocio y la carga de trabajo del negocio,
hacer mas eficaz el uso de los recursos actuales.
y poder traducirlos en términos de impacto y efecto
en el servicio, en cargas de trabajo y en utilización de
4.3.5.4  Las actividades de apoyo de Gestión de
los recursos, para que se puedan establecer umbrales
la Capacidad adecuados en cada nivel.
Las actividades descritas en esta sección son necesarias
para dar soporte a los subprocesos de Gestión de la Actividades de ajuste y optimización
Capacidad, y estas actividades pueden llevarse a cabo
Es necesario llevar a cabo varias actividades iterativamente
de forma reactiva o proactiva, o incluso como medio de
y formar un ciclo natural, como se ilustra en la Figura 4.12.
prevención.

824_005 Chapter 04.indd 93 22/1/10 13:49:33

 94 | Procesos de Diseñ̃o del Servicio
Estas actividades proporcionan la información histórica
básica y disparadores necesarios para todas las demás
actividades y procesos dentro de Gestión de la Capacidad.
Se debe establecer monitorización en todos los
componentes y en cada uno de los servicios. Los datos
deben analizarse utilizando, siempre que sea posible,
sistemas expertos para comparar niveles de uso frente a
los umbrales. Los resultados del análisis deben incluirse
en informes, y se deberán hacer las recomendaciones
apropiadas. A continuación podría aplicarse alguna forma
de mecanismo de control para actuar en función de las
recomendaciones. Esto podría tomar la forma de servicios
balanceados, cargas de trabajo equilibradas, cambios de
niveles de concurrencia y recursos añadidos o retirados.
Toda la información acumulada durante estas actividades
debe almacenarse en el Sistema de Información de
Gestión de la Capacidad (CMIS) y a continuación
comenzar el ciclo de nuevo, monitorizando cualquier
cambio realizado para garantizar que han tenido un
efecto beneficioso y recopilando más datos para futuras
ocasiones.
Monitorización de la utilización
Los monitores deben especificarse para sistemas
operativos, configuraciones de hardware, aplicaciones
especiales, etc. Es importante que los monitores puedan
recopilar todos los datos requeridos por el proceso
Gestión de la Capacidad, para un componente o servicio
específico. Los datos monitorizados más habituales
incluyen:
■■ Utilización del procesador
■■ Utilización de la memoria
■■ Porcentaje de procesador por tipo de transacción
■■ Índices IO (físicos y buffer) y utilización del dispositivo
■■ Longitudes de las colas
■■ Utilización del disco
■■ Ratios de transacción
■■ Tiempos de respuesta
■■ Duración del lote
■■ Uso de la base de datos
■■ Índice de uso
■■ Índices de efectividad
■■ Números de usuarios concurrentes
■■ Tasas de tráfico de red.
A la hora de considerar los datos que se deben incluir, es
necesario definir una distinción entre los datos recopilados
para monitorizar la capacidad (por ejemplo rendimiento)
y los datos para monitorizar el rendimiento (por ejemplo,
tiempos de respuesta). Los subprocesos de Gestión de la
Capacidad del Servicio y del Componente requieren datos
824_005 Chapter 04.indd 94
de ambos tipos. Es necesario que esta monitorización
y recopilación incorpore todos los componentes en
el servicio, lo que constituye la monitorización de la
experiencia del cliente ‘extremo a extremo’. Los datos
deben recopilarse a un nivel de utilización total de
recursos y a un perfil más detallado para la carga que cada
servicio aplica en cada componente particular. Esto debe
realizarse a través de toda la tecnología, host o servidor,
la red, servidor local y cliente o estación de trabajo. De
forma similar, es necesario recopilar los datos para cada
servicio.
Parte de la actividad de monitorización debe ser la de
umbrales y líneas de referencia o perfiles de los niveles
operativos normales. Si éstos se superaran, deberían
emitirse alarmas y generar informes de excepción.
Estos umbrales y líneas de referencia deben haberse
determinado a partir del análisis de datos registrados
previamente, y se pueden establecer en el componente y
al nivel de servicio. Todos los umbrales deben establecerse
por debajo del nivel al que el componente o servicio se
sobreutiliza, o por debajo de los objetivos incluidos en
los SLA. Cuando se alcance el umbral, o haya amenaza de
ello, todavía habrá una oportunidad para tomar acciones
correctivas antes que se haya incumplido el SLA, o que el
recurso se haya sobreutilizado y hubiera un periodo de
rendimiento deficiente. La monitorización y gestión de
estos eventos, umbrales y alarmas se incluye con detalle
en la publicación Operación del Servicio.
En muchas ocasiones es más difícil obtener los datos
sobre los volúmenes de negocio actuales como requiere
el proceso Gestión de la Capacidad del Negocio. Puede
que sea necesario derivar estas estadísticas de los datos
disponibles para los subprocesos de Gestión de la
Capacidad del Servicio y del Componente.
Monitorización del tiempo de respuesta
Muchos SLA tienen el tiempo de respuesta de usuario
como uno de los objetivos a medir, pero de igual forma,
muchas organizaciones tienen grandes dificultades para
dar apoyo a este requisito. Los tiempos de repuesta de
usuario de servicios de red y de TI pueden monitorizarse y
medirse con lo siguiente:
■■ Incorporación de código específico dentro
del software de las aplicaciones del cliente y
servidor. Esto se puede utilizar para proporcionar
tiempos de respuesta del servicio completo
‘extremo a extremo’ o en puntos de sincronización
intermedios para descomponer la respuesta general
en sus componentes. Las cifras obtenidas de estas
herramientas proporcionan los tiempos de respuesta
22/1/10 13:49:33

reales, tal y como los perciben los usuarios de un
servicio.
■■ Uso de ‘sistemas robóticos programados’ con
software de simulación de terminales. Estos
sistemas están formados por sistemas cliente
con software de simulación de terminales (por
ejemplo, navegador o sistemas Telnet) y por
software programado especializado para generar
y medir transacciones y respuestas. Estos sistemas
normalmente proporcionan tiempos de respuesta
de muestra del servicio ‘extremo a extremo’ para
proporcionar tiempos de respuesta representativos,
particularmente para transacciones de múltiples fases
o para iteraciones complejas. Éstos sólo proporcionan
tiempos de respuesta de muestra, no tiempos de
respuesta reales que perciben los usuarios reales del
servicio.
■■ Uso de software de monitorización de agentes
distribuidos. La información útil sobre los tiempos de
respuesta del servicio puede obtenerse distribuyendo
sistemas agente con software de monitorización
en diferentes puntos de una red (por ejemplo, en
diferentes países en Internet). Estos sistemas se
pueden utilizar para generar transacciones a partir de
un número de ubicaciones y pueden proporcionar
medidas periódicas de la percepción de un sitio de
Internet por parte de los usuarios internacionales de
un sitio web de Internet. Si embargo, los tiempos
recibidos son sólo indicaciones de los tiempos de
respuesta y no son tiempos de respuesta de usuario
reales.
■■ Uso de sistemas específicos de monitorización
pasiva. Seguimiento de un número de muestra
representativo de sistemas cliente. Este método radica
en la conexión de sistemas de monitorización de
red específicos, a los que con frecuencia se les hace
referencia como ‘sniffers’, que se están insertando en
puntos apropiados dentro de la red. Éstos pueden
monitorizar, registrar y medir todo el tráfico que pasa
por un punto particular de la red. Una vez registrado,
este tráfico puede analizarse para proporcionar
información detallada sobre los tiempos de respuesta
del servicio. Sin embargo, nuevamente, éstos sólo se
pueden utilizar para proporcionar una aproximación
de los tiempos de respuesta reales del usuario, aunque
con frecuencia pueden estar muy cerca de la situación
real dependiendo de la posición del propio monitor
dentro de la infraestructura de TI.
En algunos casos, podría utilizarse una combinación de
sistemas. La monitorización de los tiempos de respuesta
es un proceso complejo incluso si se trata de un servicio
824_005 Chapter 04.indd 95
Procesos de Diseñ̃o del Servicio | 95
interno en una red privada. Si fuera un servicio de Internet
externo, el proceso sería mucho más complejo debido al
número total de diferentes organizaciones y tecnologías
implicadas.
Anécdota
Una empresa con un sitio web importante implementó
un servicio de monitorización del sitio web a partir
de un suministrador externo que proveería alarmas
automáticas con respecto a la disponibilidad y
capacidad de respuesta de su sitio web. La capacidad
y velocidad de los puntos de monitorización
eran menores que las del sitio web que se estaba
monitorizando. Por lo tanto, las cifras generadas por
el servicio se correspondían con la disponibilidad
y capacidad de respuesta del propio servicio de
monitorización, en lugar de corresponder con el sitio
web monitorizado.
Sugerencias y consejos
Al implementar servicios de monitorización externos,
asegúrese de que los compromisos de los niveles
de servicio y rendimiento estén por encima de
los correspondientes a los servicios que se están
monitorizando.
Análisis
Los datos recopilados por la monitorización deben
analizarse para identificar tendencias a partir de las
cuales se puedan establecer la utilización normal y los
niveles de servicio o líneas de referencia. Mediante la
monitorización y comparación regular con esta línea de
referencia, se pueden definir las condiciones de excepción
en la utilización de componentes individuales o umbrales
del servicio, y se podrá informar de incumplimientos,
o amenaza de los mismos, en los SLAs y actuar en
consecuencia. Por otra parte, los datos se pueden utilizar
para predecir el futuro uso de los recursos, o para
monitorizar el crecimiento real del negocio con respecto al
crecimiento previsto.
El análisis de los datos podría identificar problemas tales
como:
■■ ‘Cuellos de botella’ o ‘puntos calientes’ dentro de la
infraestructura
■■ Distribución inadecuada de la carga de trabajo en
recursos disponibles
■■ Indexación inadecuada de bases de datos
■■ Ineficiencias en el diseño de la aplicación
22/1/10 13:49:33
 96 | Procesos de Diseñ̃o del Servicio
■■ Aumento inesperado de las cargas de trabajo o ratios
de transacciones
■■ Uso de memoria o programación ineficientes.
Es necesario considerar el uso de cada componente y
servicio con respecto al corto, medio y largo plazo y la
utilización mínima, máxima y promedio de estos periodos
registrados. Normalmente, el modelo de corto plazo
incluye la utilización durante un periodo de 24 horas,
mientras que el medio plazo podría incluir un periodo
de una a cuatro semanas, y el largo plazo un periodo
largo de un año. Con el tiempo, la tendencia en el uso
del recurso por parte de varios servicios de TI pasará a
ser evidente. La utilidad de esta información se mejora
posteriormente registrando cualquier factor observado
que contribuya a los picos y valles en la utilización,
por ejemplo, si un cambio del proceso de negocio del
personal coincidiera con cualquier desviación de la
utilización normal.
Es importante entender la utilización en cada uno de estos
periodos, para que los cambios en el uso de cualquier
servicio pueda relacionarse con los cambios previstos en
el nivel de utilización de componentes individuales. La
capacidad para identificar los componentes de hardware
o software específicos de los que depende un servicio de
TI particular se mejora ampliamente mediante un CMS
preciso, actualizado e integral.
Al considerar la utilización de un recurso particular, es
importante entender el nivel total de utilización y la
utilización del recurso por parte de servicios individuales.
Ejemplo
Si dos servicios diferentes, A y B, estuvieran utilizando
un procesador que tiene una carga del 75% durante
la hora pico, es importante saber cuánto de ese 75%
está siendo utilizado por cada servicio. Asumiendo que
la carga del sistema sobre el procesador es un 5%,
el 70% de la carga restante podría dividirse a partes
iguales entre los dos servicios. Si se estimara que un
cambio en el Servicio A o Servicio B fuera el doble
de su carga en el procesador, entonces el procesador
podría sobrecargarse.
Sin embargo, si el servicio A utilizara el 60% y el
Servicio B utilizara el 10% del procesador, entonces el
procesador podría sobrecargarse si el servicio A doblara
su carga en el procesador. Pero si el servicio B doblara
su carga en el procesador, entonces el procesador se
sobrecargaría necesariamente.
824_005 Chapter 04.indd 96
Ajuste
El análisis de los datos monitorizados podría identificar
áreas de la configuración que podrían ajustarse para
utilizar mejor los recursos del servicio, sistema o
componentes o para mejorar el rendimiento del servicio
particular.
Las técnicas de ajuste que son de ayuda incluyen:
■■ Equilibrio de cargas de trabajo y tráfico - las
transacciones podrían llegar al host o servidor por una
pasarela de red particular, dependiendo de dónde se
inició la transacción; el balanceo del índice de puntos
de inicio por pasarela puede aumentar los beneficios
del ajuste
■■ Equilibrio del tráfico de disco – almacenando datos en
disco de forma eficiente y estratégica, por ejemplo, el
intercalado de datos a través de muchos terminales
podría reducir la contención de datos
■■ La definición de una estrategia de bloqueo aceptada
que especifique cuándo son necesarios los bloqueos
y el nivel apropiado, por ejemplo, base de datos,
página, archivo, registro y fila, retrasando el bloqueo
hasta que es necesaria una actualización puede
ofrecer beneficios
■■ Uso eficiente de memoria – podría incluir la utilización
de más o menos memoria, en función de las
circunstancias.
Antes de implementar cualquiera de las recomendaciones
que surgen de las técnicas de ajuste, podría ser apropiado
considerar la prueba de la validez de la recomendación.
Por ejemplo, ‘¿Se puede utilizar Gestión de la Demanda
para evitar la necesidad de realizar cualquier ajuste?’ o
‘¿Se puede proponer modelar el cambio para mostrar su
eficacia antes de que se implemente?’
Implementación
El objetivo de esta actividad es introducir en los servicios
de operación reales cualquier cambio que se hubiera
identificado mediante las actividades de monitorización,
análisis y ajuste. La implementación de cualquier cambio
que surja de estas actividades deberá llevarse a cabo
mediante un proceso de Gestión de Cambios estricto y
formal. El impacto de los cambios de ajuste del sistema
puede tener implicaciones importantes en los clientes del
servicio. Es probable que el impacto y riesgo asociados
con estos tipos de cambios sean mayores que los de otros
tipos diferentes de cambios.
Es importante que se aplique una monitorización posterior
para que se evalúen los efectos del cambio. Podría ser
necesario hacer cambios posteriores o deshacer algunos
de los cambios originales.
22/1/10 13:49:34

Explotación de la nueva tecnología
Esto implica entender nuevas técnicas y tecnologías
y cómo se utilizan para dar soporte al negocio y para
obtener mejoras innovadoras. Podría ser apropiado
introducir una nueva tecnología para mejorar la provisión
y soporte de los servicios de TI de los que depende
la organización. Esta información puede recopilarse
estudiando publicaciones profesionales (revistas y artículos
de prensa) y asistiendo a:
■■ Seminarios promocionales impartidos por
suministradores de hardware y software
■■ Reuniones de grupos de usuarios de suministradores
de hardware y software
■■ Reuniones de grupos de usuarios para otros
profesionales de TI implicados en Gestión de la
Capacidad.
Cada uno de ellos proporciona fuentes de información
asociadas con técnicas, tecnologías, hardware y software
potenciales que podrían ser ventajosos para TI a la hora de
materializar los beneficios para el negocio. Sin embargo,
en todo momento, Gestión de la Capacidad debe aceptar
que la introducción y uso de esta nueva tecnología debe
estar justificada en costes y ofrecer beneficios reales para
el negocio. No sólo es importante la nueva tecnología en
sí misma, sino que Gestión de la Capacidad también debe
ser consciente de las ventajas que se obtendrán del uso
de las nuevas tecnologías, utilizando técnicas como por
ejemplo ‘grid computing’, ‘virtualización’ y ‘aplicaciones
bajo demanda’.
Diseño de la capacidad de recuperación
Gestión de la Capacidad colabora con la identificación
y mejora de la capacidad de recuperación dentro de
la infraestructura de TI o de cualquier subconjunto
de la misma, siempre que esté justificado en costes.
Junto con Gestión de la Disponibilidad, Gestión de la
Capacidad debe utilizar técnicas como por ejemplo
Análisis de Impacto de Fallos de Componentes (CFIA, tal
y como se describe en la sección 4.4 sobre Gestión de
la Disponibilidad) para identificar la sensibilidad de la
configuración actual con respecto al fallo o sobrecarga de
componentes individuales y para hacer recomendaciones
sobre cualquier solución rentable.
Gestión de la Capacidad debe ser capaz de identificar el
impacto en los recursos disponibles de fallos particulares, y
la posibilidad de ejecutar los servicios más importantes en
función de los recursos restantes. Por lo tanto, la provisión
de capacidad de reserva puede actuar como capacidad de
recuperación o fail-over en situaciones de fallo.
824_005 Chapter 04.indd 97
Procesos de Diseñ̃o del Servicio | 97
Los requisitos para la capacidad de recuperación en
la infraestructura de TI siempre se deben considerar
en el momento del diseño del servicio o sistema. Sin
embargo, en el caso de muchos servicios, la capacidad de
recuperación del servicio sólo se considera después de
que esté en uso operativo real. Incorporar la capacidad de
recuperación en Diseño del Servicio es mucho más eficaz
y eficiente que añadirla posteriormente, una vez que el
servicio haya pasado a estar operativo.
4.3.5.5  Control y gestión de umbrales
Las actividades de monitorización pueden utilizar límites
y restricciones técnicas en los servicios y componentes
individuales para establecer los umbrales a partir de los
cuales surgirán alarmas y advertencias y se generarán
informes de excepciones. Sin embargo, deben tomarse
todas las precauciones posibles al establecer umbrales, ya
que muchos de ellos dependen de las tareas que se están
realizando en el componente particular.
La gestión y control de los umbrales del componente
o servicio es fundamental para la entrega eficaz de
servicios que cumplan sus niveles de servicio acordados.
Esto garantiza que todos los umbrales del servicio y los
componentes se mantengan en los niveles apropiados y
se monitoricen de forma continua y automática, y que
se generen alertas y advertencias cuando se produzcan
incumplimientos. Siempre que se incumplan los umbrales
monitorizados o haya amenaza de ello, se generarán
alarmas y advertenciase informes de excepciones,e
incumplimientos. El análisis de la situación debe
completarse y adoptarse acciones correctivas siempre
que esté justificado, garantizando que la situación no
vuelva a producirse. Los mismos elementos de datos se
pueden utilizar para identificar cuándo se incumplen los
SLA o cuándo hubiera posibilidad de que se incumplan,
o cuándo el rendimiento del componente se degrada o
es probable que se degrade. Con el ajuste de umbrales
por debajo o por encima de los objetivos reales, se
podrán tomar acciones y evitarse un incumplimiento de
los objetivos del SLA. La monitorización de los umbrales
no sólo debe dedicarse a avisar sobre la superación
de un umbral, sino que también debe monitorizar la
velocidad de su evolución y predecir cuándo se alcanzará
el umbral. Por ejemplo, un monitor de espacio de disco
debe monitorizar la velocidad de crecimiento y emitir una
alarma cuando la velocidad actual pueda provocar que se
llene el disco en los siguientes N días. Si un disco de 1GB
hubiera alcanzado el 90% de capacidad, y creciera a una
tasa de 100 KB al día, esto corresponderá con 1.000 días
antes de que se llene. Si estuviera creciendo a una tasa
de 10 MB al día, sólo serán 10 días antes de que se llene.
22/1/10 13:49:34
 98 | Procesos de Diseñ̃o del Servicio
La monitorización y gestión de estos eventos y alarmas
se incluye con detalle en la publicación Operaciones del
Servicio.
Podrían existir ocasiones en las que fuera necesario
mantener la optimización de los recursos y componentes
de la infraestructura o mejorar el rendimiento o volumen
de trabajo. En muchas ocasiones esto puede hacerse
a través de Gestión de la Carga de Trabajo, que es un
término genérico para indicar acciones como:
■■ Replanificar un servicio o carga de trabajo en particular
para que se ejecute en un momento diferente del día,
o día de la semana, etc. (normalmente lejos de los
periodos de mayor demanda en ventanas de tiempo
sin demanda), que con frecuencia significará tener que
hacer ajustes en el software de planificación de tareas
■■ Mover un servicio o carga de trabajo de una ubicación
o conjunto de CIs a otra, normalmente para equilibrar
el uso o el tráfico
■■ ‘Virtualización’ técnica: establecer y utilizar técnicas y
sistemas de virtualización para permitir el movimiento
del procesamiento alrededor de la infraestructura
para ofrecer un mejor rendimiento/capacidad de
recuperación de forma dinámica
■■ Limitar o mover la demanda de componentes
o recursos a través de técnicas de Gestión de la
Demanda, junto con Gestión Financiera (vea la sección
4.3.5.6).
Sólo será posible gestionar cargas de trabajo de forma
eficaz si existe un buen entendimiento de las cargas de
trabajo que se ejecutarán y en qué momento, y cuántos
recursos se ponen a disposición para cada carga de
trabajo aplicada en la infraestructura de TI. Por lo tanto,
la monitorización y análisis detallados de las cargas de
trabajo, junto con un CMIS global, serán necesarios en
base a una operativa continua.
4.3.5.6  Gestión de la Demanda
El objetivo principal de Gestión de la Demanda es influir
en la demanda del usuario y cliente de servicios de TI y
gestionar el impacto sobre recursos de TI.
Esta actividad se puede realizar como un requisito a corto
plazo debido a que no hay suficiente capacidad actual
para dar soporte a la tarea que se está ejecutando, o,
como una política deliberada de gestión de TI, para limitar
la capacidad requerida a largo plazo.
La Gestión de la Demanda, a corto plazo, podría
desencadenarse cuando se hubiera producido un fallo
parcial de un recurso crítico en la infraestructura de
TI. Por ejemplo, si se hubiera producido un fallo de un
824_005 Chapter 04.indd 98
procesador en un servidor multiprocesador, puede que
no sea posible ejecutar todo el rango de servicios. Sin
embargo, podría ejecutarse un subconjunto limitado de
servicios. Gestión de la Capacidad debe ser consciente
de la prioridad del negocio de cada uno de los servicios,
conocer los requisitos de recursos de cada servicio (en este
caso, la cantidad de potencia requerida del procesador
para ejecutar el servicio) y a continuación ser capaz de
identificar los servicios que pueden ejecutarse cuando
haya una cantidad limitada de potencia disponible en el
procesador.
La Gestión de la Demanda a largo plazo podría ser
necesaria cuando sea difícil justificar los costes de una
actualización cara. Por ejemplo, muchos procesadores
se utilizan a fondo durante sólo algunas horas al
día, normalmente de 10.00 a 12.00 y de 14.00 a
16.00. Durante estos periodos, el procesador podría
sobrecargarse durante sólo una o dos horas. Durante
las horas entre las 18.00 y 08.00, estos procesadores se
cargan muy poco y se infrautilizan los componentes.
¿Es posible justificar el coste de una actualización para
proporcionar capacidad adicional durante sólo algunas
horas al dia? ¿O es posible influir en la demanda y
amplitud del requisito para utilizar el recurso durante
24 horas, retrasando o evitando la necesidad de una
actualización costosa?
Es necesario que Gestión de la Demanda entienda
qué servicios están utilizando el recurso y a qué nivel,
y la programación de cuándo deben ejecutarse. A
continuación puede tomarse una decisión sobre si será
posible influir en el uso del recurso y, si fuera así, qué
opción es la apropiada.
La influencia en los servicios que se están ejecutando
podría ejercerse mediante:
■■ Restricciones físicas: por ejemplo, podría ser posible
detener algunos servicios en ciertos momentos, o
limitar el número de clientes que puedan utilizar
un servicio particular, por ejemplo, limitando el
número de usuarios concurrentes; la restricción
debe implementarse en un recurso o componente
específico, por ejemplo, limitando el número de
conexiones físicas a un router o switch de red
■■ Restricciones financieras: si se facturan los servicios
de TI, se deben ofrecer tarifas reducidas para ejecutar
el trabajo en momentos del día cuando haya menos
demanda del recurso. Esto se conoce como cobro
diferencial.
22/1/10 13:49:34

4.3.5.7  Modelado y tendencia
Un objetivo importante de Gestión de la Capacidad es
predecir el comportamiento de los servicios de TI bajo un
volumen dado y una variedad de trabajos. El modelado
es una actividad que se puede utilizar para obtener
beneficios en muchos de los subprocesos de Gestión de la
Capacidad.
Los diferentes tipos de modelado abarcan desde las
estimaciones basadas en la experiencia y en la información
sobre la utilización actual de los recursos, hasta estudios
piloto, prototipos y benchmarks a gran escala. El primero
es un método económico y razonable para las pequeñas
decisiones diarias, mientras que el último es caro aunque
puede ser aconsejable cuando se implemente un
nuevo servicio o proyecto grande. Con todos los tipos
de modelado se pueden obtener niveles similares de
precisión, aunque todos dependerán de la habilidad de la
persona a la hora de construir el modelo y la información
usada para crearlo.
Establecer la línea de referencia
La primera etapa en el modelado es crear un modelo de
línea de referencia que refleje con precisión el rendimiento
que se está alcanzando. Cuando se haya creado este
modelo de línea de referencia, se puede realizar el
modelado predictivo, es decir, hacer preguntas como
‘¿Qué ocurre si?’ que reflejen fallos, cambios planificados
en el hardware y/o el volumen/variedad de cargas de
trabajo. Si el modelo de línea de referencia es preciso,
entonces la precisión del resultado de los posibles fallos y
cambios puede ser fiable.
Una Gestión de la Capacidad eficaz, junto con las técnicas
de modelado, permiten a Gestión de la Capacidad
responder a las preguntas ‘¿Qué pasa si?’. ¿Qué pasa si
el rendimiento del Servicio A se duplica?’ ¿Qué pasa si el
Servicio B se traslada del servidor actual a otro servidor
nuevo? -¿Cómo cambiarán los tiempos de respuesta en los
dos servicios?
Análisis de tendencias
El análisis de tendencias puede realizarse sobre la
información de la utilización de los recursos y del
rendimiento del servicio que recopiló Gestión de la
Capacidad. Los datos pueden analizarse en una hoja de
cálculo y los recursos gráficos, análisis de tendencias y
previsión, sirven para mostrar la utilización de un recurso
particular durante un periodo de tiempo anterior, y cómo
se espera que evolucione en el futuro.
Normalmente, el análisis de tendencias sólo proporciona
estimaciones de la futura utilización de los recursos. El
análisis de tendencias es menos eficaz para generar una
824_005 Chapter 04.indd 99
Procesos de Diseñ̃o del Servicio | 99
estimación precisa de los tiempos de respuesta, por lo que
se debería emplear el modelo de simulación o el modelo
analítico. El análisis de tendencias es más eficaz cuando
existe una relación lineal entre un número pequeño de
variables, y menos eficaz cuando no existen relaciones
lineales entre variables o cuando hay muchas variables.
Modelado analítico
Los modelos analíticos son representaciones del
comportamiento de sistemas informáticos mediante
técnicas matemáticas como por ejemplo la teoría de
colas de redes multiclase. Normalmente, un modelo se
construye utilizando un paquete de software en un PC,
especificando dentro del paquete los componentes e
infraestructura de la configuración que será necesario
modelar, y la utilización de los componentes, por ejemplo,
procesador, memoria y disco, por las diferentes cargas de
trabajo o aplicaciones. Cuando se ejecuta el modelo, la
teoría de colas sirve para calcular los tiempos de respuesta
en el sistema informático. Si los tiempos de respuesta
predichos por el modelo son suficientemente próximos a
los tiempos de respuesta registrados en la práctica, puede
concluirse que el modelo es una representación precisa
del sistema informático.
La técnica de modelado analítico requiere menos tiempo y
esfuerzo que el modelo de simulación, pero normalmente
proporciona resultados menos precisos. El modelo
también debe mantenerse actualizado. Sin embargo, si
los resultados estuvieran dentro del 5% de precisión para
la utilización, y del 15-20% para los tiempos de respuesta
de la aplicación on line, los resultados serán normalmente
satisfactorios.
Simulación
La simulación involucra el modelado de eventos discretos,
como por ejemplo las tasas de llegada de transacciones,
con respecto a una configuración hardware dada. Este tipo
de modelado puede ser muy preciso para dimensionar
nuevas aplicaciones o predecir los efectos de los cambios
en las aplicaciones existentes, pero también puede
consumir mucho tiempo y, por lo tanto, ser costoso.
Cuando simule las tasas de llegada de las transacciones,
haga que parte del personal introduzca una serie de
transacciones desde secuencias de comando preparadas,
o utilice software para introducir las mismas transacciones
programadas con una tasa de llegadas aleatoria.
Cualquiera de estos métodos requiere tiempo y esfuerzo
de preparación y ejecución. Sin embargo, su coste
puede estar justificado para organizaciones con servicios
y sistemas muy grandes, donde el coste principal y las
implicaciones de rendimiento vinculadas, adquieren gran
importancia.
22/1/10 13:49:34
 100 | Procesos de Diseñ̃o del Servicio
4.3.5.8  Dimensionamiento de la aplicación
El dimensionamiento de la aplicación tiene una vida
útil finita. Se inicia en la etapa de diseño para un nuevo
servicio, o cuando hay un cambio importante en un
servicio existente, y se completa cuando se acepta la
aplicación en el entorno operativo activo. Las actividades
de dimensionamiento deben incluir todas las áreas de
tecnología asociadas con las aplicaciones, y no sólo las
propias aplicaciones. Esto debe incluir la infraestructura, el
entorno y los datos, y en muchas ocasiones utiliza técnicas
de modelado y elaboración de tendencias.
El objetivo principal de dimensionamiento de la aplicación
es estimar los requisitos de recursos para dar soporte
a un cambio propuesto en un servicio existente o a la
implementación de un nuevo servicio, para garantizar que
cumpla sus niveles requeridos de servicio. Para lograr esto,
el dimensionamiento de la aplicación tiene que ser parte
integral del Ciclo de Vida del Servicio.
Durante los requisitos iniciales y el diseño, los niveles de
servicio requeridos deberán especificarse en un SLR. Esto
permite a Diseño del Servicio y desarrollo emplear las
tecnologías y productos pertinentes para lograr un diseño
que cumpla los niveles deseados de servicio. Es mucho
más fácil y menos caro lograr los niveles de servicio
requeridos si Diseño del Servicio considera los niveles
de servicio requeridos al comienzo del Ciclo de Vida
del Servicio, en lugar de considerarlos en alguna etapa
posterior.
Otras consideraciones en el dimensionamiento de la
aplicación son los aspectos de capacidad de recuperación
que podrían ser necesarios construir en el diseño de
los nuevos servicios. Gestión de la Capacidad tiene la
posibilidad de proporcionar asesoramiento y directrices al
proceso de Gestión de la Disponibilidad con respecto a los
recursos requeridos para proporcionar el nivel requerido
de rendimiento y capacidad de recuperación.
El dimensionamiento de la aplicación debe refinarse
cuando progrese el proceso de diseño y desarrollo.
El modelado se puede utilizar dentro del proceso de
dimensionamiento de la aplicación.
Los SLR de los desarrollos de la aplicación planificada no
se deben considerar de forma aislada. Es probable que
los recursos a analizar por la aplicación se compartan
con otros servicios, y deberán reconocerse y gestionarse
las amenazas potenciales en los objetivos de los SLA
existentes.
Al comprar paquetes de software de suministradores
externos, es importante entender los requisitos de recursos
necesarios para dar soporte al servicio. En muchas
824_005 Chapter 04.indd 100
ocasiones puede ser difícil obtener esta información de
los suministradores y esto podría variar dependiendo
del rendimiento. Por lo tanto, es beneficioso identificar
clientes similares del producto y entender mejor las
implicaciones de los recursos en ellos. Podría ser
pertinente comparar, evaluar o probar el producto antes
de la compra.
Mensaje clave
La calidad se debe construir.
Algunos aspectos de la calidad del servicio pueden
mejorarse después de la implementación (por ejemplo,
se puede añadir hardware adicional para mejorar el
rendimiento). Otros, particularmente aspectos como la
fiabilidad y capacidad de mantenimiento del software
de las aplicaciones, radican en la calidad que se está
‘incorporando’, ya que intentar añadirla en una etapa
posterior implica rediseñar y desarrollar, normalmente a
un coste mucho mayor que el desarrollo original. Incluso
en el ejemplo del hardware mencionado anteriormente,
es probable que el coste sea mayor si se añade capacidad
adicional después de la implementación del servicio en
lugar de hacerlo como parte del proyecto original.
4.3.6  Disparadores, entradas, salidas e
interfaces
Existen muchos disparadores que iniciarán actividades de
Gestión de la Capacidad. Éstos incluyen:
■■ Interrupciones del servicio, eventos y alertas de
capacidad o rendimiento, incluyendo eventos de
umbral
■■ Informes de excepciones
■■ Revisión periódica de la capacidad y rendimiento
actuales y la revisión de previsiones, informes y planes
■■ Servicios nuevos y modificados que requieren
capacidad adicional
■■ Modelado y elaboración de tendencias periódicas
■■ Revisión de planes y estrategias de negocio y de TI
■■ Revisión de diseños y estrategias
■■ Revisión de SLAs, OLAs, contratos o cualquier otro
acuerdo.
Existen varias fuentes de información que son relevantes
para el proceso de Gestión de la Capacidad. Algunas de
éstas son las siguientes.
4.3.6.1  Entradas
■■ Información del negocio: procedente de la
estrategia, planes de negocio y financieros de la
22/1/10 13:49:34

organización y de la información sobre sus requisitos
actuales y futuros.
■■ Información del servicio y TI: procedente de
Estrategia del Servicio, la estrategia y planes de TI
y presupuestos actuales, incluyendo todas las áreas
de tecnología y planes de tecnología, incluyendo la
infraestructura, datos y aplicaciones, y la forma en la
que se asocian con los planes y estrategia de negocio.
■■ Información de la capacidad y rendimiento del
componente: de tecnología nueva y existente,
procedente de fabricantes y suministradores.
■■ Problemas de rendimiento del servicio: los
procesos de Gestión de Problemas e Incidencias,
con incidencias y problemas que se asocian con un
rendimiento deficiente.
■■ Información del servicio: procedente del proceso
SLM, con detalles de los servicios del Porfolio
de Servicios y del Catálogo de Servicios y de los
objetivos de nivel de servicio dentro de SLAs y SLRs,
y posiblemente procedente de la monitorización de
SLAs, revisiones del servicio e incumplimientos de los
SLA.
■■ Información financiera: procedente de Gestión
Financiera, los costes de la provisión del
servicio, el coste de los recursos, componentes
y actualizaciones, el beneficio resultante para el
negocio y los planes y presupuestos financieros,
junto con los costes asociados con el fallo del
servicio y de los componentes. Algunos de los
costes de los componentes y de las actualizaciones
de los componentes se obtendrán de compras,
suministradores y fabricantes.
■■ Información del cambio: procedente del proceso
Gestión de Cambios, con una Planificación de Cambios
y una necesidad de evaluar todos los cambios
con respecto a su impacto en la capacidad de la
tecnología.
■■ Información del rendimiento: procedente del
Sistema de Información de Gestión de la Capacidad
(CMIS) sobre el rendimiento actual de todos los
servicios existentes y sobre los componentes de la
infraestructura de TI.
■■ CMS: que contiene información sobre las relaciones
entre el negocio, los servicios, los servicios de soporte
y la tecnología.
■■ Información de la carga de trabajo: procedente del
equipo de Operaciones de TI, con programaciones de
todo el trabajo que es necesario realizar, e información
sobre dependencias entre diferentes servicios e
información, y las interdependencias dentro de un
servicio.
824_005 Chapter 04.indd 101
Procesos de Diseñ̃o del Servicio | 101
4.3.6.2  Salidas
Las salidas de Gestión de la Capacidad se utilizan dentro
de las demás partes del proceso, por muchos otros
procesos y por otras partes de la organización. En muchas
ocasiones esta información se suministra en forma de
informes electrónicos o visualizaciones sobre áreas
compartidas, o como páginas en servidores de Internet,
para asegurar que siempre se utilice la información más
actualizada. La información proporcionada es la siguiente:
■■ El Sistema de Información de Gestión de la
Capacidad (CMIS): mantiene la información que
necesitan todos los subprocesos dentro de Gestión de
la Capacidad. Por ejemplo, los datos monitorizados y
recopilados como parte de Gestión de la Capacidad
del Servicio y del Componente se utilizan en Gestión
de la Capacidad del Negocio para determinar qué
componentes de la infraestructura o actualizaciones de
los componentes son necesarios, y cuándo.
■■ El Plan de Capacidad: utilizado por todas las áreas
de gestión de TI y del negocio. El proveedor de
servicios de TI y la gestión senior de la organización
lo activan para planificar la capacidad de la
infraestructura de TI. También proporciona la entrada
de planificación para muchas otras áreas de TI y del
negocio. Contiene información sobre el uso actual
del servicio y los componentes, y los planes para
que el desarrollo de la capacidad de TI satisfaga las
necesidades de crecimiento del servicio existente
y de cualquier servicio nuevo acordado. El Plan de
Capacidad debe utilizarse activamente como base para
la toma de decisiones. Con demasiada frecuencia, se
crean Planes de Capacidad a los que nunca se hace
referencia ni se utilizan.
■■ Informes e información del rendimiento del
servicio: utilizados por muchos otros procesos. Por
ejemplo, el proceso Gestión de la Capacidad ayuda
a Gestión del Nivel de Servicio con la generación de
informes y la revisión del rendimiento del servicio
y con el desarrollo de SLRs nuevos o con cambios
en SLAs existentes. También ayuda al proceso
de Gestión Financiera a identificar cuándo es
necesario presupuestar dinero para actualizaciones
de la infraestructura de TI, o para la compra de
componentes nuevos.
■■ Informes y análisis de la carga de trabajo:
utilizados por Operaciones de TI para evaluar e
implementar cambios junto con Gestión de la
Capacidad para programar o reprogramar el momento
en el que se ejecutan los servicios o cargas de trabajo,
garantizando que se haga el uso más eficaz y eficiente
de los recursos disponibles.
22/1/10 13:49:34
 102 | Procesos de Diseñ̃o del Servicio
■■ Informes de rendimiento y capacidad ad hoc:
utilizados por todas las áreas de Gestión de la
Capacidad, TI y el negocio para analizar y resolver
problemas del servicio y de rendimiento.
■■ Previsiones e informes predictivos: utilizados
por todas las áreas para analizar, predecir y prever
escenarios particulares del negocio y TI y sus posibles
soluciones.
■■ Umbrales, alertas y eventos.
4.3.7 Indicadores Clave de Rendimiento
Algunos de los KIPs y métricas que se pueden utilizar para
juzgar la eficiencia y eficacia de las actividades de Gestión
de la Capacidad deben incluir:
■■ Previsiones precisas del negocio:
●●Generación a tiempo de previsiones de la carga de
trabajo
●● Precisión porcentual de las previsiones de
tendencias del negocio
●● Incorporación puntual de planes de negocio en el
Plan de Capacidad
●● Reducción del número de cambios de los planes
de negocio y Planes de Capacidad.
■■ Conocimiento de tecnologías actuales y futuras:
●● Incremento de la capacidad para monitorizar el
rendimiento de todos los servicios y componentes
●● Justificación e implementación puntual de nueva
tecnología en línea con los requisitos del negocio
(tiempo, coste y funcionalidad)
●● Reducción del uso de tecnología antigua,
provocando el incumplimiento de SLAs debido a
problemas con el soporte o rendimiento.
■■ Capacidad para demostrar la rentabilidad:
●● Reducción de las compras a última hora para
abordar problemas urgentes de rendimiento
●● Reducción del exceso de capacidad de TI
●● Previsiones precisas del gasto planificado
●● Reducción de la perturbación del negocio
provocada por una falta de capacidad de TI
adecuada
●● Reducción relativa en el coste de producción del
Plan de Capacidad.
■■ Capacidad para planificar e implementar la capacidad
de TI apropiada para que corresponda con las
necesidades de negocio:
●● Reducción del porcentaje del número de
incidencias debido a un rendimiento deficiente
●● Reducción del porcentaje de negocio perdido
debido a una capacidad inadecuada
824_005 Chapter 04.indd 102
●● Todos los nuevos servicios implementados se
corresponden con los Requisitos de Nivel de
Servicio (SLRs)
●● Aumento del porcentaje de recomendaciones
realizadas por Gestión de la Capacidad y que se
llevan a cabo
●● Reducción del número de incumplimientos de SLAs
debido a un rendimiento deficiente del servicio o
de los componentes.
4.3.8  Gestión de la Información
El objetivo del CMIS es proporcionar la información de la
capacidad y rendimiento pertinente para generar informes
y dar soporte al proceso Gestión de la Capacidad. Estos
informes proporcionan información valiosa para muchos
procesos de Gestión del Servicio y TI. Éstos informes
deben incluir lo siguiente.
Informes basados en el componente
Para cada componente debería haber un equipo de
personal técnico responsable de su control y gestión.
Deben generarse informes para ilustrar cómo se están
comportando los componentes y cuánta de su máxima
capacidad se está utilizando.
Informes basados en el servicio
También deben generarse informes e información para
ilustrar cómo el servicio y sus componentes se están
comportando con respecto a sus objetivos y restricciones
generales del servicio. Estos informes proporcionarán la
base de SLM y de los informes de servicio del cliente.
Informes de excepciones
También se requieren informes que muestren al personal
técnico y de gestión cuándo la capacidad y rendimiento
de un componente o servicio particular pasan a ser
inaceptables a partir del análisis de los datos de
capacidad. Se pueden establecer umbrales para cualquier
componente, servicio o medida dentro del CMIS. Un
umbral de ejemplo podría ser que el porcentaje de
utilización del procesador para un servidor particular se
haya incumplido el 70% durante tres horas consecutivas, o
que el número concurrente de usuarios registrados supere
el límite acordado.
En particular, los informes de excepciones son de interés
para el proceso SLM a la hora de determinar si se han
incumplido los objetivos en los SLA. Además, los procesos
de Gestión de Problemas e Incidencias podrían ser capaces
de utilizar los informes de excepciones en la resolución de
incidencias y problemas.
22/1/10 13:49:34

Informes predictivos y de previsiones
Para garantizar que el proveedor de servicios de
TI continúe proporcionando los niveles de servicio
requeridos, el proceso Gestión de la Capacidad debe
predecir las futuras cargas de trabajo y el crecimiento. Para
hacerlo, se debe prever la futura capacidad y rendimiento
del componente y del servicio. Esto puede hacerse con
una gran variedad de métodos, dependiendo de las
técnicas y de la tecnología utilizadas. Los cambios en las
cargas de trabajo mediante el desarrollo e implementación
de nueva funcionalidad y servicios deben considerarse
junto con el crecimiento en la funcionalidad actual y en
los servicios impulsados por el crecimiento del negocio.
Un ejemplo simple de una previsión de la capacidad
es una correlación entre una directriz de negocio y la
utilización de un componente, por ejemplo, utilización del
procesador frente al número de cuentas del cliente. Estos
datos pueden correlacionarse para encontrar el efecto que
un incremento en el número de cuentas del cliente tendrá
en la utilización del procesador. Si las previsiones en los
futuros requisitos de capacidad identifican un requisito
para el aumento de recursos, es necesario introducir este
requisito en el Plan de Capacidad e incluirlo dentro del
ciclo del presupuesto de TI.
En muchas ocasiones los informes de capacidad se
consolidan juntos y se almacenan en un sitio de la intranet
para que cualquiera pueda acceder y hacer referencias a
ellos.
4.3.8.1  Sistema de Información de Gestión de la
Capacidad
Normalmente los datos de capacidad se almacenan en
bases de datos y herramientas tecnológicas, y no se
obtiene todo el valor posible de los datos, la información
contenida y su análisis. El valor real de los datos sólo se
puede obtener cuando los datos se combinan en un único
conjunto de repositorios de información integrados o en
un conjunto de bases de datos.
El Sistema de Información de Gestión de la Capacidad
(CMIS) es la piedra angular de un proceso de Gestión
de la Capacidad satisfactorio. La información contenida
dentro del CMIS se almacena y analiza mediante todos
los subprocesos de Gestión de la Capacidad, ya que es un
repositorio que contiene varios tipos diferentes de datos,
incluyendo datos del negocio, servicio, recursos o de
utilización y financieros, procedentes de todas las áreas de
tecnología.
Sin embargo, es poco probable que el CMIS sea una
única base de datos, y probablemente se encuentre
en varias ubicaciones físicas. Los datos procedentes de
824_005 Chapter 04.indd 103
Procesos de Diseñ̃o del Servicio | 103
todas las áreas de tecnología, de todos los componentes
que componen los servicios de TI, pueden combinarse
para el análisis y provisión de informes técnicos y de
gestión. Únicamente cuando toda la información se
integra pueden generarse informes del servicio ‘extremo
a extremo’. La integridad y precisión de los datos que se
encuentran dentro del CMIS se gestionan cuidadosamente.
Si el CMIS no fuera parte de un CMS o SKMS general,
entonces es necesario implementar vínculos entre estos
sistemas para garantizar la consistencia y precisión de la
información registrada en ellos.
La información en el CMIS se utiliza para formar la base
de los informes y vistas del rendimiento y de Gestión
de la Capacidad que se vayan a entregar a clientes,
gestión de TI y personal técnico. Además, los datos se
utilizan para generar futuras provisiones de capacidad y
permitir que Gestión de la Capacidad se planifique para
futuros requisitos de capacidad. En muchas ocasiones se
proporciona una interfaz web para que el CMIS facilite
los diferentes accesos y vistas requeridos fuera del propio
proceso de Gestión de la Capacidad.
Todo el rango de tipos de datos almacenados en el CMIS
es el siguiente.
Datos de negocio
Es fundamental tener información de calidad sobre
las necesidades actuales y futuras del negocio. Es
necesario considerar los futuros planes de negocio de
la organización y los efectos en el entendimiento de
los servicios de TI. Los datos de negocio se utilizan para
prever y validar cómo los cambios en las directrices
de negocio afectan a la capacidad y rendimiento de la
infraestructura de TI. Los datos de negocio deben incluir
transacciones y medidas del negocio, como por ejemplo
el número de cuentas, número de facturas generadas y
número de líneas de producto.
Datos del servicio
Para lograr un método orientado al servicio para Gestión
de la Capacidad, los datos del servicio deben almacenarse
dentro del CMIS. Los datos típicos del servicio son tiempos
de respuesta de transacción, ratios de transacción,
volúmenes de carga de trabajo, etc. En general, los SLA y
SLR proporcionan los objetivos del servicio para los que
el proceso de Gestión de la Capacidad necesita registrar
y monitorizar datos. Para garantizar que se logren los
objetivos en los SLA, deben incluirse umbrales de SLM
para que la actividad de monitorización pueda medirse
con respecto a estos umbrales del servicio y puedan
emitirse advertencias e informes de excepciones antes de
que se incumplan los objetivos del servicio.
22/1/10 13:49:34
 104 | Procesos de Diseñ̃o del Servicio
Datos de utilización del componente
También es necesario que el CMIS registre datos de
recursos que consisten en información de la utilización,
umbrales y límites sobre todos los componentes
tecnológicos que dan apoyo al servicio. La mayoría de
los componentes de TI tienen limitaciones con respecto
al nivel al que deben utilizarse. Por encima de este
nivel de utilización, el recurso estará sobreutilizado y el
rendimiento de los servicios que utilizan el recurso se
deteriorará. Por ejemplo, el nivel máximo recomendado
de utilización en un procesador podría ser del 80%, o la
utilización de un segmento LAN Ethernet compartido no
debe superar el 40%.
Además, los componentes tienen varias limitaciones
físicas que son incompatibles con una conectividad o uso
mayor. Por ejemplo, el número máximo de conexiones
a través de una aplicación o una pasarela de red es 100,
o un tipo particular de disco tiene una capacidad física
de 15 Gb. Por lo tanto, el CMIS debe contener, para cada
componente y los límites de rendimiento y capacidad
máximos, las tasas de utilización actuales y pasadas y los
umbrales asociados del componente. Con el tiempo esto
puede requerir la acumulación de grandes cantidades de
datos, por lo que serán necesarias buenas técnicas para
analizar, agregar y archivar estos datos.
Datos financieros
El proceso Gestión de la Capacidad requiere datos
financieros. Para evaluar opciones de actualización
alternativas, al proponer varios escenarios en el Plan de
Capacidad, debe conocerse y tenerse en cuenta el coste
financiero de las actualizaciones para los componentes
de la infraestructura de TI, junto con información sobre
el presupuesto actual de hardware de TI. La mayoría de
estos datos podrían estar disponibles a partir del proceso
de Gestión Financiera de Servicios de Tecnología de
Información (TI), pero es necesario que Gestión de la
Capacidad considere esta información al gestionar los
futuros requisitos de negocio.
4.3.9  Desafíos, Factores Críticos de Éxito y
riesgos
Uno de los retos principales que afronta Gestión de la
Capacidad es persuadir al negocio para que proporcione
información sobre sus planes estratégicos de negocio para
posibilitar que la organización del proveedor de servicios
de TI proporcione una Gestión de la Continuidad del
Negocio (BCM) eficaz. Esto ocurre excepcionalmente en
situaciones de externalización en las que podrían existir
razones comerciales o confidenciales por las que los datos
no se puedan compartir. Incluso si los datos sobre el
824_005 Chapter 04.indd 104
negocio estratégico estuvieran disponibles, podrían existir
problemas asociados con la cantidad y precisión de los
datos contenidos en los planes de negocio en relación con
BCM.
Otro desafío es la combinación de todos los datos de
CCM dentro de un conjunto integrado de información que
se pueda analizar de forma constante para proporcionar
detalles del uso de todos los componentes de los servicios.
Esto representa un reto particular cuando diferentes
herramientas en diferentes formatos proporcionan
información procedente de diferentes tecnologías. En
muchas ocasiones la calidad de la información sobre el
rendimiento de la tecnología de los componentes es
variable en su calidad y precisión.
Las cantidades de información generadas por BCM, y
especialmente por SCM y CCM, son altas y el análisis de
esta información es difícil de lograr. Es necesario que las
personas y los procesos se centren en los recursos clave
y en su uso, evitando que se ignoren otras áreas. Para
hacer esto, deben utilizarse umbrales adecuados, y tener
confianza en las herramientas y tecnología para gestionar
automáticamente la tecnología y proporcionar avisos y
alertas cuando las cosas se desvíen significativamente de
la ‘norma’.
Los CSF principales para el proceso Gestión de la
Capacidad son:
■■ Previsiones precisas del negocio
■■ Conocimiento de tecnologías actuales y futuras
■■ Capacidad para demostrar la rentabilidad
■■ Capacidad para planificar e implementar la capacidad
de TI apropiada para que corresponda con las
necesidades del negocio.
Algunos de los riesgos principales asociados con Gestión
de la Capacidad incluyen:
■■ Una falta de compromiso por parte del negocio con
respecto al proceso de Gestión de la Capacidad
■■ Una falta de información apropiada por parte del
negocio sobre futuros planes y estrategias
■■ Una falta de compromiso de la gestión senior o una
falta de recursos y/o presupuesto para el proceso
Gestión de la Capacidad
■■ SCM y CCM se llevan a cabo de forma aislada
porque BCM es difícil, o hay una falta de información
apropiada y precisa del negocio
■■ Los procesos pasan a ser demasiado burocráticos o
demasiado manuales
■■ Los procesos se centran demasiado en la tecnología
(CCM) y no demasiado en los servicios (SCM) y en el
negocio (BCM)
22/1/10 13:49:34

■■ Los informes e información proporcionados son
demasiado voluminosos o demasiado técnicos y no
ofrecen la información requerida o apropiada para los
clientes y el negocio.
4.4  Gestión de la Disponibilidad
4.4.1  Propósito/meta/objetivo
El objetivo del proceso Gestión de la Disponibilidad es
garantizar que el nivel de disponibilidad de servicio en
todos los servicios corresponda o supere las necesidades
actuales y futuras acordadas del negocio, y de forma
rentable.
El propósito de Gestión de la Disponibilidad es
proporcionar un punto de enfoque y gestión para todos
los aspectos asociados con la disponibilidad, en relación
con los servicios y recursos, garantizando que se midan y
logren los objetivos de disponibilidad en todas las áreas.
Los objetivos de Gestión de la Disponibilidad son:
■■ Generar y mantener un Plan de Disponibilidad
actualizado y adecuado que refleje las necesidades
actuales y futuras del negocio
■■ Proporcionar asesoramiento y directrices para todas las
demás áreas del negocio y de TI con respecto a todos
los aspectos relacionados con la disponibilidad
■■ Garantizar que los logros de disponibilidad del servicio
cumplan o superen todos sus objetivos gestionando
el rendimiento de la disponibilidad asociada con los
recursos y servicios
■■ Colaborar con el diagnóstico y resolución
de incidencias y problemas asociados con la
disponibilidad
■■ Evaluar el impacto de todos los cambios en el Plan de
Disponibilidad, y el rendimiento y capacidad de todos
los servicios y recursos
■■ Asegurar que se implementen medidas proactivas para
mejorar la disponibilidad de los servicios siempre que
tengan un coste justificable.
Gestión de la Disponibilidad debe garantizar que se
proporcione el nivel acordado de disponibilidad. La
medida y monitorización de la disponibilidad de TI es
una actividad clave para garantizar que se cumplan
consistentemente los niveles de disponibilidad. Gestión
de la Disponibilidad debe buscar la optimización
continua y mejorar proactivamente la disponibilidad de la
infraestructura de TI, de los servicios y de la organización
de soporte para proporcionar mejoras rentables de
disponibilidad que puedan ofrecer beneficios al negocio y
al cliente.
824_005 Chapter 04.indd 105
Procesos de Diseñ̃o del Servicio | 105
4.4.2 Ámbito
El ámbito del proceso de Gestión de la Disponibilidad
incluye el diseño, implementación, medida, gestión
y mejora de la disponibilidad del servicio de TI y de
los componentes. Es necesario que Gestión de la
Disponibilidad entienda los requisitos de disponibilidad
del servicio y de los componentes desde la perspectiva del
negocio en términos de:
■■ Los procesos de negocio actuales, su operación y
requisitos
■■ Los futuros planes y requisitos de negocio
■■ Los objetivos del servicio y la entrega y Operación del
Servicio de TI actuales
■■ La infraestructura de TI, datos, aplicaciones y entorno y
su rendimiento
■■ Los impactos en el negocio y prioridades en relación
con los servicios y su uso.
El entendimiento de todo esto permitirá a Gestión
de la Disponibilidad asegurar que todos los servicios
y componentes se diseñen y entreguen para cumplir
sus objetivos en términos de necesidades del negocio
acordadas. El proceso Gestión de la Disponibilidad:
■■ Debe aplicarse a toda la tecnología y servicios
operativos, particularmente a aquellos recogidos por
SLAs. También se puede aplicar a aquellos servicios
de TI que se consideren críticos para el negocio
independientemente de si existen SLAs formales
■■ Debe aplicarse a todos los servicios nuevos de TI y
a los servicios existentes si se hubieran establecido
Requisitos de Nivel de Servicio (SLRs) o Acuerdos de
Nivel de Servicio (SLAs)
■■ Debe aplicarse a todos los servicios de soporte y a
los socios y suministradores (internos o externos) que
forman la organización de soporte de TI como un
impulsor para la creación de acuerdos formales
■■ Considera todos los aspectos de los servicios de
TI, componentes y organizaciones de soporte que
podrían tener un impacto en la disponibilidad,
incluyendo la formación, habilidades, eficacia del
proceso, procedimientos y herramientas.
El proceso Gestión de la Disponibilidad no incluye Gestión
de la Continuidad del Negocio y la reanudación del
proceso del negocio después de un desastre importante.
El soporte de BCM se incluye dentro de Gestión de
Continuidad de los Servicios de Tecnología de Información
(ITSCM). Sin embargo, Gestión de la Disponibilidad
proporciona entradas clave a ITSCM, y los dos procesos
tienen una estrecha relación, particularmente en la
22/1/10 13:49:34
 106 | Procesos de Diseñ̃o del Servicio

evaluación y gestión de riesgos y en la implementación de
medidas de recuperación y reducción de riesgos.
El proceso Gestión de la Disponibilidad deberá incluir:
■■ Monitorización de todos los aspectos de
disponibilidad, fiabilidad y capacidad de
mantenimiento de servicios de TI y de los
componentes de soporte, con eventos, alarmas y
escalado apropiados, con scripts automatizados para la
recuperación
■■ Mantenimiento de un conjunto de métodos, técnicas
y cálculos para todas las medidas, métricas e informes
de disponibilidad
■■ Asistencia con actividades de evaluación del riesgo y
gestión
■■ Conjunto de medidas, análisis y producción de
informes regulares y ad hoc sobre la disponibilidad del
servicio y de los componentes
■■ Entender las demandas actuales y futuras acordadas
del negocio para servicios de TI y su disponibilidad
■■ Influir en el diseño de los servicios y componentes
para que se alineen con las necesidades del negocio
■■ Elaborar un Plan de Disponibilidad que permita al
proveedor de servicio continuar dando y mejorando
servicios en línea con los objetivos de disponibilidad
definidos en Acuerdos de Nivel de Servicio (SLAs), y
planificar y prever futuros niveles de disponibilidad
requeridos, como se define en los Requisitos de Nivel
de Servicio (SLRs)
■■ Mantener una programación de pruebas para todos
los componentes y mecanismos de recuperación de
fallos
■■ Colaborar con la identificación y resolución de
cualquier incidencia y problema asociados con la falta
de disponibilidad del servicio o componente
■■ Mejora proactiva de la disponibilidad del servicio o
componente siempre que sea justificable en costes y
satisfaga las necesidades del negocio.
4.4.3  Valor para el negocio
El proceso Gestión de la Disponibilidad garantiza que la
disponibilidad de los sistemas y servicios corresponda
con las necesidades cambiantes acordadas del negocio.
El rol de TI dentro del negocio ahora es esencial. La
disponibilidad y fiabilidad de los servicios de TI pueden
influir en la satisfacción del cliente y en la reputación
del negocio. Esta es la razón por la que Gestión de la
Disponibilidad es fundamental para garantizar que TI
entregue los niveles correctos de disponibilidad del
servicio requeridos por el negocio para satisfacer sus
objetivos de negocio y para entregar la calidad del servicio
demandada por sus clientes. En el mercado competitivo
actual, la satisfacción del cliente con los servicios
suministrados es primordial. Ya no se puede contar con la

Actividades reactivas

Monitorizar, medir,
analizar, informar y revisar Sistema de
la capacidad del servicio de Información
y del componente de Gestión de la
Disponibilidad (AMIS)

Investigar la
indisponibilidad de todos
los servicios y componentes
Informes de
e instigar acciones correctivas Gestión de la
Disponibilidad

Actividades proactivas Plan de

Disponibilidad
Evaluación y gestión Planificar y diseñar
del riesgo servicios nuevos y
modificados
Criterios de
diseño de la
Implementar Revisar todos los servicios disponibilidad
contramedidas nuevos y modificados y probar todos
justificables en coste los mecanismos de disponibilidad y
capacidad de recuperación Planificación
de pruebas de
disponibilidad

Figura 4.13  El Proceso de Gestión de la Disponibilidad

824_005 Chapter 04.indd 106 22/1/10 13:49:35


lealtad del cliente, y la insatisfacción con la disponibilidad
y fiabilidad del servicio de TI puede ser un factor clave
para que los clientes confíen en su empresa o en la de un
competidor.
El proceso y planificación de Gestión de la Disponibilidad,
al igual que Gestión de la Capacidad, deben implicarse
en todas las etapas del Ciclo de Vida del Servicio
desde Estrategia y Diseño, a través de Transición y
Operación hasta Mejora. La disponibilidad y capacidad
de recuperación deberán diseñarse en servicios y
componentes desde las etapas iniciales de diseño. Esto no
sólo garantizará que la disponibilidad de cualquier servicio
nuevo o modificado cumpla sus objetivos esperados, sino
que también todos los servicios y componentes continúen
cumpliendo todos sus objetivos. Esta es la base de una
provisión del servicio estable.
4.4.4  Políticas/principios/conceptos básicos
El proceso Gestión de la Disponibilidad está intentando
continuamente garantizar que todos los servicios
operativos cumplan sus objetivos de disponibilidad
acordados, y que los servicios nuevos o modificados se
diseñen adecuadamente para cumplir sus objetivos, sin
comprometer el rendimiento de los servicios existentes.
Para lograr eso, Gestión de la Disponibilidad debe llevar a
cabo actividades reactivas y proactivas representadas en la
Figura 4.13.
Las actividades reactivas de Gestión de la Disponibilidad
consisten en monitorizar, medir, analizar, transmitir
y revisar todos los aspectos de la disponibilidad del
componente y del servicio. Esto se hace para garantizar
que se midan y logren todos los objetivos acordados
del servicio. Siempre que se detecten desviaciones o
incumplimientos, éstos se investigan y se promueven
acciones correctivas. La mayoría de estas actividades se
realizan dentro de la etapa de Operaciones del ciclo de
vida y se vinculan con las actividades de monitorización
y control, y con los procesos de Gestión de Incidencias y
Eventos. (Vea la publicación Operación del Servicio).
Las actividades proactivas consisten en la generación de
recomendaciones, planes y documentos sobre directrices y
criterios de diseño de servicios nuevos y modificados, y en
la mejora continua del servicio y reducción del riesgo en
servicios existentes siempre que se justifiquen sus costes.
Estas actividades son aspectos clave a considerar dentro
de las actividades de Diseño del Servicio.
Un proceso de Gestión de la Disponibilidad eficaz,
consistente en actividades reactivas y proactivas, puede
marcar la diferencia, y el negocio lo reconocerá como tal
si el despliegue de Gestión de la Disponibilidad dentro de
824_005 Chapter 04.indd 107
Procesos de Diseñ̃o del Servicio | 107
la organización de TI tuviera un marcado énfasis en las
necesidades del negocio y de los clientes. Para reforzar
este énfasis, existen varios principios de guía que deben
apoyar el proceso Gestión de la Disponibilidad y su
enfoque:
■■ La disponibilidad del servicio se encuentra en el
centro de la satisfacción del cliente y del éxito del
negocio: hay una correlación directa en la mayoría de
las organizaciones entre la disponibilidad del servicio
y la satisfacción del cliente y del usuario, donde el
rendimiento deficiente del servicio se define como
indisponibilidad.
■■ Reconocer que cuando el servicio falla todavía es
posible lograr la satisfacción del negocio, cliente
y usuario, y reconocer que: la forma en la que un
proveedor de servicio reacciona ante una situación de
fallo tiene una influencia importante en la percepción
y expectativas del cliente y del usuario.
■■ La mejora de la disponibilidad sólo puede comenzar
después de entender cómo los servicios de TI dan
soporte a la operación del negocio.
■■ La disponibilidad del servicio sólo es igual de buena
que el eslabón más débil de la cadena: ésta se puede
aumentar ampliamente eliminando Puntos Únicos de
Fallo (SPOFs) o un componente poco fiable o débil.
■■ Disponibilidad no sólo es un proceso reactivo.
Mientras más proactivo sea el proceso, mayor será
la disponibilidad del servicio. Disponibilidad no
debe reaccionar únicamente al fallo del servicio
y componente. Mientras más eventos y fallos se
prevean, eviten previamente y se impidan, mayor será
el nivel de disponibilidad del servicio.
■■ Es más barato diseñar el nivel correcto de
disponibilidad del servicio desde el comienzo, que
intentar ajustarlo posteriormente. Añadir capacidad
de recuperación a un servicio o componente es
invariablemente más caro que diseñarla desde el
comienzo. Además, una vez que un servicio tenga
fama de ser poco fiable, se hace muy difícil cambiar
su imagen. La capacidad de recuperación representa
también una consideración clave de ITSCM, por lo que
debe considerarse simultáneamente.
El ámbito del proceso de Gestión de la Disponibilidad
incluye el diseño, implementación, medida y gestión de
la disponibilidad de la infraestructura y del servicio de TI.
Esto se refleja en la descripción del proceso mostrada en
la Figura 4.13 y que se describe en los siguientes párrafos.
El proceso Gestión de la Disponibilidad tiene dos
elementos clave:
22/1/10 13:49:35
 108 | Procesos de Diseñ̃o del Servicio
■■ Actividades reactivas: el aspecto reactivo de Gestión
de la Disponibilidad implica la monitorización, medida,
análisis y gestión de todos los eventos, incidencias
y problemas que implican la indisponibilidad. Estas
actividades se incluyen principalmente dentro de los
roles operativos.
■■ Actividades proactivas: las actividades proactivas de
Gestión de la Disponibilidad implican la planificación,
diseño y mejora proactiva de la disponibilidad. Estas
actividades se incluyen principalmente dentro de los
roles de diseño y planificación.
Gestión de la Disponibilidad se completa en dos niveles
interrelacionados:
■■ Disponibilidad del servicio: implica todos los
aspectos de la disponibilidad e indisponibilidad
del servicio y el impacto de la disponibilidad
del componente, o el impacto potencial de la
indisponibilidad del componente en la disponibilidad
del servicio
■■ Disponibilidad del componente: implica todos los
aspectos de la disponibilidad e indisponibilidad del
componente.
Gestión de la Disponibilidad se basa en la monitorización,
medida, análisis e información de los siguientes aspectos:
Disponibilidad: la capacidad de un servicio, componente
o CI para realizar su función acordada cuando se
requiere. Con frecuencia se mide y se transmite como un
porcentaje:
(Tiempo de Servicio Acordado ■■ Tiempo de reparación o sustitución física
(AST) – tiempo de caída)
Disponibilidad (%) = X 100 %
Tiempo de Servicio estado funcionando durante un periodo de 5.020 horas
Acordado (AST)
Nota: El tiempo de caída sólo debe incluirse en el cálculo
anterior cuando se produce dentro del Tiempo de Servicio
Acordado (AST). Sin embargo, el tiempo de caída total
también debe registrarse y transmitirse.
Fiabilidad: una medida de cuánto tiempo tarda un
servicio, componente o CI en realizar su función acordada
sin interrupciones. La fiabilidad del servicio puede
mejorarse aumentando la fiabilidad de los componentes
individuales o aumentando la capacidad de recuperación
del servicio con respecto a un fallo del componente
individual (es decir, aumentando la redundancia del
componente, por ejemplo, utilizando técnicas de balanceo
de carga). Con frecuencia se mide y se trasmite como
Tiempo Medio Entre Incidencias del Servicio (MTBSI) y
Tiempo Medio Entre Fallos (MTBF).
824_005 Chapter 04.indd 108
Tiempo disponible en horas
Fiabilidad
=
(MTBSI en horas)
Número de interrupciones
Tiempo disponible en horas –
Tiempo de caída total en horas
Fiabilidad
=
(MTBF en horas)
Número de interrupciones
Capacidad de Mantenimiento: una medida de cómo
de rápida y eficazmente se puede restaurar un servicio,
componente o CI hasta alcanzar su funcionamiento
normal después de un fallo. Se mide y transmite como
Tiempo Medio para Restaurar el Servicio (MTRS) y debe
calcularse utilizando la siguiente fórmula:
Capacidad de Tiempo de caída total en horas
mantenimiento =
(MTRS en horas) Número de interrupciones del
servicio
MTRS debe utilizarse para evitar la ambigüedad del
término más habitual de la industria Tiempo Medio de
Reparación (MTTR), que en algunas definiciones incluye
sólo el tiempo de reparación, pero que en otras incluye
el tiempo de recuperación. El tiempo de caída en MTRS
cubre todos los factores que hacen que el servicio,
componente o CI no esté disponible:
■■ Tiempo de registro
■■ Tiempo de respuesta
■■ Tiempo de resolución
■■ Tiempo de recuperación.
Ejemplo: Una situación en la que un servicio 24 x 7 ha
con sólo dos interrupciones, una de seis horas y una de 14
horas, ofrecería las siguientes cifras:
Disponibilidad = (5.020–(6+14)) / 5.020 x 100 = 99,60%
Fiabilidad (MTBSI) = 5.020 / 2 = 2.510 horas
Fiabilidad (MTBF) = 5.020–(6+14) / 2 = 2.500 horas
Capacidad de mantenimiento (MTRS)
= (6+14) / 2 = 10 horas
Capacidad de servicio: la capacidad de un proveedor
externo para cumplir los términos de su contrato.
En muchas ocasiones este contrato incluirá niveles
acordados de disponibilidad, fiabilidad y/o capacidad de
mantenimiento para un servicio de soporte o componente.
Estos aspectos y sus interrelaciones se ilustran en la Figura
4.14.
22/1/10 13:49:35

Negocio
Clientes Clientes
Acuerdos de Nivel de Servicio
Disponibilidad (% de
disponibilidad del servicio)
Servicio A Servicio B
TI
Sistemas de TI
Acuerdos de Nivel Operativo
Fiabilidad y capacacidad de
mantenimiento (MTBF & MTRS)
Equipos de soporte internos
Figura 4.14  Medidas y términos de la disponibilidad
Aunque el principal objetivo del servicio dentro de
SLAs para los clientes y el negocio es la disponibilidad,
como se ilustra en la Figura 4.14, algunos clientes
también requieren la inclusión de objetivos de fiabilidad
y capacidad de mantenimiento. Si éstos se incluyen,
deberán asociarse con los objetivos de fiabilidad y
capacidad de mantenimiento del servicio, mientras que
los objetivos de fiabilidad y capacidad de mantenimiento
en los OLAs y contratos se asocian con los objetivos del
componente y del servicio de soporte y con frecuencia
pueden incluir objetivos de disponibilidad en relación con
los componentes o servicios de soporte relevantes.
El término Función Vital de Negocio (VBF) se utiliza para
reflejar los elementos críticos del proceso de negocio al
824_005 Chapter 04.indd 109
Procesos de Diseñ̃o del Servicio | 109
Clientes
Servicio C
Contratos y acuerdos
Capacidad de servicio
(disponibilidad, MTBF y MTRSß)
Suministradores
que da soporte un servicio de TI. Un servicio de TI podría
dar soporte a varias funciones de negocio que sean menos
críticas. Por ejemplo, la VBF de un cajero automático
(ATM) sería la de proporcionar efectivo. Sin embargo, la
capacidad de obtener un estado del ATM puede que no
se considere como vital.. Esta distinción es importante
y debe influir en el diseño de disponibilidad y en los
costes asociados. Cuanto más esencial sea la función de
negocio, mayor será el nivel de capacidad de recuperación
y disponibilidad que es necesario incorporar en el diseño
requerido en los servicios de TI de soporte. Para todos
los servicios, ya sean VBF o no, será el negocio, y no TI,
quién deberá determinar los requisitos de disponibilidad.
Normalmente, los objetivos iniciales de disponibilidad se
establecen a un nivel demasiado alto, y esto conduce a
22/1/10 13:49:35
 110 | Procesos de Diseñ̃o del Servicio
servicios demasiado caros o a una discusión iterativa entre
el proveedor de servicio y el negocio para acordar un
compromiso apropiado entre la disponibilidad del servicio
y el coste del mismo y su tecnología de soporte.
Ciertas VBF podrían necesitar diseños especiales, que
ahora se están utilizando como algo natural dentro de los
planes de Diseño del Servicio, y que incorporan:
■■ Alta disponibilidad: una característica del servicio de
TI que minimiza u oculta los efectos del fallo del
componente de TI a los usuarios de un servicio.
■■ Tolerancia a fallos: la capacidad de un servicio de
TI, componente o CI para continuar funcionando
correctamente después del fallo de una parte del
componente.
■■ Operación continua: un método o diseño para
eliminar la parada planificada de un servicio de TI.
Tenga en cuenta que los componentes individuales
o CIs podrían estar interrumpidos incluso si siguiera
estando disponible el servicio.
■■ Disponibilidad continua: un método o diseño para
lograr el 100% de disponibilidad. Un servicio de TI
disponible continuamente no tiene interrupciones
planificadas o sin planificar.
Visión de la industria
Muchos suministradores se comprometen con
soluciones de alta disponibilidad o de disponibilidad
continua sólo si se utilizan estándares o procesos
de capacidad de recuperación. Normalmente
acuerdan tales contratos sólo después de que se haya
completado un estudio del emplazamiento físico y se
hayan realizado mejoras adicionales, y algunas veces
costosas.
Gestión de la Disponibilidad comienza en cuanto estén
suficientemente claros los requisitos de disponibilidad
de un servicio de TI para su integración. Es un proceso
continuo, que acaba sólo cuando el servicio de TI se retira
o elimina. Las actividades clave del proceso Gestión de la
Disponibilidad son:
■■ Determinar los requisitos de disponibilidad a partir del
negocio para un servicio de TI nuevo o mejorado y
formular los criterios de disponibilidad y diseño de la
recuperación para componentes de TI de soporte
■■ Determinar las VBF, junto con el negocio e ITSCM
■■ Determinar el impacto que puede producirse por
el fallo del componente o servicio de TI junto con
ITSCM y, si fuera apropiado, revisar la disponibilidad
de los criterios de diseño para proporcionar capacidad
824_005 Chapter 04.indd 110
de recuperación adicional para evitar o minimizar el
impacto en el negocio
■■ Definir los objetivos de disponibilidad, fiabilidad y
capacidad de mantenimiento para los componentes
de la infraestructura de TI que apoyan el servicio de
TI para permitir que éstos se documenten y acuerden
dentro de SLAs, OLAs y contratos
■■ Establecer medidas e informes de disponibilidad,
fiabilidad y capacidad de mantenimiento que reflejen
las perspectivas del negocio, usuario y organización de
soporte de TI
■■ Monitorización y análisis de tendencias de
la disponibilidad, fiabilidad y capacidad de
mantenimiento de los componentes de TI
■■ Revisar la disponibilidad del componente y servicio de
TI e identificar niveles inaceptables
■■ Investigar las razones subyacentes para una
disponibilidad inaceptable
■■ Generar y mantener un Plan de Disponibilidad que
priorice y planifique mejoras de disponibilidad de TI.
4.4.5 Actividades, métodos y técnicas del
proceso
El proceso Gestión de la Disponibilidad depende en gran
medida de la medición de los logros del servicio y del
componente en relación con la disponibilidad.
Mensajes clave
‘Si no lo mides, no puedes gestionarlo’.
‘Si no lo mides, no puedes mejorarlo’.
‘Si no lo mides, probablemente no te importa’.
‘Si no puedes influir o controlarlo, entonces no lo
midas’.
‘Qué medir y cómo transmitirlo’ depende inevitablemente
de la actividad a la que se está dando apoyo, quienes
sean los receptores y cómo se utilizará la información.
Es importante reconocer las diferentes perspectivas de
disponibilidad para garantizar que la medida e informes
satisfagan estas necesidades:
■■ La perspectiva del negocio considera la disponibilidad
del servicio de TI en términos de su contribución o
impacto en las VBF que impulsan la operación de
negocio.
■■ La perspectiva del usuario considera la disponibilidad
del servicio de TI como una combinación de tres
factores, concretamente, la frecuencia, la duración y
el ámbito del impacto, es decir, todos los usuarios,
algunos usuarios, todas las funciones del negocio
22/1/10 13:49:35

o ciertas funciones del negocio. El usuario también
considera la disponibilidad del servicio de TI en
términos de tiempos de respuesta. Para muchas
aplicaciones centradas en el rendimiento, los tiempos
de respuesta deficientes se consideran iguales en
impacto a los fallos de tecnología.
■■ La perspectiva del proveedor de servicios de TI
considera la disponibilidad del componente y del
servicio de TI en relación con la disponibilidad,
fiabilidad y capacidad de mantenimiento.
Para satisfacer las diferentes perspectivas de disponibilidad,
es necesario que Gestión de la Disponibilidad considere el
espectro de medidas necesarias para informar del ‘mismo’
nivel de disponibilidad de formas diferentes. Es necesario
que las medidas sean significativas y añadan valor si la
medida e informes de disponibilidad tienen el objetivo
final de beneficiar a las organizaciones de TI y del negocio.
Esto está influenciado ampliamente por la combinación de
‘qué medir’ y ‘cómo informar de ello’.
4.4.5.1  Las actividades reactivas de Gestión de
la Disponibilidad
Monitorizar, medir, analizar e informar de la
disponibilidad del servicio y componente
Una salida clave del proceso Gestión de la Disponibilidad
es la medida e información de la disponibilidad de TI. Las
medidas de disponibilidad deben incorporarse en SLAs,
OLAs y en cualquier contrato de soporte. Éstas deben
revisarse regularmente en reuniones de revisión del
Nivel de Servicio. Las medidas y generación de informes
proporcionan la base para:
■■ Monitorizar la disponibilidad real entregada con
respecto a los objetivos acordados
■■ Establecer medidas de disponibilidad y acordar
objetivos de disponibilidad con el negocio
■■ Identificar niveles inaceptables de disponibilidad que
impacten en el negocio y en los usuarios
■■ Revisar la disponibilidad con la organización de
soporte de TI
■■ Actividades de mejora continua para optimizar la
disponibilidad.
Las organizaciones de los proveedores de servicios de TI
han medido e informado durante muchos años basándose
en su perspectiva de la disponibilidad. Tradicionalmente,
estas medidas se han concentrado en la disponibilidad del
componente y se han separado un poco de los puntos
de vista del negocio y del usuario. Normalmente, estas
medidas tradicionales se basan en una combinación de
un porcentaje de disponibilidad (%), tiempo perdido, y
824_005 Chapter 04.indd 111
Procesos de Diseñ̃o del Servicio | 111
frecuencia del fallo. A continuación se incluyen algunos
ejemplos de estas medidas tradicionales:
■■ Porcentaje de disponibilidad – la medida real
‘tradicional’ que representa la disponibilidad como
un porcentaje y, como tal, mucho más útil como
medida de la disponibilidad de un componente que la
medida de disponibilidad de un servicio. Normalmente
se utiliza para rastrear e informar de los logros con
respecto al objetivo de nivel de servicio. Tiende a
enfatizar el ‘número grande’ para que si el objetivo
de nivel de servicio fuera el 98,5% y el logro fuera el
98,3%, no parezca tan negativo. Esto puede motivar
un comportamiento complaciente dentro de la
organización de soporte de TI.
■■ Porcentaje de indisponibilidad – lo contrario a
lo anterior. Sin embargo, esta representación tiene
el beneficio de centrarse en la indisponibilidad.
Basándonos en el ejemplo anterior, si el objetivo
para la indisponibilidad fuera del 1,5% y el logro
fuera del 1,7%, entonces ésta es una diferencia
relativa mucho mayor. Este método de información
tiene más probabilidades de crear concienciación
de las deficiencias a la hora de entregar el nivel de
disponibilidad requerido.
■■ Duración – se logra convirtiendo el porcentaje de
indisponibilidad en horas y minutos. Esto proporciona
una medida más ‘humana’ con la que se pueden
asociar las personas. Si el objetivo del tiempo de
caída semanal fuera de dos horas, pero una semana
el tiempo de caída real fue de cuatro horas, esto
representaría una tendencia que conduciría a cuatro
días adicionales de indisponibilidad para el negocio
durante un año completo. Este tipo de medida e
informes tiene más probabilidades de motivar que se
ponga el foco en la mejora del servicio.
■■ Frecuencia del fallo – utilizado para registrar el
número de interrupciones para el servicio de TI. Ayuda
a proporcionar una buena indicación de la fiabilidad
desde una perspectiva de usuario. Se utiliza mejor en
combinación con la ‘duración’ para lograr una visión
equilibrada del nivel de las interrupciones del servicio
y de la duración del tiempo perdido para el negocio.
■■ Impacto del fallo – esta es la medida real de la
indisponibilidad del servicio. Depende de la madurez
de la incidencia registrando si la incapacidad de los
usuarios para realizar sus tareas de negocio es la parte
más importante de la información capturada. Todas las
demás medidas se enfrentan a una posible ocultación
de los efectos reales del fallo del servicio y con
frecuencia se convierten en un impacto financiero.
22/1/10 13:49:35
 112 | Procesos de Diseñ̃o del Servicio
El negocio puede haber aceptado, durante muchos años,
que la disponibilidad de TI que perciben se represente en
términos de disponibilidad del componente en lugar de
disponibilidad de todo el servicio o negocio. Sin embargo,
esto ya no se está viendo como aceptable y el negocio está
intentando representar mejor la disponibilidad en medidas
que demuestren las consecuencias positivas y negativas de
la disponibilidad de TI en sus usuarios y negocio.
Mensajes clave
Las medidas más importantes de la disponibilidad son
aquellas que reflejan y miden la disponibilidad desde
la perspectiva del negocio y del usuario.
Es necesario que Gestión de la Disponibilidad
considere la disponibilidad desde la perspectiva
del negocio/proveedor de servicios de TI y desde
la perspectiva de un componente de TI. Éstas son
aspectos completamente diferentes, y aunque el
concepto subyacente es similar, la medida, el enfoque
y el impacto son completamente diferentes.
El rol propuesto para generar estas medidas e informes de
disponibilidad, incluyendo aquellos desde la perspectiva
del negocio, es el de mejorar la calidad y disponibilidad
del servicio de TI proporcionado al negocio y usuarios.
Todas las medidas, informes y actividades deben reflejar
este propósito.
La disponibilidad, cuando se mide y se transmite para
reflejar la experiencia del usuario, proporciona una visión
más representativa sobre la calidad de todo el servicio
de TI. La visión del usuario de la disponibilidad está
influenciada por tres factores:
■■ Frecuencia del tiempo de caída
■■ Duración del tiempo de caída
■■ Ámbito del impacto.
Por lo tanto, las medidas e información de la
disponibilidad del usuario deben adoptar estos factores. La
metodología empleada para reflejar la disponibilidad del
usuario podría considerar dos métodos:
■■ Impacto por minutos perdidos del usuario: se
basará en los cálculos sobre la duración del tiempo
de caída multiplicado por el número de usuarios
afectados. Puede ser la base para informar de la
disponibilidad como productividad perdida del
usuario, o para calcular el porcentaje de disponibilidad
desde la perspectiva del usuario, y también
puede incluir los costes de recuperación para la
productividad perdida (por ejemplo, aumento de
pagos por horas extras).
824_005 Chapter 04.indd 112
■■ Impacto por la transacción del negocio: se basará
en los cálculos sobre el número de transacciones
de negocio que no se pudieron procesar durante el
periodo de tiempo de caída. Esto proporciona una
mejor indicación del impacto en el negocio que refleje
los diferentes perfiles de procesamiento de transacción
durante el día, semana, etc. En muchas ocasiones,
el impacto en el usuario podría asociarse con una
VBF, por ejemplo, si el usuario recibiera órdenes de
compra del cliente y una VBF fuera ventas al cliente.
Esta medida será la base para reflejar el impacto en la
operación del negocio y en el usuario.
El método empleado debería estar influenciado por la
naturaleza de las operaciones de negocio. Una operación
de negocio que da soporte a la actividad de entrada de
datos es idónea para generar informes que reflejen la
pérdida de productividad del usuario. Las operaciones
de negocio que más se enfrentan al cliente, por ejemplo,
servicios ATM, se benefician de los informes del impacto
de las transacciones. También es necesario tener en
cuenta que no todo el impacto en el negocio se asocia
con el usuario. Con el aumento de la automatización y
del procesamiento electrónico, la capacidad para procesar
transacciones automatizadas o para cumplir los tiempos
requeridos por el mercado también puede tener un gran
impacto financiero que podría ser mayor que el aumento
de la capacidad de los usuarios a la hora de operar.
Es necesario que la organización de soporte de TI sea
plenamente consciente de la experiencia del usuario con
respecto a la disponibilidad. Sin embargo, los beneficios
reales se obtienen al añadir la visión del usuario a la
visión general del negocio. Un principio de guía del
proceso Gestión de la Disponibilidad es que ‘La mejora
de la disponibilidad sólo puede comenzar cuando se
entiende la tecnología que da soporte al negocio’.
Por lo tanto, Gestión de la Disponibilidad no sólo consiste
en entender la disponibilidad de cada componente de
TI, sino que consiste en entender todos los aspectos del
impacto del fallo del componente en la disponibilidad del
servicio y del usuario. Desde la perspectiva del negocio, un
servicio de TI sólo se puede considerar que está disponible
cuando el negocio es capaz de realizar todas las funciones
vitales requeridas para permitir la operación de negocio.
Para que el servicio de TI esté disponible, debe confiar en
que todos los componentes en los que se basa el servicio
estén disponibles, es decir, sistemas, componentes clave,
red, datos y aplicaciones.
El método tradicional de TI sería medir individualmente
la disponibilidad de cada uno de estos componentes. Sin
embargo, la medida real de la disponibilidad tiene que
basarse en los impactos positivos y negativos en las VBFs
22/1/10 13:49:35

sobre las que dependerá la operación de negocio. Este
método asegura que los informes sobre la disponibilidad
de TI y SLAs se basen en medidas que entiendan el
negocio y TI. Midiendo las VBF que se basan en servicios
de TI, las medidas e informes pasan a estar dirigidos por
el negocio, reflejando las consecuencias del impacto
del fallo en el negocio. También es importante que la
disponibilidad de los servios se defina y acuerde con el
negocio y se refleje dentro de SLAs. Esta definición de
disponibilidad debe incluir:
■■ ¿Cuál es el nivel mínimo disponible de funcionalidad
del servicio?
■■ ¿A qué nivel de respuesta del servicio se considera
que el servicio no está disponible?
■■ ¿Dónde se medirá este nivel de funcionalidad y
respuesta?
■■ ¿Cuáles son los valores específicos relativos para la
indisponibilidad parcial del servicio?
■■ Si se viera afectada una ubicación u oficina, ¿todo
el servicio se considera indisponible, o se considera
‘parcialmente indisponible’? Esto es necesario
acordarlo con los clientes.
Se requieren herramientas de generación de informes
y análisis para el manejo de los datos almacenados
en las diferentes bases de datos utilizadas por Gestión
de la Disponibilidad. Estas herramientas pueden estar
basadas en plataformas o en PCs y con frecuencia son
una combinación de las dos. Esto estará influenciado
por las tecnologías seleccionadas de repositorios de
bases de datos y por la complejidad del procesamiento y
generación de informes de los datos. Será necesario que
Gestión de la Disponibilidad, una vez implementada y
desplegada, genere informes regulares de forma acordada,
por ejemplo, informes mensuales de disponibilidad, Plan
de Disponibilidad, Análisis de fallos del servicio (SFA),
informes de estado, etc. Las actividades implicadas dentro
de estas actividades de generación de informes pueden
requerir mucho más esfuerzo manual y la única solución
sería automatizar lo máximo posible la actividad de
generación de informes. Para la generación de informes,
se deben utilizar, siempre que sea posible, estándares
organizativos de generación de los mismos. Si éstos no
existieran, deben desarrollarse estándares de TI para que
se puedan elaborar estos informes utilizando herramientas
y técnicas estándar. Esto significa que será mucho más
fácil lograr la integración y consolidación de los informes.
Análisis de indisponibilidad
Deben investigarse todos los eventos e incidencias que
provocan indisponibilidad de los servicios y componentes,
con las acciones correctivas que se están implementando
824_005 Chapter 04.indd 113
Procesos de Diseñ̃o del Servicio | 113
dentro del Plan de Disponibilidad o en el SIP general.
Deben generarse tendencias a partir de este análisis para
dirigir y enfocar actividades, como por ejemplo Análisis de
fallos del servicio (SFA), en aquellas áreas que provocan
el mayor impacto o interrupción en el negocio y en los
usuarios.
Los costes generales de un servicio de TI están
influenciados por los niveles de disponibilidad requeridos
y por las inversiones requeridas en la tecnología y servicios
proporcionados por la organización de soporte de TI
para cumplir sus requisitos. Obviamente la disponibilidad
no es gratis. Sin embargo, es importante reflejar que la
indisponibilidad de TI también tiene un coste, por lo
que la indisponibilidad tampoco es gratuita. Para VBFs
y procesos de negocio extremadamente críticos, es
necesario considerar no sólo el coste de suministrar el
servicio, sino también los costes en los que se incurre a
partir de un fallo. El equilibrio óptimo es el coste de la
solución de disponibilidad ponderado con respecto a los
costes de indisponibilidad.
Antes de aceptar cualquier SLR, y de negociar y acordar
en última instancia el SLR o SLA entre el negocio y la
organización de TI, es fundamental que se analicen los
requisitos de disponibilidad del negocio para evaluar
si/cómo el servicio de TI puede entregar los niveles
requeridos de disponibilidad. Esto se aplica no sólo a
servicios de TI nuevos que se están introduciendo, sino
también a cualquier cambio requerido para los requisitos
de disponibilidad de servicios de TI existentes.
El coste de un fallo de TI podría expresarse simplemente
como el número de transacciones del negocio o de TI
que se ven afectadas, ya sea como una cifra real (derivada
de la instrumentación) o en función de una estimación.
Cuando se miden nuevamente las VBFs que dan soporte
a la operación de negocio, esto puede proporcionar una
indicación obvia de la consecuencia del fallo. La ventaja
de este método es la relativa facilidad de obtener los
datos del impacto y la ausencia de cualquier cálculo
complejo. También pasa a ser un ‘valor’ que lo entiende la
organización de TI y el negocio. Esto puede representar el
estímulo para identificar oportunidades de mejora y puede
convertirse en una métrica clave en la monitorización de
la disponibilidad de los servicios de TI.
La principal desventaja de este método es que no ofrece
un valor crematístico obvio que se podría necesitar
para justificar cualquier decisión de inversión financiera
significativa para mejorar la disponibilidad. Cuando se
requiere tomar decisiones decisivas de inversión financiera,
es mejor expresar ante el negocio el coste del fallo que
22/1/10 13:49:35
 114 | Procesos de Diseñ̃o del Servicio
surja de la pérdida del servicio, sistema, aplicación o
función como un ‘valor’ crematístico o monetario.
El valor monetario se puede calcular como una
combinación de costes tangibles asociados con el fallo,
pero también puede incluir varios costes intangibles. El
valor monetario también debe reflejar el impacto del coste
en toda la organización, es decir, en el negocio y en la
organización de TI.
Los costes tangibles pueden incluir:
■■ Productividad perdida del usuario
■■ Productividad perdida del personal de TI
■■ Ingresos perdidos
■■ Pagos adicionales
■■ Material y bienes desaprovechados
■■ Pagos por penalizaciones o multas impuestas.
El área financiera del negocio y de la organización de TI
normalmente entiende bien estos costes, y en términos
relativos son más fáciles de obtener y añadir que los
costes intangibles asociados con un fallo de TI.
Los costes intangibles pueden incluir:
■■ Pérdida de clientes
■■ Pérdida del fondo de comercio del cliente (satisfacción
del cliente)
■■ Pérdida de oportunidades de negocio (para vender,
ganar nuevos clientes o ingresos, etc).
■■ Daños en la reputación del negocio
■■ Pérdida de confianza en el proveedor de servicios de
TI
■■ Daños en la moral del personal.
Es importante no limitarse únicamente a descartar
los costes intangibles (y las posibles consecuencias)
sobre la base de que podrían ser difíciles de medir. La
indisponibilidad general del servicio, el coste tangible
total y los costes intangibles totales que surgen de la
indisponibilidad del servicio, son todas las métricas clave
en la medida de la eficacia del proceso Gestión de la
Disponibilidad.
El ciclo de vida expandido de la incidencia
Un principio de guía de Gestión de la Disponibilidad es
reconocer que todavía es posible lograr la satisfacción
del cliente incluso cuando las cosas van mal. Un método
para ayudar a lograr esto requiere que Gestión de la
Disponibilidad garantice que se minimice la duración de
cualquier incidencia para permitir que las operaciones de
servicio normales se reinicien lo más rápidamente posible.
Un objetivo de Gestión de la Disponibilidad es garantizar
que se minimice la duración e impacto de las incidencias
824_005 Chapter 04.indd 114
que impactan en servicios de TI, para permitir que las
operaciones de negocio se reinicien lo más rápidamente
posible. El análisis del ‘ciclo de vida expandido de la
incidencia’ permite descomponer el tiempo de caída
total del servicio de TI para cualquier incidencia y hacerlo
corresponder con las etapas principales a través de las
que progresan todas las incidencias (el ciclo de vida).
Gestión de la Disponibilidad debe trabajar estrechamente
con Gestión de Incidencias y Gestión de Problemas
en el análisis de todas las incidencias que provocan
indisponibilidad.
Una buena técnica para colaborar en el análisis técnico
de las incidencias que afectan a la disponibilidad de los
componentes y servicios de TI, es disponer de una visión
del ‘ciclo de vida’ de la incidencia. Cada incidencia pasa a
través de varias etapas principales. El tiempo transcurrido
en estas etapas podría variar considerablemente. Para
propósitos de Gestión de la Disponibilidad, el ‘ciclo de
vida’ estándar de la incidencia, como se describe en
Gestión de Incidencias, se ha ampliado para proporcionar
ayuda y guía adicional particularmente en el área de
‘diseño para la recuperación’. La Figura 4.15 ilustra el ciclo
de vida expandido de la incidencia
A partir de lo expuesto anteriormente se puede ver
que una incidencia se puede descomponer en etapas
individuales dentro de un ciclo de vida que puede ser
dividido por tiempos y medido. Esta visión del ciclo de
vida proporciona un marco de trabajo importante a la
hora de determinar, entre otros, requisitos de gestión
de sistemas para la detección de eventos e incidencias,
requisitos de captura de datos de diagnóstico y
herramientas para el diagnóstico, planes de recuperación
para lograr una recuperación rápida y cómo verificar
que se ha restaurado el servicio de TI. A continuación se
tratarán con más detalle las etapas individuales del ciclo
de vida.
■■ Detección de incidencias: el momento en el que
la organización del proveedor de servicios de TI es
consciente de una incidencia. Las herramientas de
gestión de sistemas influyen positivamente en la
capacidad de detectar eventos e incidencias y por lo
tanto mejoran los niveles de disponibilidad que se
pueden entregar. La implementación y explotación
deben centrarse en lograr una alta disponibilidad y
mejorar los objetivos de recuperación. En el contexto
de recuperación, tales herramientas deben explotarse
para proporcionar una detección automatizada de
fallos, ayudar en el diagnóstico de fallos y dar soporte
a la recuperación automatizada de errores, con
respuestas programadas. Las herramientas son muy
importantes a la hora de reducir todas las etapas del
22/1/10 13:49:36

Inicio de
incidencia
Tiempo
disponible
Servicio
disponible
Tiempo de caída (tiempo
de restauración)(MTRS)
Servicio no disponible
Disponibilidad
Diagnosticar Recuperar
Detectar Reparar
Restaurar
Tiempo entre incidencias del sistema
Tiempo
Figura 4.15  El ciclo de vida expandido de la incidencia
ciclo de vida de las incidencias, pero principalmente
para la detección de eventos e incidencias. Idealmente,
el evento se detecta y resuelve automáticamente antes
de que los usuarios tengan constancia del mismo o se
hayan visto afectados de alguna forma.
■■ Diagnóstico de incidencias: el momento en el que
se ha completado el diagnóstico para determinar la
causa subyacente. Cuando los componentes de TI
fallan, es importante que se obtenga el nivel requerido
de diagnóstico para permitir determinar el problema
e identificar la causa raíz y resolver el problema. El
uso y capacidad de las herramientas y habilidades
de diagnóstico son críticos para lograr una rápida
resolución de los problemas del servicio. Para ciertos
fallos, la obtención de diagnósticos podría ampliar
el tiempo de caída del servicio. Sin embargo, la falta
de obtención de los diagnósticos apropiados crea y
expone al servicio a fallos repetitivos. Si el tiempo
requerido para hacer el diagnóstico se considerara
excesivo, o variara con respecto al objetivo, deberá
impulsarse una revisión para identificar si las técnicas
y/o procedimientos se pueden simplificar para reducir
el tiempo requerido. De igual forma, el ámbito de los
datos disponibles para la obtención del diagnóstico
puede evaluarse para garantizar que sólo se tomen
824_005 Chapter 04.indd 115
Procesos de Diseñ̃o del Servicio | 115
Inicio de Inicio de
incidencia incidencia
Tiempo Tiempo disponible
disponible (disponibilidad)
Servicio Servicio
disponible disponible
Tiempo de
caída
Disponi-
bilidad Servicio no
disponible
Tiempo entre fallos (MTBF)
los datos de diagnóstico considerados como
fundamentales. El tiempo de caída adicional requerido
para obtener los diagnósticos debe incluirse en las
métricas de recuperación documentadas para cada
componente de TI.
■■ Reparación de incidencias: el momento en el
que el fallo se ha reparado/arreglado. Los tiempos
de reparación de incidencias deben monitorizarse
y compararse continuamente con respecto a los
objetivos acordados incluidos en OLAs, contratos de
soporte y otros acuerdos. Esto es particularmente
importante con respecto al rendimiento de
los servicios suministrados externamente y
del suministrador. Siempre que se observen
incumplimientos, deben utilizarse técnicas para reducir
o eliminar incumplimientos de incidencias similares
que se produzcan en el futuro.
■■ Recuperación de incidencias: el momento en el que
se ha completado la recuperación del componente.
Los requisitos de backup y de recuperación para los
componentes que apoyan a un servicio de TI nuevo,
deben identificarse lo antes posible dentro del ciclo
de diseño. Estos requisitos deben incluir el hardware,
software, datos y objetivos de recuperación. La salida
de esta actividad debe ser un conjunto documentado
22/1/10 13:49:36
 116 | Procesos de Diseñ̃o del Servicio
de requisitos de recuperación que permita el
desarrollo de planes de recuperación apropiados. Para
anticiparse y prepararse para la recuperación de tal
forma que el restablecimiento del servicio sea eficaz
y eficiente, se requiere el desarrollo y prueba de
planes de recuperación apropiados en función de los
requisitos documentados de recuperación. Siempre
que sea posible, las actividades operativas incluidas en
el plan de recuperación deben estar automatizadas.
La prueba de los planes de recuperación también
ofrece tiempos aproximados para la recuperación. Se
pueden utilizar estas métricas de recuperación para
dar soporte a la comunicación de la recuperación
estimada del servicio y para validar o mejorar la
documentación del Análisis de Impacto del Fallo
del Componente. Gestión de la Disponibilidad debe
buscar y promover continuamente métodos más
rápidos de recuperación para todas las posibles
incidencias. Esto se puede lograr a través de una
gama de métodos, incluyendo detección automatizada
de fallos, recuperación automatizada, procedimientos
de escalado más estrictos, explotación de herramientas
y técnicas de recuperación nuevas y más rápidas.
Los requisitos de disponibilidad también deben
contribuir a determinar qué piezas de repuesto se
deben considerar Repuestos Definitivos para facilitar
reparaciones rápidas y eficaces, como se describe en la
publicación Transición del Servicio.
■■ Restauración después de una incidencia: el
momento en el que se reinicia el servicio de negocio
normal. Una incidencia sólo se puede considerar
‘cerrada’ cuando el servicio se haya restaurado y se
haya iniciado la operación normal del negocio. Es
importante verificar que el servicio de TI restaurado
está funcionando correctamente tan pronto como
se complete la restauración del servicio y antes de
que se retire el personal técnico implicado en la
incidencia. En la mayoría de las situaciones, esto es
simplemente un caso de obtención de la confirmación
de los usuarios afectados. Sin embargo, los usuarios
de algunos servicios podrían ser clientes del negocio,
es decir, servicios ATM, servicios basados en Internet.
Para estos tipos de servicios, se recomienda desarrollar
procedimientos de verificación del servicio de TI para
permitir que la organización del proveedor de servicios
de TI verifique que el servicio de TI restablecido está
ahora funcionando como se espera. Éstos podrían ser
simplemente comprobaciones visuales del rendimiento
de la transacción o scripts de simulación del usuario
que validen el servicio extremo a extremo.
Cada etapa, y el tiempo asociado, influye en el tiempo de
caída total percibido por el usuario. Con este método, es
824_005 Chapter 04.indd 116
posible ver dónde se está ‘perdiendo’ tiempo durante el
transcurso de una incidencia. Por ejemplo, el servicio no
estaba disponible para el negocio durante 60 minutos,
aunque sólo se tardan cinco minutos en aplicar una
solución, por lo que la pregunta es, ¿de dónde proceden
los otros 55 minutos?
Con este método se identifican las áreas posibles de
ineficiencia que se combinan para hacer que la pérdida
experimentada del servicio por parte del negocio sea
mayor de la que debería ser. Éstos métodos podrían cubrir
áreas que tienen una automatización deficiente (alertas,
recuperación automatizada, etc.), herramientas y scripts de
diagnóstico deficientes, procedimientos de escalado poco
claros (que retardan el escalado hasta el suministrador
o grupo de soporte técnico apropiado), o la falta de
documentación operativa global. Es necesario que Gestión
de la Disponibilidad trabaje estrechamente con Gestión
de Problemas e Incidencias para garantizar la eliminación
de ocurrencias repetidas. Se recomienda establecer
y capturar estas medidas para todas las incidencias
asociadas con la disponibilidad. Esto proporciona a
Gestión de la Disponibilidad métricas para incidencias
específicas e información de tendencias. Esta información
se puede utilizar como entrada a asignaciones del SFA,
actividades del SIP e informes regulares de Gestión de la
Disponibilidad, y para proporcionar un impulso para que
la actividad de mejora continua persiga mejoras rentables.
También puede permitir establecer objetivos para etapas
específicas del ciclo de vida de la incidencia. Aceptando
que cada incidencia podría tener un nivel determinado
de complejidad técnica, los objetivos se pueden utilizar
para reflejar la consistencia de cómo la organización del
proveedor de servicios de TI responde a las incidencias.
Una salida del proceso de Gestión de la Disponibilidad
consiste en los requisitos de monitorización en tiempo
real para componentes y servicios de TI. Para lograr los
niveles de disponibilidad requeridos y/o para garantizar la
rápida reparación del servicio después de un fallo de TI,
se requiere la inversión y explotación de un conjunto de
herramientas de gestión de sistemas. Las herramientas de
gestión de sistemas forman un bloque de construcción
fundamental para servicios de TI que requieren un
alto nivel de disponibilidad y pueden proporcionar
un rol inestimable a la hora de reducir la cantidad de
tiempo de caída en el que se incurre. Los requisitos
de Gestión de la Disponibilidad incluyen la detección
y alerta de excepciones del componente y servicio de
TI, el escalado automático y la notificación de fallos de
TI, y la recuperación y restauración automatizadas de
componentes a partir de situaciones conocidas de fallo
de TI. Esto hace posible identificar si se está perdiendo
22/1/10 13:49:36

tiempo y proporciona la base para la identificación de
factores que pueden mejorar los tiempos de recuperación
y restauración. Estas actividades se realizan habitualmente
en Operación del Servicio.
Análisis de fallos del servicio
Análisis de fallos del servicio (SFA) es una técnica diseñada
para proporcionar un método estructurado con el que
identificar las causas subyacentes de las interrupciones
del servicio en el usuario. SFA utiliza un rango de fuentes
de datos para evaluar dónde y por qué se producen
deficiencias en la disponibilidad. SFA permite una vista
integral que se tomará para impulsar no sólo las mejoras
tecnológicas, sino también las mejoras en la organización
de soporte de TI, procesos, procedimientos y herramientas.
SFA se ejecuta como una asignación o proyecto, y
podría utilizar otros métodos y técnicas de Gestión de
la Disponibilidad para formular las recomendaciones
para la mejora. El análisis detallado de las interrupciones
del servicio puede identificar oportunidades para
mejorar los niveles de disponibilidad. SFA es una técnica
estructurada para identificar oportunidades de mejora
en la disponibilidad del servicio extremo a extremo
que pueden proporcionar beneficios al usuario. Muchas
de las actividades involucradas en el SFA se alinean
estrechamente con las de Gestión de Problemas, y
en varias organizaciones estas actividades se realizan
conjuntamente por Gestión de la Disponibilidad y Gestión
de Problemas.
Los objetivos de alto nivel del SFA son:
■■ Mejorar la disponibilidad general de los servicios
de TI logrando un conjunto de mejoras para
la implementación o entrada en el Plan de
Disponibilidad
■■ Identificar las causas subyacentes de la interrupción
del servicio de los usuarios
■■ Evaluar la eficacia de la organización de soporte de TI
y de los procesos clave
■■ Generar informes que detallen las conclusiones y
recomendaciones principales
■■ Que se midan las mejoras de la disponibilidad
derivadas de actividades dirigidas por SFA.
Las iniciativas del SFA deben utilizar entradas procedentes
de todas las áreas y procesos incluyendo las del negocio
y de los usuarios. Cada asignación del SFA debe tener
patrocinadores reconocidos (idealmente, patrocinio
conjunto de TI y del negocio) e implicar recursos de
muchas áreas técnicas y de proceso. El uso del método SFA:
■■ Proporciona la capacidad de entregar niveles
mejorados de disponibilidad sin costes importantes
824_005 Chapter 04.indd 117
Procesos de Diseñ̃o del Servicio | 117
■■ Proporciona al negocio un compromiso visible desde
la organización de soporte de TI
■■ Desarrolla habilidades y competencias internas para
evitar gastos de consultoría elevados asociados con la
mejora de la disponibilidad
■■ Motiva al equipo interdisciplinar y rompe barreras
entre equipos, y es un facilitador del pensamiento
divergente, desafiando los conceptos tradicionales
y proporcionando soluciones innovadoras y con
frecuencia poco caras
■■ Proporciona un programa de oportunidades de mejora
que pueda hacer realidad la diferencia con respecto a
la calidad del servicio y la percepción del usuario
■■ Proporciona oportunidades que se centran en la
entrega de beneficio al usuario
■■ Proporciona una ‘comprobación de estado’ de los
procesos de Gestión del Servicio de TI y es el estímulo
para lograr mejoras del proceso.
Para maximizar el tiempo del personal asignado a la tarea
del SFA y la calidad del informe entregado, se requiere
un método estructurado. Esta estructura se ilustra en la
Figura 4.16. Este método es similar a muchos modelos
de consultoría utilizados en la industria, y en muchos
aspectos Gestión de la Disponibilidad se puede considerar
como una forma de consultoría interna proporcionada por
el SFA.
A continuación se describe brevemente la estructura
anterior de alto nivel.
Seleccionar oportunidad
Asignación de ámbito
Asignación del plan
Construir hipótesis
Analizar datos clave
Entrevistar a personal clave
Hallazgos y conclusiones
Recomendaciones
Informe
Validación
Tiempo
Figura 4.16  El método estructurado para el Análisis de
fallos del servicio (SFA)
22/1/10 13:49:36
 118 | Procesos de Diseñ̃o del Servicio
■■ Seleccionar oportunidad: antes de programar una
asignación del SFA, es necesario que haya un acuerdo
con el que se seleccionará el servicio de TI o la
tecnología. Se recomienda que se programen al año
un número acordado de asignaciones dentro del Plan
de Disponibilidad y, si fuera posible, se seleccionen
los servicios de TI anticipadamente como parte del
método proactivo para Gestión de la Disponibilidad.
Antes de comenzar con el SFA, es importante que la
asignación tenga un patrocinador reconocido desde
dentro de la organización de TI y/o el negocio, y
que se impliquen y se actualicen regularmente con
el progreso de la actividad del SFA. Esto garantiza la
visibilidad organizativa para el SFA y asegura que las
recomendaciones estén respaldadas en un nivel senior
dentro de la organización.
■■ Asignación del ámbito: consiste en establecer las
áreas que se incluyen o que no se incluyen dentro
de la asignación. Esto normalmente se documenta en
los Términos de referencia presentados antes de la
asignación.
■■ Asignación del plan: es necesario planificar la
asignación del SFA con varias semanas de anticipación
antes de que comience la asignación, con un
plan de proyecto acordado y con un conjunto de
recursos comprometidos. El proyecto debe buscar
la identificación de oportunidades de mejora que
beneficien al usuario. Por lo tanto, es importante
obtener una visión extremo a extremo de los datos y
de los requisitos del Sistema de Información de Gestión
(MIS). Los datos y la documentación deben recopilarse
de todas las áreas y ser analizados desde la perspectiva
del usuario y del negocio. Debe formarse un equipo
de SFA ‘virtual’ a partir de todas las áreas relevantes
para asegurar que se consideren todos los aspectos
y perspectivas. El tamaño del equipo debe reflejar el
ámbito y la complejidad de la asignación del SFA.
■■ Construir hipótesis: este es un método útil para
construir escenarios probables que puedan ayudar al
equipo de estudio a extraer conclusiones anticipadas
dentro del periodo de análisis. Estos escenarios pueden
construirse a partir del análisis de la futura asignación
con roles clave, por ejemplo, gestión senior y usuarios,
o utilizando la sesión de planificación para obtener
una lista del equipo constituido. La lista completa
de hipótesis debe documentarse e introducirse en el
periodo de análisis para proporcionar algún enfoque
anticipado sobre los datos y el Sistema de Información
de Gestión (MIS) que se correspondan con los
escenarios individuales. Debe tenerse en cuenta que
este método también elimina problemas percibidos,
es decir, ningún dato o MIS respalda lo que se percibe
que es un problema del servicio.
824_005 Chapter 04.indd 118
■■ Analizar datos: el número de individuos que
forman el equipo del SFA dicta cómo asignar
responsabilidades específicas de análisis. Durante este
periodo de análisis, la lista de hipótesis debe utilizarse
para ayudar a llegar anticipadamente a algunas
conclusiones.
■■ Entrevistar a personal clave: es fundamental
entrevistar a los representantes clave del negocio
y a los usuarios para garantizar que se capturen
las perspectivas del negocio y de los usuarios. Es
sorprendente cómo con este diálogo se pueden
identificar rápidamente oportunidades, ya que con
frecuencia lo que ve el negocio como un gran
problema puede abordarse mediante una simple
solución de TI. Por lo tanto, estas entrevistas deben
iniciarse lo antes posible dentro de la asignación
del SFA. El equipo de estudio también debe buscar
la entrada procedente de individuos clave dentro
de la organización del proveedor de servicios de TI
para identificar áreas problemáticas adicionales y las
soluciones posibles que se pueden ofrecer al equipo de
estudio. El diálogo también ayuda a capturar aquellos
problemas que no son visibles fácilmente a partir de
los datos agrupados y de los informes del MIS.
■■ Hallazgos y conclusiones: después del análisis de los
datos y del MIS proporcionado, de las entrevistas y de
la revisión continua de la lista de hipótesis, el equipo
de estudio debe estar en posición de comenzar a
documentar los hallazgos y conclusiones iniciales. Se
recomienda que el equipo se reúna inmediatamente
después del periodo de análisis para compartir sus
hallazgos individuales y, a continuación, adoptar
una visión conjunta para redactar los hallazgos y
conclusiones iniciales. Es importante que todos los
hallazgos puedan evidenciarse por hechos recopilados
durante el análisis. Durante esta fase de la asignación,
podría ser necesario validar los hallazgos mediante un
análisis adicional para garantizar que el equipo de SFA
pueda respaldar todos los hallazgos con evidencias
documentadas claras.
■■ Recomendaciones: después de que se hayan validado
todos los hallazgos y conclusiones, el equipo del SFA
debe estar en posición de formular recomendaciones.
En muchos casos, las recomendaciones para dar
soporte a un hallazgo particular son directas y
obvias. Sin embargo, el beneficio de ofrecer un
equipo multidisciplinar para la asignación del SFA
es crear un entorno oportuno para métodos de
pensamiento divergente e innovador. El responsable
de la asignación del SFA debe facilitar esta sesión con
el objetivo de identificar recomendaciones que sean
prácticas y sostenibles una vez implementadas.
22/1/10 13:49:36

■■ Informar: el informe final debe enviarse al
patrocinador con un resumen de gestión. Los estilos
de los informes normalmente están determinados
por las organizaciones individuales. Es importante
que el informe muestre claramente dónde se está
produciendo la falta de disponibilidad y cómo abordan
este hecho las recomendaciones. Si el informe incluyera
muchas recomendaciones, debe hacerse un intento
para cuantificar el beneficio para la disponibilidad de
cada recomendación, junto con el esfuerzo estimado
en la implementación. Esto permite aportar alternativas
documentadas sobre cómo aplicar las recomendaciones
y cómo éstas deben priorizarse y provisionarse
■■ Validación: se recomienda que para cada SFA,
se capturen y registren las medidas clave que
reflejen las perspectivas del negocio y del usuario
antes de la asignación, como la visión ‘anterior’.
Cuando progresen las recomendaciones del SFA,
deberán capturarse los impactos positivos sobre la
disponibilidad para proporcionar la visión ‘posterior’
para fines de comparación. Si no se hubieran
entregado beneficios anticipados, debe investigarse
este hecho y adoptar las acciones correctivas
oportunas. Después de haber invertido tiempo y
esfuerzo a la hora de completar la asignación del
SFA, es importante que las recomendaciones, una vez
acordadas por el patrocinador, se lleven adelante para
su implementación. El mejor mecanismo para lograrlo
es incorporar las recomendaciones como actividades
a completar dentro del Plan de Disponibilidad o del
SIP general. El éxito de la asignación del SFA deberá
monitorizarse y medirse para asegurar su continua
eficacia.
Sugerencias y consejos
Considere la categorización de las recomendaciones
bajo los siguientes encabezados:
DETECCIÓN: Recomendaciones que, si se implementan,
proporcionarán mejoras en los indicadores clave
de los informes para garantizar que se detecten
anticipadamente los problemas subyacentes del
servicio de TI que permitan una respuesta proactiva.
REDUCCIÓN: Recomendaciones que, si se implementan,
reducirán o minimizarán el impacto en el usuario
procedente de la interrupción del servicio de TI, por
ejemplo, se pueden mejorar la recuperación y/o
restauración para reducir la duración del impacto.
PREVENCIÓN: Recomendaciones que, si se
implementan, eliminarán esta causa particular de
interrupción del servicio de TI.
824_005 Chapter 04.indd 119
Procesos de Diseñ̃o del Servicio | 119
4.4.5.2  Las actividades proactivas de Gestión de
la Disponibilidad
La capacidad del proceso Gestión de la Disponibilidad
es influida positivamente por la variedad y la calidad
de de las técnicas y métodos proactivos utilizados por
el proceso. Las siguientes actividades representan las
técnicas y actividades proactivas del proceso Gestión de la
Disponibilidad.
Identificación de las Funciones Vitales del
Negocio (VBFs)
El término Función Vital de Negocio (VBF) se utiliza para
reflejar los elementos críticos del proceso de negocio al
que da soporte un servicio de TI. Puede que el servicio
también dé soporte a procesos y funciones críticos del
negocio, y es importante que las VBF se conozcan y
documenten para proporcionar el alineamiento y enfoque
apropiados del negocio.
Diseño para la disponibilidad
El nivel de disponibilidad requerido por el negocio influye
en el coste general del servicio de TI proporcionado. En
general, cuanto más alto sea el nivel de disponibilidad
requerido por el negocio, mayor será el coste. Estos
costes no se corresponden únicamente con la compra de
la tecnología de TI base ni con los servicios requeridos
para apoyar la infraestructura de TI. Se incurren en costes
adicionales para proporcionar los procesos de Gestión del
Servicio, herramientas de gestión de sistemas y soluciones
de alta disponibilidad apropiados requeridos para cumplir
los requisitos de disponibilidad más exigentes. El nivel
Soluciones
especiales
con
redundancia
Diseño de
alta
disponibilidad
Costes
Gestión
eficaz del
servicio
Gestión de
sistemas
Productos, tecnología
y componentes básicos
Disponibilidad
Figura 4.17  Relación entre niveles de disponibilidad y
costes generales
22/1/10 13:49:37
 120 | Procesos de Diseñ̃o del Servicio
de disponibilidad más alto debe incluirse en el diseño de
aquellos servicios que dan soporte a las VBF más críticas.
Al considerar cómo se cumplirán los requisitos de
disponibilidad del negocio, es importante garantizar que
el nivel de disponibilidad que se proporcionará para un
servicio de TI esté en el nivel requerido realmente, y que
sea asequible y justificable en costes para el negocio. La
Figura 4.17 indica los productos y procesos requeridos
para proporcionar diferentes niveles de disponibilidad y las
implicaciones en términos de costes.
Componentes y producto base
La compra o desarrollo de los productos, tecnología y
componentes base debe fundamentarse en su capacidad
a la hora de cumplir requisitos estrictos de disponibilidad
y fiabilidad. Éstos deben considerarse como la piedra
angular del diseño de la disponibilidad. La inversión
adicional requerida para lograr incluso niveles mayores
de disponibilidad se desperdiciará y los niveles de
disponibilidad no se cumplirán si estos productos y
componentes base fueran poco fiables y propensos al
fallo.
Gestión de sistemas
Gestión de sistemas debe proporcionar la monitorización,
diagnóstico y recuperación automatizada de errores para
permitir una rápida detección y resolución de fallos de TI
posibles o reales.
Procesos de Gestión del Servicio
Los procesos eficaces de Gestión del Servicio contribuyen
a lograr mayores niveles de disponibilidad. Procesos como
Gestión de la Disponibilidad, Gestión de Incidencias,
Gestión de Problemas, Gestión de Cambios, Gestión de
la Configuración, etc., desempeñan un rol crucial en la
gestión general del servicio de TI.
Diseño de alta disponibilidad
Es necesario que el diseño para obtener alta disponibilidad
considere la eliminación de SPOFs y/o la provisión de
componentes alternativos para proporcionar la mínima
interrupción en la operación de negocio si se produjera
el fallo de un componente de TI. También es necesario
que el diseño elimine o minimice los efectos de la parada
planificada en la operación de negocio que normalmente
se requiere para adecuar la actividad de mantenimiento, la
implementación de cambios en la infraestructura de TI o
en la aplicación del negocio. Los criterios de recuperación
deben definir la rápida recuperación y restablecimiento
del servicio de TI como un objetivo clave dentro de la fase
de diseño para la recuperación.
824_005 Chapter 04.indd 120
Soluciones especiales con redundancia total
Para alcanzar la disponibilidad continua en el rango
del 100% re requieren soluciones caras que incorporen
una total simetría o redundancia. La redundancia es la
técnica de mejora de la disponibilidad mediante el uso de
componentes duplicados. Para cumplir requisitos estrictos
de disponibilidad, es necesario que éstos funcionen
autónomamente en paralelo. Estas soluciones no sólo
están restringidas a los componentes de TI, sino también
a los entornos de TI, es decir, centros de datos, fuentes de
alimentación, aire acondicionado y telecomunicaciones.
Si se estuvieran desarrollando nuevos servicios de TI, es
esencial que Gestión de la Disponibilidad asuma un rol
de diseño anticipado y participativo para determinar los
requisitos de disponibilidad. Esto permite a Gestión de
la Disponibilidad influir positivamente en el diseño de la
infraestructura de TI para garantizar que pueda entregar el
nivel de disponibilidad requerido. La importancia de esta
participación anticipada en el diseño de la infraestructura
de TI no se puede subestimar. Es necesario que haya
un diálogo entre TI y el negocio para determinar el
equilibrio entre la percepción del negocio del coste de
indisponibilidad y el coste exponencial de la entrega de
niveles mayores de disponibilidad.
Como se ilustra en la Figura 4.17, existe un aumento
significativo de los costes cuando el requisito de negocio
es mayor que el nivel óptimo de disponibilidad que
puede entregar la infraestructura de TI. El aumento de
estos costes está impulsado por el rediseño importante
de la tecnología y por el cambio de los requisitos para la
organización de soporte de TI.
Es importante que el nivel de disponibilidad diseñado en
el servicio sea apropiado para las necesidades del negocio,
para la criticidad de los procesos de negocio a los que se
está dando soporte y para el presupuesto disponible. Se
debe consultar al negocio lo antes posible en el ciclo de
vida de Diseño del Servicio para que se puedan costear
y acordar las necesidades de un servicio de TI nuevo
o mejorado. Esto es particularmente importante si los
requisitos estrictos de disponibilidad pudieran requerir una
inversión adicional en procesos de Gestión del Servicio,
en herramientas de Gestión de Sistemas y del servicio
de TI, en el diseño de alta disponibilidad y en soluciones
especiales con redundancia total.
Es probable que la necesidad del negocio con respecto a
la disponibilidad de TI no se pueda expresar en términos
técnicos. Por lo tanto, Gestión de la Disponibilidad
proporciona un rol importante a la hora de ser capaz
de traducir los requisitos del negocio y del usuario en
objetivos y condiciones cuantificables de la disponibilidad.
22/1/10 13:49:37

Esto es una entrada importante en el Diseño del Servicio
de TI y proporciona la base para evaluar la capacidad del
diseño de TI y de la organización de soporte para cumplir
los requisitos de disponibilidad del negocio.
Los requisitos de negocio para la disponibilidad de TI
deben contener al menos:
■■ Una definición de las VBF a las que da soporte el
servicio de TI
■■ Una definición del tiempo de caída del servicio de
TI, es decir, las condiciones bajo las que el negocio
considera que el servicio de TI no está disponible
■■ El impacto en el negocio provocado por la pérdida de
servicio, junto con el riesgo asociado
■■ Requisitos cuantitativos de disponibilidad, es decir, el
nivel al cual el negocio tolera el tiempo de caída del
servicio de TI o el servicio degradado
■■ Las horas requeridas de servicio, es decir, cuándo se
va a proveer el servicio
■■ Una evaluación de la importancia relativa de los
diferentes periodos de trabajo
■■ Requisitos específicos de seguridad
■■ La capacidad de recuperación y backup del servicio.
Cuando se determinen el diseño de la tecnología de TI
y la organización de soporte de TI, la organización del
proveedor de servicios estará en posición de confirmar
si se pueden cumplir los requisitos de disponibilidad. Si
se identificaran deficiencias, se requiere el diálogo con el
negocio para presentar las opciones de costes que existen
con las que mejorar el diseño propuesto para cumplir los
requisitos de disponibilidad. Esto permite al negocio volver
a evaluar si se requieren niveles de disponibilidad menores
o mayores, y para entender el impacto apropiado y costes
asociados con su decisión.
Es probable que la definición de los requisitos de
disponibilidad sea un proceso iterativo, particularmente
si fuera necesario equilibrar el requisito de disponibilidad
del negocio con respecto a los costes asociados. Los pasos
necesarios son:
■■ Determinar el impacto en el negocio provocado por la
pérdida de servicio
■■ A partir de los requisitos de negocio, especificar los
requisitos de disponibilidad, fiabilidad y capacidad de
mantenimiento para los componentes y el servicio de
TI a los que da soporte la organización de soporte de
TI
■■ Para componentes y servicios de TI suministrados
externamente, identificar los requisitos de capacidad
de servicio
824_005 Chapter 04.indd 121
Procesos de Diseñ̃o del Servicio | 121
■■ Estimar los costes a los que se incurrirá a la hora de
cumplir los requisitos de disponibilidad, fiabilidad,
capacidad de mantenimiento y capacidad de servicio
■■ Determinar, con el negocio, si están justificados los
costes identificados para cumplir los requisitos de
disponibilidad
■■ Determinar, desde el negocio, los costes en los que es
probable que se incurra por la pérdida o degradación
del servicio
■■ Si éstos costes se consideraran justificados, definir en
acuerdos los requisitos de disponibilidad, fiabilidad,
capacidad de mantenimiento y capacidad de servicio y
negociarlos en contratos.
Sugerencias y consejos
Si los costes fueran prohibitivos:
■■ Volver a evaluar el diseño de la infraestructura
de TI y proporcionar opciones para reducir costes
y evaluar las consecuencias con respecto a la
disponibilidad;
■■ Volver a evaluar el uso y confianza del negocio con
respecto al servicio de TI y renegociar los objetivos
de disponibilidad incluidos en el SLA.
El proceso SLM normalmente es responsable de
comunicarse con el negocio sobre cómo se cumplirán sus
requisitos de disponibilidad para los servicios de TI y de
negociar el SLR/SLA para el proceso Diseño del Servicio de
TI. Por lo tanto, Gestión de la Disponibilidad proporciona
un soporte y entrada importantes para los procesos SLM
y de diseño durante este periodo. Aunque en muchas
ocasiones se pueden proporcionar niveles mayores de
disponibilidad mediante la inversión en herramientas
y tecnología, no hay justificación para proporcionar un
nivel mayor de disponibilidad que el que necesita y
suministra el negocio. La realidad es que la satisfacción
de los requisitos de disponibilidad siempre representa un
equilibrio entre coste y calidad. Esto se cumple si Gestión
de la Disponibilidad puede desempeñar un rol clave
en la optimización de la disponibilidad del Diseño del
Servicio de TI para satisfacer el aumento de demanda de
disponibilidad a la vez que se aplaza un incremento de los
costes.
El diseño del servicio con respecto a la disponibilidad
es una actividad clave dirigida por Gestión de la
Disponibilidad. Esto garantiza que se pueda cumplir el
nivel requerido de disponibilidad para un servicio de TI. Es
necesario que Gestión de la Disponibilidad garantice que
la actividad de diseño para la disponibilidad mire la tarea
desde dos perspectivas asociadas, pero distintas:
22/1/10 13:49:37
 122 | Procesos de Diseñ̃o del Servicio
■■ Diseño para la disponibilidad: esta actividad se
asocia con el diseño técnico del servicio de TI y con
el alineamiento de suministradores internos y externos
para cumplir los requisitos de disponibilidad del
negocio. Es necesario incluir todos los aspectos de
la tecnología, incluyendo la infraestructura, entorno,
datos, y aplicaciones.
■■ Diseño para la recuperación: esta actividad se asocia
con los puntos de diseño requeridos para garantizar
que, en caso de fallo de un servicio de TI, el servicio
y sus componentes se puedan restablecer lo más
rápidamente posible para permitir las operaciones de
negocio normales. Nuevamente, es necesario que se
incluyan todos los aspectos de la tecnología.
Adicionalmente, la capacidad para recuperarse
rápidamente podría ser un factor crucial. En términos
sencillos, puede que no sea posible o no esté justificado
en costes construir un diseño que tenga una elevada
capacidad de recuperación ante los fallos. La capacidad
para cumplir los requisitos de disponibilidad dentro de
los parámetros de coste podría radicar en la capacidad
sistemática de recuperación de forma puntual y efectiva.
Deben considerarse todos los aspectos de disponibilidad
en el proceso Diseño del Servicio y deben considerarse
todas las etapas dentro del Ciclo de Vida del Servicio.
La contribución de Gestión de la Disponibilidad dentro de
las actividades de diseño es proporcionar:
■■ La especificación de los requisitos de disponibilidad
para todos los componentes del servicio
■■ Los requisitos para los puntos de medida de la
disponibilidad (instrumentación)
■■ Los requisitos para sistemas nuevos/mejorados y para
Gestión del Servicio
■■ Ayuda con el diseño de la infraestructura de TI
■■ La especificación de los requisitos de fiabilidad,
capacidad de mantenimiento y capacidad de servicio
para componentes suministrados por suministradores
internos y externos
■■ Validación del diseño final con respecto al
cumplimiento de los niveles mínimos de
disponibilidad requeridos por el negocio para el
servicio de TI.
Si no se pudieran cumplir los requisitos de disponibilidad,
la siguiente tarea será reevaluar el Diseño del Servicio e
identificar los cambios de diseño justificados en costes.
Se pueden lograr mejoras en el diseño para cumplir
los requisitos de disponibilidad revisando la capacidad
de la tecnología que se desplegará en el diseño de TI
propuesto. Por ejemplo:
824_005 Chapter 04.indd 122
■■ La explotación de tecnología tolerante a fallos para
ocultar el impacto de paradas planificadas o sin
planificar de los componentes
■■ Duplexado, o la provisión de componentes alternativos
de la infraestructura de TI para permitir que un
componente asuma el trabajo de otro componente
■■ Mejorar la fiabilidad del componente mejorando el
régimen de pruebas
■■ Mejora del diseño y desarrollo del software
■■ Mejora de procesos y procedimientos
■■ Mejoras/explotación de gestión de sistemas
■■ Mejora de servicios suministrados externamente,
contratos o acuerdos
■■ Desarrollo de la capacidad de las personas con más
formación.
Sugerencias y consejos
Considere documentar los requisitos y consideraciones
de diseño de la disponibilidad para nuevos servicios de
TI y póngalos a disposición de las funciones de diseño
e implementación. A más largo plazo, busque acordar
estos requisitos e integrarlos dentro de los mecanismos
apropiados de gobierno que incluyen la introducción
de nuevos servicios de TI.
Parte de la actividad de diseño para la disponibilidad
debe garantizar que todos los requisitos de seguridad del
negocio, datos e información se incorporen dentro del
Diseño del Servicio. El objetivo general de la seguridad
de TI es una ‘seguridad equilibrada exhaustiva’, con la
implementación de controles justificables para garantizar
que se aplique la política de Seguridad de la Información
y que continúen operativos los servicios de TI dentro de
los parámetros de seguridad (es decir, confidencialidad,
integridad y disponibilidad). Durante la recopilación de
los requisitos de disponibilidad para nuevos servicios
de TI, es importante que se definan los requisitos que
cubren la seguridad de TI. Es necesario aplicar estos
requisitos dentro de la fase de diseño para la tecnología
de soporte. Para muchas organizaciones, el método
adoptado para la seguridad de TI está recogido por una
Política de Seguridad de la Información de propiedad y
mantenida por Gestión de la Seguridad de la Información.
En la aplicación de la política de seguridad, Gestión de
la Disponibilidad desempeña un rol importante en su
operación para nuevos servicios de TI.
Si la operación de negocio tuviera una gran dependencia
de la disponibilidad del servicio de TI, y el coste del fallo o
la pérdida de reputación del negocio no se consideraran
aceptables, el negocio podría definir requisitos estrictos
de disponibilidad. Estos factores podrían ser suficientes
22/1/10 13:49:37

para que el negocio justifique los costes adicionales
requeridos para cumplir estos niveles de disponibilidad
cada vez más exigentes. El logro de los niveles acordados
de disponibilidad comienza con el diseño, compra y/o
desarrollo de productos y componentes de buena calidad.
Sin embargo, si éstos estuvieran aislados posiblemente
no entregarían los niveles continuos de disponibilidad
requeridos. Para lograr un nivel consistente y continuo de
disponibilidad se requiere la inversión, y el despliegue, de
procesos eficaces de Gestión del Servicio, herramientas
de gestión de sistemas, diseño de alta disponibilidad y en
última instancia soluciones especiales con total simetría o
redundancia.
El diseño para la disponibilidad es una actividad
clave, dirigida por Gestión de la Disponibilidad, que
garantiza que se cumplan los requisitos establecidos
de disponibilidad para un servicio de TI. Sin embargo,
Gestión de la Disponibilidad también debe asegurar que
dentro de esta actividad de diseño haya un enfoque
sobre los elementos de diseño requeridos para garantizar
que, cuando fallen los servicios de TI, el servicio pueda
restablecerse lo más rápidamente posible para permitir
las operaciones de negocio normales. Puede que ‘Diseño
para la recuperación’ parezca inicialmente un concepto
negativo. Un diseño de la disponibilidad claramente
adecuado trata de evitar fallos y ofrece, siempre que sea
posible, una infraestructura de TI tolerante a los fallos. Sin
embargo, ¿con este enfoque se confía demasiado en la
tecnología y se pone demasiado énfasis en los aspectos
de la tolerancia a los fallos de la infraestructura de TI? La
realidad es que se producirán fallos. La forma en la que la
organización de TI gestiona las situaciones de fallo puede
tener un efecto positivo en la percepción del negocio,
clientes y usuarios de los servicios de TI.
Mensaje clave
Todo fallo es un importante ‘momento de la verdad’,
una oportunidad para fortalecer o perder su reputación
con el negocio.
Centrándose en los aspectos del ‘diseño para la
recuperación’ de la disponibilidad general, el diseño
puede garantizar que todo fallo sea una oportunidad para
mantener e incluso mejorar la satisfacción del cliente y del
usuario. Para proporcionar un ‘diseño para la recuperación’
eficaz, es importante reconocer que tanto el negocio
y la organización de TI tienen necesidades que deben
satisfacerse para permitir una recuperación eficaz a partir
de un fallo de TI. Éstas son necesidades de información
que requiere el negocio como ayuda para gestionar el
impacto del fallo en su negocio y establecer expectativas
dentro del negocio, comunidad de usuarios y sus clientes
824_005 Chapter 04.indd 123
Procesos de Diseñ̃o del Servicio | 123
de negocio. Éstas son las habilidades, conocimiento,
procesos, procedimientos y herramientas requeridos para
permitir que la recuperación técnica se complete en un
plazo óptimo.
Sugerencias y consejos
Considere documentar los requisitos y consideraciones
de diseño de la recuperación para nuevos servicios de
TI y póngalos a disposición de las áreas responsables
del diseño e implementación. A más largo plazo,
busque acordar estos requisitos e integrarlos dentro de
los mecanismos apropiados de gobierno que incluyen
la introducción de nuevos servicios de TI.
Un objetivo clave es evitar que incidencias menores se
conviertan en incidencias graves asegurando que se
impliquen las personas correctas con suficiente antelación
para evitar que se cometan errores y para asegurar que
se invoque a los procedimientos de recuperación técnica
y del negocio apropiados a la primera oportunidad. El
proceso Gestión de Incidencias es responsable de impulsar
estas actividades y es un rol del Centro de Servicio al
Usuario. Para garantizar que se satisfagan las necesidades
del negocio durante fallos importantes del servicio de TI, y
para garantizar la recuperación más óptima, es necesario
que Gestión de Incidencias y el Centro de Servicio al
Usuario hayan definido y ejecutado procedimientos
eficaces para evaluar y gestionar todas las incidencias.
Mensaje clave
Lo expuesto anteriormente no son responsabilidades
de Gestión de la Disponibilidad. Sin embargo,
la eficacia del proceso Gestión de Incidencias y
del Centro de Servicio al Usuario puede influir
ampliamente en todo el periodo de recuperación.
El uso de los métodos y técnicas de Gestión de la
Disponibilidad para optimizar más la recuperación
de TI podría ser el estímulo para actividades de
mejora continua posteriores en el proceso Gestión de
Incidencias y en el Centro de Servicio al Usuario.
Para que siga siendo eficaz, debe monitorizarse la
capacidad de mantenimiento de los servicios TI, de sus
componentes,y su impacto en un ‘ciclo de vida expandido
de la incidencia’ entendido, gestionado y mejorado.
Análisis de Impacto de Fallos de Componentes
Análisis de Impacto de Fallos de Componentes (CFIA)
se puede utilizar para predecir y evaluar el impacto
en el servicio de TI como consecuencia de fallos de
componentes dentro de la tecnología. La salida de CFIA
se puede utilizar para identificar si debe considerarse
22/1/10 13:49:37
 124 | Procesos de Diseñ̃o del Servicio

una capacidad de recuperación adicional para evitar o CI Servicio 1 Servicio 2

PC 1 PC 2
minimizar el impacto del fallo del componente en los PC1 M M

usuarios y operación del negocio. Esto es particularmente Cable 1 Cable 2 PC2 M M

Cable 1 M M
importante durante la etapa Diseño del Servicio, Switch 1
Cable 2 M M
donde es necesario predecir y evaluar el impacto en la Cable 3
Switch 1 X X
disponibilidad del servicio de TI como consecuencia de Cable 3 X X
WAN
fallos en el componente dentro del Diseño del Servicio WAN X X
Centro de Datos y Entorno
propuesto. Sin embargo, la técnica también se puede Cable 4 X X
Cable 4 Switch 2 X X
aplicar a servicios e infraestructura existentes. Servidor 1
Software Cable 5 X X
Cable 5 del Sistema
CFIA es una técnica relativamente simple que se puede Centro de Datos X X
Servidor 1 X X
utilizar para proporcionar esta información. IBM ideó el Aplicación
Disco 1 A A
1
CFIA a principios de los años 70. Inicialmente se basaba en Disco 2 A A
la configuración y en el diseño del hardware. Sin embargo, Aplicación Sistema S/W X X
se recomienda que CFIA se utilice en un contexto Sistema Sistema
2 Aplicación 1 X
de Disco 1 de Disco 2
mucho más amplio para reflejar todo el ámbito de la Aplicación 2 X

infraestructura de TI, es decir, hardware, red, software,
aplicaciones, centros de datos y personal de soporte.
Adicionalmente, la técnica también se puede aplicar
para identificar el impacto y las dependencias en las
habilidades y competencias de la organización de soporte
de TI entre el personal que da soporte al nuevo servicio
de TI. Esta actividad normalmente se completa junto con
ITSCM y posiblemente con Gestión de la Capacidad.
La salida de un CFIA proporciona información fundamental
para garantizar que los criterios de diseño de la
disponibilidad y de la recuperación para el nuevo servicio
de TI estén influenciados para evitar o minimizar el
impacto del fallo en los usuarios y operación de negocio.
CFIA logra esto proporcionando e indicando:
■■ SPOFs que pueden tener impacto en la disponibilidad
■■ El impacto del fallo del componente en la operación
de negocio y en los usuarios
■■ Dependencia del componente y las personas
■■ Plazos de recuperación del componente
■■ La necesidad de identificar y documentar opciones de
recuperación
■■ La necesidad de identificar e implementar medidas de
reducción de riesgos.
Lo indicado anteriormente también puede proporcionar
el estímulo para la entrada en ITSCM y con ello considerar
el equilibrio entre opciones de recuperación y medidas
de reducción de riesgos, es decir, si el posible impacto
en el negocio fuera alto, sería necesario concentrarse en
medidas de alta disponibilidad de reducción de riesgos,
es decir, aumento de la capacidad de recuperación o de
sistemas en standby.
Después de determinar la configuración de la
infraestructura de TI que se abordará, el primer paso
es crear una cuadrícula con CIs en un eje y en el otro
eje los servicios de TI que tienen una dependencia del
Figura 4.18  Análisis del impacto del fallo del
componente
CI, como se ilustra en la Figura 4.18. Esta información
debe estar disponible desde el CMS, o alternativamente
se puede construir utilizando gráficos de configuración
documentados y SLAs.
El siguiente paso es realizar el CFIA y rellenar la cuadrícula
de la siguiente forma:
■■ Dejar un espacio en blanco cuando un fallo del CI no
tenga ningún impacto en el servicio
■■ Insertar una ‘X’ cuando el fallo del CI provoque que el
servicio de TI deje de estar operativo
■■ Insertar una ‘A’ cuando haya un CI alternativo para
proporcionar el servicio
■■ Insertar una ‘M’ cuando haya un CI alternativo aunque
el servicio requiera la intervención manual para su
recuperación.
Después de haber creado la cuadrícula, los CI que tienen
un gran número de Xs son críticos para muchos servicios y
pueden dar como resultado un alto impacto si el CI fallara.
De forma similar, los servicios de TI que tienen un gran
número de Xs son complejos y vulnerables a los fallos.
Esta aproximación básica al CFIA puede proporcionar
información valiosa para identificar rápidamente SPOFs,
servicios de TI en riesgo de fallo de CI y las alternativas
que están disponibles si fallaran CIs. También se debería
utilizar para evaluar la existencia y validez de los procesos
de recuperación para los CI seleccionados. El ejemplo
anterior asume una infraestructura común soportando
múltiples servicios de TI. El mismo enfoque puede
aplicarse a un servicio de TI individual asociando los
elementos de configuración con las VBFs y los usuarios
a los que da soporte cada componente, entendiendo el
impacto del fallo de un componente, en el negocio y el

824_005 Chapter 04.indd 124 22/1/10 13:49:37


usuario. El método también se puede refinar y desarrollar
posteriormente para incluir y desarrollar factores de
‘ponderación de la disponibilidad del componente’ que
se pueden utilizar para evaluar y calcular el efecto general
del fallo del componente en la disponibilidad total del
servicio.
Para asumir un CFIA avanzado se requiere la ampliación
de la matriz CFIA para proporcionar campos adicionales
requeridos para un análisis más detallado. Esto podría
incluir campos tales como:
■■ Ponderación de la disponibilidad del componente:
un factor de ponderación apropiado para el impacto
del fallo del componente en la disponibilidad total del
servicio. Por ejemplo, si el fallo de un switch puede
hacer que 2.000 usuarios perdieran el servicio de una
base de usuarios del servicio total de 10.000, entonces
el factor de ponderación debe ser el 0,2, o 20%
■■ Probabilidad de fallo: esto puede basarse en la
fiabilidad del componente medida por la información
sobre el Tiempo Medio Entre Fallos (MTBF) si se
dispusiera de la misma, o en base a las tendencias
actuales. Esto se puede expresar como un indicador
bajo/medio/alto o como una representación numérica
■■ Tiempo de recuperación: es el tiempo de
recuperación estimado para recuperar el CI. Puede
basarse en tiempos recientes de recuperación,
información de recuperación de las pruebas de
recuperación de desastres, o en una recuperación de
prueba programada
■■ Procedimientos de recuperación: esto es
la verificación de que los procedimientos de
recuperación actualizados están disponibles para el CI
■■ Independencia del dispositivo: si los CI de software
tuvieran archivos duplicados para proporcionar
capacidad de recuperación, esto se hace para
garantizar que se ha verificado que los archivos están
ubicados en configuraciones de disco de hardware
separadas. Esto también se aplica a fuentes de
alimentación. Debe comprobarse que las fuentes de
alimentación alternativas se conecten correctamente
■■ Dependencia: para mostrar cualquier dependencia
entre CIs. Si fallara un CI, podría haber un impacto en
otros CI, por ejemplo, si fallara el CI de seguridad, el
sistema operativo podría evitar el procesamiento de
cintas.
Análisis de punto único de fallo
Un Punto único de fallo (SPOF) es cualquier componente
dentro de la infraestructura de TI que no tiene backup
o capacidad de recuperación de fallos, y que tiene la
posibilidad de provocar la interrupción en el negocio,
824_005 Chapter 04.indd 125
Procesos de Diseñ̃o del Servicio | 125
clientes o usuarios si fallara. Es importante que no exista
ningún SPOF sin reconocer dentro del diseño de la
infraestructura de TI o de la tecnología real, y que se
eviten siempre que sea posible.
Se recomienda el uso del análisis de SPOFs o CFIA como
técnicas para identificar SPOFs. Los ejercicios de análisis
de SPOFs y CFIA deben realizarse regularmente, y siempre
que se identifiquen SPOFs, CFIA se puede utilizar para
identificar el impacto potencial en el negocio, cliente o
usuario y ayudar a determinar las alternativas que pueden
o deben considerarse para su aplicación en esta debilidad
en el diseño o infraestructura real. A continuación
deben implementarse contramedidas siempre que
sean justificables en costes. El impacto e interrupción
provocados por el fallo potencial del SPOF deben utilizarse
para justificar los costes de su implementación.
Análisis del Árbol de Fallos
El Análisis del árbol de fallos (FTA) es una técnica que se
puede emplear para identificar la cadena de eventos que
provocan una interrupción de los servicios de TI. El FTA,
junto con métodos de cálculo, puede ofrecer modelos
detallados de disponibilidad. Esto se puede utilizar
para evaluar la mejora de la disponibilidad que puedan
lograr opciones de diseño de componentes tecnológicos
individuales. Con FTA:
■■ Puede proporcionarse información para su uso en
cálculos de disponibilidad
■■ Se pueden realizar operaciones en función del árbol
de fallos resultante; estas operaciones corresponden
con las opciones de diseño
■■ Se puede elegir el nivel deseado de detalle en el
análisis.
El FTA realiza la representación de una cadena de eventos
mediante el uso de símbolos Booleanos. La Figura 4.19
proporciona el ejemplo de un árbol de fallos.
El FTA distingue esencialmente los siguientes eventos:
■■ Eventos básicos – puntos terminales para el árbol
de fallos, por ejemplo, fallo de alimentación, error
del operador. Los eventos básicos no se investigan
con gran exhaustividad. Si los eventos básicos se
investigaran con más exhaustividad, éstos pasarán a
ser automáticamente eventos resultantes.
■■ Eventos resultantes – nodos intermedios en el
árbol de fallos, que resultan de una combinación
de eventos. El punto más alto en el árbol de fallos
normalmente es un fallo del servicio de TI.
■■ Eventos condicionales – eventos que sólo se
producen bajo ciertas condiciones, por ejemplo, el
fallo del equipo de aire acondicionado sólo afecta al
22/1/10 13:49:37
 126 | Procesos de Diseñ̃o del Servicio
Servicio caído
Fuera del horario
Inhibir de servicio
Sistema caído
O
Red caída
Servidor caído Aplicación caída
Línea principal
caída
Figura 4.19  Ejemplo de Análisis del Árbol de Fallos
servicio de TI si la temperatura del equipo superara los
valores del servicio.
■■ Eventos de disparo – eventos que disparan otros
eventos, por ejemplo, el equipo de detección de fallos
de alimentación puede disparar un corte automático
de los servicios de TI.
Estos eventos se pueden combinar utilizando operadores
lógicos, es decir:
■■ Puerta AND – el evento resultante sólo se produce
cuando todos los eventos de entrada se producen
simultáneamente
■■ Puerta OR – el evento resultante se produce cuando
se producen uno o más eventos de entrada
■■ Puerta OR exclusivo – el evento resultante se
produce cuando uno y sólo uno de los eventos de
entrada se produce
■■ Puerta inhibidora – el evento resultante sólo se
produce cuando la condición de entrada no se
cumple.
Esta es la técnica básica de FTA. Esta técnica también
se puede refinar, pero el FTA complejo y la evaluación
matemática de los árboles de fallos van más allá del
ámbito de esta publicación.
Modelado
Para evaluar si los nuevos componentes dentro de
un diseño pueden corresponder con los requisitos
824_005 Chapter 04.indd 126
establecidos, es importante que el régimen de
pruebas impulsado garantice que se pueda entregar la
disponibilidad esperada. Deben considerarse seriamente
las herramientas de simulación, modelado y pruebas de
carga para generar la demanda esperada del usuario con
respecto al nuevo servicio de TI para garantizar que los
componentes continúen funcionando bajo condiciones
anticipadas de esfuerzo y volumen.
También se requieren herramientas de modelado para
prever la disponibilidad y para evaluar el impacto de los
cambios en la infraestructura de TI. Las entradas en el
proceso de modelado incluyen datos descriptivos de la
fiabilidad, capacidad de mantenimiento y capacidad de
servicio del componente. Normalmente basta con un
paquete de hojas de cálculo. Si se requirieran datos más
precisos y detallados, podría ser necesario desarrollar
o adquirir una herramienta de modelado compleja.
La falta en el mercado de herramientas de modelado
Línea de de la disponibilidad podría implicar la necesidad de
conmutac. desarrollar y mantener internamente una herramienta,
automática
pero esto implica una actividad muy cara, y que consume
mucho tiempo, que sólo debería considerarse si se
pudiera justificar la inversión. A menos que haya un
beneficio claro percibido de tal desarrollo y de los costes
continuos de mantenimiento, debería ser suficiente el
uso de herramientas y de hojas de cálculo existentes. Sin
embargo, algunas herramientas de Gestión de Sistemas
proporcionan capacidad de modelado y pueden ofrecer
información útil sobre las tendencias y previsiones de las
necesidades de disponibilidad.
Análisis y Gestión del Riesgo
Para evaluar la vulnerabilidad ante fallos dentro de
la configuración y la capacidad del servicio de TI y
de la organización de soporte, se recomienda que la
infraestructura de TI, configuraciones del servicio, Diseño
del Servicio y organización de soporte (suministradores
internos y externos) existentes o propuestos, estén
sujetos a ejercicios formales de Análisis y Gestión del
Riesgo. Análisis y Gestión del Riesgo es una técnica que
se puede utilizar para identificar y cuantificar riesgos y
contramedidas justificables que se puedan implementar
para proteger la disponibilidad de los sistemas de
TI. La identificación de los riesgos y la provisión de
contramedidas justificadas para reducir o eliminar las
amenazas que plantean tales riesgos, pueden desempeñar
un rol importante a la hora de lograr los niveles requeridos
de disponibilidad para un servicio de TI nuevo o mejorado.
El Análisis de Riesgo debe abordarse durante la fase de
diseño para la tecnología de TI y servir para identificar:
22/1/10 13:49:38

Activos Amenazas Vulnerabilidades
Análisis
del Riesgo
Riesgos
Contramedidas
Gestión
del Riesgo
Figura 4.20  Análisis y Gestión del Riesgo
■■ Riesgos que podrían implicar la indisponibilidad de
componentes de TI dentro de la tecnología y Diseño
del Servicio
■■ Riesgos que podrían implicar falta de confidencialidad
y/o integridad dentro de la tecnología y Diseño del
Servicio
La mayoría de las metodologías de gestión y evaluación
del riesgo implican el uso de un método formal para
la evaluación del riesgo y para la posterior mitigación
del riesgo con la implementación de contramedidas
justificables en coste, como se ilustra en la Figura 4.20.
El Análisis de Riesgo incluye la identificación y evaluación
del nivel (medición) de los riesgos, calculado a partir
de los valores evaluados de los activos y de los niveles
evaluados de las amenazas para las vulnerabilidades de
estos activos. Hasta cierto punto, el riesgo también se
determina por su aceptación. Algunas organizaciones y
negocios pueden estar más dispuestas a aceptar el riesgo,
mientras que otras no estarán tan predispuestas a ello.
Gestión del Riesgo también implica la identificación,
selección y adopción de contramedidas justificadas por
los riesgos identificados para los activos en términos de
su impacto potencial sobre los servicios en caso de fallo, y
la reducción de tales riesgos a un nivel aceptable. Gestión
de Riesgo es una actividad que se asocia con muchas
otras actividades, especialmente ITSCM, Gestión de la
Seguridad y Transición del Servicio. Todos estos ejercicios
de evaluación del riesgo deberían coordinarse en lugar de
separarse en actividades.
Este enfoque, una vez aplicado a través de un método
formal, asegura que la cobertura sea completa, junto con
la suficiente confianza de que:
■■ Se hayan identificado todos los posibles riesgos y
contramedidas
■■ Se hayan identificado todas las vulnerabilidades y
evaluado sus niveles de forma precisa
■■ Se hayan identificado todas las amenazas y evaluado
sus niveles de forma precisa
824_005 Chapter 04.indd 127
Procesos de Diseñ̃o del Servicio | 127
■■ Todos los resultados sean consistentes en todo el
conjunto de tecnología revisado
■■ Pueda justificarse todo el gasto en las contramedidas
seleccionadas.
Los métodos formales de Análisis y Gestión del Riesgo son
actualmente un elemento importante en el diseño general
y la provisión de servicios de TI. La evaluación del riesgo
se basa a menudo en la probabilidad e impacto potencial
de la ocurrencia de un suceso. Las contramedidas se
implementan, siempre que pueda justificarse su coste,
para reducir el impacto o la probabilidad de ocurrencia de
un evento, o ambos.
Gestión del Riesgo (MoR) proporciona un marco de trabajo
genérico alternativo para la gestión del riesgo en todas
las partes de una organización: estratégico, programa,
proyecto, operativo. Incorpora todas las actividades que
se re-quieren para identificar y controlar la exposición
a cualquier tipo de riesgo, positivo o negativo, que
pueda afectar al logro de los objetivos de negocio de la
organización.
MoR proporciona un marco de trabajo contrastado,
probado y eficaz para ayudar a eliminar o gestionar
los riesgos implicados en la consecución de los logros.
MoR adopta una aplicación sistemática de principios,
metodología y procesos a la tarea de identificar, evaluar y
planificar e implementar posteriormente las respuestas al
riesgo. La guía enfatiza una metodología colaborativa y se
centra en los siguientes elementos clave:
■■ Desarrollar un marco de trabajo que sea transparente,
repetible y adaptable
■■ Comunicar claramente la política y sus beneficios a
todo el personal
■■ Designar a individuos claves en la gestión senior para
que sean ‘propietarios’ de las iniciativas de gestión del
riesgo y asegurar que se progrese
■■ Asegurar que la cultura se involucre y se respalde
adecuadamente el riesgo considerado, incluyendo la
innovación
■■ Integrar los sistemas de gestión del riesgo en la
gestión y aplicarlos uniformemente
■■ Asegurar que gestión del riesgo respalde los objetivos,
y no lo contrario
■■ Evaluar explícitamente los riesgos que implica la
colaboración con otras organizaciones
■■ Adoptar un enfoque que no culpe la monitorización y
revisar la actividad de evaluación del riesgo.
22/1/10 13:49:38
 128 | Procesos de Diseñ̃o del Servicio
Planificación de las pruebas de disponibilidad
Un entregable clave del proceso de Gestión de la
Disponibilidad es la ‘planificación de las pruebas de
disponibilidad’. Esta es una programación para la prueba
regular de todos los mecanismos disponibles. Algunos
mecanismos de disponibilidad, como ‘load balancing’,
‘mirroring’ y ‘grid computing’, se emplean diariamente
en la provisión del servicio normal; otros se utilizan
cuando se realiza una recuperación automática o una
reconfiguración manual. En consecuencia, es crucial que
todos los mecanismos de disponibilidad se prueben de
forma regular y planificada para asegurar que funcionen
cuando realmente sean necesarios. Esta planificación
debe mantenerse y comunicarse para que todas las áreas
sean conscientes de su contenido y para que el resto de
actividades propuestas puedan sincronizarse con dicho
contenido, como por ejemplo:
■■ La planificación de cambios
■■ Los planes y calendario de entrega
■■ Todos los planes, proyectos y programas de transición
■■ Planificaciones de mantenimiento planificado y
preventivo
■■ La planificación para probar la continuidad del servicio
de TI y los planes de recuperación
■■ Planes de negocio y planificaciones.
Mantenimiento planificado y preventivo
Todos los componentes deberían estar sujetos a una
estrategia de mantenimiento planificado. La frecuencia y
niveles de mantenimiento requeridos varían en función
del componente, teniendo en cuenta las tecnologías
implicadas, criticidad y los beneficios de negocio
potenciales que puedan introducir. Las actividades de
mantenimiento planificado permiten que la organización
de soporte de TI proporcione:
■■ Mantenimiento preventivo para evitar fallos
■■ Actualizaciones de software o hardware planificadas
para proporcionar nuevas funcionalidades o capacidad
adicional
■■ Cambios solicitados por el negocio a las aplicaciones
de negocio
■■ Implementación de nueva tecnología y funcionalidad
para que la explote el negocio.
El requisito de parada planificada influye de forma
evidente en el nivel de disponibilidad que se puede
proporcionar para un servicio de TI, particularmente en
aquellos que tienen requisitos de disponibilidad rigurosos.
A la hora de determinar los requisitos de disponibilidad
para un servicio de TI nuevo o mejorado, la cantidad
de tiempo de caída y la pérdida resultante de ingresos
824_005 Chapter 04.indd 128
requeridos para el mantenimiento planificado puede que
no sea aceptable para el negocio. Esto comienza a ser un
problema en el área de la Operación del Servicio 24 x 7.
En estos casos, es esencial que la operación continua sea
una funcionalidad del diseño central para permitir que
la actividad de mantenimiento se realice sin afectar a la
disponibilidad de los servicios de TI.
Cuando las horas de servicio requeridas para los
servicios de TI sean menos de 24 horas al día y/o siete
horas a la semana, es probable que la mayor parte del
mantenimiento planificado pueda organizarse sin afectar
a la disponibilidad del servicio. Sin embargo, cuando el
negocio necesite que los servicios de TI estén disponibles
24 horas al día y siete días a la semana, Gestión de la
Disponibilidad debe determinar la metodología más
eficaz para equilibrar los requisitos del mantenimiento
planificado con la pérdida de servicio para el negocio.
A menos que existan mecanismos que permitan la
operación continua, el tiempo de caída previsto para
el mantenimiento planificado es esencial si se quieren
obtener y mantener niveles de disponibilidad elevados.
En el caso de todos los servicios de TI, lógicamente
debería existir un periodo de ‘bajo impacto’ para la
implementación del mantenimiento. Una vez se hayan
definido y acordado los requisitos para gestionar el
mantenimiento planificado, deberían documentarse al
menos en:
■■ SLAs
■■ OLAs
■■ Contratos de soporte
■■ Planificaciones de Gestión de Cambios
■■ Planificaciones de Gestión del Despliegue de Entregas.
Sugerencias y consejos
Gestión de la Disponibilidad debería asegurar que el
mantenimiento preventivo sea una de las principales
consideraciones de diseño para un servicio de TI
‘24 x 7’.
La hora más adecuada para programar la parada
planificada es, evidentemente, cuando el impacto sobre
el negocio y sus clientes sea menor. Esta información
debería ser facilitada inicialmente por el negocio cuando
se determinen los requisitos de disponibilidad. En el
caso de un servicio de TI existente, o una vez que se
haya establecido el nuevo servicio, la monitorización de
las transacciones del negocio y el cliente contribuyen
a establecer las horas en las que el uso del servicio de
TI es menor. Esto debería determinar el momento más
adecuado para retirar los componentes en la actividad de
mantenimiento planificado.
22/1/10 13:49:38

La incorporación de los requisitos de los componentes
individuales para la parada planificada a la vez que se
equilibran los requisitos de disponibilidad del servicio del
negocio, proporciona una oportunidad para considerar
simultáneamente la programación del mantenimiento
planificado en múltiples componentes. Los beneficios de
esta metodología representan la reducción del número
de interrupciones del servicio requeridas para cumplir los
requisitos de mantenimiento. Aunque esta metodología
presenta beneficios, existen riesgos potenciales que es
necesario evaluar. Por ejemplo:
■■ La capacidad de la organización de soporte de TI
para coordinar la implementación simultánea de un
número elevado de cambios
■■ La capacidad para realizar una identificación eficaz del
problema cuando el servicio de TI se vea afectado por
la finalización de múltiples cambios
■■ El impacto de la dependencia del cambio en múltiples
componentes cuando la marcha atrás de un cambio
fallido requiera la eliminación de múltiples cambios.
La gestión eficaz de la parada planificada es una
contribución importante para satisfacer los niveles
de disponibilidad requeridos para un servicio de TI.
Cuando se requiera la parada planificada de forma
cíclica para uno o varios componentes de TI, el tiempo
de indisponibilidad del componente para permitir que
se realice la actividad de mantenimiento planificado
debería definirse y acordarse con el suministrador interno
o externo. Esto se transforma en un objetivo estipulado
que puede formalizarse, medirse y comunicarse. Todo
el mantenimiento planificado debería programarse,
gestionarse y controlarse para asegurar que los objetivos
individuales y los plazos de tiempo no se vean superados
y para garantizar que las actividades se coordinen
con todas las planificaciones de actividad con el fin
de minimizar coincidencias y conflictos (por ejemplo,
planificaciones de cambio y entrega, programaciones de
pruebas). Además, durante la actividad de mantenimiento
proporcionan una alerta anticipada del tiempo asignado
a la duración de la parada planificada antes de que llegue
a ser incumplida. Esto puede permitir que se tome una
decisión anticipada sobre si se permite que la actividad
finalice con la posibilidad de afectar adicionalmente
al servicio o abortar la actividad e instigar el plan de
marcha atrás. Debe registrarse la parada planificada y el
rendimiento frente a los objetivos estipulados para cada
componente y emplearse en los informes del servicio.
Elaboración del documento de la Parada de
Servicio Planificada (PSO)
Gestión de la Disponibilidad debería elaborar y mantener
el documento PSO. Este documento incluye cualquier
824_005 Chapter 04.indd 129
Procesos de Diseñ̃o del Servicio | 129
variación de la disponibilidad del servicio acordada dentro
de los SLAs. Debería elaborarse en función de las entradas
recibidas de:
■■ La planificación de cambios
■■ Los calendarios de entrega
■■ Planificaciones de mantenimiento planificado y
preventivo
■■ Planificaciones de las pruebas de disponibilidad
■■ ITSCM y planificaciones de pruebas de Gestión de la
Continuidad del Negocio.
La PSO contiene información detallada de toda la parada
de servicio planificada y programada dentro de las horas
de servicio acordadas para todos los servicios. Estos
documentos deberían acordarse con todas las áreas y
representantes apropiados tanto del negocio como de TI.
Una vez se haya acordado la PSO, el Centro de Servicio
al Usuario debería asegurar que se comunique a todas
las partes convenientes para que todo el mundo sea
consciente de cualquier parada del servicio planificada
adicional.
Revisión y mejora continua
Las necesidades cambiantes del negocio y las variaciones
de la demanda pueden requerir la revisión de los niveles
de disponibilidad provistos para un servicio de TI. Tales
revisiones deberían incluirse en las revisiones regulares
del servicio con el negocio realizadas por SLM. También
se debería tener en cuenta periódicamente otra entrada
desde ITSCM, particularmente a partir de los ejercicios
de Análisis de Impacto en el Negocio y de Análisis
de Riesgo actualizados. La criticidad de los servicios
cambiará con frecuencia y es importante que Gestión
de la Disponibilidad revise y mejore regularmente el
diseño y la tecnología que respaldan a tales servicios para
asegurar que el cambio de importancia en el servicio se
refleje dentro de un diseño revisado y en la tecnología
de soporte. Cuando ya se hayan entregado los niveles
de disponibilidad, se requerirá un esfuerzo considerable
y se incurrirá en un coste importante para alcanzar
una pequeña mejora incremental dentro del nivel de
disponibilidad.
Una actividad crítica para Gestión de la Disponibilidad
es analizar continuamente oportunidades para optimizar
la disponibilidad de la infraestructura de TI junto con
las actividades de Mejora Continua del Servicio. Los
beneficios de esta metodología de revisión regular son
que, algunas veces, pueden conseguirse mejoras en los
niveles de disponibilidad, pero con costes muy inferiores.
El enfoque orientado a la optimización es un primer paso
sensato para proporcionar un mayor valor obtenido por
el dinero. Pueden aplicarse diversas técnicas de Gestión
22/1/10 13:49:38
 130 | Procesos de Diseñ̃o del Servicio
de la Disponibilidad para identificar las oportunidades
de optimización. Se recomienda no restringir el ámbito a
la tecnología, e incluir también una revisión del proceso
de negocio y otras responsabilidades extremo a extremo
que pertenezcan al negocio. Para contribuir a alcanzar
estos logros, el proceso Gestión de la Disponibilidad
debe ser reconocido como una influencia que dirige a
la organización del Proveedor de Servicios de TI para
asegurar un enfoque continuo en la disponibilidad y
estabilidad de la tecnología.
Gestión de la Disponibilidad puede proporcionar a la
organización de soporte de TI una perspectiva real,
procedente del negocio y del usuario, sobre cómo
las deficiencias dentro de la tecnología y el proceso
y procedimiento de apoyo afectan a la operación del
negocio y, finalmente, a sus clientes. El uso de métricas
dirigidas al negocio puede mostrar este impacto en
términos reales y contribuir a cuantificar los beneficios de
las oportunidades de mejora. Gestión de la Disponibilidad
puede desempeñar un rol importante a la hora de
ayudar a la organización del proveedor de servicio de
TI a conocer dónde se puede añadir valor mediante la
utilización de sus habilidades y competencias técnicas
en un contexto de disponibilidad. La técnica de mejora
continua puede servir a Gestión de la Disponibilidad a
aprovechar esta capacidad técnica. Puede aplicarse a
grupos reducidos de personal técnico o a un grupo más
amplio dentro de una reunión de trabajo o un entorno
SFA.
El impulso para aprovechar la disponibilidad proviene de
uno o más de los siguientes aspectos:
■■ La incapacidad, para los servicios de TI nuevos o
existentes, de cumplir los objetivos del SLA de forma
consistente
■■ Periodos de inestabilidad del servicio de TI que
provoquen niveles de disponibilidad inaceptables
■■ Tendencias en las medidas de la disponibilidad que
indiquen un deterioro gradual de la disponibilidad
■■ Tiempos de recuperación y restauración del servicio de
TI inaceptables
■■ Peticiones del negocio para incrementar el nivel de
disponibilidad provisto
■■ Impacto creciente sobre el negocio y sus clientes
de los fallos del servicio de TI como resultado del
crecimiento y/o incremento de las prioridades o
funcionalidades del negocio
■■ Una petición de SLM para mejorar la disponibilidad
dentro de un SIP general
■■ Monitorización y análisis de tendencias de Gestión de
la Disponibilidad.
824_005 Chapter 04.indd 130
Gestión de la Disponibilidad debería adoptar un
rol proactivo en la identificación y desarrollo de
oportunidades de mejora de la disponibilidad justificadas
en coste dentro del Plan de Disponibilidad. Esta capacidad
permite contar con una medición y elaboración de
informes sobre la disponibilidad adecuados y significativos.
Para asegurar que las mejoras de la disponibilidad
proporcionen beneficios al negocio y usuarios, es
importante que la medición y elaboración de informes
no sólo refleje la disponibilidad del componente de TI,
sino también la disponibilidad desde la perspectiva de la
operación del negocio y del usuario.
Cuando el negocio tenga un requisito para mejorar la
disponibilidad, la organización del proveedor de servicios
de TI debería seguir un proceso y técnicas para reevaluar
la tecnología y la capacidad de cumplimiento de estos
requisitos. Una salida de esta actividad es una mejora de
la disponibilidad y criterios de diseño de la recuperación.
La satisfacción del requisito del negocio de niveles
superiores de disponibilidad puede requerir una inversión
financiera adicional para mejorar la tecnología de soporte
y/o ampliar los servicios provistos por la organización
del proveedor de servicios de TI. Es importante que se
justifique el coste de cualquier inversión adicional de
mejora de los niveles de disponibilidad provistos. La
determinación del coste de la indisponibilidad, como
resultado de los fallos de TI, puede contribuir a respaldar
cualquier decisión de inversión financiera en la mejora de
la disponibilidad.
4.4.6  Disparadores, entradas, salidas e
interfaces
Muchos eventos pueden iniciar la actividad de Gestión de
la Disponibilidad. Éstos incluyen:
■■ Necesidades nuevas o modificados del negocio o
servicios
■■ Objetivos nuevos o modificados dentro de acuerdos,
como SLRs, SLAs, OLAs o contratos
■■ Incumplimientos del servicio o componente, eventos
de disponibilidad y alertas, incluyendo eventos de
umbrales, informes de excepciones
■■ Actividades periódicas como revisar, repasar o informar
■■ Revisión de previsiones, informes y planes de Gestión
de la Disponibilidad
■■ Revisión de planes y estrategias de negocio y de TI
■■ Revisión de diseños y estrategias
■■ Reconocimiento o notificación de un cambio del
riesgo o impacto de un proceso de negocio o VBF, un
servicio de TI o componente
22/1/10 13:49:38

■■ Petición de ayuda de SLM con objetivos de
disponibilidad y explicación de los logros.
Las interfaces clave que Gestión de la Disponibilidad tiene
con otros procesos son:
■■ Gestión de Incidencias y Problemas:
proporcionando colaboración con la resolución,
justificación posterior y corrección de las incidencias y
problemas de disponibilidad
■■ Gestión de la Capacidad: con la provisión de
capacidad de recuperación y capacidad libre
■■ Gestión de la Continuidad del Servicio de TI:
con la evaluación del impacto y riesgo de negocio,
provisión de capacidad de recuperación, exceso de
capacidad y mecanismo de recuperación
■■ Gestión del Nivel de Servicio: colaboración con
la determinación de objetivos de disponibilidad y
la investigación y resolución de incumplimientos de
servicio y componente.
4.4.6.1  Entradas
Diversas fuentes de información son adecuadas para el
proceso de Gestión de la Disponibilidad. Algunas de éstas
son las siguientes:
■■ Información del negocio: desde la estrategia de
negocio, planes financieros de la organización e
información sobre sus requisitos actuales y futuros,
incluyendo los requisitos de disponibilidad para
servicios de TI nuevos o mejorados
■■ Información del impacto en el negocio: desde BIAs
y evaluación de VBFs apoyados por servicios de TI
■■ Análisis Anteriores del Riesgo: e informes de
Evaluación y un Registro de Riesgos
■■ Información del servicio: desde el Porfolio de
Servicios y el Catálogo de Servicios
■■ Información del servicio: procedente del proceso
SLM, con detalles de los servicios del Porfolio
de Servicios y del Catálogo de Servicios y de los
objetivos de nivel de servicio dentro de SLAs y SLRs,
y posiblemente a partir de la monitorización de SLAs,
revisiones del servicio e incumplimientos de los SLA.
■■ Información financiera: desde Gestión Financiera,
el coste de la provisión del servicio, de recursos y
componentes
■■ Información del cambio y de la entrega:
procedente del proceso Gestión de Cambios con una
Planificación de Cambios, el Calendario de entrega
de Gestión de la Entrega y una necesidad de evaluar
todos los cambios con respecto a su impacto en la
disponibilidad del servicio
824_005 Chapter 04.indd 131
Procesos de Diseñ̃o del Servicio | 131
■■ Gestión de la Configuración: contiene información
sobre las relaciones entre el negocio, servicios,
servicios de soporte y la tecnología
■■ Objetivos del servicio: procedente de SLAs, SLRs,
OLAs y contratos
■■ Información del componente: sobre los requisitos
de disponibilidad, fiabilidad y mantenimiento para
los componentes de la tecnología que respaldan los
servicios de TI
■■ Información de la tecnología: desde el CMS sobre la
topología y las relaciones entre los componentes y la
evaluación de las capacidades de la nueva tecnología
■■ Rendimiento anterior: a partir de mediciones
anteriores, logros e informes del Sistema de
Información de Gestión de la Disponibilidad (AMIS)
■■ Información sobre indisponibilidad y fallo: desde
incidencias y problemas.
4.4.6.2  Salidas
Las salidas generadas por Gestión de la Disponibilidad
deberían incluir:
■■ El Sistema de Información de Gestión de la
Disponibilidad (AMIS)
■■ El Plan de Disponibilidad para la mejora proactiva de
los servicios de TI y la tecnología
■■ Criterios de disponibilidad y diseño de la recuperación
y objetivos de servicio propuestos para servicios
nuevos o modificados
■■ Informes de logros de la disponibilidad, fiabilidad
y mantenimiento del servicio frente a los objetivos,
incluyendo la entrada para todos los informes del
servicio
■■ Informes de logros de la disponibilidad, fiabilidad y
mantenimiento del componente frente a los objetivos
■■ Revisiones e informes revisados del análisis de riesgo y
un Registro de Riesgos actualizado
■■ Requisitos de monitorización, gestión y elaboración
de informes para los servicios y componentes de TI
con el objetivo de asegurar que las desviaciones de
la disponibilidad, fiabilidad y mantenimiento sean
detectadas, corregidas, registradas y transmitidas
■■ Una planificación de pruebas de Gestión de la
Disponibilidad para probar todos los mecanismos de
disponibilidad y capacidad de recuperación
■■ Las planificaciones de mantenimiento planificado y
preventivo
■■ La Parada de Servicio Planificada (PSO) junto con
Gestión de Cambios y de la Entrega
■■ Detalles técnicas y medidas de disponibilidad
proactivas que se desplegarán para proporcionar
22/1/10 13:49:39
 132 | Procesos de Diseñ̃o del Servicio
capacidad de recuperación adicional a fin de evitar
o minimizar el impacto de los fallos del componente
sobre la disponibilidad del servicio de TI
■■ Acciones de mejora para su inclusión dentro del SIP.
4.4.7 Indicadores Clave de Rendimiento
Se pueden emplear muchos KPIs para medir la eficacia y
eficiencia de Gestión de la Disponibilidad, entre los que se
incluyen los ejemplos siguientes:
Gestionar la disponibilidad y fiabilidad del servicio de
TI:
■■ Reducción porcentual de la indisponibilidad de
servicios y componentes
■■ Incremento porcentual de la fiabilidad de servicios y
componentes
■■ Revisión eficaz y seguimiento de todos los
incumplimientos de los SLAs, OLAs y contratos de
soporte
■■ Mejora porcentual de la disponibilidad extremo a
extremo global del servicio
■■ Reducción porcentual del número e impacto de
roturas del servicio
■■ Mejora del Tiempo Medio Entre Fallos (MTBF)
■■ Mejora del Tiempo Medio Entre Incidencias del
Servicio (MTBSI)
■■ Reducción del Tiempo Medio de Restauración del
Servicio (MTRS).
Satisfacer necesidades de acceso del negocio a
servicios de TI:
■■ Reducción porcentual de la indisponibilidad de
servicios
■■ Reducción porcentual del coste de las horas extras del
negocio provocadas por la indisponibilidad de TI
■■ Reducción porcentual de los fallos en momentos
críticos, por ejemplo planificación teniendo en cuenta
picos de negocio específicos y necesidades de
disponibilidad prioritarias
■■ Mejora porcentual en el negocio y usuarios satisfechos
con el servicio (por resultados CSS).
Disponibilidad de la infraestructura de TI obtenida a
costes óptimos:
■■ Reducción porcentual del coste de la indisponibilidad
■■ Mejora porcentual de los costes de Provisión de
Servicio
■■ Finalización puntual del Análisis de Riesgo y revisión
regular del sistema
824_005 Chapter 04.indd 132
■■ Finalización puntual del análisis coste-beneficio regular
establecido para el Análisis de Impacto de Fallos de
Componentes (CFIA) de la infraestructura
■■ Reducción porcentual de los fallos del rendimiento
de terceros sobre el MTRS/MTBF frente a los objetivos
contractuales
■■ Reducción del tiempo necesario para finalizar (o
actualizar) un Análisis de Riesgo
■■ Reducción del tiempo necesario para revisar la
capacidad de recuperación del sistema
■■ Reducción del tiempo necesario para finalizar un Plan
de Disponibilidad
■■ Elaboración puntual de informes de gestión
■■ Reducción porcentual en la incidencia de revisiones
operativas que no cubran las exposiciones a la
seguridad y fiabilidad en los diseños de la aplicación.
4.4.8  Gestión de la Información
El proceso de Gestión de la Disponibilidad debería
mantener un AMIS que contenga todas las medidas
e información que se requieren para completar el
proceso de Gestión de la Disponibilidad y proporcionar
la información apropiada para el negocio con respecto
al nivel de servicio de TI provisto. Esta información,
que abarca servicios, componentes y servicios de
soporte, proporciona la base para la información de la
disponibilidad ad hoc y de excepción, y la identificación
de tendencias dentro de los datos para impulsar
actividades de mejora. Estas actividades y la información
contenida dentro del AMIS proporcionan la base para el
desarrollo del contenido del Plan de Disponibilidad.
Debería formularse y mantenerse un Plan de
Disponibilidad a fin de proporcionar estructura y centrarse
en una amplia variedad de iniciativas que pueda ser
necesario emprender para mejorar la disponibilidad. El
Plan de Disponibilidad debería tener metas, objetivos y
entregables y debería tener en cuenta más ampliamente
problemas de personas, procesos y técnicas, así como un
enfoque en la tecnología. En las etapas iniciales puede
alinearse con un plan de implementación para Gestión de
la Disponibilidad, pero ambos son diferentes y no deben
confundirse. A medida que madure el proceso de Gestión
de la Disponibilidad, el plan debería evolucionar para
tratar lo siguiente:
■■ Niveles de disponibilidad reales frente a niveles de
disponibilidad acordados para servicios de TI clave.
Las medidas de la disponibilidad deberían centrarse
siempre en el negocio y el cliente y debe informarse
sobre la disponibilidad experimentada por el negocio
y los usuarios.
22/1/10 13:49:39

■■ Actividades en progreso para abordar la escasez de
disponibilidad en los servicios de TI existentes. Cuando
se requieran decisiones de inversión, deberían incluirse
opciones con los costes y beneficios asociados.
■■ Detalles de los requisitos de disponibilidad cambiantes
de los servicios de TI existentes. El plan debería
documentar las opciones disponibles para satisfacer
estos requisitos modificados. Cuando se requieran
decisiones de inversión, deberían incluirse los costes
asociados de cada opción.
■■ Detalles de los requisitos de disponibilidad para
los nuevos servicios de TI futuros. El plan debería
documentar las opciones disponibles para satisfacer
estos nuevos requisitos. Cuando se requieran
decisiones de inversión, deberían incluirse los costes
asociados de cada opción.
■■ Una planificación innovadora para las asignaciones SFA
planificadas.
■■ Deben realizarse revisiones regulares de las
asignaciones SFA para asegurar que la disponibilidad
de la tecnología mejore proactivamente junto con el
SIP.
■■ Una sección de la tecnología futura para proporcionar
información sobre los beneficios potenciales y
las oportunidades de explotación existentes para
las actualizaciones de tecnología planificadas. En
la medida de lo posible, deberían detallarse los
beneficios anticipados de la disponibilidad, basados en
medidas centradas en el negocio, junto con Gestión
de la Capacidad. También debería cuantificarse el
esfuerzo requerido para materializar estos beneficios.
Durante la elaboración del Plan de Disponibilidad, se
recomienda colaborar con todas las áreas funcionales,
técnicas y de proceso. El Plan de Disponibilidad debería
abarcar un periodo de uno a dos años, con una visión más
detallada e información de los últimos seis meses. El plan
debería revisarse periódicamente, con revisiones menores
trimestrales y revisiones principales cada semestre. En
los casos en los que la tecnología sólo se vea sujeta a
un nivel bajo de cambio, se puede ampliar según resulte
adecuado.
Se recomienda considerar el Plan de Disponibilidad
como un complemento del Plan de Capacidad y el Plan
Financiero, y que la publicación esté alineada con la
capacidad y el ciclo presupuestario del negocio. Si se
prevé demanda para niveles elevados de disponibilidad
que no se pueden cumplir debido a las restricciones
de la infraestructura de TI o del presupuesto existentes,
entonces pueden requerirse informes de excepciones
para llamar la atención de la dirección senior de TI y del
negocio.
824_005 Chapter 04.indd 133
Procesos de Diseñ̃o del Servicio | 133
Para facilitar la elaboración del Plan de Disponibilidad, es
posible que Gestión de la Disponibilidad desee contar con
su propio repositorio de base de datos. El AMIS puede
servir para registrar y almacenar datos e información
requeridos a fin de respaldar actividades clave, como la
elaboración de informes, análisis estadístico, previsión
y planificación de la disponibilidad. El AMIS debería ser
el principal repositorio para el registro de las métricas,
medidas, objetivos y documentos de la disponibilidad
de TI, incluyendo el Plan de Disponibilidad, medidas de
disponibilidad, informes de logros, informes de asignación
SFA, criterios de diseño, planes de acción y planificaciones
de pruebas.
Sugerencias y consejos
Sea pragmático, defina los requisitos iniciales de la
herramienta e identifique qué hay ya desplegado que
pueda ser utilizado y compartido para comenzar con
la mayor brevedad. Cuando aún no haya herramientas
básicas disponibles, trabaje con el otro servicio de
TI y procesos de gestión del servicio para identificar
requisitos comunes con el objetivo de seleccionar y
minimizar costes compartidos. El AMIS debería abordar
las necesidades de información específicas de Gestión
de la Disponibilidad que aún no estén cubiertas por
los repositorios existentes, e integrarlas con ellos y sus
contenidos.
4.4.9  Desafíos, Factores Críticos de Éxito y
riesgos
Gestión de la Disponibilidad se enfrenta a muchos
desafíos, pero probablemente el principal de ellos es
cumplir realmente las expectativas de los clientes, del
negocio y de la gestión senior. Estas expectativas se basan
en que los servicios estarán siempre disponibles, no sólo
durante sus horas de servicio acordadas, sino que todos
los servicios estarán disponibles 24 horas al día, 365 días
al año. Cuando no sea así, se asume que se recuperarán
en unos minutos. Esto sólo es el caso si se ha aplicado
el nivel de inversión y diseño adecuado al servicio, y
sólo debería realizarse cuando el impacto en el negocio
justifique ese nivel de inversión. Sin embargo, el mensaje
debe ser comunicado a todos los clientes y áreas del
negocio para que, cuando los servicios fallen, tengan el
nivel de expectativas adecuado sobre su recuperación.
Esto también implica que Gestión de la Disponibilidad
debe tener acceso al nivel adecuado de información de
calidad sobre la necesidad de negocio actual de servicios
de TI y de sus planes para el futuro. Este es otro desafío
al que se enfrentan muchos procesos de Gestión de la
Disponibilidad.
22/1/10 13:49:39
 134 | Procesos de Diseñ̃o del Servicio
Otro desafío al que se enfrenta Gestión de la
Disponibilidad es la integración de todos los datos de
disponibilidad dentro de un conjunto integrado de
información (AMIS) que se pueda analizar de forma
consistente para proporcionar detalles sobre el uso
de todos los servicios y componentes. Esto representa
un reto particular cuando diferentes herramientas en
distintos formatos proporcionan información procedente, a
menudo, de diversas tecnologías.
Otro desafío adicional al que se enfrenta Gestión de la
Disponibilidad es convencer al negocio y a la gestión
senior de la inversión que se requiere para las medidas
de disponibilidad proactivas. La inversión siempre se
acepta cuando ya se han producido fallos, pero en ese
momento ya es demasiado tarde. Convencer a negocios
y clientes para invertir en capacidad de recuperación que
evite la posibilidad de que se produzcan fallos es un duro
desafío. Gestión de la Disponibilidad debería trabajar
estrechamente con Gestión de la Continuidad del Servicio,
Gestión de la Seguridad y Gestión de la Capacidad para
elaborar las justificaciones necesarias que aseguren la
inversión apropiada.
Los CSF principales para el proceso Gestión de la
Disponibilidad son:
■■ Gestionar la disponibilidad y fiabilidad del servicio de
TI
■■ Satisfacer las necesidades del negocio de acceso a
servicios de TI
■■ Disponibilidad de la infraestructura de TI, tal y como
se documenta en SLAs, proporcionada a costes
óptimos.
Algunos de los riesgos principales asociados con Gestión
de la Disponibilidad incluyen:
■■ Falta de compromiso del negocio respecto al proceso
de Gestión de la Disponibilidad
■■ Falta de compromiso del negocio y falta de
información adecuada sobre planes y estrategias
futuros
■■ Falta de compromiso de la gestión senior o falta de
recursos y/o presupuesto para el proceso Gestión de
la Disponibilidad
■■ El proceso de información requiere mucha mano de
obra
■■ Los procesos se centran demasiado en la tecnología y
no lo suficiente en los servicios y en las necesidades
del negocio
■■ La información de Gestión de la Disponibilidad
(AMIS) se mantiene aislada y no se comparte o no es
consistente con otras áreas del proceso, especialmente
824_005 Chapter 04.indd 134
ITSCM, Gestión de la Seguridad y Gestión de
la Capacidad. Esta inversión es particularmente
importante cuando se tienen en cuenta las
herramientas, tecnología, procesos de backup y
recuperación del servicio y del componente para
satisfacer las necesidades acordadas.
4.5  Gestión de la Continuidad del
Servicio de TI
4.5.1  Propósito/meta/objetivo
‘La meta de ITSCM es respaldar el proceso general de
Gestión de la Continuidad del Negocio asegurando que
las instalaciones técnicas y del servicio de TI requeridas
(que incluyen sistemas informáticos, redes, aplicaciones,
repositorios de datos, telecomunicaciones, entorno, soporte
técnico y Centro de Servicio al Usuario) puedan reanudarse
según los plazos de tiempo de negocio requeridos y
acordados’.
Puesto que la tecnología es un componente central de
la mayoría de los procesos de negocio, la disponibilidad
alta o continua de TI es crítica para la supervivencia del
negocio en su totalidad. Esto se consigue introduciendo
medidas de reducción del riesgo y opciones de
recuperación. Al igual que todos los elementos de ITSM,
sólo puede realizarse con éxito la implementación de
ITSCM con el compromiso de la gestión senior y con el
respaldo de todos los miembros de la organización. El
mantenimiento continuo de la capacidad de recuperación
es esencial si se desea que este éxito se mantenga.
El propósito de ITSCM es mantener la capacidad de
recuperación continua necesaria dentro de los servicios de
TI y sus componentes de soporte.
Los objetivos de ITSCM son:
■■ Mantener un conjunto de Planes de Continuidad
de los Servicios y planes de recuperación de TI que
respalden los Planes de Continuidad del Negocio
(BCPs) generales de la organización
■■ Completar ejercicios regulares de Análisis de Impacto
en el Negocio (BIA) para asegurar que se mantengan
todos los planes de continuidad alineados con los
impactos y requisitos cambiantes del negocio
■■ Realizar ejercicios regulares de Análisis y Gestión del
Riesgo, especialmente junto con el negocio y los
procesos de Gestión de la Disponibilidad y Gestión de
la Seguridad, que gestionen los servicios de TI dentro
de un nivel de riesgo de negocio acordado
■■ Proporcionar asesoramiento y directrices a todas las
demás áreas del negocio y de TI en todos los aspectos
relacionados con la continuidad y la recuperación
22/1/10 13:49:39

■■ Asegurar que se pongan en práctica los mecanismos
de continuidad y recuperación adecuados para
satisfacer o superar los objetivos de continuidad del
negocio acordados
■■ Evaluar el impacto de todos los cambios sobre los
Planes de Continuidad de los Servicios y planes de
recuperación de TI
■■ Asegurar que se implementen medidas proactivas para
mejorar la disponibilidad de los servicios siempre que
tengan un coste justificable
■■ Negociar y acordar los contratos necesarios con
suministradores para la provisión de la capacidad de
recuperación necesaria para dar apoyo a todos los
planes de continuidad junto con el proceso de Gestión
de Suministradores.
4.5.2 Ámbito
ITSCM se centra en los eventos a los que el negocio
concede suficiente importancia como para que se
consideren un desastre. Los eventos menos importantes se
abordarán dentro del proceso de Gestión de Incidencias.
La definición de qué constituye un desastre diferirá de
una organización a otra. El impacto de una pérdida de un
proceso de negocio, por ejemplo una pérdida financiera,
daño a la reputación o incumplimiento regulatorio,
se mide a través de un ejercicio BIA, que determina
los requisitos críticos mínimos. ITSCM ofrece soporte a
los requisitos técnicos de TI y de servicio específicos.
El ámbito de ITSCM dentro de una organización se
determina a través de la estructura organizativa, cultura
y dirección estratégica (del negocio y la tecnología) en
términos de servicios provistos y cómo se desarrollan y
cambian con el paso del tiempo.
ITSCM tiene en cuenta principalmente los activos y
configuraciones de TI que respaldan los procesos de
negocio. Si (después de un desastre) se requiere reasignar
a una ubicación de trabajo alternativa, también se
requerirá la provisión de elementos como instalaciones y
alojamiento para el personal, copias de registros en papel
críticos, servicios de mensajería e instalaciones telefónicas
para comunicarse con clientes y terceros.
El ámbito tendrá que tener en cuenta el número y
ubicación de las oficinas de la organización y los servicios
realizados en cada una.
Normalmente, ITSCM no cubre directamente riesgos a
más largo plazo, como los de los cambios en la dirección
del negocio, diversificación, reestructuración, fallo de
un competidor principal y demás. Aunque estos riesgos
pueden tener un impacto importante en los elementos
del servicio de TI y sus mecanismos de continuidad,
824_005 Chapter 04.indd 135
Procesos de Diseñ̃o del Servicio | 135
normalmente hay tiempo para identificar y evaluar
el riesgo e incluir la mitigación del riesgo a través de
cambios o variaciones en las estrategias del negocio y TI,
formando parte en consecuencia del programa de Gestión
de Cambios general del negocio y TI.
De forma similar, ITSCM no trata normalmente fallos
técnicos menores (por ejemplo, fallo de disco no crítico),
a menos que exista la posibilidad de que el impacto
pueda tener un efecto importante en el negocio. Se
esperaría que estos riesgos se cubriesen principalmente
a través del Centro de Servicio al Usuario y del proceso
de Gestión de Incidencias, o que se resoviesen a través
de la planificación asociada con los procesos de Gestión
de la Disponibilidad, Gestión de Problemas, Gestión de
Cambios, Gestión de la Configuración y de la gestión
operativa ‘rutinaria’.
El proceso ITSCM incluye:
■■ El acuerdo del ámbito del proceso ITSCM y las
políticas adoptadas.
■■ Análisis de Impacto en el Negocio (BIA) para
cuantificar el impacto que tendría la pérdida del
servicio de TI sobre el negocio.
■■ Análisis de Riesgo (RA) – identificación y evaluación
del riesgo para identificar amenazas potenciales en la
continuidad y la probabilidad de que las amenazas se
materialicen. También incluye la adopción de medidas
para gestionar las amenazas identificadas cuando se
justifique su coste.
■■ Elaboración de una estrategia de ITSCM general
que debe integrarse en la estrategia de BCM. Puede
elaborarse siguiendo los dos pasos identificados
anteriormente, y es probable que se incluyan
elementos de reducción del riesgo, así como la
selección de opciones de recuperación adecuadas e
integrales.
■■ Elaboración de un plan de ITSCM, que de nuevo debe
integrarse con los planes generales de BCM.
■■ Pruebas de los planes.
■■ Operación y mantenimiento continuo de los planes.
4.5.3  Valor para el negocio
ITSCM proporciona un rol inestimable en el respaldo del
proceso de Planificación de la Continuidad del Negocio. En
muchas organizaciones, ITSCM sirve para concienciar sobre
los requisitos de continuidad y recuperación y a menudo
se usa para justificar e implementar un proceso de
Planificación y Planes de Continuidad del Negocio. ITSCM
se debería dirigir por el riesgo de negocio identificado por
la Planificación de la Continuidad del Negocio, y asegura
que los acuerdos de recuperación de los servicios de TI
22/1/10 13:49:39
 136 | Procesos de Diseñ̃o del Servicio
Ciclo de Vida
Gestión de
la Continuidad Iniciación
del Negocio
(BCM)
Requisitos
Estrategia
de Continuidad y estrategia
del Negocio
Planes
de Continuidad
del Negocio Implementación
Operación
Invocación continua
Figura 4.21  Ciclo de vida de Gestión de la Continuidad del Servicio
estén alineados con los impactos, riesgos y necesidades de
negocio.
4.5.4  Políticas/principios/conceptos básicos
Debería adoptarse una metodología de ciclo de vida a la
configuración y operación de un proceso ITSCM. La Figura
4.21 muestra el ciclo de vida de ITSCM, desde el inicio
hasta el aseguramiento continuo de que la protección
provista por el plan está actualizada y refleja todos los
cambios en los servicios y niveles de servicio. ITSCM es un
proceso cíclico a lo largo del ciclo de vida para asegurar
que, una vez se hayan desarrollado planes de continuidad
y recuperación, se mantengan alineados con los Planes de
continuidad del negocio (BCPs) y prioridades del negocio.
La Figura 4.21 también muestra el rol desempeñado
dentro del proceso ITSCM de BCM.
Las etapas de iniciación y requisitos son principalmente
actividades de BCM. ITSCM sólo debería involucrarse
en estas etapas para respaldar las actividades de BCM y
entender la relación entre los procesos de negocio y los
impactos que provoca la pérdida del servicio de TI sobre
los mismos. Como resultado de estas actividades BIA y
de Análisis de Riesgo iniciales, BCM debería elaborar una
Estrategia de Continuidad del Negocio, y la primera tarea
real de ITSCM es elaborar una estrategia de ITSCM que
respalde a la estrategia de BCM y sus necesidades.
824_005 Chapter 04.indd 136
Actividades clave
Establecimiento de la política
Ámbito
Iniciar un proyecto
Análisis del Impacto en el Negocio
Evaluación del Riesgo
Estrat. de Contin. del Servicio de TI
Desarrollo Planes Cont. Servicio de TI
Desarrollar planes de TI, planes y
procedimientos de recuperación
Planificación de la Organización
Estrategia de pruebas
Educación, concienciación y formación
Revisión y auditoría
Pruebas
Gestión de Cambios
La Estrategia de Continuidad del Negocio debería
centrarse principalmente en los procesos de negocio
y problemas asociados (por ejemplo, continuidad del
proceso de negocio, continuidad del personal, continuidad
de los edificios). Una vez se haya elaborado la Estrategia
de Continuidad del Negocio, y se haya determinado el
rol que los servicios de TI deben desempeñar dentro de
la estrategia, puede elaborarse una estrategia de ITSCM
que respalde y permita la Estrategia de Continuidad del
Negocio. Esto asegura que se puedan tomar decisiones
rentables que tengan en cuenta todos los ‘recursos’ para
proveer un proceso de negocio. En caso de hacerse lo
anterior, puede existir la tendencia a fomentar opciones de
ITSCM que sean más rápidas, más elaboradas y caras de lo
que en realidad se necesita.
Las actividades a considerar durante la iniciación
dependen del grado de aplicación de las instalaciones
de continuidad dentro de la organización. Es posible
que algunas partes del negocio hayan establecido
Planes de Continuidad del Negocio individuales basados
en soluciones provisionales manuales, y que TI haya
desarrollado planes de continuidad para los sistemas
que se consideren críticos. Esta es una buena entrada al
proceso. Sin embargo, la eficacia de ITSCM depende del
soporte de funciones críticas de negocio. La única forma
de implementar ITSCM de forma eficaz es realizarlo a
través de la identificación de procesos de negocio críticos
y el análisis y coordinación de la tecnología y los servicios
de Soporte de TI requeridos.
22/1/10 13:49:39

Esta situación puede ser aún más complicada en
situaciones de externalización en las que un proceso de
ITSCM dentro de un suministrador externo de servicios
u organización de externalización no sólo tiene que
satisfacer las necesidades del proceso BCM y estrategia
del cliente, sino también las del proceso BCM y estrategia
de la propia organización de externalización. Estas
necesidades pueden entrar en conflicto entre sí, o con
las necesidades de BCM de uno de los clientes de la
organización de externalización.
Sin embargo, en muchas organizaciones no existe BCM
o existe muy poco enfoque en el mismo, y a menudo se
requiere ITSCM para cumplir muchos de los requisitos
y actividades de BCM. El resto de esta sección ha
asumido que ITSCM ha tenido que realizar muchas de
las actividades requeridas por BCM. Cuando se haya
establecido un proceso BCM con Estrategias y Planes de
Continuidad del Negocio en práctica, estos documentos
deberían proporcionar el enfoque e impulso para
establecer ITSCM.
4.5.5 Actividades, métodos y técnicas del
proceso
Las siguientes secciones contienen detalles de cada una
de las etapas del ciclo de vida de ITSCM.
4.5.5.1   Etapa 1 – Iniciación
El proceso de iniciación cubre la totalidad de la
organización y consta de las siguientes actividades:
■■ Definición de la política – debería definirse y
comunicarse lo antes posible para que todos los
miembros de la organización implicados en, o
afectados por, problemas de Continuidad del Negocio
sean conscientes de sus responsabilidades para
cumplir y respaldar ITSCM. Como mínimo, la política
debería determinar la intención y los objetivos de la
gestión.
■■ Especificar términos de referencia y ámbito – se
incluye la definición del ámbito y las responsabilidades
de todo el personal de la organización. Cubre tareas
tales como realizar un Análisis del Riesgo y Análisis
de Impacto en el Negocio y la determinación de la
estructura de orden y control requerida para respaldar
una interrupción del negocio. También existe la
necesidad de tener en cuenta problemas como
puntos de auditoría pendientes, requisitos regulatorios
o del cliente y estipulaciones de la organización
aseguradora, y conformidad con normas como ISO
27001, el Estándar sobre Gestión de la Seguridad de
la Información, que también aborda requisitos de
Continuidad del Negocio.
824_005 Chapter 04.indd 137
Procesos de Diseñ̃o del Servicio | 137
■■ Asignar recursos – el establecimiento de un
entorno de Continuidad del Negocio eficaz requiere
considerables recursos tanto económicos como de
personal. En función de la madurez de la organización
con respecto a ITSCM, puede existir el requisito de
familiarizar y/o formar al personal para realizar las
tareas de la Etapa 2. De forma alternativa, el uso de
consultores externos experimentados puede ayudar
a realizar el análisis con mayor rapidez. No obstante,
es importante que la organización pueda mantener el
avance del proceso sin la necesidad de confiar, total o
parcialmente, en soporte externo.
■■ Definir la organización del proyecto y la
estructura de control – los proyectos de ITSCM y
BCM son potencialmente complejos y deben estar
bien organizados y controlados. Se recomienda
encarecidamente utilizar una metodología de
planificación de proyectos estándar y reconocida,
como Proyectos en Entornos controlados (PRINCE2®) o
Project Management Body Of Knowledge (PMBOK®).
■■ Acordar planes de proyecto y de calidad – los
planes permiten controlar el proyecto y abordar las
variaciones. Los planes de calidad garantizan que
se consigan los resultados con un nivel de calidad
aceptable. También facilitan un mecanismo para
comunicar los requisitos de recursos y entregables del
proyecto, obteniéndose de esta forma la aceptación
de las partes necesarias.
4.5.5.2  Etapa 2 – Requisitos y estrategia
La determinación de los requisitos de negocio para la
continuidad del servicio de TI es un componente crítico
para identificar la eficacia con la que una organización
sobrevivirá a una interrupción del negocio o desastre y los
costes en los que incurrirá. Si el análisis de los requisitos
es incorrecto, o se ha perdido información clave, podrían
producirse graves consecuencias en la eficacia de los
mecanismos de ITSCM.
Esta etapa puede dividirse eficazmente en dos secciones:
■■ Requisitos – realizar un Análisis de Impacto en el
Negocio y una evaluación del riesgo
■■ Estrategia – después del análisis de los requisitos,
la estrategia debería documentar las medidas
requeridas de reducción del riesgo y las opciones de
recuperación para respaldar al negocio.
Requisitos – Análisis de Impacto en el Negocio
El propósito de un Análisis de impacto en el negocio
es cuantificar el impacto en el negocio que tendría la
pérdida de servicio. Este impacto podría ser ‘tangible’ ya
que puede identificarse con precisión, como por ejemplo
22/1/10 13:49:39
 138 | Procesos de Diseñ̃o del Servicio
una pérdida financiera, o ‘intangible’, como por ejemplo
relaciones públicas, moral, seguridad y salud o pérdida de
ventaja competitiva. El BIA identificará los servicios más
importantes para la organización y, en consecuencia, será
una entrada clave para la estrategia.
El BIA identifica:
■■ La forma que el daño o pérdida puede adoptar, por
ejemplo:
●● Pérdida de ingresos
●● Costes adicionales
●● Daño a la reputación
●● Pérdida de fondo de comercio
●● Pérdida de ventaja competitiva
●● Incumplimiento de la ley, seguridad y salud
●● Riesgo para la seguridad personal
●● Pérdida de cuota de mercado inmediata y a largo
plazo
●● Bochorno político, corporativo o personal
●● Pérdida de capacidad operativa – por ejemplo, en
un entorno de orden y control
Crítico
Preventivo – reducción del riesgo
Alto
Impacto
Medio
Bajo
1 Semana 2 Semanas
Figura 4.22  Representación gráfica de impactos de negocio
824_005 Chapter 04.indd 138
■■ Probabilidad de escalado del grado de daño o pérdida
después de una interrupción del servicio y las horas
del día, semana, mes o año en la que la interrupción
será más grave
■■ Plantilla, habilidades, instalaciones y servicios
(incluyendo los servicios de TI) necesarios para
permitir que procesos de negocio críticos y esenciales
continúen operando en un nivel mínimo aceptable
■■ El tiempo en el que deberían recuperarse los niveles
mínimos de personal, instalaciones y servicios
■■ El tiempo en el que deberían recuperarse por
completo todos los procesos de negocio, personal,
instalaciones y servicios requeridos
■■ La prioridad de recuperación de negocio relativa para
cada uno de los servicios de TI.
Una de las salidas clave de un ejercicio BIA es un gráfico
del impacto de negocio anticipado provocado por la
pérdida de un proceso de negocio o por la pérdida de
un servicio de TI en el tiempo, tal y como se ilustra en la
Figura 4.22.
Por lo tanto, este gráfico puede emplearse para impulsar
las estrategias y planes de continuidad de negocio y
Equilibrado
Continuidad – recuperación
3 Semanas 4 Semanas 5 Semanas
Tiempo
22/1/10 13:49:40

TI. Es necesario adoptar medidas más preventivas en
esos procesos y servicios con impactos más próximos
y elevados, mientras que debería ponerse un mayor
énfasis en las medidas de continuidad y recuperación
para aquellos en los que el impacto sea menor y se tarde
más tiempo en desarrollar. Debería adoptarse un enfoque
equilibrado de ambas medidas en los casos intermedios.
Estos elementos proporcionan los impulsores para el
nivel de mecanismos de ITSCM que se deben considerar
o desplegar. Una vez se presentan estas opciones, el
negocio puede decidir que pueden ser más aceptables
niveles de servicio inferiores o mayores retrasos, en
función de un análisis coste-beneficio, o es posible que
se tengan que implementar medidas de prevención de
desastres integrales.
Estas evaluaciones permiten la asignación de componentes
críticos de aplicaciones, servicios y tecnologías a procesos
de negocio críticos, lo cual contribuye a identificar los
elementos de ITSCM que es necesario proporcionar.
Los requisitos de negocio se clasifican, y se confirman y
priorizan los elementos de ITSCM asociados en términos
de reducción del riesgo y planificación de la recuperación.
Los resultados del BIA, comentados anteriormente, son
una entrada inestimable para varias áreas de diseño del
proceso, incluyendo Gestión del Nivel de Servicio para
entender los niveles de servicio requeridos.
Los impactos deberían medirse con respecto a escenarios
particulares para cada proceso de negocio, como por
ejemplo una incapacidad para liquidar intermediaciones
en un proceso de negociación en el mercado monetario, o
la incapacidad para facturar durante un periodo de varios
días. Un ejemplo es un entorno de negociación en el
mercado monetario en el que la pérdida de información
de datos del mercado podría implicar que la organización
comenzase a perder dinero inmediatamente al no poder
continuar su intermediación. Además, los clientes pueden
marcharse a otra organización, lo cual podría implicar una
pérdida potencial de negocio. La pérdida del sistema de
liquidación no impide que se realice la intermediación
pero, si no pueden liquidarse las intermediaciones ya
realizadas dentro de un periodo de tiempo especificado,
la organización podría incumplir normas regulatorias o
periodos de liquidación y sufrir multas y daños en su
reputación. En realidad, este impacto puede ser más
importante que la incapacidad para intermediar, debido a
la incapacidad para cumplir las expectativas de los clientes.
También es importante entender cómo pueden cambiar
los impactos con el tiempo. Por ejemplo, es posible que
un negocio pueda funcionar sin un proceso particular
durante un breve periodo de tiempo. En un escenario
824_005 Chapter 04.indd 139
Procesos de Diseñ̃o del Servicio | 139
equilibrado, se producirán impactos en el negocio que
pueden hacerse más importantes con el paso del tiempo.
Sin embargo, no todas las organizaciones se ven afectadas
de esta forma. En algunas organizaciones, los impactos
no se perciben inmediatamente. No obstante, en cierto
momento, en el caso de cualquier organización, los
impactos se acumularán hasta un nivel tal que impedirá
que el negocio pueda continuar operando. ITSCM asegura
que se identifiquen las opciones de contingencia para que
se puedan aplicar las medidas apropiadas en el momento
adecuado para mantener en un nivel mínimo los impactos
de negocio debidos a la interrupción del servicio.
Al realizar un BIA, es importante obtener las visiones de
los representantes senior del área de negocio sobre el
impacto posterior a una pérdida de servicio. También
es igual de importante que se obtengan las visiones
del personal de supervisión y del personal con menos
experiencia para asegurar que se determinen todos
los aspectos del impacto posteriores a una pérdida de
servicio. A menudo, niveles diferentes de personal tendrán
visiones diferentes sobre el impacto, y todas las visiones
deberán ser tenidas en cuenta al elaborar la estrategia
general.
En muchas organizaciones será imposible, o no podrá
justificarse en coste la recuperación total del servicio en
un plazo de tiempo muy reducido. En muchos casos, los
procesos de negocio pueden reestablecerse sin la totalidad
de personal, sistemas y otras instalaciones requeridos, y
continuarán manteniendo un nivel de servicio aceptable
para clientes y consumidores. En consecuencia, los
objetivos de recuperación del negocio deberían estipularse
en términos de:
■■ El tiempo en el cual deben recuperarse un equipo
esencial predefinido de personal y las instalaciones
mínimas estipuladas
■■ El calendario de recuperación del personal y las
instalaciones restantes.
Podría ocurrir que no siempre fuera posible proporcionar
requisitos de recuperación hasta un nivel detallado. Existe
la necesidad de equilibrar el impacto potencial con el
coste de recuperación para asegurar que los costes sean
aceptables. No obstante, los objetivos de recuperación
proporcionan un punto de inicio desde el cual pueden
evaluarse diferentes opciones de recuperación del negocio
y de ITSCM.
Requisitos – Análisis de Riesgo
El segundo impulsor en la determinación de los requisitos
de ITSCM es la probabilidad de que realmente se produzca
un desastre u otras interrupciones graves del servicio. Ésta
22/1/10 13:49:40
 140 | Procesos de Diseñ̃o del Servicio

es una evaluación del nivel de amenaza y el grado hasta

Más grave
el cual una organización es vulnerable a esa amenaza. Incendio/
Análisis de Riesgo también puede servir para evaluar y Daño por
explosión
reducir la oportunidad de que se produzcan incidencias Fuga química tormenta Pérdida de

Gravedad/Impacto
operativas normales y es una técnica que utiliza Gestión PBX/
ACD
de la Disponibilidad para asegurar que se mantengan los
Fallo Fallo
niveles requeridos de disponibilidad y fiabilidad. Análisis del de
de Riesgo es también un aspecto clave de Gestión de servidor red
importante Robo
la Seguridad de la Información. El proceso Gestión de la
Disponibilidad, en la sección 4.4, contiene un diagrama Riesgo
aceptable
sobre Análisis y Gestión del Riesgo (Figura 4.20). Fallo de

Menos grave
alimentación
Existen diversos métodos de Análisis y Gestión del Riesgo
Vertido
disponibles para el sector comercial y el sector público. Base de datos de café en
Análisis de Riesgo es la evaluación de los riesgos que corrupta el PC
pueden dar lugar a una interrupción del servicio o a una
violación de seguridad. Gestión del Riesgo se preocupa de Menos probable Riesgo Más probable
aceptable
identificar respuestas adecuadas al riesgo o contramedidas Probabilidad de ocurrencia
justificables en coste para luchar contra esos riesgos.
Debería emplearse una metodología estándar, como por Figura 4.24  Ejemplo de resumen de perfil de riesgo
ejemplo Gestión del Riesgo (MoR), para evaluar y gestionar
●● Política de Gestión del Riesgo
riesgos dentro de una organización. El marco de trabajo
●● Guía del Proceso
de MoR se ilustra en la Figura 4.23.
●● Planes
La metodología de MoR se basa en el marco de trabajo ●● Registros del riesgo
anterior, que consta de lo siguiente:
●● Registros de Problemas.
■■ Principios MoR: estos principios son esenciales para el ■■ Procesos de MoR: los siguientes cuatro pasos
desarrollo de la buena práctica de gestión del riesgo y principales describen las entradas, salidas y actividades
emanan de los principios de gobierno corporativo. que aseguran que se controlen los riesgos:
■■ Metodología MoR: es necesario acordar y definir una ●● Identificar: las amenazas y oportunidades dentro
metodología de la organización para estos principios de una actividad que podría impactar en la
dentro de los siguientes documentos activos: capacidad para alcanzar su objetivo
●● Evaluar: la comprensión del efecto individual de
las amenazas identificadas y las oportunidades
Principios de Rie
n de sgo asociadas cuando se juntan varias amenazas
e stió
G rar y Revisar
Integ
Méto
do do M
oR ●● Planificar: preparar una respuesta de gestión
Reg MoR Méto istro
de R istro R e g
mas específica que reducirá las amenazas y maximizará
iesg roble
os de P
Implementar las oportunidades
Identificar
●● Implementar: las acciones de gestión del riesgo
planificadas; monitorizar su eficacia y adoptar
Comunicar
acciones correctivas cuando las respuestas no
M coincidan con las expectativas.
Planificar Pla étod
nd oM
Evaluar de e Ge oR ■■ Integrar y revisar MoR: una vez puestos en práctica
R i e stió
sgo n
oR s los principios, metodología y procesos, éstos deben
o M tión
é tod e Ges revisarse y mejorarse de forma continua para asegurar
M a d gos
ític ies
Pol de R que mantienen su eficacia.
■■ Comunicación: contar con las actividades de
Guía del Proceso de
Gestión de Riesgos
Método MoR

comunicación adecuadas para asegurar que todos

los interesados se mantengan informados sobre los
cambios en las amenazas, actividades y cualquier otro
aspecto de gestión del riesgo.
Figura 4.23  Gestión del Riesgo

824_005 Chapter 04.indd 140 22/1/10 13:49:40


Este método de MoR requiere la evaluación de riesgos y el
desarrollo de un perfil de riesgo, como el ejemplo que se
muestra en la Figura 4.24.
La Figura 4.24 muestra un ejemplo de perfil de riesgo
que contiene muchos riesgos que se quedan fuera
del nivel definido de ‘riesgo aceptable’. El Análisis de
Riesgo permite determinar las respuestas adecuadas o
medidas de reducción del riesgo (mecanismos ITSCM)
para gestionar los riesgos, esto es, reducir el riesgo hasta
un nivel aceptable o mitigarlo. Siempre que sea posible,
deberían implementarse respuestas adecuadas al riesgo
para reducir el impacto, la probabilidad, o ambos, de que
Tabla 4.1 Ejemplos de riesgos y amenazas
Riesgo
Pérdida de sistemas/redes de TI internas, PABXs, ACDs, etc.
Pérdida de sistemas/redes de TI externas, por ejemplo servidores
de comercio electrónico, sistemas criptográficos
Pérdida de datos
Pérdida de servicios de red
Indisponibilidad de personal técnico y de soporte clave
Fallo de proveedores de servicio, por ejemplo TI externalizada
824_005 Chapter 04.indd 141
Procesos de Diseñ̃o del Servicio | 141
estos riesgos se manifiesten. En el contexto de ITSCM,
existen diversos riesgos que es necesario tener en cuenta.
A continuación se muestra una lista que, aunque no es
completa, proporciona algunos ejemplos de riesgos y
amenazas que el proceso de ITSCM debe abordar.
Estrategia de Continuidad del Servicio de TI
Los resultados del Análisis de Impacto en el Negocio y del
Análisis de Riesgo permitirán que se elaboren estrategias
de Continuidad del Servicio de TI y del Negocio alineadas
con las necesidades del negocio. La estrategia será un
equilibrio óptimo de reducción de riesgo y opciones de
Amenaza
Incendio
Fallo de alimentación
Incendio provocado y vandalismo
Inundación
Impacto de un avión
Dan~os meteorológicos, por ejemplo, huracán
Desastre medioambiental
Ataque terrorista
Sabotaje
Fallo catastrófico
Dan~o eléctrico, por ejemplo, un rayo
Dan~o accidental
Software de poca calidad
Todas las anteriores
Demanda excesiva de servicios
Ataque de denegación de servicio, por ejemplo contra un firewall
de Internet
Fallo técnico, por ejemplo, de un sistema criptográfico
Fallo técnico
Error humano
Virus, software malicioso, por ejemplo ataques de applets
Dan~o o denegación de acceso a las instalaciones del proveedor de
servicio de red
Pérdida de los sistemas/redes de TI del proveedor de servicio
Pérdida de datos del proveedor de servicio
Fallo del proveedor de servicio
Huelga laboral
Denegación de acceso a instalaciones
Dimisión
Enfermedad/lesiones
Dificultades de transporte
Fallo comercial, por ejemplo insolvencia
Denegación de acceso a instalaciones
Indisponibilidad de personal del proveedor de servicio
Incumplimiento de niveles de servicio contractuales
22/1/10 13:49:40
 142 | Procesos de Diseñ̃o del Servicio
recuperación o continuidad. Esto incluye la consideración
de las prioridades relativas en la recuperación del servicio
y los cambios en la prioridad relativa del servicio para la
hora del día, día de la semana y las variaciones mensuales
y anuales. Los servicios que se hayan identificado con
impacto elevado a corto plazo dentro del BIA desearán
concentrar los esfuerzos en métodos preventivos de
reducción del riesgo, por ejemplo a través de la capacidad
de recuperación completa y la tolerancia a fallos, mientras
que, en el caso de una organización que tenga bajos
impactos a corto plazo, serían más adecuadas las opciones
integrales de recuperación, tal y como se describe en
las siguientes secciones. Puede encontrarse consejo y
guía similares en las Directrices de Buenas Prácticas del
Business Continuity Institute.
Medidas de respuesta al riesgo
La mayoría de las organizaciones tendrán que adoptar
un enfoque equilibrado en el se requiera reducción y
recuperación del riesgo de forma complementaria. Esto
implica la reducción, en la medida de lo posible, de los
riesgos en la provisión continua del servicio de TI, lo
cual se consigue normalmente a través de Gestión de la
Disponibilidad. Aunque la planificación sea adecuada, es
imposible eliminar todos los riesgos por completo. Por
ejemplo, un incendio en un edificio cercano puede llegar a
dañar, o al menos denegar el acceso como resultado de la
implementación de un cordón de seguridad. Como regla
general, la invocación de una capacidad de recuperación
sólo debería realizarse como último recurso. En un caso
ideal, una organización debería evaluar todos los riesgos
a fin de reducir el requisito potencial para recuperar el
negocio, que probablemente incluya los servicios de TI.
Se deberían implementar medidas de reducción del
riesgo y se deberían promover junto con Gestión de la
Disponibilidad, debido a que muchas de ellas reducen
la probabilidad de fallo que afecta a la disponibilidad
del servicio. Las medidas de reducción del riesgo típicas
incluyen:
■■ Instalación de SAI y alimentación de backup para el
ordenador
■■ Sistemas tolerantes a fallos para aplicaciones críticas
que no acepten ni siquiera un tiempo de caída
mínimo, por ejemplo un sistema bancario
■■ Arrays RAID y replicación de disco en servidores
LAN para evitar la pérdida de datos y asegurar la
disponibilidad continua de los mismos
■■ Equipos/componentes de reserva a emplear en caso
de fallo de equipos o componentes, por ejemplo,
un servidor LAN de reserva ya configurado con la
configuración estándar y disponible para sustituir a un
824_005 Chapter 04.indd 142
servidor defectuoso con un tiempo de construcción y
configuración mínimo
■■ La eliminación de SpoFs, como puntos de red de
acceso o suministro de alimentación únicos en un
edificio
■■ Sistemas y redes TI con capacidad de recuperación
■■ Servicios externalizados a más de un proveedor
■■ Mayores controles de seguridad físicos y basados en TI
■■ Mejores controles para detectar interrupciones del
servicio, como sistemas de detección de incendios
acoplados con sistemas de extinción
■■ Una estrategia de backup y recuperación integral,
incluyendo almacenamiento fuera del emplazamiento.
Las medidas anteriores no resolverán necesariamente un
problema de ITSCM ni eliminarán el riesgo totalmente,
pero todas o una combinación de ellas pueden reducir de
forma significativa los riesgos asociados con la forma en la
que se proveen los servicios al negocio.
Almacenamiento fuera del emplazamiento
Un método de respuesta al riesgo es asegurar que se
realiza una copia de seguridad de todos los datos vitales
y se almacena fuera del emplazamiento. Una vez que
se haya definido la estrategia de recuperación, debería
adoptarse e implementarse una estrategia de backup
adecuada para respaldarla. La estrategia de backup debe
incluir el traslado regular (probablemente diaria) de datos
(incluyendo el CMS para facilitar la recuperación) desde los
centros de datos principales hasta una ubicación adecuada
de almacenamiento fuera del emplazamiento. Esto
asegurará la recuperación de datos después de un fallo
operativo relativamente menor y después de desastres
totales y completos. Al igual que los datos electrónicos,
toda la información y documentos importantes deberían
almacenarse fuera del emplazamiento, siendo los planes
de ITSCM el principal ejemplo.
Opciones de recuperación de ITSCM
La estrategia de ITSCM de una organización es un
equilibrio entre el coste de las medidas de reducción del
riesgo y las opciones de recuperación que respaldan la
recuperación de procesos críticos de negocio dentro de
plazos de tiempo acordados. A continuación se presenta
una lista de las opciones potenciales de recuperación de TI
que es necesario considerar al desarrollar la estrategia.
Soluciones provisionales manuales
En el caso de ciertos tipos de servicios, las soluciones
provisionales manuales pueden ser una medida temporal
eficaz durante un periodo de tiempo limitado hasta que
se reanude el servicio de TI. Por ejemplo, un servicio de
22/1/10 13:49:40

registro de llamadas del Centro de Servicio al Usuario
podría sobrevivir durante un tiempo limitado utilizando
formularios en papel vinculados a un ordenador portátil
con una hoja de cálculo.
Acuerdos recíprocos
En el pasado, los acuerdos recíprocos eran medidas de
contingencia en las que se ponían en práctica acuerdos
con otra organización que utilizaba tecnología similar.
Esto ya no es eficaz ni posible para la mayoría de los
tipos de sistemas de TI, pero aún se puede utilizar en
casos específicos, por ejemplo establecer un acuerdo para
compartir instalaciones de impresión de alta velocidad.
Los acuerdos recíprocos también se pueden utilizar para
el almacenamiento de backups y otra información crítica
fuera del emplazamiento.
Recuperación gradual
Esta opción (denominada en ocasiones como ‘cold
standby’) incluye la provisión de una oficina completa,
equipada con alimentación, controles e infraestructura de
cableado de red local, conexiones de telecomunicaciones
y disponible en una situación de desastre para que una
organización instale sus propios equipos informáticos.
No incluye el equipo informático real, por lo que no es
aplicable para servicios que requieran una recuperación
rápida, debido a que se requiere tiempo de configuración
antes de que se pueda iniciar la recuperación de servicios.
Esta opción de recuperación sólo se recomienda para
servicios que puedan asumir un retardo de tiempo de
recuperación de días o semanas, no horas. Cualquier
servicio no crítico que pueda asumir este tipo de retardo
debería tener en cuenta el coste de esta opción frente al
beneficio para el negocio antes de determinar si debería
incluirse una opción de recuperación gradual en las
opciones de ITSCM para la organización.
El alojamiento se puede proveer comercialmente por
un tercero, a cambio de una tarifa, o puede ser privado
(establecido por la propia organización) y provisto como
un servicio fijo o portátil.
Una instalación portátil es normalmente un edificio
prefabricado provisto por un tercero y ubicado, cuando se
requiera, en un emplazamiento predeterminado acordado
con la organización. Esta ubicación puede ser otra
ubicación situada a cierta distancia del emplazamiento
inicial, posiblemente otro edificio propiedad de la
organización. Deberá planificarse el equipo informático
de sustitución, pero los suministradores de equipos
informáticos no siempre garantizan equipos de sustitución
dentro de un plazo de tiempo fijo, aunque podrían
hacerlo normalmente empleando sus mejores esfuerzos.
824_005 Chapter 04.indd 143
Procesos de Diseñ̃o del Servicio | 143
Recuperación intermedia
Esta opción (en ocasiones denominada ‘warm standby’)
la eligen las organizaciones que necesitan recuperar
instalaciones de TI dentro de un plazo de tiempo
predeterminado para evitar impactos en el proceso de
negocio. El tiempo predeterminado se habrá acordado
con el negocio durante el BIA.
Los más habitual es el uso de instalaciones comerciales,
que ofrecen organizaciones de recuperación externas
a diversos abonados, distribuyéndose el coste entre
esos abonados. A menudo, las instalaciones comerciales
incluyen operación, gestión de sistemas y soporte técnico.
El coste varía en función de las instalaciones solicitadas,
como procesadores, periféricos, comunicaciones y la
rapidez con la que se desea recuperar los servicios.
La ventaja de este servicio es que el cliente puede
acceder virtualmente al instante a un emplazamiento,
alojado en un edificio seguro, en caso de desastre. Debe
entenderse, no obstante, que la restauración de servicios
en el emplazamiento puede llevar algún tiempo, debido a
que pueden producirse retrasos mientras se reconfigura el
emplazamiento para la organización que solicita el servicio
y será necesario restaurar las aplicaciones y datos de los
backups.
Una desventaja potencial principal son las implicaciones
con respecto a la seguridad de la explotación de servicios
de TI en el centro de datos de un suministrador externo.
Es necesario tener esto en cuenta al planificar el uso
de este tipo de instalación. Por esta razón, la opción
de recuperación intermedia externa puede que no sea
adecuada en el caso de ciertas organizaciones.
Si se solicita el uso del emplazamiento, normalmente
existe una tarifa diaria por el uso del servicio en una
emergencia, aunque puede compensar con respecto al
coste adicional de aseguramiento del trabajo.
Se pueden proveer los servicios de recuperación
comerciales de una forma autónoma, portátil o
móvil cuando se provea un sistema acordado en el
emplazamiento de un cliente, dentro de un tiempo
acordado.
Recuperación Rápida
Esta opción (en ocasiones denominada ‘hot standby’)
permite la recuperación rápida y la restauración de
servicios y a menudo se provee como una ampliación de
la recuperación intermedia provista por un proveedor de
recuperación externo. Algunas organizaciones proveerán
sus propias instalaciones dentro de la organización, pero
en un emplazamiento alternativo al que se emplea para
las operaciones normales. Otras implementan sus propias
22/1/10 13:49:41
 144 | Procesos de Diseñ̃o del Servicio
ubicaciones secundarias internas en un emplazamiento
alternativo para proporcionar una mayor capacidad de
recuperación.
Cuando exista la necesidad de restaurar rápidamente un
servicio, se puede ‘alquilar’ espacio en el emplazamiento
de recuperación e instalar servidores o sistemas con
sistemas de aplicación y comunicaciones ya disponibles, y
datos duplicados desde los servidores operativos. En caso
de producirse un fallo del sistema, los clientes pueden
recuperar y conmutar a la instalación de backup con
poca pérdida de servicio. Esto normalmente implica el
reestablecimiento de los sistemas y servicios críticos en un
periodo de 24 horas.
Recuperación inmediata
Esta opción (también denominada en ocasiones como
‘hot standby’, ‘mirroring’, ‘equilibrio de la carga’ o
‘emplazamiento dividido’) permite la restauración
inmediata de los servicios sin pérdida del servicio. En
el caso de los servicios críticos para el negocio, las
organizaciones que requieran la operación continua
proporcionarán sus propias instalaciones dentro de la
organización, pero no en el mismo emplazamiento en
el que se realizan las operaciones normales. Se aplicará
una ‘ubicación dual’ de equipo de TI suficiente en una
ubicación propietaria o alojada para explotar el servicio
completo desde cualquier ubicación en caso de pérdida
de una instalación, sin pérdida de servicio para el cliente.
El segundo emplazamiento puede recuperarse mientras
se provee el servicio desde la ubicación operativa
individual. Esta es una opción cara, pero puede justificarse
Manual Inmediato
Centro de
Servicio Sí
al Usuario
Plantilla del
Sí
mainframe
Sistema
financiero
Sistema
distribuidor Sí
Figura 4.25  Ejemplo de conjunto de opciones de recuperación
824_005 Chapter 04.indd 144
para procesos de negocio críticos o VBFs en los que la
indisponibilidad durante un periodo breve de tiempo
podría provocar un impacto importante, o en los que no
sería adecuado explotar servicios de TI en las instalaciones
de un tercero por razones de seguridad o de otro tipo.
La instalación debe ubicarse de forma independiente y lo
suficientemente alejada del emplazamiento base como
para no verse perjudicada por un desastre que afecte a
esa ubicación. Sin embargo, estos servidores duplicados y
opciones de emplazamiento deberían implementarse en
estrecha colaboración con Gestión de la Disponibilidad
debido a que respaldan servicios con niveles de
disponibilidad elevados.
La estrategia probablemente sea incluir una combinación
de medidas de respuesta al riesgo y una combinación de
las opciones de recuperación anteriores, tal y como se
ilustra en la Figura 4.25.
La Figura 4.25 muestra que se han utilizado diversas
opciones para proporcionar continuidad del servicio. Un
ejemplo de la Figura 4.25 muestra que, inicialmente, la
continuidad del Centro de Servicio al Usuario se provee
mediante la aplicación de procesos manuales, como por
ejemplo un conjunto de formularios y, posiblemente,
una hoja de cálculo en un ordenador portátil, mientras
que los planes de recuperación para el servicio se
completan en un emplazamiento de ‘recuperación
rápida’ alternativo. Una vez que se encuentra operativo
el emplazamiento alternativo, el Centro de Servicio al
Usuario puede volver a usar el servicio de TI. Sin embargo,
el uso del emplazamiento de ‘recuperación rápida’
alternativo probablemente tenga una duración limitada,
Rápido Intermedio Gradual
Sí Sí Sí
Sí Sí
Sí Sí
Sí Sí
22/1/10 13:49:41

por lo que mientras se actúa temporalmente desde
este emplazamiento, es posible que el ‘emplazamiento
intermedio’ entre en operación y puedan transferirse las
operaciones a largo plazo al mismo.
Diferentes servicios dentro de una organización requieren
opciones distintas integradas con diferentes capacidades
de recuperación. Independientemente de la opción
elegida, será necesario justificar el coste de la solución.
Como regla general, cuanto más tiempo pueda sobrevivir
el negocio sin un servicio, más barata será la solución.
Por ejemplo, un sistema crítico de atención sanitaria que
requiera operación continua será muy costoso debido
a que será necesario eliminar la pérdida potencial de
servicio a través del uso de recuperación inmediata,
mientras que en el caso de un servicio cuya ausencia no
afecta gravemente al negocio durante aproximadamente
una semana podría ser respaldado por una solución más
económica, como por ejemplo recuperación intermedia.
Al igual que la recuperación del equipo informático, la
planificación debe incluir la recuperación del alojamiento
y la infraestructura para el personal de TI y del negocio.
Otras áreas a tener en cuenta incluyen servicios críticos
como alimentación, telecomunicaciones, agua, servicios
de mensajería, correo, registros en papel y material de
referencia.
Es importante recordar que la recuperación se basa en
una serie de acuerdos de recuperación, que incluyen el
alojamiento, procedimientos y personas, así como sistemas
y servicios de telecomunicaciones. La implementación de
los acuerdos de recuperación requiere ciertas acciones. Por
ejemplo:
■■ Negociación de las instalaciones de recuperación
de terceros y el establecimiento de un acuerdo
contractual
■■ Preparación y equipamiento del alojamiento de
recuperación
■■ Adquisición e instalación de sistemas informáticos de
recuperación.
4.5.5.3  Etapa 3 – Implementación
Una vez se haya aprobado la estrategia, deben elaborarse
los Planes de Continuidad de los Servicios de TI alineados
con los Planes de Continuidad del Negocio.
Deben desarrollarse planes de ITSCM para permitir
que la información necesaria para sistemas, servicios e
instalaciones críticas se continúe suministrando o sea
restablecida en un periodo de tiempo aceptable para
el negocio. El Apéndice K incluye un ejemplo de plan
de recuperación de ITSCM. Generalmente, los Planes de
824_005 Chapter 04.indd 145
Procesos de Diseñ̃o del Servicio | 145
Continuidad del Negocio se basan en la disponibilidad
de los servicios de TI, instalaciones y recursos. Como
consecuencia de lo anterior, los planes de ITSCM deben
abordar todas las actividades para asegurar que se
entreguen los servicios, instalaciones y recursos requeridos
en un estado operativo aceptable y que estén ‘ajustados
al propósito’ cuando sean aceptados por el negocio. Esto
no sólo incluye la restauración de servicios e instalaciones,
sino también el entendimiento de las dependencias entre
ellos, las pruebas requeridas antes de la entrega (pruebas
de rendimiento, funcionales, operativas y de aceptación) y
la validación de la integridad y consistencia de datos.
Debería tenerse en cuenta que los planes de continuidad
son algo más que simples planes de recuperación,
y deberían incluir documentación sobre las medidas
de capacidad de recuperación y las medidas que se
han puesto en práctica para permitir la recuperación,
junto con explicaciones de por qué se ha adoptado
una metodología particular (esto facilita las decisiones
si la invocación determina que la situación particular
requiere una modificación en el plan). Sin embargo, el
formato del plan debería permitir el acceso rápido a
la propia información de recuperación, posiblemente
como un anexo al que se pueda acceder directamente.
Todo el personal clave tiene acceso a copias de toda la
documentación de recuperación necesaria.
La gestión de distribución de los planes es importante
para asegurar que las copias estén disponibles para el
personal clave en todo momento. Los planes deberían ser
documentos controlados (manteniéndose los documentos
formalizados bajo el control de Gestión de Cambios y
Gestión de la Configuración) para asegurar que sólo
circulen las últimas versiones y cada destinatario debería
asegurarse de mantener una copia personal fuera del
emplazamiento.
El plan debería asegurar que se documenten por completo
todos los detalles relacionados con la recuperación de
servicios de TI después de un desastre. Debería incluir
detalles suficientes como para permitir que un técnico
no familiarizado con los sistemas pueda seguir los
procedimientos. Los planes de recuperación incluyen
detalles clave como el punto de recuperación de datos,
una lista de los sistemas dependientes, la naturaleza de
la dependencia y sus puntos de recuperación de datos,
requisitos de hardware y software del sistema, detalles de
la configuración y referencias a otra información relevante
o esencial sobre el servicio y los sistemas.
Es buena idea incluir una lista de comprobación que cubra
acciones específicas que se requieran durante todas las
etapas de recuperación para el servicio o sistema. Por
22/1/10 13:49:41
 146 | Procesos de Diseñ̃o del Servicio
ejemplo, después de que el sistema se haya restaurado a
un estado operativo, deberían realizarse comprobaciones
de conectividad, funcionalidad o consistencia e integridad
antes de transferir el servicio al negocio.
Hay diversos planes técnicos que pueden existir ya dentro
de una organización, y que documenten procedimientos
de recuperación de un fallo operativo normal. El desarrollo
y mantenimiento de estos planes será responsabilidad de
los equipos de especialistas, pero serán coordinados por
el equipo de Gestión de Continuidad del Negocio. Estos
planes serán apéndices o complementos útiles del plan
principal. Adicionalmente, los planes que será necesario
integrar con el BCP principal son:
■■ Plan de Respuesta a Emergencias: para interactuar
con todos los servicios y actividades de emergencia
■■ Plan de Evaluación de Daños: contiene detalles de
los contactos, procesos y planes de evaluación de
daños
■■ Plan de Salvamento: contiene información sobre
contactos, procesos y planes de salvamento
■■ Plan de Registros Vitales: detalles de todos los
registros e información, junto con su ubicación, que
son críticos para la operación continua del negocio
■■ Plan de Gestión de Crisis y de Relaciones Públicas:
planes sobre el comando y control de diferentes
situaciones de crisis y gestión de los medios y
relaciones públicas
■■ Plan de Alojamiento y Servicios: detalla la gestión
del alojamiento, instalaciones y servicios necesarios
para su operación continua
■■ Plan de Seguridad: muestra cómo se gestionarán
todos los aspectos de la seguridad en todas las
ubicaciones base y en los emplazamientos de
recuperación
■■ Plan Personal: contiene detalles sobre cómo se
gestionarán todos los problemas personales durante
una incidencia grave
■■ Plan de Comunicación: muestra cómo se tratarán y
gestionarán todos los aspectos de la comunicación
con todas las áreas y partes relevantes involucradas en
una incidencia grave
■■ Plan Financiero y de Administración: contiene
detalles de métodos y procesos alternativos
para obtener la posible autorización y acceso de
emergencia a los fondos esenciales durante una
incidencia grave.
Finalmente, cada área de negocio crítica es responsable
del desarrollo de un plan que especifique los individuos
que integrarán los equipos de recuperación y las tareas a
emprender al invocar los acuerdos de recuperación.
824_005 Chapter 04.indd 146
El Plan de ITSCM debe contener toda la información
necesaria para recuperar los sistemas de TI, redes y
sistemas de telecomunicaciones en caso de desastre
una vez se haya decidido realizar una invocación y, a
continuación, gestionar la operación de retorno a la
normalidad del negocio una vez se haya solucionado
la interrupción del servicio. Una de las entradas más
importantes al desarrollo del plan son los resultados del
Análisis de Impacto en el Negocio. Adicionalmente, será
necesario analizar otras áreas, como Acuerdos de Nivel
de Servicio (SLAs), requisitos de seguridad, instrucciones
operativas y procedimientos y contactos externos. Es
probable que se haya acordado un SLA independiente
con objetivos alternativos si se realiza la explotación en un
emplazamiento de recuperación después de un desastre.
Otras áreas que será necesario implementar después de la
aprobación de la estrategia son:
Planificación de la organización
Durante el proceso de recuperación de desastres, la
estructura organizativa será inevitablemente diferente de
la operación normal y se fundamenta en:
■■ Dirección ejecutiva – incluyendo al consejo de
gestión/ejecutivo senior, con autoridad y control
general dentro de la organización y responsable de
la gestión de crisis y de la interrelación con otros
departamentos, divisiones, organizaciones, medios,
reguladores, servicios de emergencia, etc.
■■ Coordinación – normalmente un nivel por debajo del
grupo ejecutivo y responsable de coordinar el esfuerzo
de recuperación general dentro de la organización
■■ Recuperación – una serie de equipos de recuperación
del negocio y del servicio, que representan funciones
de negocio críticas y servicios que es necesario
establecer para respaldar estas funciones. Cada equipo
es responsable de ejecutar los planes dentro de sus
propias áreas y de interrelacionarse con el personal,
clientes y terceros. Los equipos de recuperación
deberían agruparse por servicio de TI y aplicación
dentro de TI. Por ejemplo, el equipo de infraestructura
puede tener una o más personas responsables de
la recuperación de conexiones externas, servicios de
voz, redes de área local, etc. y los equipos de soporte
pueden dividirse por plataforma, sistema operativo o
aplicación. Además, las prioridades de recuperación
para el servicio, aplicación o sus componentes
identificadas durante el Análisis de Impacto en el
Negocio deberían documentarse dentro de planes de
recuperación y aplicarse durante su ejecución.
22/1/10 13:49:41

Pruebas
La experiencia ha evidenciado que los planes de
recuperación que no han sido probados en su totalidad
no funcionan según se desea, si es que llegan a funcionar.
Como consecuencia de ello, las pruebas son una parte
crítica del proceso de ITSCM general y la única forma
de asegurar que realmente se pondrán en práctica
la estrategia, acuerdos de recuperación, logística,
planes y procedimientos de recuperación del negocio
seleccionados.
El proveedor de servicio es responsable de asegurar que
los servicios de TI puedan recuperarse en los plazos de
tiempo requeridos con la funcionalidad y el rendimiento
necesario después de un desastre.
Existen cuatro tipos básicos de pruebas que se pueden
realizar:
■■ Pueden realizarse pruebas superficiales cuando se
haya elaborado el plan reuniendo simplemente a las
personas relevantes para ver si los planes funcionan al
menos de una forma simulada.
■■ Las pruebas completas deberían realizarse lo antes
posible después de la elaboración del plan, y a
intervalos regulares de al menos un año. Deberían
implicar a unidades de negocio para ayudar a proveer
la capacidad para recuperar los servicios de forma
adecuada. Deberían, en la medida de lo posible,
replicar una invocación real de todos los acuerdos de
standby y deberían implicar a partes externas si se
planifica hacer una invocación real. Las pruebas no
sólo deberían probar la recuperación de los servicios
de TI sino también la recuperación de los procesos
de negocio. Se recomienda que un observador
independiente registre todas las actividades de
las pruebas y los tiempos de recuperación del
servicio. La documentación del observador de
las pruebas será una entrada vital en la revisión
post mortem subsiguiente. Las pruebas completas
se pueden anunciar o no. La primera prueba del
plan probablemente será anunciada y planificada
cuidadosamente, pero los participantes clave pueden
encontrarse con pruebas subsiguientes sin previo
aviso. También es esencial que se involucre a muchas
personas diferentes, incluyendo aquellas que no
estén muy familiarizadas con el servicio y sistemas
de TI, debido a que es posible que las personas con
más conocimientos no estén disponibles cuando se
produzca realmente un desastre.
■■ También se pueden realizar pruebas parciales cuando
se pruebe la recuperación de ciertos elementos del
plan general, como servicios o servidores individuales.
824_005 Chapter 04.indd 147
Procesos de Diseñ̃o del Servicio | 147
Estos tipos de pruebas no deben sustituir a las
pruebas completas sino ser complementarias. La
prueba completa puede ser la mejor forma de probar
que todos los servicios se pueden recuperar en los
plazos de tiempo requeridos y se pueden explotar
juntos en los sistemas de recuperación.
■■ Las pruebas de escenario pueden servir para probar
reacciones y planes para condiciones, eventos y
escenarios específicos. Pueden incluir pruebas de
la interfaz entre BCPs y Planes de Continuidad de
los Servicios de TI, así como su interfaz con otros
planes implicados en el tratamiento y gestión de una
incidencia grave.
Es necesario realizar todas las pruebas en los escenarios
de prueba definidos, que se describen de la forma más
realista posible. Debería tenerse en cuenta, no obstante,
que incluso la prueba más completa no abarca todo.
Por ejemplo, en una interrupción del servicio en la que
algunos compañeros han sufrido lesiones, o incluso la
muerte, no es posible probar la reacción del personal
a una crisis y los planes deben tener esto en cuenta.
Además, las pruebas deben tener objetivos y Factores
Críticos de Éxito claramente definidos, que se utilizarán
para determinar el éxito u otro resultado del ejercicio.
4.5.5.4  Etapa 4 – Operación continua
Esta etapa consta de lo siguiente:
■■ Educación, concienciación y formación – debería
cubrir los elementos específicos de la continuidad
del servicio de la organización y, en particular, de la
organización de TI. Esto asegura que todo el personal
sea consciente de las implicaciones de la continuidad
del negocio y del servicio, las tenga en cuenta dentro
de su trabajo normal y que todos los implicados en el
plan hayan recibido formación para implementar sus
acciones.
■■ Revisión – es necesario realizar la revisión regular
de todos los entregables del proceso de ITSCM para
asegurar que siguen estando actualizados.
■■ Pruebas – después de las pruebas iniciales, es
necesario establecer un programa de pruebas
regulares para asegurar que se prueben los
componentes críticos de la estrategia, al menos
anualmente si fuera posible, aunque las pruebas de
los Planes de Continuidad del Servicio de TI deberían
organizarse en línea con las necesidades del negocio
y de los BCPs. También deberían probarse todos
los planes después de cada cambio de negocio
importante. Es fundamental que también se incluya
en la estrategia cualquier cambio introducido en
la tecnología de TI, que se implemente de una
22/1/10 13:49:41
 148 | Procesos de Diseñ̃o del Servicio
forma adecuada y que se pruebe para garantizar
que funciona correctamente dentro de la provisión
general de TI después de un desastre. El backup y
la recuperación del servicio de TI también deberían
monitorizarse y probarse para asegurar que funcionen
tal y como se requiere durante una incidencia
grave. Este aspecto se trata con mayor detalle en la
publicación Operación del Servicio.
■■ Gestión de cambios – el proceso Gestión de Cambios
debería asegurarse de evaluar el impacto potencial
de todos los cambios en los planes de ITSCM. Si el
cambio planificado va a invalidar los planes, debe
actualizarse el plan antes de que se implemente el
cambio y debería probarse dentro de las pruebas
del cambio. Los propios planes deben estar bajo
un control muy estricto por parte de Gestión de
Cambios y Gestión de la Configuración. El fallo de los
BCPs puede provocar que existan planes imprecisos
y capacidad de recuperación inadecuada. Además,
de forma continua, siempre que haya servicios
nuevos o cuando se produzcan cambios importantes
en los mismos, es esencial que se realice un BIA
y una evaluación de riesgos en el servicio nuevo
o modificado y que la estrategia y los planos se
actualicen según corresponda.
Invocación
Invocación es la prueba final de los Planes de Continuidad
del Negocio y ITSCM. Si todo el trabajo de preparación
ha concluido con éxito y se han desarrollado y probado
los planes, entonces una invocación de los Planes de
Continuidad del Negocio debería ser un proceso sencillo,
aunque pueden esperarse fallos si no se hubieran probado
los planes. Es importante prestar la atención debida al
diseño de todos los procesos de invocación para asegurar
que estén ajustados para su propósito e interactúen con
todos los demás procesos de invocación necesarios.
Invocación es un componente clave de los planes,
que debe incluir el proceso y guía de la invocación.
Es necesario recordar que la decisión de realizar la
invocación no debe tomarse a la ligera, especialmente si
se debe utilizar una instalación de recuperación externa.
Existirán costes y el proceso implicará alteraciones para el
negocio. Esta decisión normalmente la adopta un equipo
de ‘Gestión de crisis’, integrado por gestores senior del
negocio y de departamentos de soporte (incluyendo
TI), que utilizan información recopilada a través de la
evaluación de daños y otras fuentes.
Es esencial que la guía sobre el proceso de invocación
esté fácilmente disponible debido a que podría producirse
una interrupción en cualquier momento del día o de la
824_005 Chapter 04.indd 148
noche. El personal clave de la oficina y desplazado de la
misma debe disponer de los planes.
La decisión de invocación debe ser tomada con rapidez,
debido a que puede existir un plazo de espera en el
establecimiento de las instalaciones en un emplazamiento
de recuperación. La decisión es fácil de tomar en el caso
de un incendio grave en un edificio. Sin embargo, en el
caso de un fallo de alimentación o del hardware en el
que se espera una resolución en un periodo de tiempo
breve, debería estipularse un plazo de tiempo para que se
realice la invocación si la incidencia no se ha resuelto en
un tiempo definido. Si se utilizan suministradores externos
de servicios, debería advertirse inmediatamente si existe la
oportunidad de realizar una invocación.
La decisión de invocación debe tener en cuenta:
■■ El nivel de daño y el ámbito de la invocación
potencial
■■ La duración probable de la interrupción y de la
indisponibilidad de las instalaciones y/o servicios
■■ La hora del día/mes/año y el impacto potencial en
el negocio. Al finalizar el año, la necesidad de la
invocación puede ser más acuciante, para asegurar
que el procedimiento de cierre del año se realice a
tiempo.
En consecuencia, el diseño del proceso de invocación
debe proporcionar una guía sobre cómo todas estas
áreas y circunstancias deberían evaluarse para ayudar a la
persona que invoque el plan de continuidad.
El Plan de ITSCM debería incluir detalles de las actividades
que se deben realizar, incluyendo:
■■ Extracción de cintas de backup o uso de copias de
respaldo remotas para extraer datos
■■ Extracción de documentación, procedimientos,
imágenes de estaciones de trabajo, etc. esenciales
almacenados fuera del emplazamiento
■■ Movilización del personal técnico necesario para que
acuda al emplazamiento de recuperación e inicie la
recuperación de los sistemas y servicios requeridos
■■ Contacto y puesta en alerta de los suministradores de
telecomunicaciones, servicios de soporte, proveedores
de aplicaciones, etc. que pueden requerirse para
realizar acciones o proveer asistencia en el proceso de
recuperación.
La invocación y recuperación inicial probablemente se
realice en un momento de elevada actividad, que implica
muchas horas para muchas personas. Esto debe ser
reconocido y gestionado por los líderes del equipo de
recuperación para asegurar que se permitan descansos
que eviten que el personal se ‘queme’. Debe realizarse
22/1/10 13:49:41

la planificación de turnos y transferencias para asegurar
que se haga el mejor uso de las instalaciones disponibles.
También tiene una importancia vital garantizar que los
controles del negocio y la tecnología usuales sigan en
práctica durante la invocación, recuperación y retorno a la
normalidad para asegurar que se mantenga la seguridad
de la información en el nivel correcto y se conserve la
protección de datos.
Una vez haya finalizado la recuperación, el negocio
debería ser capaz de operar desde el emplazamiento de
recuperación en el nivel determinado y acordado en la
estrategia y SLA necesario. Sin embargo, el objetivo será
llevar el negocio hasta los niveles normales, mantener la
operación del emplazamiento de recuperación a corto
plazo y dejar libre el emplazamiento de recuperación en
el plazo más breve posible. Los planes deben contener
información detallada de todas estas actividades. Si se
utilizan servicios externos, existirá un periodo contractual
finito para utilizar la instalación. Independientemente del
periodo, debe planificarse cuidadosamente un retorno
a la normalidad y realizarlo de una forma controlada.
Normalmente esto se realizará durante un fin de semana
y puede incluir la necesidad de un cierto tiempo de caída
en horario de negocio. Es importante que esto se gestione
bien y que todo el personal implicado sea consciente de
sus responsabilidades para asegurar una transición sin
problemas.
4.5.6  Disparadores, entradas, salidas e
interfaces
Muchos eventos pueden iniciar la actividad de ITSCM.
Éstos incluyen:
■■ Necesidades nuevas o modificadas del negocio o
servicios
■■ Objetivos nuevos o modificados dentro de acuerdos,
como SLRs, SLAs, OLAs o contratos
■■ La ocurrencia de una incidencia grave que requiera la
evaluación de la invocación potencial de los Planes de
Continuidad del Negocio o de TI
■■ Actividades periódicas, como las actividades BIA o
de Análisis de Riesgo, mantenimiento de Planes de
Continuidad u otras actividades de revisión, repaso o
de elaboración de informes
■■ Evaluación de cambios y asistencia a reuniones del
Comité de Cambios
■■ Revisión y repaso de planes y estrategias de negocio
y de TI
■■ Revisión y repaso de diseños y estrategias
824_005 Chapter 04.indd 149
Procesos de Diseñ̃o del Servicio | 149
■■ Reconocimiento o notificación de un cambio del
riesgo o impacto de un proceso de negocio o VBF, un
servicio de TI o componente
■■ Iniciación de pruebas de continuidad y planes de
recuperación.
Existen interfaces e integración desde ITSCM hasta el resto
de procesos. Algunos ejemplos importantes:
■■ Gestión de Cambios – es necesario considerar
el impacto de todos los cambios en los planes de
continuidad y, si se requieren modificaciones del plan,
será necesario incluir las actualizaciones como parte
del cambio. El propio plan debe estar bajo el control
de Gestión de Cambios.
■■ Gestión de Incidencias y Problemas – las incidencias
pueden evolucionar hasta convertirse fácilmente
incidencias graves o desastres. Es necesario acordar y
documentar criterios claros para la invocación de los
planes de ITSCM.
■■ Gestión de la Disponibilidad – la realización del
Análisis de Riesgo y la implementación de respuestas
al riesgo deberían coordinarse estrechamente con el
proceso de disponibilidad para optimizar la mitigación
del riesgo.
■■ Gestión del Nivel de Servicio – los requisitos de
recuperación se acordarán y documentarán en los
SLAs. Podrían acordarse y documentarse diferentes
niveles de servicio que podrían ser aceptables en una
situación de desastre.
■■ Gestión de Capacidad – asegurar que existan
suficientes recursos para permitir la recuperación en
ordenadores de sustitución después de un desastre.
■■ Gestión de la Configuración – el CMS documenta
los componentes que conforman la infraestructura y
las relaciones entre los componentes. Esta información
es inestimable para todas las etapas del ciclo de
vida de ITSCM, el mantenimiento de los planes y las
instalaciones de recuperación.
■■ Gestión de la Seguridad de la Información – existe
una relación muy estrecha entre ITSCM y Gestión de
la Seguridad de la Información. Una violación grave
de la seguridad puede considerarse un desastre, por
lo tanto, la seguridad será una consideración muy
importante al realizar BIA y Análisis de Riesgo.
4.5.6.1  Entradas
Existen muchas fuentes de entrada que requiere el
proceso de ITSCM.
■■ Información del negocio: procedente de la estrategia
de negocio, planes financieros de la organización y de
la información sobre sus requisitos actuales y futuros
22/1/10 13:49:41
 150 | Procesos de Diseñ̃o del Servicio
■■ Información de TI: procedente de la estrategia y
planes de TI y de los presupuestos actuales
■■ Una Estrategia y un conjunto de Planes de
Continuidad del Negocio: desde todas las áreas del
negocio
■■ Información del servicio: procedente del proceso SLM,
con detalles de los servicios del Porfolio de Servicios
y del Catálogo de Servicios y de los objetivos de nivel
de servicio incluidos en SLAs y SLRs
■■ Información financiera: desde Gestión Financiera, el
coste de la provisión del servicio, el coste de recursos
y componentes
■■ Información del cambio: procedente del proceso
Gestión de Cambios, con una Planificación de Cambios
y una necesidad de evaluar todos los cambios con
respecto a su impacto en todos los planes de ITSCM
■■ CMS: contiene información sobre las relaciones entre
el negocio, servicios, servicios de soporte y tecnología
■■ Planificaciones de pruebas de Gestión de la
Continuidad del Negocio y de Gestión de la
Disponibilidad
■■ Planes de Continuidad de los Servicios de TI e
informes de pruebas recibidos de suministradores y
socios, cuando sea necesario.
4.5.6.2  Salidas
Las salidas de los procesos de ITSCM incluyen:
■■ Una política y estrategia de ITSCM revisadas
■■ Un conjunto de planes de ITSCM, que incluyen
todos los Planes de Gestión de Crisis, Planes de
Respuesta a Emergencias y Planes de Recuperación
de Desastres, junto con un conjunto de planes de
soporte y contratos con proveedores de servicios de
recuperación
■■ Ejercicios e informes de Análisis de Impacto en el
Negocio, junto con BCM y el negocio
■■ Revisiones e informes de Análisis y Gestión del Riesgo,
junto con el negocio, Gestión de la Disponibilidad y
Gestión de la Seguridad
■■ Una planificación de pruebas de ITSCM
■■ Escenarios de prueba de ITSCM
■■ Informes y revisiones de pruebas de ITSCM.
Todas las áreas utilizan previsiones e informes predictivos
para analizar, predecir y prever escenarios particulares de
negocio y TI y sus posibles soluciones.
4.5.7 Indicadores Clave de Rendimiento
Los servicios de TI se pueden entregar y recuperar para
cumplir los objetivos de negocio:
824_005 Chapter 04.indd 150
■■ Auditorías regulares de los Planes de ITSCM para
asegurar que en todo momento puedan alcanzarse los
requisitos de recuperación acordados del negocio
■■ Todos los objetivos de recuperación del servicio están
acordados y documentados en SLAs y tales objetivos
pueden ser alcanzados dentro de los Planes de ITSCM
■■ Pruebas regulares y completas de los Planes de ITSCM
■■ Se realizarán revisiones regulares, al menos
anualmente, de los planes de continuidad del negocio
y de TI con las áreas de negocio
■■ Negociación y gestión de todos los contratos de
ITSCM necesarios con terceros
■■ Reducción general del riesgo e impacto del posible
fallo de los servicios de TI.
Concienciación de los planes en toda la organización:
■■ Asegurar la concienciación del impacto de negocio,
necesidades y requisitos en todo TI
■■ Asegurar que todas las áreas y personal de servicio
de TI estén preparados y puedan responder a una
invocación de los Planes de ITSCM
■■ Comunicación regular de los objetivos y
responsabilidades de ITSCM dentro de las áreas de
servicio del Negocio y de TI necesarias.
4.5.8  Gestión de la Información
ITSCM debe registrar toda la información necesaria para
mantener un conjunto completo de planes de ITSCM. Esta
base de información debería incluir:
■■ Información sobre la última versión del BIA
■■ Información completa sobre el riesgo dentro del
Registro de Riesgos, incluyendo la evaluación del
riesgo y las respuestas al riesgo
■■ La última versión de la estrategia BCM y BCPs
■■ Detalles relacionados con todas las pruebas finalizadas
y una planificación de todas las pruebas planificadas
■■ Detalles de todos los Planes de ITSCM y sus
contenidos
■■ Detalles del resto de planes asociados con Planes de
ITSCM
■■ Detalles de todas las instalaciones de recuperación
existentes, proveedores y socios de recuperación,
acuerdos y contratos de recuperación, equipo
alternativo y de reserva
■■ Detalles de todos los procesos, planificaciones,
sistemas y medios de backup y recuperación y sus
ubicaciones respectivas.
Toda la información anterior debe integrarse y alinearse
con toda la información de BCM y con el resto de
información que requiere ITSCM. Se requieren interfaces
22/1/10 13:49:41

con muchos otros procesos para asegurar que se
mantenga este alineamiento.
4.5.9  Desafíos, Factores Críticos de Éxito y
riesgos
Uno de los principales desafíos a los que se enfrenta
ITSCM es proporcionar planes adecuados cuando no
exista ningún proceso BCM. Si no existe ningún proceso
BCM, es probable que TI realice suposiciones incorrectas
sobre la criticidad de negocio de los procesos de negocio
y, en consecuencia, adopte estrategias y opciones de
continuidad equivocadas. Sin BCM, soluciones y planes
costosos de ITSCM resultarán inservibles debido a la
ausencia de planes y acuerdos correspondientes dentro
del negocio. Además, si no existe BCM, el negocio puede
fallar al identificar soluciones económicas ajenas a TI
y desperdiciar dinero en soluciones de TI ineficaces y
costosas.
En algunas organizaciones, la percepción del negocio
es que la continuidad es una responsabilidad de TI y, en
consecuencia, el negocio asume que TI será responsable
de la recuperación de desastres y que los servicios de
TI seguirán en marcha bajo cualquier circunstancia.
Ésto es especialmente cierto en algunas situaciones de
externalización en las que el negocio puede ser reacio a
compartir su información de BCM con un suministrador
externo de servicios.
Si ya existe un proceso de BCM establecido, el desafío
pasa a ser el alineamiento y la integración. ITSCM
debe asegurar que se obtenga información precisa de
los procesos BCM sobre las necesidades, impacto y
prioridades del negocio, y que la información y planes de
ITSCM estén alineados e integradas con las del negocio.
Una vez se consigue este alineamiento, el desafío pasa a
ser mantenerlos alineados a través de la gestión y control
del cambio en el negocio y TI. Por lo tanto, es vital que
todos los documentos y planes se mantengan bajo el
control estricto de Gestión de Cambios y Gestión de la
Configuración.
Los CSF principales para el proceso ITSCM son:
■■ Los servicios de TI se entregan y pueden recuperarse
para cumplir los objetivos de negocio
■■ Concienciación en toda la organización del negocio y
de los planes de Continuidad del Servicio de TI.
Algunos de los riesgos principales asociados con ITSCM
incluyen:
■■ Falta de compromiso del negocio hacia los procesos y
procedimientos de ITSCM
824_005 Chapter 04.indd 151
Procesos de Diseñ̃o del Servicio | 151
■■ Falta de compromiso por parte del negocio y una falta
de información adecuada sobre planes y estrategias
futuros
■■ Falta de compromiso de la gestión senior o una falta
de recursos y/o presupuesto para el proceso ITSCM
■■ Los procesos se centran excesivamente en los
problemas de la tecnología y no se centran lo
suficiente en los servicios de TI y en las necesidades y
prioridades del negocio
■■ El Análisis y Gestión del Riesgo se realizan de forma
aislada, y no en colaboración con Gestión de la
Disponibilidad y Gestión de la Seguridad
■■ Los planes e información de ITSCM se desactualizan y
se pierde alineamiento con la información y los planes
del negocio y BCM.
4.6  Gestión de la Seguridad de la
Información
4.6.1  Propósito/meta/objetivo
‘La meta del proceso ISM es alinear la seguridad de TI con
la seguridad del negocio, y garantizar que la seguridad de
la información se gestione de forma eficaz en todas las
actividades del servicio y de Gestión del Servicio
ISM debe estar incluido dentro del marco de trabajo de
gobierno corporativo general. El gobierno corporativo
es el conjunto de responsabilidades y prácticas ejercidas
por el consejo y dirección ejecutiva con el objetivo
de proporcionar dirección estratégica, asegurar la
consecución de los objetivos, verificar que los riesgos se
estén gestionando de forma conveniente y comprobar que
los recursos de la empresa se utilicen de forma eficaz.
Seguridad de la información es una actividad de gestión
dentro del marco de trabajo de gobierno corporativo,
que proporciona la dirección estratégica para las acciones
de seguridad y asegura que se alcancen los objetivos.
Además, asegura que se gestionen adecuadamente
los riesgos de seguridad de la información y que los
recursos de información de la empresa se usen con
responsabilidad. El propósito de ISM es proporcionar un
enfoque para todos los aspectos de seguridad de TI y
gestionar todas las actividades de TI.
El término ‘información’ se utiliza como un término
general e incluye almacenamiento de datos, bases
de datos y metadatos. El objetivo de seguridad de la
información es proteger los intereses de aquellos que se
basen en la información, y los sistemas y comunicaciones
que proporcionan la información, del perjuicio provocado
por los fallos de disponibilidad, confidencialidad e
integridad.
22/1/10 13:49:41
 152 | Procesos de Diseñ̃o del Servicio
En la mayoría de las organizaciones, el objetivo de
seguridad se cumple cuando:
■■ La información está disponible y se puede utilizar
cuando se requiera, y los sistemas que la proveen
pueden resistir adecuadamente ataques y recuperarse
de, o evitar, fallos (disponibilidad)
■■ La información se observa o divulga exclusivamente
a aquellas personas con derecho a conocerla
(confidencialidad)
■■ La información es completa, precisa y está protegida
frente a la modificación no autorizada (integridad)
■■ Se puede confiar en las transacciones de negocio,
así como en los intercambios de información entre
empresas o con socios (autenticidad y no repudio).
La priorización de la confidencialidad, integridad y
disponibilidad debe considerarse en el contexto del
negocio y de los procesos de negocio. La guía principal
para definir qué se debe proteger y el nivel de protección
debe provenir del negocio. Seguridad, para ser eficaz,
debe abordar el proceso de negocio completo extremo
a extremo y cubrir los aspectos físicos y técnicos. La
dirección sólo puede definir seguridad dentro del contexto
de las necesidades y riesgos de negocio.
4.6.2 Ámbito
El proceso ISM debería ser el punto de enfoque para todos
los problemas de seguridad de TI, y debe asegurar que se
elabore, mantenga y aplique una Política de Seguridad de
la Información que cubra el uso y mal uso de todos los
sistemas y servicios de TI. ISM debe entender el entorno
total de la seguridad del negocio y de TI, incluyendo:
■■ La Política y Planes de Seguridad del Negocio
■■ La operación actual del negocio y sus requisitos de
seguridad
■■ Los futuros planes y requisitos de negocio
■■ Requisitos legislativos
■■ Las obligaciones y responsabilidades con respecto a la
seguridad que se incluyen en los SLAs
■■ Los riesgos del negocio y de TI y su gestión.
El entendimiento de todo esto permitirá a ISM garantizar
que se gestionen de forma eficaz todos los aspectos
actuales y futuros de seguridad y los riesgos del negocio.
El proceso ISM debería incluir:
■■ Elaboración, mantenimiento, distribución y aplicación
de una Política de Seguridad de la Información y
política de seguridad de apoyo
824_005 Chapter 04.indd 152
■■ Entendimiento de los requisitos de seguridad actuales
y futuros acordados del negocio y de la Política y
planes de Seguridad del Negocio
■■ Implementación de un conjunto de controles de
seguridad que respalde a la Política de Seguridad de
la Información y gestión de los riesgos asociados con
el acceso a servicios, información y sistemas
■■ Documentación de todos los controles de seguridad,
junto con la operación y mantenimiento de los
controles y sus riesgos asociados
■■ Gestión de suministradores y contratos relacionados
con el acceso a sistemas y servicios, junto con Gestión
de Suministradores
■■ Gestión de todas las violaciones e incidencias de
seguridad asociadas con todos los sistemas y servicios
■■ La mejora proactiva de los controles de seguridad,
gestión del riesgo para la seguridad y la reducción de
los riesgos para la seguridad
■■ Integración de los aspectos de la seguridad dentro del
resto de procesos de ITSCM.
Para conseguir un gobierno de seguridad de la
información eficaz, la gestión debe establecer y mantener
un Sistema de Gestión de Seguridad de la Información
(SGSI) para guiar el desarrollo y gestión de un programa
de seguridad de la información integral que respalde los
objetivos de negocio.
4.6.3  Valor para el negocio
ISM asegura que se mantenga y aplique una Política de
Seguridad de la Información que satisfaga las necesidades
de la Política de Seguridad del Negocio y los requisitos de
gobierno corporativo. ISM fomenta la concienciación sobre
la necesidad de seguridad dentro de todos los servicios y
activos de TI en toda la organización, lo cual asegura que
la política se adapte a las necesidades de la organización.
ISM gestiona todos los aspectos de TI y de seguridad de la
información dentro de todas las áreas de la actividad de TI
y de Gestión del Servicio.
ISM proporciona el aseguramiento de los procesos de
negocio aplicando los controles de seguridad adecuados
en todas las áreas de TI y gestionando el riesgo de TI en
línea con los procesos y directrices de gestión del riesgo
de negocio y corporativo.
4.6.4  Políticas/principios/conceptos básicos
Las prácticas de negocio prudentes requieren que los
procesos e iniciativas de TI estén alineados con los
procesos y objetivos de negocio. Esto es crítico cuando se
trata de la seguridad de la información, que debe alinearse
estrechamente con la seguridad y las necesidades del
22/1/10 13:49:42

negocio. Adicionalmente, todos los procesos de la
organización de TI deben incluir consideraciones con
respecto a la seguridad.
La dirección ejecutiva es la responsable final de la
información de la organización y asume la tarea de
responder a los problemas que afectan a su protección.
Además, se espera que los consejos de administración
adopten la seguridad de la información como una parte
integral del gobierno corporativo. Por consiguiente, todas
las organizaciones proveedoras de servicios de TI deben
asegurarse de tener políticas ISM integrales y los controles
de seguridad necesarios para monitorizar y aplicar las
políticas.
4.6.4.1  Marco de trabajo de seguridad
El proceso y marco de trabajo de Gestión de la Seguridad
de la Información consistirá generalmente en:
■■ Una Política de Seguridad de la Información y políticas
de seguridad específicas que aborden cada aspecto de
la estrategia, controles y regulación
■■ Un Sistema de Gestión de Seguridad de la Información
(SGSI), que contenga los estándares, procedimientos
de gestión y directrices que respalden las políticas de
seguridad de la información
■■ Una estrategia de seguridad integral, vinculada
estrechamente con los objetivos, estrategias y planes
de negocio
■■ Una estructura organizativa de seguridad eficaz
■■ Un conjunto de controles de seguridad para respaldar
la política
■■ La gestión de los riesgos de seguridad
■■ Procesos de monitorización para asegurar la
conformidad y proporcionar retroalimentación sobre la
eficacia
■■ Estrategia y plan de comunicaciones para seguridad
■■ Estrategia y plan de formación y concienciación.
4.6.4.2  La Política de Seguridad de la
Información
La actividades de Gestión de la Seguridad de la
Información deberían centrarse y estar impulsadas por
una política de Seguridad de la Información general y un
conjunto de políticas de seguridad específicas de soporte.
La Política de Seguridad de la Información debería contar
con el respaldo absoluto de la alta dirección ejecutiva de
TI, e idealmente, con el apoyo y el compromiso de la alta
dirección ejecutiva del negocio. La política debería cubrir
todas las áreas de seguridad, ser apropiada, y satisfacer las
necesidades del negocio, y debería incluir:
824_005 Chapter 04.indd 153
Procesos de Diseñ̃o del Servicio | 153
■■ Una Política de Seguridad de la Información general
■■ Uso y mal uso de la política de activos de TI
■■ Una política de control del acceso
■■ Una política de control de contraseñas
■■ Una política de correos electrónicos
■■ Una política de Internet
■■ Una política anti-virus
■■ Una política de clasificación de la información
■■ Una política de clasificación de documentos
■■ Una política de acceso remoto
■■ Una política con respecto al acceso de suministradores
al servicio, información y componentes de TI
■■ Una política de eliminación de activos.
Estas políticas debería estar totalmente disponibles para
todos los clientes y usuarios, y su conformidad se debería
mencionar en todos los SLRs, SLAs, contratos y acuerdos.
Las políticas deberían estar autorizadas por la dirección
ejecutiva dentro del negocio y TI, y su cumplimiento
debería respaldarse regularmente. Todas las políticas de
seguridad se deben revisar y, cuando sea conveniente,
modificadas al menos una vez al año.
4.6.4.3  El Sistema de Gestión de Seguridad de la
Información (SGSI)
El marco de trabajo o el SGSI proporciona a su vez una
base para el desarrollo de un programa de información
económico que respalda los objetivos de negocio.
Implicará las cuatro P de personas (People), proceso
(Process), productos (Products) y tecnología, así como
socios (Partners) y suministradores para asegurar la
aplicación de niveles elevados de seguridad.
ISO 27001 es el estándar formal con el que las
organizaciones pueden buscar la certificación
independiente de sus SGSI (esto es, sus marcos de trabajo
para diseñar, implementar, mantener y aplicar procesos
y controles de seguridad de la información de forma
sistemática y uniforme en todas las organizaciones).
El SGSI que se muestra en la Figura 4.26 contiene una
metodología que se utiliza ampliamente y que se basa
en el asesoramiento y guía que se describe en muchas
fuentes, incluyendo ISO 27001.
Los cinco elementos que contiene este marco de trabajo
son los siguientes:
Control
Los objetivos del elemento de control del SGSI son:
■■ Establecer un marco de trabajo para iniciar y gestionar
la seguridad de la información en la organización
22/1/10 13:49:42
 154 | Procesos de Diseñ̃o del Servicio

Clientes – Requisitos – Necesidades de Negocio

MANTENER PLANIFICAR
Aprender Acuerdos de Nivel de Servicio
Mejorar Contratos de Soporte
Planificar Acuerdos de Nivel Operativo
Implementar Declaraciones de la Política

CONTROLAR
Organizar
Establecer marco de trabajo
Asignar responsabilidades IMPLEMENTAR
Crear concienciación
Clasificación y registro
EVALUAR Seguridad personal
Auditorías internas Seguridad física
Auditorías externas Redes, aplicaciones, ordenadores
Auto-evaluaciones Gestión de derechos de acceso
Incidencias de seguridad Procedimientos de incidencias de seguridad

Figura 4.26  Marco de trabajo para gestionar la seguridad de TI

■■ Establecer una estructura organizativa para preparar,
aprobar e implementar la Política de Seguridad de la
Información
■■ Asignar responsabilidades
■■ Establecer y controlar documentación.
Plan
El objetivo del elemento del plan del SGSI es concebir
y recomendar las medidas de seguridad adecuadas,
basándose en una comprensión de los requisitos de la
organización.
Los requisitos se recopilarán de fuentes como riesgo de
negocio y servicio, planes y estrategias, SLAs y OLAs y
de las responsabilidades legales, morales y éticas para la
seguridad de la información. Deben tenerse en cuenta
otros factores, como la cantidad de financiación disponible
y la cultura y actitudes existentes hacia la seguridad.
La Política de Seguridad de la Información define la
actitud y posición de la organización con respecto a los
asuntos de seguridad. Éste debería ser un documento para
toda la organización, no sólo aplicable al proveedor de
servicios de TI. La responsabilidad de mantenimiento de
los documentos reside en el Gestor de la Seguridad de la
Información.
Implementación
El objetivo de la implementación del SGSI es asegurar
que se pongan en práctica los procesos, herramientas y
controles adecuados para apoyar la Política de Seguridad
de la Información.
Entre las medidas se incluyen:
■■ Responsabilidad para los activos – Aquí son
inestimables Gestión de la Configuración y el CMS
■■ Clasificación de la información – la información y
los repositorios deberían clasificarse de acuerdo con la
sensibilidad y el impacto de la divulgación.
La implementación exitosa de los controles y medidas de
seguridad depende de diversos factores:
■■ Establecimiento de una política clara y acordada,
integrada con las necesidades del negocio
■■ Procedimientos de seguridad que estén justificados,
sean apropiados y estén respaldados por la gestión
senior
■■ Marketing y formación eficaces en los requisitos de
seguridad
■■ Un mecanismo de mejora.
Evaluación
Los objetivos del elemento de evaluación del SGSI son:
■■ Supervisar y comprobar la conformidad con la política
de seguridad y los requisitos de seguridad en SLAs y
OLAs
■■ Realizar auditorías regulares de seguridad técnica de
los sistemas de TI

824_005 Chapter 04.indd 154 22/1/10 13:49:42


■■ Proporcionar información a auditores y reguladores
externos, si se requiere.
Mantenimiento
Los objetivos del elemento de mantenimiento del SGSI
son:
■■ Mejorar los acuerdos de seguridad especificados en,
por ejemplo, SLAs y OLAs
■■ Mejorar la implementación de medidas y controles de
seguridad.
Lo anterior debería lograrse utilizando un ciclo PDCA
(Planificar-Hacer-Verificar-Actuar), que es una metodología
formal sugerida por ISO 27001 para el establecimiento del
Sistema de Gestión de Seguridad de la Información (SGSI)
o marco de trabajo. Este ciclo se describe con más detalle
en la publicación Mejora Continua del Servicio.
Gobierno de la seguridad
El gobierno de la seguridad de la información, cuando se
implemente adecuadamente, debería proporcionar seis
resultados básicos.
■■ Alineamiento estratégico:
●●Los requisitos empresariales deberían dirigir los
requisitos de seguridad
●● Las soluciones de seguridad deben adaptarse a los
procesos empresariales
●● La inversión en seguridad de la información
debería alinearse con la estrategia empresarial y
con el perfil de riesgo acordado.
■■ Entrega de valor:
●● Un conjunto estándar de prácticas de seguridad,
esto es, requisitos de seguridad de un línea de
referencia de mejores prácticas
●● Esfuerzo adecuadamente priorizado y distribuido
en las áreas con el mayor impacto y beneficio de
negocio
●● Soluciones institucionalizadas y de aplicación
masiva
●● Soluciones completas, que abarcan a la
organización y los procesos, así como a la
tecnología
●● Una cultura de mejora continua.
■■ Gestión del riesgo:
●● Perfil de riesgo acordado
●● Comprensión de la exposición al riesgo
●● Concienciación de las prioridades de gestión del
riesgo
●● Mitigación del riesgo
●● Aceptación/adhesión del riesgo.
824_005 Chapter 04.indd 155
Procesos de Diseñ̃o del Servicio | 155
■■ Gestión del rendimiento:
Conjunto de métricas definido, acordado y
●●
significativo
●● Proceso de medida que ayudará a identificar
carencias y a proporcionar retroalimentación
sobre el progreso realizado en la resolución de
problemas
●● Aseguramiento independiente.
■■ Gestión de recursos:
●● Se reúne el conocimiento y está disponible
●● Procesos y prácticas de seguridad documentados
●● Arquitecturas de seguridad desarrolladas para
utilizar los recursos de infraestructura con eficacia.
■■ Aseguramiento del proceso de negocio.
4.6.5 Actividades, métodos y técnicas del
proceso
El propósito del proceso ISM es asegurar que los aspectos
de seguridad con respecto a los servicios y todas las
actividades de Gestión del Servicio se gestionen y
controlen en línea con las necesidades y riesgos del
negocio:
Las actividades clave dentro del proceso ISM son:
■■ Producción, revisión y repaso de una Política de
Seguridad de la Información y un conjunto de
políticas específicas de apoyo
■■ Comunicación, implementación y aplicación de las
políticas de seguridad
■■ Evaluación y clasificación de todos los activos de
información y documentación
■■ Implementación, revisión, repaso y mejora de un
conjunto de controles de seguridad y evaluación del
riesgo y respuestas
■■ Monitorización y gestión de todas las violaciones e
incidencias de seguridad graves
■■ Análisis, informe y reducción de los volúmenes e
impacto de las violaciones de seguridad e incidencias
■■ Planificación y finalización de revisiones de seguridad,
auditorías y pruebas de penetración.
Las interacciones entre estas actividades clave se ilustran
en la Figura 4.27.
Los procesos de Gestión de la Seguridad de la Información
desarrollados, junto con los métodos, herramientas y
técnicas, constituyen la estrategia de seguridad. El gestor
de la seguridad debería garantizar que las tecnologías,
productos y servicios estén en práctica y que la política
general se desarrolle y publicite adecuadamente. El gestor
de la seguridad también es responsable de la arquitectura
22/1/10 13:49:42
 156 | Procesos de Diseñ̃o del Servicio

Elaborar y
mantener una
Política de Segur.
de la Información

Evaluar y
categorizar
Comunicar, activos de
implementar y Monitorizar y información, riesgos
hacer cumplir gestionar y vulnerabilidades
todas las políticas incidencias
de seguridad e incumplimientos

Evaluar, revisar,
e informar
regularmente de
riesgos y amenazas
para la seguridad

Imponer y
Informar, revisar revisar controles
y reducir de seguridad,
incumplimientos revisar e
de seguridad e implementar
incidencias mitigación de
importantes riesgos

Sistema de
Gestión de la Políticas de Informes e Riesgos y
Controles respuestas de
Información de Seguridad de la información de
de seguridad seguridad
Seguridad (SMIS) Información seguridad

Figura 4.27  Proceso de Gestión de la Seguridad de TI

de seguridad, autenticación, autorización, administración y
recuperación.
La estrategia de seguridad también debe tener en cuenta
cómo integrará buenas prácticas de seguridad en cada
área del negocio. La formación y concienciación son
vitales en la estrategia general, debido a que la seguridad
es a menudo más débil en la etapa del usuario final.
Además, es aquí donde existe la necesidad de desarrollar
métodos y procesos que permitan implementar y seguir
las políticas y estándares con más facilidad.
4.6.5.1  Controles de seguridad
El Gestor de la Seguridad de la Información debe entender
que la seguridad no es un paso en el ciclo de vida de
los servicios y sistemas y que la seguridad no se puede
resolver a través de tecnología. En lugar de esto, la
seguridad de la información debe ser una parte integral
de todos los servicios y sistemas y es un proceso continuo
que debe gestionarse continuamente utilizando un
conjunto de controles de seguridad, tal y como se muestra
en la Figura 4.28.

Deben asignarse recursos para realizar el seguimiento
de los desarrollos en estas tecnologías de apoyo y de
los productos que respaldan. Por ejemplo, la privacidad
sigue siendo importante y, progresivamente, el enfoque
de la regulación gubernamental, lo que hace que las
tecnologías de conformidad de la privacidad sean una
tecnología de apoyo importante.
El conjunto de controles de seguridad debería diseñarse
para respaldar y hacer cumplir la Política de Seguridad
de la Información y minimizar todas las amenazas
reconocidas e identificadas. Los controles serán
considerablemente más económicos si se incluyen
dentro del diseño de todos los servicios. Ésto asegurará
la protección continua de todos los servicios existentes y

824_005 Chapter 04.indd 156 22/1/10 13:49:42


Amenaza
Prevención/ Evaluación/
Reducción Informes
Incidencia
Dirección/ Evaluación/
Represión Informes
Daño
Corrección/ Evaluación/
Recuperación Informes
Control
Figura 4.28  Controles de seguridad para amenazas e
incidencias
que los nuevos servicios, y el acceso a los mismos, estén
alineados con la política.
Las medidas de seguridad se pueden utilizar en una
etapa específica en la prevención y gestión de incidencias
de seguridad, tal y como se ilustra en la Figura 4.28.
Las incidencias de seguridad no sólo se deben a las
amenazas técnicas. La estadística muestra que, por
ejemplo, la amplia mayoría se deriva de errores humanos
(intencionales o no) o de errores de procedimiento, y
a menudo tienen implicaciones en otros campos como
seguridad, legal o salud.
Pueden identificarse las siguientes etapas. Al comienzo
existe el riesgo de que se materialice una amenaza.
Una amenaza puede ser cualquier cosa que perturbe el
proceso de negocio o que tenga un impacto negativo
sobre el negocio. Cuando una amenaza se materializa, se
convierte en una incidencia de seguridad. Esta incidencia
de seguridad puede provocar daños (a la información
o a los activos) que se tienen que reparar o corregir de
otra manera. Pueden seleccionarse medidas adecuadas
para cada una de estas etapas. La selección de medidas
dependerá de la importancia asociada con la información.
■■ Preventivas: se usan medidas de seguridad para
evitar que ocurra una incidencia de seguridad. El
ejemplo mejor conocido de medidas preventivas es la
asignación de derechos de acceso a un grupo limitado
de personas autorizadas. Los requisitos adicionales
asociados a esta medida incluyen el control de
derechos de acceso (concesión, mantenimiento y
824_005 Chapter 04.indd 157
Procesos de Diseñ̃o del Servicio | 157
retirada de derechos), autorización (identificar a quién
se permite acceder a qué información y a utilizar qué
herramientas), identificación y autenticación (confirmar
quién está intentando acceder) y control de acceso
(asegurar que sólo pueda obtener acceso personal
autorizado).
■■ Reductoras: pueden adoptarse medidas adicionales
anticipadamente para minimizar cualquier posible
daño que pueda producirse. Éstas son mediciones
‘reductoras’. Ejemplos conocidos de medidas de
reducción son realizar backups regulares y el
desarrollo, prueba y mantenimiento de planes de
contingencia.
■■ De detección: si se produce una incidencia de
seguridad, es importante descubrirla lo antes
posible; detección. Un ejemplo habitual de esto es
la monitorización, vinculada a un procedimiento de
alerta. Otro ejemplo es el software de comprobación
de virus.
■■ Restrictivas: las medidas se utilizan entonces para
contrarrestar cualquier continuación o repetición de la
incidencia de seguridad. Por ejemplo, se bloquea una
cuenta o dirección de red temporalmente después
de numerosos intentos fallidos para iniciar sesión o
se retiene una tarjeta cuando se realizan múltiples
intentos con un número PIN incorrecto.
■■ Correctivas: El daño se repara en la medida de lo
posible utilizando medidas correctivas. Por ejemplo,
las medidas correctivas incluyen la restauración del
backup, o regresar a una situación estable anterior
(roll-back, marcha atrás). Una reserva también puede
considerarse como una medida correctiva.
La documentación de todos los controles debería
mantenerse para reflejar su operación, mantenimiento y
método de operación de forma precisa.
4.6.5.2  Gestión de violaciones e incidencias de
seguridad
En el caso de una violación o incidencia de seguridad
grave, se requiere una evaluación a su debido tiempo,
para determinar qué salió mal, qué lo provocó y cómo
puede evitarse en el futuro. Sin embargo, este proceso
no debería limitarse a incidencias de seguridad graves.
Todas las violaciones e incidencias de seguridad deben
estudiarse para obtener una visión completa de la
eficacia de las medidas de seguridad. Se requiere un
procedimiento para informar sobre las incidencias de
seguridad tal que permita evaluar la eficacia y eficiencia
de las medidas de seguridad. Ésto se consigue gracias al
mantenimiento de ficheros de log y de auditoría y, por
supuesto, registros de incidencias de la función del Centro
22/1/10 13:49:43
 158 | Procesos de Diseñ̃o del Servicio
de Servicio al Usuario. El análisis de estas estadísticas sobre
los problemas de seguridad llevan a acciones de mejora
centradas en la reducción del impacto y volumen de
todas las violaciones e incidencias de seguridad, junto con
Gestión de Problemas.
4.6.6  Disparadores, entradas, salidas e
interfaces
La actividad de ISM puede activarse a través de muchos
eventos. Éstos incluyen:
■■ Directrices de gobierno corporativo nuevas o
modificadas
■■ Política de Seguridad del Negocio nueva o modificada
■■ Procesos y directrices de gestión del riesgo corporativo
nuevos o modificados
■■ Necesidades nuevas o modificadas del negocio o
servicios
■■ Requisitos nuevos o modificados dentro de acuerdos,
como SLRs, SLAs, OLAs o contratos
■■ Revisión y repaso de planes y estrategias de negocio
y de TI
■■ Revisión y repaso de diseños y estrategias
■■ Violaciones o advertencias de seguridad del servicio o
componente, eventos y alertas, incluyendo eventos de
umbrales e informes de excepciones
■■ Actividades periódicas, como revisión, repaso o
elaboración de informes, incluyendo la revisión y
repaso de políticas, informes y planes de ISM
■■ Reconocimiento o notificación de un cambio en el
riesgo o impacto de un proceso de negocio o VBF, un
servicio de TI o componente
■■ Peticiones de otras áreas, particularmente SLM para
proporcionar asistencia con problemas de seguridad.
La implementación efectiva y eficiente de una Política de
Seguridad de la Información dentro de una organización
dependerá, en gran medida, de buenos procesos de
Gestión del Servicio. De hecho, la implementación eficaz
de algunos procesos puede verse como un requisito
previo para el control eficaz de la seguridad. Las interfaces
clave que ISM tiene con otros procesos son las siguientes:
■■ Gestión de Incidencias y Problemas: proporcionando
asistencia con la resolución, justificación y corrección
posterior de las incidencias y problemas de seguridad.
El proceso de Gestión de Incidencias debe incluir
la capacidad de identificar y abordar las incidencias
de seguridad. El personal del Centro de Servicio al
Usuario y Operación del Servicio debe ‘reconocer’ una
incidencia de seguridad.
824_005 Chapter 04.indd 158
■■ ITSCM: con la evaluación del impacto y riesgo de
negocio y la provisión de mecanismos de capacidad
de recuperación. La seguridad es un problema grave
cuando se prueban e invocan planes de seguridad. Un
plan de ITSCM operativo es un requisito obligatorio
para ISO 27001.
■■ SLM: colaboración en la determinación de requisitos
y responsabilidades de seguridad y su incorporación
dentro de SLRs y SLAs, junto con la investigación y
resolución de violaciones de seguridad del servicio y
componente
■■ Gestión de Cambios: ISM debería colaborar con
la evaluación del impacto de cada cambio en la
seguridad y los controles de seguridad. ISM también
puede proporcionar información sobre cambios no
autorizados.
■■ Deben tenerse en cuenta los problemas legales y de
RR.HH. al investigar los problemas de seguridad.
■■ Gestión de la Configuración dispondrá de la capacidad
de proporcionar información precisa de los activos
para colaborar con la clasificación de la seguridad. Por
lo tanto, contar con un CMS preciso es una entrada de
ISM extremadamente útil.
■■ La seguridad se contempla a menudo como un
elemento de Gestión de la Disponibilidad, siendo
Confidencialidad, Integridad y Disponibilidad (CID) la
esencia de Disponibilidad e ISM. Además, ISM debería
trabajar junto con Gestión de la Disponibilidad e
ITSCM para realizar ejercicios conjuntos de Análisis y
Gestión del Riesgo.
■■ Gestión de la Capacidad debe tener en cuenta las
implicaciones de seguridad al seleccionar e introducir
una tecnología nueva. La seguridad es un asunto
importante a tener en cuenta al adquirir cualquier
tecnología o software nuevo.
■■ Gestión Financiera debería facilitar fondos adecuados
para financiar los requisitos de seguridad.
■■ Gestión de Suministradores debería contribuir a la
gestión conjunta de los suministradores y su acceso
a servicios y sistemas, así como a los términos
y condiciones a incluir dentro de los contratos
relacionados con las responsabilidades de los
suministradores.
4.6.6.1  Entradas
Gestión de la Seguridad de la Información tendrá que
obtener la entrada de muchas áreas, entre las que se
incluyen:
■■ Información del negocio: estrategia de negocio, planes
financieros de la organización e información sobre sus
requisitos actuales y futuros.
22/1/10 13:49:43

■■ Gobierno corporativo y políticas y directrices de
seguridad del negocio, planes de seguridad, Análisis
del Riesgo y respuestas
■■ Información de TI: estrategia y planes de TI y
presupuestos actuales
■■ Información del servicio: procedente del proceso SLM,
con detalles de los servicios del Porfolio de Servicios
y del Catálogo de Servicios y de los objetivos de nivel
de servicio dentro de SLAs y SLRs, y posiblemente
procedente de la monitorización de SLAs, revisiones
del servicio e incumplimientos de los SLAs
■■ Procesos e informes de Análisis de Riesgo: desde ISM,
Gestión de la Disponibilidad e ITSCM
■■ Detalles de todos los eventos y violaciones de
seguridad: desde todas las áreas de IT y SM,
especialmente Gestión de Incidencias y Gestión de
Problemas
■■ Información del cambio: procedente del proceso de
Gestión de Cambios, con una Planificación de Cambios
y una necesidad de evaluar su impacto en todas las
políticas, planes y controles de seguridad
■■ CMS: contiene información sobre las relaciones entre
el negocio, servicios, servicios de soporte y tecnología
■■ Detalles del acceso de socios y suministradores:
procedentes de Gestión de Suministradores y Gestión
de la Disponibilidad, sobre el acceso externo a
servicios y sistemas.
4.6.6.2  Salidas
Las salidas generadas por el proceso de Gestión de la
Seguridad de la Información se utilizan en todas las áreas
y deberían incluir:
■■ Una Política de Gestión de la Seguridad de la
Información general, junto con un conjunto de
políticas de seguridad específicas
■■ Un Sistema de Información para la Gestión de la
Seguridad (SGSI), que contiene toda la información
relacionada con ISM
Procesos e informes revisados de evaluación del riesgo
para la seguridad
■■ Un conjunto de controles de seguridad, junto con
detalles de la operación y mantenimiento y sus riesgos
asociados
■■ Auditorías de seguridad e informes de auditoría
■■ Planificaciones y planes de pruebas de seguridad, que
incluyen pruebas de penetración de seguridad y otras
pruebas e informes de seguridad
■■ Un conjunto de clasificaciones de seguridad y de
activos de información clasificados
824_005 Chapter 04.indd 159
Procesos de Diseñ̃o del Servicio | 159
■■ Revisiones e informes de violaciones de seguridad e
incidencias graves
■■ Políticas, procesos y procedimientos para gestionar
socios y suministradores y su acceso a servicios e
información.
4.6.7 Indicadores Clave de Rendimiento
Se pueden utilizar muchos KPIs y métricas para evaluar
la eficacia y eficiencia del proceso y actividades de ISM.
Estas métricas deben desarrollarse desde la perspectiva del
servicio, cliente y negocio, como por ejemplo:
■■ Protección del negocio frente a las violaciones de
seguridad:
●● Reducción porcentual de las violaciones de
seguridad comunicadas al Centro de Servicio al
Usuario
●● Reducción porcentual del impacto de las
violaciones e incidencias de seguridad
●● Incremento porcentual de la conformidad del SLA
con las cláusulas de seguridad.
■■ La determinación de una política clara y acordada,
integrada con las necesidades del negocio: reducción
del número de no conformidades del proceso ISM con
la política y proceso de seguridad del negocio.
■■ Procedimientos de seguridad que estén justificados,
sean adecuadas y estén respaldados por la gestión
senior:
●● Incremento de la aceptación y conformidad de los
procedimientos de seguridad
●● Incremento en el soporte y compromiso de la
gestión senior.
■■ Un mecanismo de mejora:
●● El número de mejoras sugeridas en los
procedimientos y controles de seguridad
●● Reducción del número de no conformidades de
seguridad detectadas durante las auditorías y
pruebas de la seguridad.
■■ La seguridad de la información es una parte integral
de todos los servicios de TI y procesos de ITSM:
incremento del número de servicios y procesos que
cumplen los procedimientos y controles de seguridad.
■■ Marketing y formación eficaces en relación con los
requisitos de seguridad, concienciación del personal
de TI de la tecnología que da soporte a los servicios:
●● Aumento de la concienciación de la política
de seguridad y sus contenidos, en toda la
organización
●● Incremento porcentual de la integridad del
Catálogo de Servicios Técnicos con respecto a los
componentes de TI que dan soporte a los servicios
22/1/10 13:49:43
 160 | Procesos de Diseñ̃o del Servicio
●● Centro de Servicio al Usuario que ofrece soporte
para todos los servicios.
4.6.8  Gestión de la Información
Toda la información que requiera ISM debería estar
incluida dentro del SGSI. Debería incluir todos los
controles, riesgos, violaciones, procesos e informes de
seguridad necesarios para respaldar y mantener la Política
de Seguridad de la Información y el SGSI. Esta información
debería cubrir todos los servicios y componentes de TI y
se debe integrar y mantener de forma que esté alineada
con el resto de sistemas de gestión de la información de
TI, particularmente el Porfolio del Servicio y el CMS. El
SGSI también proporcionará la entrada para las auditorías
y revisiones de seguridad así como para las actividades
de mejora continua, tan importantes para todos los SGSI.
El SGSI también proporcionará una entrada inestimable al
diseño de nuevos sistemas y servicios.
4.6.9  Desafíos, Factores Críticos de Éxito y
riesgos
ISM se enfrenta a muchos desafíos al establecer una
Política de Seguridad de la Información adecuada con
controles y procesos de soporte eficaces. Uno de los
principales desafíos es asegurar que exista soporte
adecuado del negocio, seguridad del negocio y de la
gestión senior. Si no se dispone de ese soporte, será
imposible establecer un proceso ISM eficaz. Si existe
respaldo de la gestión senior, pero no existe el soporte del
negocio, los controles de seguridad de TI y la evaluación
del riesgo se verán gravemente limitados en los objetivos
a alcanzar, debido a esta falta de soporte del negocio. Es
inútil implementar políticas, procedimientos y controles
de seguridad en TI si no se pueden aplicar en todo el
negocio. El principal uso de los servicios y activos de TI
se encuentra fuera de TI y, por esta razón, también la
mayoría de las amenazas y riesgos de seguridad.
En algunas organizaciones, la percepción del negocio
es que la seguridad es una responsabilidad de TI y, en
consecuencia, el negocio asume que TI será responsable
de todos los aspectos de la seguridad de TI y que los
servicios de TI estarán protegidos adecuadamente. Sin
embargo, sin el compromiso y respaldo del negocio y del
personal del negocio, se desperdiciará buena parte del
dinero invertido en caros controles y procedimientos de
seguridad, y la mayoría de ellos serán ineficaces.
Si ya existiera un proceso establecido de seguridad del
negocio, entonces el desafío pasa a ser el alineamiento
y la integración. ISM debe asegurar que se obtenga
información precisa del proceso de seguridad del
negocio sobre las necesidades, impacto y prioridades del
824_005 Chapter 04.indd 160
negocio, y que las políticas, información y planes de ISM
estén alineados e integrados con las del negocio. Una
vez se consiga este alineamiento, el desafío pasa a ser
mantenerlos alineados a través de la gestión y control del
cambio en el negocio y TI utilizando un control estricto
de Gestión de Cambios y Gestión de la Configuración. De
nuevo, ésto requiere soporte y compromiso del negocio y
de la gestión senior.
Los CSF principales para el proceso ISM son:
■■ Protección del negocio frente a violaciones de
seguridad
■■ Determinación de una política clara y acordada,
integrada con las necesidades del negocio
■■ Procedimientos de seguridad que estén justificados,
sean adecuados y estén respaldados por la gestión
senior
■■ Marketing y formación eficaz en los requisitos de
seguridad
■■ Mecanismo de mejora
■■ La seguridad de la información es una parte integral
de todos los servicios de TI y de todos los procesos de
ITSM
■■ La disponibilidad de los servicios no se ve
comprometida por incidencias de seguridad
■■ Clara propiedad y concienciación de las políticas de
seguridad entre la comunidad de clientes.
Los sistemas de información pueden crear muchos
beneficios directos e indirectos, y también muchos riesgos
directos e indirectos. Estos riesgos han generado un gap
entre la necesidad de proteger los sistemas y servicios y
el grado de protección aplicado. El gap se debe a factores
internos y externos que incluyen el uso extendido de
la tecnología, dependencia creciente del negocio en TI,
complejidad y capacidad de interconexión creciente de
los sistemas, desaparición de las barreras tradicionales en
las organizaciones y requisitos regulatorios cada vez más
costosos.
Esto implica que existen nuevas áreas de riesgo
que podrían tener un impacto importante sobre las
operaciones de negocio críticas, como por ejemplo:
■■ Requisitos cada vez mayores para la disponibilidad y
robustez
■■ Posibilidad cada vez mayor de que se produzca
una mala utilización y abuso de los sistemas de
información que afecten a la privacidad y valores
éticos
■■ Peligros externos de hackers, que provocan
denegación del servicio y ataques de virus,
extorsión, espionaje industrial y fugas de información
organizativa o datos privados.
22/1/10 13:49:43

Debido a que la tecnología nueva proporciona la
posibilidad de una brusca mejora del rendimiento del
negocio, la mejora y fundamento de la seguridad de la
información puede agregar valor real a la organización
al contribuir a la interacción con los socios comerciales,
estrechar las relaciones con los clientes, mejorar la ventaja
competitiva y proteger la información. También puede
permitir formas nuevas y más sencillas para procesar
transacciones electrónicas y generar confianza. En la
economía global y competitiva actual, si una organización
desea hacer negocios, es muy posible que se le soliciten
detalles sobre su postura de riesgo y resultados de
su desempeño anterior expresados en las pruebas
realizadas para garantizar la seguridad de sus recursos de
información.
Otras áreas de riesgos graves asociados con ISM incluyen:
■■ Falta de compromiso del negocio hacia los procesos y
procedimientos de ISM
■■ Falta de compromiso del negocio y falta de
información adecuada sobre planes y estrategias
futuros
■■ Falta de compromiso de la gestión senior o de
recursos y/o presupuesto para el proceso ISM
■■ Los procesos se centran excesivamente en los
problemas de la tecnología y no se centran lo
suficiente en los servicios de TI y en las necesidades y
prioridades del negocio
■■ La evaluación y gestión del Riesgo se realizan de
forma aislada, y sin colaboración con Gestión de la
Disponibilidad e ITSCM
■■ Las políticas, planes, riesgos e información de ISM
se desactualizan y pierden su alineamiento con la
correspondiente información relevante, planes y
seguridad del negocio.
4.7  Gestión de Suministradores
4.7.1  Propósito/meta/objetivo
‘La meta del proceso de Gestión de suministradores es
gestionar suministradores y los servicios que suministran
para proporcionar la calidad continua del servicio de TI para
el negocio, asegurando que se obtenga una buena relación
calidad-precio.’
El proceso Gestión de Suministradores asegura que se
gestionen los suministradores y los servicios que proveen
para dar soporte a los objetivos del servicio de TI y
expectativas del negocio. El objetivo de esta sección es
concienciar sobre el contexto de trabajo con socios y
suministradores del negocio, y cómo este trabajo puede
824_005 Chapter 04.indd 161
Procesos de Diseñ̃o del Servicio | 161
dirigirse de la mejor forma para materializar el beneficio
de negocio en la organización.
Es muy importante que los procesos y planificación de
Gestión de Suministradores se impliquen en todas las
etapas del Ciclo de Vida del Servicio, desde estrategia
y diseño, a través de transición y operación, hasta
mejora del servicio. La complejidad de las exigencias de
negocio requiere un ámbito completo de habilidades
y capacidades para dar soporte a la provisión de un
conjunto integral de servicios de TI a un negocio.
En consecuencia, el uso de redes de valor y los
suministradores y servicios que proveen son una parte
integral de cualquier solución extremo a extremo. Los
suministradores y la gestión de suministradores y socios
son esenciales para la provisión de servicios de TI de
calidad.
El propósito del proceso de Gestión de Suministradores
es conseguir una buena relación calidad-precio con los
suministradores y garantizar que éstos se ciñan a los
objetivos incluidos en sus contratos y acuerdos, mientras
cumplen todos los términos y condiciones.
Los principales objetivos del proceso Gestión de
Suministradores son:
■■ Conseguir una buena relación calidad-precio con el
suministrador y contratos
■■ Asegurar que los acuerdos y contratos de soporte con
suministradores estén alineados con las necesidades
de negocio, y den soporte y estén alineados con los
objetivos de los SLRs y SLAs, junto con SLM
■■ Gestionar relaciones con suministradores
■■ Gestionar el rendimiento de los suministradores
■■ Negociar y acordar contratos con suministradores y
gestionarlos a lo largo de su ciclo de vida
■■ Mantener una política de suministradores y una Base
de Datos de Suministradores y Contratos (SDC).
4.7.2 Ámbito
El proceso Gestión de Suministradores debería incluir
la gestión de todos los suministradores y contratos
para dar respaldo a la provisión de servicios de TI al
negocio. Cada proveedor de servicio debería contar
con procesos formales para la gestión de todos los
suministradores y contratos. Sin embargo, los procesos
deberían adaptarse en función de la importancia del
suministrador y/o el contrato y el impacto de negocio
potencial sobre la provisión de servicios. Muchos
suministradores proporcionan soporte para servicios
y productos que independientemente tienen un rol
relativamente menor e indirecto en la generación de
valor, pero que colectivamente realizan una contribución
22/1/10 13:49:43
 162 | Procesos de Diseñ̃o del Servicio
directa e importante a la generación de valor y a la
implementación de la estrategia general del negocio.
Cuanto mayor sea la contribución que el suministrador
aporte al valor del negocio, más esfuerzo debería poner
el proveedor de servicio en la gestión del suministrador y
más debería implicarse éste en el desarrollo y realización
de la estrategia del negocio. Cuanto menor sea la
contribución de valor del suministrador, más probable
será que la relación se gestione principalmente a un nivel
operativo, con una interacción limitada con el negocio.
En algunas organizaciones, particularmente las grandes,
podría ser apropiado la gestión de los equipos internos
y suministradores, en los que las unidades de negocio
pueden dar soporte a elementos clave.
El proceso Gestión de Suministradores deberá incluir:
■■ Implementación y aplicación de la política del
suministrador
■■ Mantenimiento de una Base de Datos de
Suministradores y de Contratos (SCD)
■■ Categorización y evaluación del riesgo de
suministradores y contratos
■■ Evaluación y selección de suministradores y contratos
■■ Desarrollo, negociación y acuerdo de contratos
■■ Revisión, renovación y finalización de contratos
Proveedor de Servicio
Gestión de Suministr.
Propietario del Proceso
Gestor de Gestor de
Suministradores 1 Suministradores 2
Servicio Servicio Servicio
Suministrador 3
Suministrador 2
Suministrador 1
Suministrador
subcontratado 1
Figura 4.29  Gestión de Suministradores – roles e interfaces
824_005 Chapter 04.indd 162
■■ Gestión y rendimiento de los suministradores
■■ Acuerdo e implementación del servicio y planes de
mejora del suministrador
■■ Mantenimiento de contratos, términos y condiciones
estándar
■■ Gestión de resolución de conflictos contractuales
■■ Gestión de suministradores subcontratados.
Gestión de Suministradores de TI a menudo debe cumplir
los estándares, directrices y requisitos organizativos o
corporativos, particularmente los legales, financieros y de
aprovisionamiento corporativos, tal y como se ilustra en la
Figura 4.29.
Para garantizar que los suministradores proporcionen una
buena relación calidad-precio y cumplan sus objetivos
de servicio, un individuo dentro de la organización del
proveedor de servicio debería ser propietario de la relación
entre cada suministrador. Sin embargo, un único individuo
puede ser propietario de la relación para uno o más
suministradores, tal y como se ilustra en la Figura 4.29.
Para asegurar que las relaciones se desarrollen de forma
consistente y que el rendimiento de los suministradores
se revise y gestione adecuadamente, es necesario
establecer roles para el propietario del proceso de
Gestión de Suministradores y el Gestor de Contratos. En
Finanzas y
Compras
Gestor
de Contratos
Legal
Gestor de Gestor de
Suministradores 3 Suministradores 4
Servicio Servicio Servicio
Suministrador 6
Suministrador 5
Suministrador 4
Suministrador
subcontratado 2
22/1/10 13:49:43
 Procesos de Diseñ̃o del Servicio | 163

organizaciones más pequeñas, estos roles independientes 4.7.4  Políticas/principios/conceptos básicos

pueden combinarse en una única responsabilidad.
4.7.3  Valor para el negocio
Los principales objetivos del proceso de Gestión de
Suministradores son proporcionar una buena relación
calidad-precio con los suministradores y contratos para
asegurar que todos los objetivos en los contratos y
acuerdos del suministrador de soporte estén alineados
con las necesidades del negocio y objetivos acordados
dentro de los SLAs. Esto permite al negocio asegurar la
entrega de servicios de TI extremo a extremo de calidad y
homogéneos que estén alineados con las expectativas del
negocio. El proceso de Gestión de Suministradores debería
alinearse con todos los requisitos corporativos y del resto
de procesos de TI y SM, particularmente ISM e ITSCM. Esto
asegura que el negocio obtenga beneficio de los servicios
del suministrador de soporte y que estén alineados con las
necesidades del negocio.
El proceso de Gestión de Suministradores intenta asegurar
que los suministradores cumplan los términos, condiciones
y objetivos de sus contratos y acuerdos, a la vez que
se intenta incrementar la buena relación calidad-precio
con los suministradores y servicios que proveen. Toda
la actividad del proceso de Gestión de Suministradores
debería impulsarse en una estrategia de gestión de
suministradores y en la política de Estrategia de Servicio.
Para alcanzar consistencia y eficacia en la implementación
de la política, debería establecerse una Base de datos
de Contratos y Proveedores (SCD), tal y como se ilustra
en la Figura 4.30, junto con roles y responsabilidades
claramente definidos.
Idealmente, el SCD debería ser un elemento integrado de
un CMS o SKMS integral, que registre todos los detalles de
suministradores y contratos, junto con detalles del tipo de
servicio(s) o producto(s) provistos por cada suministrador,
y el resto de información y relaciones con otros CIs.
Los servicios provistos por los suministradores también
formarán una parte integral del Porfolio de Servicios y del

Estrategia y política
de suministradores

Evaluación de nuevos
suministradores y
contratos

Categorización de Establecer nuevos

suministradores y suministradores y
mantenimiento del SCD contratos

Gest. y rendimiento
de suministradores
y contratos

Base de Datos de Suministr.

y Contratos
SCD Informes e info.
de suministradores
Renovación y/o
finalización de
contratos

Figura 4.30  Proceso de Gestión de Suministradores

824_005 Chapter 04.indd 163 22/1/10 13:49:44

 164 | Procesos de Diseñ̃o del Servicio
Catálogo de Servicios. La relación entre los servicios de
soporte y los servicios de TI y de negocio que soportan
son clave para proveer servicios de TI de calidad.
Esta información dentro de SCD proporcionará un
conjunto completo de información de referencia para
todos los procedimientos y actividades de Gestión de
Suministradores:
■■ Categorización y mantenimiento de los
suministradores de la Base de datos de Contratos y
Proveedores (SCD)
■■ Evaluación y aprovisionamiento de nuevos
suministradores y contratos
■■ Establecer suministradores nuevos
■■ Gestión de Suministradores, Contratos y rendimiento
■■ Renovación y finalización de contratos.
Los dos primeros elementos dentro de la lista anterior
se tratan dentro de la etapa Diseño del Servicio. El tercer
elemento forma parte de Transición del Servicio, y los dos
últimos forman parte de la etapa Operación del Servicio y
se tratan más detalladamente en esas publicaciones.
4.7.5 Actividades, métodos y técnicas del
proceso
Esta sección proporciona más detalles sobre el proceso
Gestión de Suministradores, sus subprocesos y actividades,
y la gestión del ciclo de vida del contrato.
Al tratar con suministradores externos, se recomienda
encarecidamente establecer un contrato formal con
responsabilidades claramente definidas, acordadas y
documentadas y gestionarlo a lo largo de las etapas de su
ciclo de vida, desde la identificación de la necesidad del
negocio hasta la operación y cese del contrato.
■■ Identificación de la necesidad del negocio y
preparación del caso de negocio:
●● Elaborar una Declaración de Requisitos (SOR) y/o
Convocatoria de Licitación (ITT)
●● Asegurar la conformidad con la estrategia/política
●● Preparar el caso de negocio inicial, incluyendo
opciones (internas y externas), costes, plazos de
tiempo, objetivos, beneficios y evaluación de
riesgos.
■■ Evaluación y aprovisionamiento de nuevos
suministradores y contratos:
●● Identificar el método de compra o
aprovisionamiento
●● Establecer criterios de evaluación – por ejemplo,
servicios, capacidad (tanto personal como
organizativa), calidad y coste
824_005 Chapter 04.indd 164
●● Evaluar opciones alternativas
●● Seleccionar
●● Negociar contratos, objetivos y los términos y
condiciones, incluyendo responsabilidades, cierre,
renovación, extensión, disputa y transferencia
●● Acordar y conceder el contrato.
■■ Establecer nuevos suministradores y contratos:
●● Configurar el servicio y contrato del suministrador,
dentro del SCD y cualquier otro sistema
corporativo asociado
●● Transición del servicio
●● Establecer contactos y relaciones.
■■ Categorización de suministradores y contratos:
●● Evaluación o reevaluación del suministrador y
contrato
●● Asegurar que los cambios progresen a lo largo de
la Transición del Servicio
●● Categorización del suministrador
●● Actualización del SCD
●● Mantenimiento continuo del SCD.
■■ Gestionar el rendimiento del suministrador y contrato:
●● Gestión y control de la operación y entrega de
servicios/productos
●● Monitorizar e informar (servicio, calidad y costes)
●● Revisar y mejorar (servicio, calidad y costes)
●● Gestión del suministrador y de la relación
(comunicación, riesgos, cambios, fallos, mejoras,
contactos e interfaces)
●● Revisar, al menos anualmente, el ámbito del
servicio con respecto a la necesidad, objetivos y
acuerdos del negocio
●● Planificar un cierre/renovación/extensión.
■■ Fin de la vigencia:
●● Revisar (determinar los beneficios entregados,
requisitos continuos)
●● Renegociar y renovar o rescindir y/o transferir.
El negocio, TI, finanzas, compras y aprovisionamiento
deben colaborar juntos para asegurar que todas las etapas
del ciclo de vida del contrato se gestionen con eficacia.
Todas las áreas deben involucrarse de forma conjunta para
seleccionar la solución y gestionar el rendimiento continuo
del suministrador, asumiendo cada área la responsabilidad
de los intereses de su propia área y asumiendo las
implicaciones en toda la organización. El proceso
implicado en las etapas del ciclo de vida del contrato se
explican con detalle en las secciones siguientes.
22/1/10 13:49:44

4.7.5.  Evaluación de nuevos suministradores y
contratos
Las actividades asociadas con la identificación de
necesidades del negocio y la evaluación subsiguiente
de nuevos suministradores y contratos forman parte del
proceso de Diseño del Servicio. Las salidas de este área
proporcionan las entradas a otras etapas del ciclo de
vida del contrato. TI es esencial para el éxito continuo
del contrato y para la relación en la que el negocio está
estrechamente implicado en todos los aspectos de estas
actividades. Cada organización debería tener plantillas
y un método formal para la elaboración de casos de
negocio y su aprobación y cierre. El nivel de detalle
de las necesidades de negocio y el contenido del caso
de negocio se debería acordar, aprobar y cerrar por el
negocio y TI.
Al seleccionar un nuevo suministrador o contrato, deben
tenerse en cuenta diversos factores, incluyendo el registro
de seguimiento, capacidad, referencias, clasificación
crediticia y tamaño relativo para el negocio a realizar.
Además, en función del tipo de relación del suministrador,
pueden existir problemas personales que es necesario
tener en cuenta. Cada organización debería contar
con procesos y procedimientos para establecer nuevos
suministradores y contratos.
Aunque se reconoce que pueden existir factores que
influyen en la decisión sobre el tipo de relación o elección
de suministrador (por ejemplo, política dentro de la
organización, relaciones existentes), es esencial que en
tales casos se identifique la razón y se evalúe el impacto
por completo para asegurar que se eviten errores costosos.
Los servicios se pueden suministrar a partir de un único
suministrador o de varios. Es más probable que los
servicios sean provistos por dos o más suministradores
que compiten entre sí cuando el requisito consiste en
servicios o productos estándar que ya estén disponibles
comercialmente. El aprovisionamiento de múltiples
suministradores se empleará con más probabilidad
cuando el coste sea el criterio principal y los requisitos
para desarrollar cambios en los servicios sean bajos,
aunque también puede hacerse de esta forma para
distribuir el riesgo. Los suministradores en una lista
de aprovisionamiento múltiple se pueden designar
con estado de ‘Suministrador preferente’ dentro de la
organización, limitando o eliminando el ámbito para el
uso de otros suministradores.
Las relaciones de asociación se establecen a un nivel
ejecutivo y dependen de una voluntad en el intercambio
de información estratégica para alinear estrategias
de negocio. Muchas relaciones de suministrador
824_005 Chapter 04.indd 165
Procesos de Diseñ̃o del Servicio | 165
estratégicamente importantes se posicionan actualmente
como relaciones de asociación. Esto refleja un movimiento
que se aleja de relackiones tradicionalmente jerárquicas,
en las que el suministrador actúa subordinado a la
organización del cliente, para una relación caracterizada
por:
■■ Alineamiento estratégico: buena alineación
de cultura, valores y objetivos, que llevan a un
alineamiento de estrategias de negocio
■■ Integración: una integración cerrada de los procesos
de las dos organizaciones
■■ Flujo de información: buena comunicación e
intercambio de información a todos los niveles,
especialmente a nivel estratégico, lo que produce una
estrecha comprensión
■■ Confianza mutua: una relación establecida en la
confianza mutua entre las organizaciones y sus
individuos
■■ Sinceridad: al informar sobre el rendimiento del
servicio, costes y Análisis de Riesgo
■■ Responsabilidad colectiva: equipos de asociación
conjunta asumen la responsabilidad colectiva del
rendimiento actual y el desarrollo futuro de la relación
■■ Riesgo y recompensa compartidos: por ejemplo,
acordando cómo se comparten los costes de inversión
y beneficios resultantes en la eficiencia, o cómo
se comparten los riesgos y recompensas de las
fluctuaciones de los costes materiales.
Ambas partes obtienen beneficios de la asociación. Una
organización obtiene progresivamente más beneficio de
una relación con un suministrador a medida que aumenta
el entendimiento del suministrador con respecto a la
organización en su totalidad, desde sus arquitecturas de
inventario de TI hasta su cultura, valores y objetivos de
negocio corporativos. Con el tiempo, el suministrador
tiene la capacidad de responder más rápidamente y
adecuadamente a las necesidades de la organización.
El suministrador se beneficia de un compromiso a largo
plazo por parte de la organización, lo que le proporciona
mayor estabilidad financiera y le permite financiar
inversiones a más largo plazo, beneficiando a sus clientes.
Una asociación posibilita que las partes alineen sus
infraestructuras de TI. Los acuerdos conjuntos de
arquitectura y control del riesgo permiten a los socios
implementar un amplio rango de soluciones, desde
seguridad, interconexión, intercambio de datos/
información, hasta sistemas de procesamiento del
flujo de trabajo y aplicaciones. Esta integración puede
proporcionar mejoras del servicio y costes más bajos.
Tales movimientos también reducen los riesgos y costes
22/1/10 13:49:44
 166 | Procesos de Diseñ̃o del Servicio
asociados con soluciones tácticas puntuales, que se ponen
en práctica para comunicar TI de un suministrador y TI de
la organización.
La clave para el éxito de una relación de asociación es
aclarar perfectamente los beneficios y costes que tal
relación proporcionará antes de establecerla. Ambas partes
conocerán de esta forma qué resultado se espera de ellas.
El éxito de la asociación puede implicar la transferencia de
personal al socio u organización de externalización como
parte del acuerdo y relación.
Las organizaciones del proveedor de servicio deberían
contar con procesos documentados y formales para
evaluar y seleccionar suministradores en función de:
■■ Importancia e impacto: importancia del servicio para el
negocio, proporcionado por el suministrador
■■ Riesgo: riesgos asociados con el uso del servicio
■■ Costes: coste del servicio y su provisión.
A menudo, otras áreas de la organización del proveedor
de servicio, como Legal, Finanzas y Compras, se implicarán
con este aspecto del proceso. Las organizaciones del
proveedor de servicio deberían tener procesos que cubran:
■■ Elaboración de documentos del caso de negocio
■■ Elaboración de SoR y Convocatorias de Licitación o
documentos de propuesta
■■ Evaluación y selección formal de suministradores y
contratos
■■ Inclusión de cláusulas, términos y condiciones
estándar dentro de contratos, incluyendo la
finalización anticipada, benchmarking, rescisión o
transferencia de contratos, resolución de disputas,
gestión de suministradores subcontratados y
finalización normal.
■■ Transición de nuevos contratos y suministradores.
Estos procesos pueden y deberían ser diferentes en
función del tipo, tamaño y categoría del suministrador y
del contrato.
La naturaleza y grado de un acuerdo depende del tipo de
relación y de la evaluación de los riesgos implicados. Un
Análisis de Riego previo al acuerdo es una etapa esencial
al establecer cualquier acuerdo con un suministrador
externo. Para cada parte, expone los riesgos que es
necesario abordar y debe ser tan completo como práctico,
abarcando una amplia variedad de riesgos, que incluyen
los financieros, de reputación del negocio, operativos,
regulatorios y legales.
Un acuerdo completo minimiza los riesgos de conflictos
debido a una diferencia de expectativas. Se mantiene un
acuerdo flexible, capaz de adaptarse adecuadamente a lo
824_005 Chapter 04.indd 166
largo de la vigencia del acuerdo y tolera el cambio con
una necesidad de renegociación mínima.
El contenido de un contrato de soporte o acuerdo de
servicio básico es el siguiente:
■■ Términos y condiciones básicos: vigencia (duración)
del contrato, partes, ubicaciones, ámbito, definiciones
y bases comerciales.
■■ Descripción y ámbito del servicio: funcionalidad
de los servicios provistos y su grado, junto con
las restricciones en la entrega del servicio, como
el rendimiento, disponibilidad, capacidad, interfaz
técnico y seguridad. La funcionalidad del servicio
puede definirse explícitamente, o en el caso de
servicios bien establecidos, incluyendo por referencia
otros documentos establecidos, como el Porfolio de
Servicios y el Catálogo de Servicios.
■■ Estándares de servicio: mediciones del servicio y
los niveles mínimos que constituyen el rendimiento
y calidad aceptables; por ejemplo TI puede tener
un requisito de rendimiento para responder a una
petición de un sistema nuevo de escritorio en 24
horas, estimándose que se habrá producido un
servicio aceptable cuando se cumpla este requisito de
rendimiento en el 95% de los casos. Los niveles de
servicio deben ser realistas, medibles y alineados con
las prioridades de negocio de la organización y apoyar
los objetivos acordados dentro de los SLRs y SLAs.
■■ Rangos de carga de trabajo: rangos de volumen
dentro de los cuales se aplican los estándares de
servicio, o para los que se aplican técnicas de
establecimiento de precios particulares.
■■ Información de Gestión (MI): datos que debe
informar el suministrador sobre el rendimiento
operativo - asegúrese de que MI se centre en las
medidas de información más importantes o principales
sobre las cuales se evaluará la relación. Los Indicadores
Clave de Rendimiento (KPIs) y el Cuadro de Mando
Integral (BSC) pueden ser parte del núcleo central de
los datos de rendimiento incluidos en los informes.
■■ Responsabilidades y dependencias: descripción de
las obligaciones de la organización (respaldando los
esfuerzos de provisión del servicio del suministrador)
y del suministrador (en su provisión de los servicios),
incluyendo comunicación, contactos y escalado.
También puede contener un acuerdo de nivel de servicio
ampliado:
■■ Régimen de débito y crédito del servicio (incentivos y
penalizaciones)
■■ Criterios de rendimiento adicionales.
22/1/10 13:49:44

A continuación se ofrece una muestra limitada de los
temas legales y comerciales que normalmente cubre un
acuerdo de servicio o contractual:
■■ Ámbito de los servicios a proveer
■■ Requisitos de rendimiento del servicio
■■ División y acuerdo de responsabilidades
■■ Puntos de contacto, frecuencia y contenido de la
comunicación e información
■■ Revisión de contratos y procesos de resolución de
conflictos
■■ Estructura de precios
■■ Términos de pago
■■ Compromisos con el cambio y la inversión
■■ Proceso de cambio del acuerdo
■■ Confidencialidad y acuerdos
■■ Derechos de propiedad intelectual y copyright
■■ Limitaciones de responsabilidad
■■ Derechos de finalización de cada parte
■■ Obligaciones en la finalización y después de la misma.
La forma final de un acuerdo, y parte de la terminología,
puede depender de las visiones y preferencias de los
departamentos de aprovisionamiento y legal, o de firmas
legales especializadas.
Consejo
Pida asesoramiento legal al formalizar acuerdos de
suministro externos.
Contratos formales
Los contratos formales son adecuados para los acuerdos
de suministro externos que realicen una contribución
importante a la entrega y desarrollo del negocio. Los
contratos proporcionan compromisos legales vinculantes
entre el cliente y el suministrador, y tratan las obligaciones
que cada organización tiene con respecto a la otra desde
el primer día del contrato, que a menudo se amplían más
allá de su finalización. Un contrato sirve de base para
acuerdos de suministrador externo cuando se requiera
un compromiso exigible. Las relaciones de alto valor y/o
estratégicas se ven respaldadas por un contrato formal.
La naturaleza formal y vinculante de un contrato no es
contraria a la cultura de un contrato de asociación, sino
más bien conforma la base sobre la que puede fundarse la
confianza en la relación.
Es probable que un contrato se estructure con un
apartado principal, que contiene las cláusulas comerciales
y legales, y con los elementos de un acuerdo de servicio,
tal y como se describió anteriormente, adjuntos como
824_005 Chapter 04.indd 167
Procesos de Diseñ̃o del Servicio | 167
anexos. Los contratos también pueden incluir otros
documentos diversos como anexos, por ejemplo:
■■ Requisitos de seguridad
■■ Requisitos de continuidad del negocio
■■ Estándares técnicos acordados
■■ Planes de migración (cambio planificado y acordado
previamente)
■■ Acuerdos de divulgación.
La mayoría de las organizaciones grandes cuentan
con departamentos legales y de aprovisionamiento
especializados en contratos de aprovisionamiento. Pueden
contratarse servicios de firmas legales especializadas que
respalden la función legal y de aprovisionamiento interna
al establecer contratos formales importantes.
Acuerdos de soporte
En ITIL, se define un SLA como un ‘acuerdo escrito, entre
un proveedor de servicio y el(los) cliente(s), que declara
los niveles de servicio acordados para un servicio’. Los
proveedores de servicio deberían ser conscientes de
que los SLAs se utilizan generalmente para formalizar
relaciones basadas en servicios, interna y externamente,
y que, aunque satisfacen la definición anterior, tales
acuerdos difieren considerablemente en el detalle
cubierto.
Mensaje clave
Las visiones de algunas organizaciones, como el
Chartered Institute of Purchase and Supply (CIPS)
y diversos abogados especializados, indican que
los SLAs no se deberían emplear para gestionar
relaciones externas, a menos que formen parte de
un contrato subyacente. La Guía Completa para
Preparar e Implementar Acuerdos de Nivel de Servicio
(2001) destaca que no puede exigirse legalmente
el cumplimiento de un SLA independiente, sino
que ‘representa la buena voluntad y fe de las partes
firmantes’. Por lo tanto, en interés de los proveedores
de servicio y suministradores, los SLAs se incorporan
a un marco de trabajo contractual adecuado que
satisface el objetivo de ITIL para que los SLAs sean
acuerdos vinculantes.
Los SLAs, acuerdos de soporte y contratos deberían
revisarse regularmente para asegurar que el rendimiento
satisfaga los niveles de servicio que se han acordado.
La organización probablemente dependerá de sus
propios grupos de soporte interno hasta cierto grado.
Es aconsejable contar con acuerdos formales en vigor
con estos grupos para alcanzar los objetivos del SLA.
22/1/10 13:49:44
 168 | Procesos de Diseñ̃o del Servicio
Los Acuerdos de Nivel Operativo (OLA) aseguran que
los servicios de soporte respalden los objetivos del SLA
del negocio/TI. Los OLAs se centran en los requisitos
operativos que deben cumplir los servicios. Este es
un documento no contractual, orientado al servicio,
que describe los servicios y sus estándares, con
responsabilidades y obligaciones cuando proceda.
Al igual que en el caso de los SLAs, es importante
monitorizar los OLAs para identificar problemas
potenciales. El Gestor de Nivel de Servicio tiene la
responsabilidad general de revisar el rendimiento con
respecto a los objetivos para adoptar las acciones
necesarias que permitan solucionar y evitar la recurrencia
futura de cualquier incumplimiento del OLA. En función
del tamaño de la organización y de la variedad de los
servicios, por ejemplo SLAs y OLAs, un Gestor de Nivel de
Servicio debería asumir la responsabilidad de su servicio o
conjunto de servicios.
Alto
Suministradores
Valor e importancia
Operativos
Suministradores
Medio
Bajo Suministradores
Commodity
Bajo
Riesgo e impacto
Figura 4.31  Clasificación por categorías de los suministradores
824_005 Chapter 04.indd 168
4.7.5.2  Categorización y mantenimiento de
los suministradores de la Base de Datos de
Contratos y Proveedores (SCD)
El proceso de Gestión de Suministradores debe
ser adaptativo, dedicar más tiempo y esfuerzo a la
gestión de suministradores estratégicos (clave) que a
los suministradores menos importantes. Esto significa
que debe existir alguna forma de subproceso de
clasificación por categorías dentro del proceso de
Gestión de Suministradores para clasificar por categorías
al suministrador y su importancia para el proveedor de
servicio y para los servicios suministrados al negocio.
Los suministradores pueden clasificarse por categorías
de muchas formas, pero uno de los mejores métodos se
basa en la evaluación del riesgo e impacto asociados con
el uso del suministrador, y con el valor e importancia del
suministrador y de sus servicios para el negocio, como se
ilustra en la Figura 4.3.1.
La cantidad de tiempo y esfuerzo dedicada en la gestión
del suministrador y la relación con él dependerá de su
clasificación:
Suministradores
Estratégicos
Tácticos
Suministradores
Operativos
Medio Bajo
22/1/10 13:49:44

■■ Estratégico: para relaciones significativas de
‘asociación’ que implican que los responsables senior
compartan información estratégica para facilitar la
concepción de planes a largo plazo. Estas relaciones
normalmente se gestionarían y pertenecerían a un
nivel de gestión senior dentro de la organización
del proveedor de servicio, e implicaría mantener
contactos, revisiones regulares y frecuentes del
rendimiento. Estas relaciones probablemente
requerirían la implicación de recursos de Estrategia
del Servicio y de Diseño del Servicio, e incluirían
programas específicos de mejora continua (por
ejemplo, proveedor de servicio de red que suministre
el servicio de redes mundiales y su soporte).
■■ Táctico: para relaciones que implican una actividad
comercial importante e interacción con el negocio.
Estas relaciones normalmente se gestionarían
mediante los mandos medios e implicaría revisiones
del rendimiento y contactos regulares, incluyendo en
muchas ocasiones programas de mejora continua (por
ejemplo, organización de mantenimiento de hardware
que proporciona la resolución de fallos de hardware
del servidor).
■■ Operativo: para suministradores de productos o
servicios operativos. Estas relaciones normalmente
se gestionarían a través de los mandos operativos e
implicaría contactos infrecuentes aunque regulares y
revisiones del rendimiento (por ejemplo, proveedor de
servicio de hosting de Internet que suministre espacio
de hosting para un sitio web de bajo uso y bajo
impacto o que se utilice internamente para un servicio
de TI).
■■ Commodity: para suministradores que proporcionan
productos y servicios disponibles de bajo valor y/o
ya disponibles fácilmente que podrían aprovisionarse
alternativamente con relativa facilidad (por ejemplo,
suministradores de cartuchos de impresora o de
papel).
Las relaciones con los suministradores de importancia
estratégica reciben el principal foco de atención. Es
en estos casos donde los Gestores de Suministradores
tienen que asegurar que la cultura de la organización
del proveedor de servicio se transmita a todo el
entorno del suministrador para que la relación vaya
más allá del contrato formal inicial. El crecimiento en
popularidad del aprovisionamiento externo de servicios,
y el aumento del ámbito y complejidad de algunos
acuerdos de aprovisionamiento, han dado como resultado
una diversificación de los tipos de relaciones con los
suministradores. A nivel estratégico, es importante
entender las opciones que están disponibles para que
824_005 Chapter 04.indd 169
Procesos de Diseñ̃o del Servicio | 169
pueda establecerse el tipo más adecuado de relación con
los suministradores para obtener el máximo beneficio
para el negocio y permitir que evolucione en línea con las
necesidades del negocio.
Consejo
Para seleccionar satisfactoriamente el tipo más
apropiado de relación con los suministradores, es
necesario que haya un entendimiento claro de los
objetivos de negocio que se tienen que alcanzar.
Varios factores, desde la naturaleza del servicio hasta
el coste global, determinan la importancia de un
suministrador desde una perspectiva del negocio. Como
se mostrará posteriormente, mientras mayor sea la
importancia de la relación con los suministradores para
el negocio, mayores serán las necesidades del negocio
en cuanto a la gestión y desarrollo de una relación. Un
método de clasificación formal por categorías puede
ayudar a establecer esta importancia.
Este valor para el negocio, medido como la contribución
aportada a la cadena de valor del negocio, proporciona
una evaluación más alineada con el negocio que el
simple precio del contrato. Además, mientras más
servicios estándar se estén suministrando, menor será
la dependencia de la organización con respecto al
suministrador, y con mayor facilidad se podrá sustituir
(si fuera necesario). Los servicios estandarizados dan
soporte al negocio minimizando el time to market en el
despliegue de servicios de negocio nuevos o modificados
y ayudando a llevar a cabo estrategias de reducción de
costes. Puede encontrar más información sobre esta
materia en la publicación Estrategia del Servicio.
Mientras más personalizados sean esos servicios, mayor
será la dificultad a la hora de utilizar un suministrador
alternativo. La personalización podría beneficiar al
negocio, contribuyendo a la ventaja competitiva a través
de un servicio diferenciado, o podría ser el resultado de
una evolución operativa.
Los servicios personalizados aumentan la dependencia con
respecto al suministrador, incrementan el riesgo y pueden
generar un aumento de costes. Desde la perspectiva de
un suministrador, los servicios adaptados podrían reducir
su capacidad para lograr economías de escala a través
de operaciones comunes, lo que da como resultado
márgenes más estrechos y la reducción del capital
disponible para futuras inversiones.
Siempre serán preferibles productos y servicios estándar
a menos que exista una clara ventaja para el negocio,
en cuyo caso un suministrador estratégico entregará el
servicio personalizado.
22/1/10 13:49:44
 170 | Procesos de Diseñ̃o del Servicio
Consejo
Las relaciones de alto valor o de alta dependencia
implican mayores riesgos para la organización. Estas
relaciones necesitan contratos integrales y una gestión
activa de la relación.
Después de establecer el tipo de suministrador, a
continuación es necesario formalizar las necesidades.
En el siguiente análisis, el término ‘acuerdo’ se utiliza
genéricamente para hacer referencia a cualquier
formalización de una relación entre las organizaciones
del cliente y del proveedor, y podría encontrarse entre
el rango de acuerdos informales y contratos integrales
legalmente vinculantes. Las relaciones simples y de
bajo valor podrían estar recogidas mediante términos
y condiciones estándar de un suministrador, y estar
gestionadas en su totalidad por TI. Por otra parte, una
relación de importancia estratégica para el negocio
requiere un contrato integral que asegure que el
suministrador dé soporte a la evolución de las necesidades
del negocio durante la vigencia del contrato. Es
necesario gestionar y desarrollar el contrato junto con el
departamento legal y de compras y con los interesados
del negocio.
Consejos
El acuerdo es la base para la relación. Mientras
más adecuado y completo sea el acuerdo, más
probabilidades habrá de que la relación ofrezca
beneficios de negocio para ambas partes.
La calidad de la relación entre el proveedor de servicio
y sus suministradores normalmente depende de los
individuos implicados de ambas partes. Por lo tanto,
es vital que se seleccionen los individuos que se
implicarán en estas relaciones teniendo en cuenta los
atributos, habilidades, competencias y personalidades
adecuados.
La entrega de un servicio de negocio podría depender de
varios suministradores internos y externos. Éstos podrían
incluir una combinación de suministradores estratégicos
y de suministradores commodity. Algunos suministradores
suministran directamente a la organización; otros son
suministradores indirectos o subcontratados que trabajan a
través de otro suministrador. Los suministradores directos
están directamente gestionados por el proveedor de
servicio; los suministradores indirectos o subcontratados
están gestionados por el suministrador líder o principal.
Cualquier suministrador podría suministrar productos
o servicios utilizados para dar soporte a varios de los
diferentes servicios de negocio.
824_005 Chapter 04.indd 170
El análisis de la cadena de suministro muestra la
correspondencia entre los servicios del negocio y los
servicios del suministrador. El análisis de los procesos
de negocio revelará los suministradores implicados en
cada proceso y los puntos de transferencia entre ellos.
La gestión de la cadena de suministro garantiza que
se establezcan claramente los límites funcionales y los
requisitos de rendimiento de cada suministrador para
garantizar que se logren los niveles de servicio generales
del negocio. Es más probable que los servicios del negocio
cumplan sus objetivos consistentemente si existe un
pequeño número de suministradores en la cadena de
suministro, y si las interfaces entre los suministradores
en la cadena fueran simples, estuvieran limitadas y bien
definidas.
La reducción del número de suministradores directos
reduce el número de relaciones que será necesario
gestionar, el número de problemas entre suministradores
que es necesario resolver y además la complejidad de
las actividades de Gestión de Suministradores. Algunas
organizaciones podrían reducir satisfactoriamente o
colapsar toda la cadena de suministro en torno a un
único proveedor de servicio, al que con frecuencia se le
hace referencia como suministrador ‘principal’. En muchas
ocasiones se externaliza Gestión de las Instalaciones
a un único socio o suministrador especialista, quien a
su vez podría subcontratar servicios de restauración,
mantenimiento de máquinas expendedoras y limpieza.
La externalización de todos los servicios de negocio
a un único ‘suministrador principal’ podría conducir a
riesgos adicionales. Por estas razones, es necesario que las
organizaciones consideren detenidamente sus estrategias
con respecto a la cadena de suministro antes de la
actividad de aprovisionamiento principal. Es necesario
considerar el ámbito de los servicios externalizados para
considerar el número de suministradores, y al mismo
tiempo garantizar que el riesgo se gestione y se adapte a
las competencias típicas del mercado de suministro.
La SCD es una base de datos que contiene detalles de los
suministradores de la organización, junto con los detalles
de los productos y servicios que suministran al negocio
(por ejemplo, servicio de correo electrónico, suministro e
instalación de PCs, Centro de Servicio al Usuario), junto
con los detalles de los contratos. La SCD contiene detalles
de los suministradores y un resumen de cada producto/
servicio (incluyendo acuerdos de soporte), información
sobre el proceso de solicitud y, si fuera aplicable, detalles
de los contratos. Idealmente, la SCD debe estar contenida
dentro del CMS general.
Las SCD son beneficiosas porque se pueden utilizar para
promocionar a los suministradores preferidos y para evitar
22/1/10 13:49:45

la compra de elementos no autorizados o incompatibles.
Con la coordinación y control de la actividad de compra,
es más probable que la organización sea capaz de
negociar tarifas preferenciales.
4.7.5.3  Establecimiento de nuevos
suministradores y contratos
Es necesario gestionar los nuevos suministradores o
contratos que se añaden a la SCD a través del proceso
Gestión de Cambios para garantizar que se evalúe
y entienda cualquier impacto. En la mayoría de las
organizaciones, la SCD es de propiedad del proceso
Gestión de Suministradores o del departamento de
aprovisionamiento o compras. La SCD proporciona
información centralizada y única para la gestión de todos
los suministradores y contratos.
Gestión del Riesgo, en colaboración con los
suministradores, se centra en la evaluación de las
vulnerabilidades de cada acuerdo o contrato con los
suministradores que representen amenazas para cualquier
aspecto del negocio, incluyendo el impacto en el
negocio, satisfacción del cliente, imagen de marca, cuota
de mercado, rentabilidad, cotización de las acciones
o impactos regulatorios o penalizaciones (en algunas
industrias).
La naturaleza de la relación afecta al nivel de riesgo para
el negocio. Es probable que los riesgos asociados con
un suministrador externalizado o estratégico sean más
numerosos y más complejos de gestionar que los riesgos
de un suministro interno. Es poco probable ‘externalizar’
el riesgo, aunque algunas veces alguna parte del riesgo
podría transferirse a la organización de externalización.
Transmitir las culpas a un suministrador no impresiona
a los clientes o usuarios internos afectados por una
incidencia de seguridad o por un fallo prolongado del
sistema. Es necesario identificar y gestionar los nuevos
riesgos que surgen de las relaciones, fortaleciendo la
comunicación y mecanismos de escalado si resulta
apropiado.
En el precontrato debe haberse abordado una importante
evaluación del riesgo, aunque ésto debe mantenerse en
vista de las necesidades cambiantes de negocio, de los
cambios en el ámbito del contrato, o de los cambios en el
entorno operativo.
La organización del proveedor de servicio y el
suministrador deben tener en cuenta las amenazas que
la relación plantea a sus propios activos y elaborar su
propio perfil de riesgo. Cada parte debe identificar a sus
respectivos propietarios del riesgo. En el seno de una
relación bien planteada, es posible compartir abiertamente
824_005 Chapter 04.indd 171
Procesos de Diseñ̃o del Servicio | 171
una buena parte o toda la evaluación con la otra parte. Al
involucrar a expertos del suministrador en las evaluaciones
del riesgo, especialmente en la Evaluaciones del Riesgo
Operativo (ORAs), la organización puede conseguir un
conocimiento profundo y valioso y mejorar el alcance de
la evaluación.
Al evaluar los riesgos de la interrupción de los servicios o
funciones del negocio, el negocio podría tener diferentes
prioridades para el reestablecimiento del servicio/función.
Análisis de Impacto en el Negocio (BIA) es un método
utilizado para evaluar los impactos en las diferentes áreas
del negocio que implican una pérdida de servicio. La
evaluación del riesgo y las actividades de BIA asociadas
con suministradores y contratos debe realizarse en
estrecha colaboración con Gestión de la Continuidad
del Servicio, Gestión de la Disponibilidad y Gestión de la
Seguridad de la Información, con el objetivo de reducir
el impacto y probabilidad de fallo del servicio como
resultado del fallo del suministrador o de su servicio.
Cuando se hayan completado estas actividades y se haya
incluido la información de los suministradores y contratos
en la SCD, incluyendo los individuos responsables de
la gestión del nuevo suministrador y/o contratos, será
necesario establecer la frecuencia de las reuniones de
revisión del servicio/suministrador y de las reuniones de
revisión de los contratos, con la aplicación de puntos
de interrupción, umbrales automatizados y advertencias.
La introducción de nuevos suministradores y contratos
debe gestionarse como cambios mayores a través de
transición y dentro de operaciones. Esto asegurará que
se establezcan contactos y puntos de comunicación
apropiados.
4.7.5.4  Gestión de Suministradores y Contratos y
rendimiento
A nivel operativo, es necesario aplicar procesos integrados
entre una organización y sus suministradores para
garantizar prácticas eficientes de trabajo diario. Por
ejemplo:
■■ ¿Se espera que el suministrador se alinee con el
proceso Gestión de Cambios de la organización y con
cualquier otro proceso?
■■ ¿Cómo notifica el Centro de Servicio al Usuario al
suministrador las incidencias?
■■ ¿Cómo se actualiza la información del CMS cuando
cambian los CIs como resultado de las acciones del
suministrador? ¿Quién es responsable?
Podría haber un conflicto de intereses entre la
organización del proveedor de servicio y su suministrador,
especialmente en relación con los procesos de Gestión de
22/1/10 13:49:45
 172 | Procesos de Diseñ̃o del Servicio
Cambios, Gestión de Incidencias, Gestión de Problemas
y Gestión de la Configuración. El suministrador podría
querer utilizar sus procesos y sistemas, mientras que la
organización del proveedor de servicio podría querer
utilizar los suyos propios. Si este fuera el caso, será
necesario definir y acordar responsabilidades e interfaces
claras.
Es necesario abordar éstas y muchas otras áreas para
garantizar un trabajo sin dificultades y eficiente a nivel
operativo. Para lograrlo, es necesario identificar los
contactos y establecer procedimientos para que todos
entiendan sus roles y responsabilidades. Esto debe
incluir la identificación de individuos responsables de la
propiedad de cada suministrador y contrato. Sin embargo,
una organización debe tener cuidado en no imponer
automáticamente sus propios procesos, sino aprovechar la
oportunidad de aprender de sus suministradores.
Ejemplo
Se ha adjudicado un contrato para un Sistema de
Control de Almacenes personalizado para el que el
departamento de TI de la organización ha desarrollado
procesos para dar soporte al servicio activo. Esto
incluyó procedimientos para registrar y documentar
el trabajo realizado por los ingenieros de campo en el
servicio (por ejemplo, cambios, reparaciones, mejora
y reconfiguraciones). En una reunión de seguimiento
del proyecto, el suministrador confirmó que habían
examinado los procedimientos y que podrían seguirlos
si fuera necesario. Sin embargo, después de haber
estado en esta situación muchas veces anteriormente,
ya habían desarrollado un conjunto de procedimientos
para abordar tales eventos. Estos procedimientos eran
considerablemente más adecuados, eficaces y fáciles de
seguir que aquellos desarrollados y propuestos por la
organización.
Además de las interfaces de proceso, es fundamental
identificar cómo se gestionan los problemas a nivel
operativo. Después de haber definido y comunicado
claramente las rutas de escalado, es probable identificar
los problemas y resolverlos con anticipación, minimizando
el impacto. Tanto la organización como el suministrador se
benefician de la detección y resolución anticipadas de los
problemas.
Ambos lados deben esforzarse en establecer buenos
vínculos de comunicación. El suministrador aprende
más sobre el negocio de la organización, sus requisitos
y sus planes, lo que ayuda al suministrador a entender
y satisfacer las necesidades de la organización. A su vez,
la organización se beneficia de un suministrador más
824_005 Chapter 04.indd 172
responsable que sea consciente de las directrices de
negocio y de cualquier problema, y por lo tanto tiene más
capacidad de ofrecer soluciones apropiadas. Mantener
vínculos estrechos a diario puede ayudar a cada parte a
ser consciente de la cultura y formas de trabajar de la otra
parte, lo que reduce la posibilidad de malentendidos y
conduce a una relación más satisfactoria y duradera.
Es necesario que tengan lugar dos niveles de revisión
formal a lo largo del ciclo de vida del contrato para
minimizar el riesgo y para garantizar que el negocio
ofrezca el máximo beneficio derivado del contrato:
■■ Revisiones de rendimiento del servicio/
suministrador: deben elaborarse informes regulares
sobre el rendimiento basados en la categoría del
suministrador y estos deben tomarse como base para
las reuniones de revisión del servicio. Mientras más
importante sea el suministrador, más frecuentes y
extensos serán los informes y revisiones
■■ Revisiones del servicio, alcance del servicio y
contrato: también deben realizarse de forma regular,
al menos anualmente para todos los suministradores
principales. El objetivo de éstas debe ser revisar el
servicio, rendimiento general, alcance y objetivos del
servicio y del contrato, junto con cualquier acuerdo
asociado. Esto debe compararse con las necesidades
originales y actuales del negocio para garantizar que
el suministrador y los contratos sigan alineados con las
necesidades del negocio y continúen entregando valor
por dinero.
Deben mantenerse reuniones formales y regulares para
revisar el rendimiento del suministrador con respecto a los
niveles de servicio, siempre a un nivel operativo detallado.
Estas reuniones ofrecen una oportunidad para comprobar
que la gestión actual del rendimiento del servicio
permanece centrada en el soporte de las necesidades del
negocio. Los aspectos habituales incluyen:
■■ Rendimiento del servicio frente a los objetivos
■■ Revisiones de incidencias y problemas, incluyendo
cualquier problema escalado
■■ Retroalimentación del negocio y del cliente
■■ Cambios mayores que tendrán o podrían tener
efecto en el servicio durante el siguiente periodo del
servicio, así como los cambios fallidos y aquellos que
provocaron incidencias
■■ Eventos clave del negocio durante el siguiente
periodo del servicio a los que es necesario que el
suministrador ponga una atención particular (por
ejemplo, procesamiento de final del trimestre)
■■ Mejores prácticas y Programas de Mejora del Servicio
(SIP).
22/1/10 13:49:45

Las iniciativas y acciones mayores de mejora del servicio
se controlan a través de SIPs con cada suministrador,
incluyendo cualquier acción para abordar cualquier fallo o
debilidad. El progreso de los SIP existentes, o la necesidad
de una nueva iniciativa, se revisan en las reuniones de
revisión del servicio. Las organizaciones proactivas o
innovadoras no sólo utilizan SIPs para abordar fallos,
sino para mejorar un servicio logrado consistentemente.
Es importante que un contrato proporcione iniciativas
apropiadas para que ambas partes inviertan en la mejora
del servicio. Estos aspectos se describen con más detalle
en la publicación de Mejora Continua del Servicio.
Los mecanismos de gobierno para suministradores y
contratos se extraen de las necesidades de los interesados
adecuados en diferentes niveles dentro de cada
organización, y se estructuran para que los representantes
de la organización se enfrenten a sus homólogos de
la organización del suministrador. La definición de las
responsabilidades de cada representante, los foros de
reuniones y procesos, garantizan que cada persona se
implique en el momento adecuado para dirigir o influir en
las actividades correctas.
La escala de importancia del servicio y/o del suministrador
influye en los acuerdos de gobierno necesarios. Mientras
más significativa sea la dependencia, mayor compromiso
y esfuerzo se necesitarán para gestionar la relación. El
esfuerzo necesario del lado del proveedor de servicio
para gobernar un contrato de externalización no deberá
subestimarse, especialmente en industrias fuertemente
reguladas como por ejemplo los sectores financiero y
farmacéutico.
Un objetivo clave para Gestión de Suministradores es
garantizar que se materialice el valor de un suministrador
para la organización. El valor se materializa a través de
todos los aspectos de la relación, desde el aseguramiento
del rendimiento operativo, capacidad de respuesta a las
peticiones de cambio y fluctuaciones de la demanda,
pasando por la contribución de conocimiento y experiencia
hasta la capacidad de la organización. El proveedor de
servicio también debe asegurar que las prioridades del
suministrador se correspondan con las prioridades del
negocio. El suministrador debe entender cuáles de sus
niveles de servicio son más significativos para el negocio.
Ejemplo
Una gran empresa multinacional había aplicado
acuerdos de software con el mismo suministrador en
más de 24 países. Con el acuerdo de una única licencia
global con el suministrador, el ahorro anual logrado por
la compañía fue de 5.000.000£.
824_005 Chapter 04.indd 173
Procesos de Diseñ̃o del Servicio | 173
Para garantizar que todas las actividades y contactos para
un suministrador sean consistentes y estén coordinados,
cada relación con el suministrador implica una
responsabilidad individual única asignada para todos los
aspectos de la relación.
Ejemplo
Una organización de venta al por menor de escala
nacional tenía un único responsable (propietario) a
cargo de la gestión de su suministrador principal de
servicios de red. Sin embargo, los servicios, contratos y
facturación estaban gestionados por varios individuos
diseminados por toda la organización. El propietario
individual propuso un caso de negocio para la
propiedad única del suministrador y para todos los
diferentes contratos, junto con la consolidación de
todas las facturas individuales en una única factura
trimestral. El ahorro de costes estimado para la
organización superó las 600.000 £ anuales.
Las encuestas de satisfacción también desempeñan
un rol importante a la hora de revelar el grado de
alineamiento de los niveles de servicio del suministrador
con las necesidades del negocio. Una encuesta podría
revelar casos en los que existe insatisfacción con el
servicio, aunque el suministrador se esté comportando
aparentemente bien frente a sus objetivos (y viceversa).
Esto podría producirse si los niveles de servicio se han
definido inadecuadamente, y debiera conducir a una
revisión de los contratos, acuerdos y objetivos. Algunos
proveedores de servicio publican tablas de posiciones
de los suministradores basadas en los resultados de
sus encuestas, lo que estimula la competencia entre
suministradores.
Para esas relaciones significativas en las que el negocio
tiene un interés directo con el suministrador, tanto el
negocio (junto con el departamento de compras) como TI,
habrán establecido sus objetivos para la relación y habrán
definido los beneficios que esperan obtener. Esto forma
una parte importante del caso de negocio para iniciar la
relación.
Estos beneficios deben vincularse y ser complementarios
y deben medirse y gestionarse. Si el negocio estuviera
buscando mejoras en el servicio al cliente, las relaciones
del suministrador de TI que contribuyen a esos servicios
del cliente deben ser capaces de demostrar la mejora del
servicio en su propio dominio y cuánto ha contribuido a la
mejora del servicio al cliente.
Para que las evaluaciones de los beneficios sigan siendo
válidas durante la vigencia del contrato, tienen que
tenerse en cuenta los cambios circunstanciales que se han
22/1/10 13:49:45
 174 | Procesos de Diseñ̃o del Servicio
producido desde que se preparó el caso de beneficios
original. Se podría haber seleccionado a un suministrador
en función de su capacidad para ofrecer un 5% de
reducción de los costes operativos anuales comparado
con otras opciones, aunque después de dos años no haya
ofrecido ningún ahorro de costes. Sin embargo, si esto se
debiera a cambios en el contrato, o a costes generales de
la industria que también hubieran afectado a las demás
opciones, es probable que todavía se esté materializando
un ahorro relativo de costes. Un caso de beneficios
sostenido muestra ese ahorro.
Las evaluaciones de beneficios con frecuencia reciben
menos prioridad que las iniciativas de ahorros de costes, y
en los informes de rendimiento se les da menos prioridad
que a los problemas e inventarios de problemas, aunque
es importante que se identifiquen los logros para fomentar
una relación a largo plazo. Un informe de beneficios
debe realizar evaluaciones de objetivos con respecto a
los objetivos originales, aunque también podría incluir
evidencias anecdóticas de logros y de valor añadido que
levanten la moral.
Consejo
Para ambas organizaciones es importante y para hacer
perdurar la duración de la relación, que los beneficios
que se derivan de la relación se revisen y se informe de
ellos regularmente.
Una evaluación del éxito de la relación con un
suministrador, desde una perspectiva de negocio,
probablemente se basará sustancialmente en el
rendimiento financiero. Incluso si un servicio se estuviera
llevando a cabo adecuadamente, puede que no esté
satisfaciendo objetivos financieros de una o ambas partes.
Es importante que ambas partes continúen beneficiándose
financieramente de la relación. Un contrato que reduzca
demasiado los márgenes de un suministrador podría
implicar que el suministrador reduzca la inversión, dando
como resultado una degradación gradual del servicio, o
incluso una amenaza en la viabilidad del suministrador. En
cualquier caso esto podría conducir a impactos negativos
de negocio en la organización.
La clave de una Gestión Financiera exitosa del contrato
a largo plazo radica en un esfuerzo conjunto dirigido a
mantener el equilibrio financiero, en lugar de una relación
de confrontación que ofrezca beneficios a corto plazo
exclusivamente a una parte.
La construcción de relaciones requiere tiempo y esfuerzo.
Como resultado de ello, la organización sólo podría
ser capaz de construir relaciones a largo plazo con
algunos suministradores clave. La experiencia, cultura
824_005 Chapter 04.indd 174
y compromiso de aquellos implicados en materializar
una relación con un suministrador son al menos igual
de importantes que tener un buen contrato y régimen
de gobierno. Contar con las personas adecuadas con las
actitudes correctas en el equipo de relaciones pueden
hacer que un contrato deficiente funcione, pero un buen
contrato no asegura que un equipo de relaciones pobre
cumpla con los objetivos.
Normalmente se invierte una cantidad considerable de
tiempo y dinero en la negociación con los suministradores
principales con los que habría en juego más riesgo
para ambas partes si la relación no fuera satisfactoria.
Ambas organizaciones deben garantizar que invierten
adecuadamente en los recursos humanos asignados a la
gestión de la relación. La personalidad, comportamientos
y cultura de los representantes de la relación influyen en
la relación. En una relación de asociación, es necesario
que todos aquellos implicados sean capaces de respetar y
trabajar estrecha y productivamente con sus homólogos.
4.7.5.5  Renovación y/o terminación del contrato
Deben realizarse revisiones regulares del contrato
para garantizar que el contrato siga satisfaciendo las
necesidades del negocio. Las revisiones del contrato
evalúan el funcionamiento del contrato de forma integral
y a un nivel más senior que las revisiones del servicio que
se realizan a un nivel operativo. Estas revisiones deben
considerar:
■■ Cómo está funcionando el contrato y su relevancia
para el futuro
■■ Si fuera necesario hacer cambios en: servicios,
productos, contratos, acuerdos, objetivos
■■ ¿Cuál es la futura perspectiva de la relación
con respecto al crecimiento, reducción, cambio,
finalización, transferencia, etc.?
■■ Rendimiento comercial del contrato, revisiones frente a
benchmarks o evaluaciones del mercado, adecuación
de la estructura de precios y acuerdos de imputación
de costes
■■ Guía para la futura dirección del contrato asegurando
que se establezcan los procesos de gestión de mejores
prácticas
■■ Gobierno del contrato y suministrador.
En el caso de acuerdos de suministro de alto valor, a largo
plazo o complejos el periodo de negociación y acuerdo
del contrato puede dilatarse en el tiempo, ser costoso
y podría implicar periodo de negociación prolongado.
Esto puede representar una inclinación natural a evitar
cambios posteriores en un contrato mientras sea posible.
Sin embargo, para que el negocio obtenga todo el valor
22/1/10 13:49:45

de la relación con el suministrador, el contrato debe poder
modificarse regular y rápidamente para permitir al negocio
beneficiarse de la evolución del servicio.
El benchmarking proporciona una evaluación con respecto
al mercado. El suministrador podría comprometerse
mediante el contrato a mantener los costes con respecto
al precio de mercado. Para mantener el mismo margen,
el suministrador está obligado a mejorar su eficiencia
operativa en línea con sus competidores. Conjuntamente,
estos métodos ayudan a obtener la evaluación de una
eficiencia mejorada o deteriorada.
El punto de responsabilidad dentro de la organización
para decidir cambiar la relación con un suministrador
probablemente dependerá del tipo de relación. El
proveedor de servicio podría haber identificado una
necesidad de cambio de suministrador, basada en el
rendimiento del suministrador existente, pero para una
relación contractual es necesario tomar la decisión junto
con los departamentos de compras y de asuntos legales
de la organización.
La organización debe seguir los pasos apropiados para:
■■ Realizar un análisis minucioso del riesgo e impacto
de un cambio de suministrador en la organización y
en su negocio, especialmente durante el periodo de
transición. Esto podría ser particularmente significativo
en caso de una relación estratégica.
■■ Realizar una evaluación comercial de los costes de
salida. Esto podría incluir los costes de la terminación
contractual si no estuviera clara la responsabilidad
del suministrador, aunque es probable los costes más
significativos se asocien con un proyecto de transición.
Para cualquier relación significativa en tamaño,
ésto normalmente incluye un periodo de doble
suministro mientras se migran los servicios. Cualquier
cambio asociado con un cambio en el suministrador
aumentará los costes, tanto inmediatamente sobre
los costes fijos, como a través del tiempo cuando
sean devengados por el suministrador y se vuelvan a
reflejar como cargos por el servicio.
■■ Asegúrese de recibir consejo legal sobre los términos
de finalización, periodo y mecanismos aplicables de
notificación, y cualquier otra consecuencia que pudiera
producirse, particularmente si el contrato se diera por
finalizado con anticipación.
■■ Volver a evaluar el mercado para identificar los
potenciales beneficios del cambio de suministrador.
Una organización prudente lleva a cabo la mayoría de
estos pasos en el momento en el que se establece el
contrato original para garantizar que se incluyan las
cláusulas correctas, aunque es necesario volver a evaluar
824_005 Chapter 04.indd 175
Procesos de Diseñ̃o del Servicio | 175
esta actividad de evaluación cuando se esté considerando
un cambio de suministrador.
4.7.6  Disparadores, entradas, salidas e
interfaces
Existen muchos eventos que podrían iniciar/disparar la
actividad de Gestión de Suministradores. Estos incluyen:
■■ Incorporación de nuevas directrices de gobierno
corporativo o modificación de las existentes
■■ Modificación o definición de nuevas estrategias y/o
políticas de TI y del negocio
■■ Ajustes o nuevas necesidades del negocio,
modificación de servicios existentes o incorporación
de nuevos servicios.
■■ Requisitos nuevos o modificados dentro de acuerdos,
como SLRs, SLAs, OLAs o contratos
■■ Revisión y rectificación de diseños y estrategias
■■ Actividades periódicas, como la revisión, rectificación
o de elaboración de informes, incluyendo la revisión y
rectificación de políticas, informes y planes de Gestión
de Suministradores
■■ Peticiones de otras áreas, particularmente SLM y
Gestión de la Seguridad pidiendo asistencia sobre
problemas relacionados con el suministrador
■■ Requisitos para nuevos contratos, renovación del
contrato o terminación del contrato
■■ Reclasificación por categorías de suministradores y/o
contratos.
Las interfaces clave que la Gestión de Suministradores
tiene con otros procesos son:
■■ ITSCM: en relación con la gestión de la continuidad
del servicio de los suministradores
■■ SLM: asistencia con la determinación de objetivos,
requisitos y responsabilidades y su inclusión dentro de
acuerdos y contratos de soporte (UCs) para garantizar
que den soporte a todos los objetivos de SLRs y SLAs.
También la investigación de incumplimientos de SLAs
y SLRs provocados por un rendimiento deficiente del
suministrador.
■■ ISM: en la gestión de suministradores y su acceso
a servicios y sistemas, y sus responsabilidades con
respecto a la conformidad con políticas y requisitos de
ISM.
■■ Gestión Financiera: proporcionar fondos adecuados
para financiar requisitos y contratos de la Gestión de
Suministradores y ofrecer asesoría y guía en materia
de compras.
■■ Gestión de la Cartera de Servicios: garantizar que
todos los servicios de soporte y sus detalles y
22/1/10 13:49:45
 176 | Procesos de Diseñ̃o del Servicio
relaciones se reflejen con precisión dentro del Porfolio
de Servicios.
4.7.6.1  Entradas
■■ Información del negocio: procedente de la
estrategia de negocio, planes, planes financieros de la
organización y de la información sobre sus requisitos
actuales y futuros
■■ Estrategia de suministradores y contratos: incluye
la política de aprovisionamiento del proveedor de
servicio y los tipos de suministradores y contratos
utilizados. Está generada por los procesos de
Estrategia del Servicio
■■ Planes y estrategias de suministradores: detalles
de los planes y estrategias de negocio de los
suministradores, junto con detalles de su evolución
y planes tecnológicos así como declaraciones e
información sobre su estado financiero actual y
viabilidad de negocio proyectada
■■ Contratos, acuerdos y objetivos de
suministradores: de acuerdos y contratos nuevos y
existentes de suministradores
■■ Información del rendimiento de suministradores
y contratos: de contratos y suministradores nuevos y
existentes
■■ Información de TI: procedente de la estrategia y
planes de TI y de los presupuestos actuales
■■ Problemas de rendimiento: de los procesos de
Gestión de Problemas e Incidencias, a través de
incidencias y problemas que se asocian con un
rendimiento deficiente de contratos o suministradores
■■ Información financiera: procedente de Gestión
Financiera, el coste de los servicios del suministrador
y de la provisión del servicio, el coste de los contratos
y el beneficio resultante para el negocio y los planes
y presupuestos financieros, junto con los costes
asociados con la interrupción del servicio y el fallo del
suministrador
■■ Información del servicio: procedente del proceso
SLM, con detalles de los servicios del Porfolio
de Servicios y del Catálogo de Servicios y de los
objetivos de nivel de servicio dentro de SLAs y SLRs,
y posiblemente a partir de la monitorización de SLAs,
revisiones del servicio e incumplimientos de los SLA.
También datos sobre la satisfacción del cliente con
respecto a la calidad del servicio
■■ CMS: que contiene información sobre las relaciones
entre el negocio, los servicios, los servicios de soporte
y la tecnología.
824_005 Chapter 04.indd 176
4.7.6.2  Salidas
Las salidas de Gestión de Suministradores se utilizan
dentro de las demás partes del proceso, por muchos
otros procesos y por otras partes de la organización. En
muchas ocasiones esta información se suministra en forma
de informes electrónicos o visualizaciones sobre áreas
compartidas, o como páginas en servidores de Internet,
para asegurar que siempre se utilice la información más
actualizada. La información proporcionada es la siguiente:
■■ La Base de datos de Contratos y Proveedores
(SCD): mantiene la información necesaria para todos
los subprocesos dentro de Gestión de Suministradores,
por ejemplo, los datos monitorizados y recopilados
como parte de Gestión de Suministradores. Esto
se utiliza invariablemente como una entrada para
todas las demás partes del proceso de Gestión de
Suministradores.
■■ Información e informes de rendimiento de
suministradores y contratos: utilizada como entrada
para reuniones de revisión de suministradores y
contratos usados para gestionar la calidad del servicio
proporcionado por suministradores y socios. Esto debe
incluir información del riesgo compartido si fuera
apropiado.
■■ Actas de reuniones de revisión de suministradores
y contratos: generadas para registrar las actas y
acciones de todas las reuniones de revisión con
suministradores.
■■ Programa de Mejora de Servicio (SIP) del
Suministrador: utilizada para registrar todas las
acciones y planes de mejora acordados entre
proveedores de servicio y sus suministradores, siempre
que sean necesarios, y deben utilizarse para gestionar
el progreso de las acciones acordadas de mejora,
incluyendo medidas de reducción de riesgos.
■■ Informes de encuestas sobre suministradores:
con frecuencia muchas personas dentro de una
organización del proveedor del servicio tienen
negocios con suministradores. La retroalimentación
de estos individuos debe recopilarse para garantizar
que se proporcione consistencia en la calidad del
servicio proporcionado por los suministradores. La
retroalimentación se puede publicar como tablas
de posiciones para motivar la competitividad entre
suministradores.
4.7.7 Indicadores Clave de Rendimiento
Se pueden utilizar muchos KPIs y métricas para evaluar la
eficacia y eficiencia del proceso y actividades de Gestión
de Suministradores. Estas métricas deben desarrollarse
22/1/10 13:49:45
 Procesos de Diseñ̃o del Servicio | 177

desde las perspectivas del servicio, cliente y negocio, ■■ Cambio continuo de las necesidades del negocio y de
como por ejemplo: TI y gestión de un cambio significativo en paralelo con
la entrega del servicio existente
■■ Negocio protegido ante la interrupción o del
rendimiento deficiente del suministrador: ■■ Trabajar con un contrato impuesto que no es ideal,
un contrato que incluye objetivos o términos y
●● Aumento del número de suministradores que
condiciones deficientes, o una definición deficiente o
cumplan los objetivos dentro del contrato
inexistente del servicio u objetivos de rendimiento del
●● Reducción del número de incumplimientos de
suministrador
objetivos contractuales.
■■ Problemas legales, especialmente con servicios
■■ Que los servicios de soporte y sus objetivos se alineen
externalizados recientemente
con las necesidades y objetivos del negocio:
■■ Experiencia insuficiente retenida dentro de la
●● Aumento del número de revisiones contractuales y
organización
del servicio mantenidas con los suministradores
■■ Estar ligados a contratos de largo plazo, sin posibilidad
●● Aumento del número de objetivos contractuales y
de mejora, que tienen cláusulas de penalización por
del suministrador alineados con objetivos de SLAs
rescisión anticipada
y SLRs.
■■ Situaciones en las que el suministrador depende de
■■ Que la disponibilidad de los servicios no esté
la organización a la hora de llevar a cabo la entrega
comprometida por el rendimiento del suministrador:
del servicio (por ejemplo, para una alimentación de
●● Reducción del número de incumplimientos del
datos), pueden provocar problemas con respecto a la
servicio provocados por los suministradores responsabilidad sobre el rendimiento deficiente del
●● Reducción del número de amenazas de servicio
incumplimientos del servicio provocados por los ■■ Disputas sobre los cargos
suministradores.
■■ Interferencia de cualquier parte en la operación de la
■■ Clara propiedad y concienciación sobre problemas
otra parte
contractuales y del suministrador:
■■ Ser un bombero diario en lugar tener un método
●● Aumento del número de suministradores con
proactivo
gestores de suministradores asignados
■■ Comunicación – no interactuar lo suficiente o lo
●● Aumento del número de contratos con gestores de
suficientemente rápido o no enfocarse en los aspectos
contratos asignados. correctos
■■ Conflictos de personalidades
4.7.8  Gestión de la Información
■■ Una parte utiliza el contrato en detrimento de la otra
Toda la información que requiera la Gestión de parte, lo que genera pérdidas en lugar de lograr una
Suministradores debe estar incluida dentro de la relación win-win
SCD. Deberá incluir toda la información asociada
■■ Perder perspectiva estratégica, centrarse en aspectos
con suministradores y contratos, además de toda la
no operativos, provocar una falta de enfoque en
información asociada con la operación de los servicios de
aspectos y objetivos estratégicos de la relación.
soporte suministrados por los suministradores. También
debe incluirse en el Porfolio de Servicios la información Los elementos clave que pueden ayudar a evitar los
asociada con estos servicios de soporte, junto con las problemas anteriores son:
relaciones con todos los servicios y componentes. Esta ■■ Disponer de un contrato escrito claramente, bien
información debe integrarse y mantenerse de forma definido y bien gestionado
que se alinee con el resto de sistemas de gestión de la
■■ Establecer una relación mutuamente beneficiosa
información de TI, particularmente con el Porfolio de
■■ Roles y responsabilidades claramente definidos (y
Servicios y el CMS.
comunicados) por ambas partes
■■ Buenas interfaces y comunicaciones entre las partes
4.7.9 Desafíos, Factores Críticos de Éxito y
■■ Procesos de Gestión del Servicio bien definidos
riesgos
■■ Seleccionar suministradores que han logrado
Gestión de Suministradores afronta muchos retos entre los
certificaciones internacionalmente reconocidas como
que se podrían incluir algunos de los siguientes:
ISO 9001, ISO/IEC 20000, etc.

824_005 Chapter 04.indd 177 22/1/10 13:49:45

 Los CSF principales para el proceso Gestión de
Suministradores son:
■■ Que el negocio esté protegido de interrupciones o
rendimiento deficiente del suministrador
■■ Que los servicios de soporte y sus objetivos se alineen
con las necesidades y objetivos del negocio
■■ Que la disponibilidad de los servicios no esté
comprometida por el rendimiento del suministrador
■■ Clara propiedad y concienciación sobre problemas
contractuales y del suministrador.
Las áreas principales de riesgo asociadas con Gestión de
Suministradores incluyen:
■■ Falta de compromiso por parte del negocio y de la
dirección senior con el proceso y procedimientos de
Gestión de Suministradores
■■ Falta de información apropiada sobre las futuras
políticas, planes y estrategias del negocio y de TI
■■ Falta de recursos y/o presupuesto para el proceso de
ISM
■■ Herencia de contratos acordados y escritos
deficientemente que no apoyan o dan soporte a las
necesidades del negocio o a los objetivos de SLAs y
SLRs
■■ Que los suministradores acuerden objetivos y niveles
de servicio en los contratos que luego sean imposibles
de cumplir, o que los suministradores fallen o sean
incapaces de cumplir los términos y condiciones del
contrato
■■ Que el personal o la cultura organizativa del
suministrador no se alineen con los del proveedor de
servicio o del negocio
■■ Que los suministradores no cooperen o no deseen
formar parte y dar soporte al proceso requerido por la
Gestión de Suministradores
■■ Que se tome el control de los suministradores y se
modifiquen las relaciones, personal y contratos
■■ Que las demandas del suministrador corporativo y
los procedimientos del contrato sean excesivos y
burocráticos
■■ Que procesos financieros corporativos deficientes,
como por ejemplo que compras no de un buen
soporte a la Gestión de Suministradores.

824_005 Chapter 04.indd 178 22/1/10 13:49:45

Actividades asociadas
con la tecnología de
Diseñ̃o del Servicio 5
5 Actividades asociadas con la tecnología  
de Diseño del Servicio
Este capítulo considera las actividades asociadas con la
tecnología en relación con la ingeniería de requisitos
y con el desarrollo de arquitecturas tecnológicas. Las
arquitecturas tecnológicas cubren aspectos de Diseño del
Servicio en las siguientes áreas:
■■ Gestión de la Infraestructura
■■ Gestión del Entorno
■■ Gestión de la Información y de los Datos
■■ Gestión de Aplicaciones.
5.1  Ingeniería de requisitos
La Ingeniería de requisitos es un método con el que se
introduce suficiente rigor en el proceso de identificación y
documentación de los requisitos del negocio y del usuario,
asegurando la trazabilidad de los cambios para cada
requisito. Este proceso incluye las etapas de adquisición,
análisis (que retroalimenta a la adquisición) y validación.
Todo esto contribuye a la producción de un documento
de requisitos riguroso y completo. El núcleo de este
documento consiste en un repositorio de requisitos
individuales que se debe ser desarrollado y gestionado. En
muchas ocasiones estos requisitos están impulsados por TI
aunque en última instancia es necesario documentarlos y
acordarlos con el negocio.
Existen muchas directrices sobre ingeniería de
requisitos, incluyendo la Práctica Recomendada para las
Especificaciones de Requisitos de Software (IEEE 830),
El Cuerpo de Conocimiento de Ingeniería del Software
(SWEBOK), CMMI y el Modelo en V, que se describen con
detalle en la publicación Transición del Servicio.
5.1.1 Diferentes tipos de requisitos
Una suposición fundamental aquí es que el análisis de
los procesos de negocio actuales y requeridos da como
resultado requisitos funcionales que deben cumplirse
a través de los servicios de TI (aplicaciones, datos,
infraestructura, entorno y capacidades de soporte).
Es importante tener en cuenta que habitualmente se
dice que existen tres tipos principales de requisitos
para cualquier sistema: requisitos funcionales, requisitos
operativos y de gestión y requisitos de usabilidad.
■■ Los requisitos funcionales son aquellos requeridos
específicamente para dar soporte a una función de
negocio particular.
■■ Los requisitos operativos y de gestión (a los que
algunas veces se les hace referencia como requisitos
no funcionales) abordan la necesidad de un servicio
que se presta en forma adecuada, está disponible
y es seguro y tratan una serie de aspectos como la
facilidad de despliegue, operatividad, necesidades de
gestión y seguridad.
■■ Los requisitos de usabilidad son aquellos que
abordan necesidades del usuario con respecto a la
‘apariencia y comportamiento’, y dan como resultado
funcionalidades del servicio que facilitan su facilidad
de uso. Este tipo de requisitos en muchas ocasiones
se considera parte de los requisitos operativos y de
gestión aunque, para los fines de esta sección, se
abordará por separado.
5.1.1.1  Requisitos funcionales
Los requisitos funcionales describen aquello que un
servicio intenta hacer y pueden expresarse como tareas o
funciones que se requiere que realice el componente. Un
método para especificar requisitos funcionales se basa en
un diagrama de contexto del sistema o en el uso de un
modelo de caso de uso. Otros métodos muestran cómo
se transformarán las entradas en salidas (flujo de datos o
diagramas de objetos) y descripciones textuales.
Por ejemplo, un diagrama de contexto del sistema captura
todos los intercambios de información entre, por un lado,
el servicio de TI y su entorno y por otro, fuentes y destinos
de datos utilizados por el servicio. Estos intercambios de
información y fuentes de datos representan restricciones
en el servicio bajo desarrollo.
Un modelo de caso de uso define un conjunto de
interacciones orientadas al objetivo entre actores externos
y el servicio que se está considerando. Los actores son
partes que están fuera del servicio y que interactúan con
él. Un actor podría reflejar una clase de roles del usuario
que los usuarios pueden desempeñar, u otros servicios
y sus requisitos. El propósito principal del modelado de
caso de uso es establecer el límite del sistema propuesto
y establecer completamente las capacidades funcionales
que se entregarán a los usuarios. Los casos de uso
182 | Actividades asociadas con la tecnología de Diseñ̃o del Servicio
también son útiles para establecer la comunicación
entre el negocio y los desarrolladores de la aplicación.
Proporcionan una base para dimensionar y proporcionar
la definición de los requisitos de usabilidad. Los casos de
uso definen todos los escenarios a los que tiene que dar
soporte una aplicación y por lo tanto, se pueden convertir
fácilmente en casos de prueba. Puesto que los casos de
uso describen la funcionalidad de un servio en el ámbito
de lo que es entendible para el negocio y TI, pueden
servir como un vehículo para especificar los elementos
funcionales de un SLA, como por ejemplo los entregables
reales del negocio que ofrece el servicio.
En un nivel ‘por debajo’ del caso de uso y del diagrama
de contexto se encuentran muchas otras técnicas de
modelado. Estos modelos representan características
estáticas y dinámicas de los servicios en desarrollo.
Un modelo conceptual de datos (ya se denominen
objetos o datos) describe los diferentes ‘objetos’ en el
servicio, sus relaciones mutuas y su estructura interna.
Las dinámicas del servicio se pueden describir utilizando
modelos de estado (por ejemplo, diagramas de transición
de estado) que muestran los diferentes estados de las
entidades y objetos, junto con eventos que podrían
provocar cambios de estado. Las interacciones entre
los diferentes componentes de la aplicación se pueden
describir utilizando diagramas de interacciones (por
ejemplo, diagramas de interacciones de objetos). Junto
con un proceso maduro de modelado de requisitos,
las herramientas CASE pueden ayudar a que estos
modelos sean y se mantengan consistentes, adecuados y
completos.
5.1.1.2  Requisitos operativos y de gestión
Los requisitos operativos y de gestión (o requisitos
no funcionales) se utilizan para definir requisitos y
restricciones en el servicio de TI. Estos requisitos sirven
como base para el dimensionamiento anticipado y las
estimaciones de costes de sistemas y servicios y pueden
dar soporte a la evaluación de la viabilidad del sistema
de TI propuesto. Los requisitos operativos y de gestión
también deben alentar a los desarrolladores a ampliar la
visión sobre los objetivos del proyecto.
Las categorías de requisitos operativos y de gestión
incluyen:
■■ Capacidad de gestión: ¿Funciona? ¿Falla? ¿Cómo
falla?
■■ Eficiencia: ¿Cuántos recursos consume?
■■ Disponibilidad y fiabilidad: ¿Qué fiabilidad debe
proporcionar?
■■ Capacidad y rendimiento: ¿Qué nivel de capacidad
necesitamos?
■■ Seguridad: ¿Qué clasificación de seguridad se
requiere?
■■ Instalación: ¿Cuánto esfuerzo se requiere para
instalar la aplicación? ¿Está utilizando procedimientos
automatizados de instalación?
■■ Continuidad: ¿Qué nivel de capacidad de
recuperación se requiere?
■■ Capacidad de control: ¿Se puede monitorizar,
gestionar y ajustar?
■■ Capacidad de Mantenimiento: ¿Qué posibilidades
presenta la aplicación para ser ajustada, corregida,
mantenida y modificada para futuros requisitos?
■■ Capacidad de operación: ¿Las aplicaciones
afectan negativamente a otras aplicaciones en sus
funcionalidades?
■■ Capacidad de medición y generación de informes:
¿Podemos medir e informar sobre todos los aspectos
requeridos de la aplicación?t
Los requisitos operativos y de gestión se pueden utilizar
para formular los atributos de calidad de la aplicación
que se está construyendo. Estos atributos de calidad se
pueden utilizar para diseñar planes de prueba para probar
las aplicaciones con respecto al cumplimiento de los
requisitos operativos y de gestión.
5.1.1.3  Requisitos de usabilidad
El propósito principal de los requisitos de usabilidad es
garantizar que el servicio cumpla las expectativas de sus
usuarios en relación con su facilidad de uso. Para lograr
esto:
■■ Establezca estándares de rendimiento para
evaluaciones de usabilidad
■■ Defina escenarios de prueba para los planes de prueba
de usabilidad y para las pruebas de usabilidad.
Al igual que los requisitos operativos y de gestión, los
requisitos de usabilidad también se pueden utilizar como
atributos de calidad de planes de diseño para probar
las aplicaciones con respecto a su conformidad con los
requisitos de usabilidad.
5.1.2 Requisitos de soporte – la visión del
usuario
Los usuarios han definido formalmente roles y actividades
como representantes del usuario en la definición de
requisitos y pruebas de aceptación. Deben implicarse
activamente en la identificación de todos los aspectos de
los requisitos del servicio, incluyendo las tres categorías
anteriores, y también en:
 Actividades asociadas con la tecnología de Diseñ̃o del Servicio | 183
■■ Instalaciones y procedimientos de formación del
usuario
■■ Actividades de soporte y procedimientos del Centro de
Servicio al Usuario.
5.1.3 Técnicas de investigación de requisitos
Existe un rango de técnicas que podrían utilizarse
para investigar situaciones de negocio y para detectar
requisitos del servicio. Algunas veces los clientes y el
negocio no están completamente seguros de cuáles son
realmente sus requisitos y necesitarán algún impulso
y ayuda del diseñador o del recopilador de requisitos.
Esto debe completarse de forma efectiva para garantizar
que no parezca que TI dicta nuevamente los requisitos
de negocio. Las dos técnicas que se utilizan más
habitualmente son las entrevistas y las reuniones de
trabajo, pero éstas normalmente se ven complementadas
por otras técnicas, como por ejemplo la observación y el
uso de escenarios.
5.1.3.1  Entrevistas
La entrevista es una herramienta clave y puede ser vital
para lograr diversos objetivos, como por ejemplo:
■■ Realizar el contacto inicial con interesados clave y
establecer una base para el avance
■■ Construir y desarrollar el buen entendimiento con
diferentes usuarios y gestores
■■ Adquirir información sobre la situación del negocio,
incluyendo los problemas encontrados.
Existen tres áreas que se consideran durante las
entrevistas:
■■ Procesos de negocio actuales que es necesario cumplir
en cualquier servicio o sistema de negocio nuevo
■■ Problemas con las operaciones actuales que es
necesario abordar
■■ Nuevas funcionalidades requeridas por el nuevo
sistema o servicio de negocio y por cualquier servicio
de TI de soporte.
El proceso de entrevista se mejora cuando el entrevistador
lo ha preparado exhaustivamente ya que esto ahorra
tiempo a la hora de evitar explicaciones innecesarias y
demuestra interés y profesionalidad. La estructura clásica
del cuestionario de ‘Por qué, Qué, Quién, Cuándo, Dónde,
Cómo’ proporciona un marco de trabajo excelente para
preparar las entrevistas.
Es igualmente importante cerrar formalmente la entrevista:
■■ Resumiendo los puntos recogidos y las acciones
acordadas
■■ Explicando lo que sucederá a continuación, después
de la entrevista y posteriormente
■■ Preguntar al entrevistado cómo se realizará cualquier
contacto posterior.
Siempre es una buena idea escribir notas de la entrevista
lo antes posible, idealmente acto seguido y normalmente
al día siguiente.
Las ventajas de la entrevista son:
■■ Desarrolla una relación con los usuarios
■■ Puede generar información importante
■■ Representa una oportunidad de entender diferentes
puntos de vista y actitudes a través del grupo de
usuarios
■■ Oportunidad de investigar nuevas áreas que surjan
■■ Recopilación de ejemplos de documentos e informes
■■ Apreciación de factores políticos
■■ Estudio del entorno en el que operará el nuevo
servicio.
Las desventajas de la entrevista son:
■■ Cara por el tiempo transcurrido
■■ No existe la oportunidad de resolución de conflictos.
5.1.3.2  Reuniones de trabajo
Las reuniones de trabajo proporcionan un foro en el que
se pueden analizar los problemas, resolver conflictos y
detectar los requisitos. Las reuniones de trabajo tienen
valor especialmente cuando existe mucha limitación de
tiempo y presupuesto, se tienen que examinar de cerca
varios puntos de vista, y se está adoptando una visión
iterativa e incremental del desarrollo del producto.
Las ventajas de la reunión de trabajo son:
■■ Se logra una visión más amplia del área de
investigación. Reunir a un grupo de interesados en
una sala permitirá un entendimiento más completo de
los problemas
■■ Se aumenta la velocidad y productividad. Es mucho
más rápido celebrar una reunión con un grupo de
personas que entrevistarlas una por una
■■ Se obtiene la aceptación del servicio de TI
■■ Se logra una visión consensuada. Si se implica a todos
los interesados, se aumenta la posibilidad de que se
responsabilicen de los resultados.
Existen algunas desventajas que incluyen:
■■ La organización podría consumir tiempo, por ejemplo,
no siempre es fácil reunir a todas las personas
necesarias al mismo tiempo
184 | Actividades asociadas con la tecnología de Diseñ̃o del Servicio

■■ Puede ser difícil reunir a todos los participantes con el Existen dos categorías principales de técnicas requeridas
nivel requerido de autoridad para una reunión de trabajo de requisitos, técnicas
■■ Puede ser difícil lograr una mezcla de personas descubridoras y técnicas de documentación, como se
operativas y del negocio para entender los diferentes muestra en la Figura 5.1.
requisitos.
5.1.3.3  Observación
El éxito o fracaso de una sesión de reunión de trabajo
depende en gran medida del trabajo preparatorio Observar el lugar de trabajo es muy útil para obtener
realizado por el facilitador y por el patrocinador del información sobre el entorno del negocio y sobre las
negocio para la reunión de trabajo. Éstos deben dedicar prácticas de trabajo. Tiene dos ventajas:
tiempo a las siguientes áreas antes de la planificación del ■■ Un entendimiento mucho mejor de los problemas y
evento: dificultades a las que se enfrentan los usuarios del
■■ El objetivo de la reunión de trabajo. Éste tiene que negocio
ser un objetivo que se pueda lograr dentro de las ■■ Ayudará a idear soluciones que tengan más
restricciones de tiempo de la reunión de trabajo. posibilidades de ser aceptadas por el negocio.
■■ A quién se invitará a participar en la reunión de Desde la perspectiva del otro, ser observados puede ser
trabajo. Es importante invitar a todos los interesados bastante inquietante, y es necesario ponderar el viejo
implicados en el objetivo o por lo menos que estén dicho de ‘cambias cuando estás siendo observado’ dentro
representados. de su método y hallazgos.
■■ La estructura de la reunión de trabajo y las técnicas
La observación formal implica vigilar que se esté llevando
que se utilizarán. Es necesario engranarlas para lograr
a cabo una tarea específica. Existe el peligro de que se
el objetivo definido, por ejemplo, recopilación y
muestre una situación irreal sin ninguna de las variaciones
priorización de requisitos, y deben tenerse en cuenta
diarias, aunque puede seguir siendo una herramienta útil.
las necesidades de los participantes.
■■ Determinar un punto de reunión adecuado. Éste
5.1.3.4  Análisis de Protocolos
podría estar dentro de la organización, aunque es
El Análisis de Protocolos simplemente consiste en
mejor utilizar uno ‘neutral’ fuera de la oficina.
conseguir que los usuarios realicen una tarea, y que
Durante la reunión de trabajo, es necesario que un describan cada paso tal y como lo realizan.
facilitador garantice que se analicen los problemas, que
se exterioricen los puntos de vista, y que se avance hasta
lograr el objetivo establecido. Es necesario mantener un
registro de los puntos clave que surjan de la discusión.
Al final de la reunión de trabajo, es necesario que
el facilitador resuma los puntos clave y las acciones.
Cada acción debe asignarse a un propietario que se
responsabilice de ella.

Modelos
de proceso
En cadena
Requisitos
Tormenta de ideas
Mapas mentales
Brainwriting Workshop (reunión de trabajo)
Diagramas
Ejercicio con Post-it de contexto

Refinamiento Diagramas de
paso a paso caso de uso

Escenarios de tareas

Figura 5.1  Técnicas sobre reuniones de trabajo de requisitos

 Actividades asociadas con la tecnología de Diseñ̃o del Servicio | 185
5.1.3.5  Seguimiento
La técnica de seguimiento implica realizar el seguimiento
de un usuario durante un período determinado como por
ejemplo un día, para descubrir un trabajo en particular.
Es una poderosa forma de entender un rol de usuario
particular. Solicitar explicaciones de cómo se realiza
el trabajo, o el flujo de trabajo, aclara algunos de los
aspectos ya asumidos.
5.1.3.6  Análisis de escenarios
Análisis de Escenarios está indicando fundamentalmente
el histórico de una tarea o transacción. Su valor reside
en que ayuda a un usuario que no está seguro de lo
que es necesario de un nuevo servicio a entenderlo más
claramente. Los escenarios también son útiles al analizar
o rediseñar procesos de negocio. Un escenario trazará el
curso de una transición desde un disparador de negocio
actual a través de cada uno de los pasos necesarios hasta
lograr un resultado acertado.
Los escenarios proporcionan un marco de trabajo para
descubrir rutas alternativas que podrían seguirse para
completar la transacción. Esto es extremadamente útil
en la detección y análisis de requisitos debido a que
se debaten situaciones en tiempo real, incluyendo las
circunstancias excepcionales.
Los escenarios ofrecen ventajas significativas:
■■ Fuerzan al usuario a incluir todos los pasos, por lo que
no existen elementos que se dan por sentado y se
aborda así el problema del conocimiento tácito
■■ Ayudando al usuario a visualizar todas las
contingencias, ayudan a hacer frente a la
incertidumbre sobre los futuros sistemas y servicios
■■ Un grupo que en una reunión de trabajo defina
un escenario identificará aquellas rutas que no se
adecuen a la cultura corporativa
■■ Proporcionan una herramienta para preparar scripts de
prueba.
Las desventajas de los escenarios son que pueden
consumir tiempo en el desarrollo, y algunos escenarios
pueden pasar a ser muy complejos. Si este fuera el caso,
es más fácil analizar si cada una de las rutas principales
alternativas se considera como un escenario por separado.
Un método popular para documentar descripciones
de escenarios es desarrollar descripciones de casos de
uso para dar soporte a diagramas de casos de uso. Sin
embargo, también existen varios métodos gráficos para
documentar un escenario, como por ejemplo storyboards,
diagramas de actividades, modelos de tareas y diagramas
árboles de decisión.
5.1.3.7  Prototipos
Los prototipos representan una técnica importante para
detectar, analizar, demostrar y validar requisitos. Para los
usuarios es difícil visualizar el nuevo servicio antes de
construirlo realmente. La generación de prototipos ofrece
una forma de mostrar al usuario cómo podría funcionar
el nuevo servicio y las formas en las que se puede utilizar.
Si un usuario no tuviera claro lo que necesita que haga el
servicio, en muchas ocasiones con un prototipo se pueden
liberar bloqueos de pensamiento y se puede producir
una nueva ola de requisitos. Los métodos incrementales e
iterativos para el desarrollo de servicios, como por ejemplo
el Método de Desarrollo de Sistemas Dinámicos (DSDM),
usan prototipos revolucionarios como parte integral de su
ciclo de vida de desarrollo.
Existe una gama de métodos para construir prototipos.
Éstos se pueden construir utilizando un entorno de
desarrollo de aplicaciones para que reflejen el servicio; las
imágenes de las pantallas podrían construirse utilizando
software de presentación; o podrían simplemente ser
‘maquetas’ en papel.
Existen dos métodos básicos de prototipos:
■■ La maqueta desechable, que sólo se utiliza para
demostrar la apariencia y comportamiento
■■ La implementación incremental, donde el prototipo se
desarrolla en el sistema final.
Es importante seleccionar convenientemente qué se
utilizará, de lo contrario habrá peligro de que una
maqueta de poca calidad se convierta en la base del
sistema real, provocando problemas posteriormente.
Existe un fuerte vínculo entre escenarios y prototipos
porque los escenarios se pueden utilizar como la base
del desarrollo de prototipos. Además de configurar los
requisitos de los usuarios, en muchas ocasiones los
prototipos pueden ayudar a los usuarios a identificar
nuevos requisitos.
Los prototipos se utilizan satisfactoriamente para:
■■ Aclarar cualquier incertidumbre en la parte de los
desarrolladores del servicio y confirmar al usuario que
se ha entendido lo que está solicitando
■■ Familiarizar al usuario con los nuevos requisitos
cuando entiendan lo que el servicio será capaz de
hacer por ellos
■■ Mostrar a los usuarios la ‘apariencia y comportamiento’
del servicio propuesto y detectar los requisitos de
usabilidad
■■ Validar los requisitos e identificar cualquier error.
186 | Actividades asociadas con la tecnología de Diseñ̃o del Servicio
Los problemas potenciales incluyen:
■■ Iteración que no se da por terminada
■■ Una visión de que si el prototipo funciona, todo el
servicio puede estar preparado mañana.
5.1.3.8  Otras técnicas
Otras técnicas que podrían utilizarse incluyen:
■■ Cuestionarios: pueden ser útiles para recopilar una
cantidad limitada de información de muchas personas
cuando las entrevistas no fueran prácticas o rentables.
■■ Registros de propósito general: la técnica implica a
los usuarios a la hora de mantener un registro sobre
un aspecto o tarea específicos. Por ejemplo, podrían
mantener un registro simple de cinco barras sobre
la frecuencia con la que necesitan transferir llamadas
telefónicas. Esto podría proporcionar información
sobre los problemas experimentados con este proceso
de negocio.
■■ Muestreo de actividades: es una forma un poco más
cuantitativa de observación y se puede utilizar cuando
sea necesario saber cómo las personas dedican su
tiempo, por ejemplo, ¿cuánto tiempo dedican a la
facturación? ¿Cuánto tiempo se dedica a los pagos
de reconciliación? ¿Cuánto tiempo se dedica a la
clasificación de peticiones?
5.1.4 Problemas con ingeniería de requisitos
Los requisitos, vistos por los usuarios como una parte
elemental del desarrollo de un nuevo servicio, constituyen
realmente el aspecto más problemático y a pesar de eso
el tiempo asignado es mucho menor que para las demás
fases.
Las escalas de tiempo y presupuestos restringidos,
ambos como resultado de las restricciones en el negocio,
presionan al equipo de desarrollo a la hora de entregar un
servicio. El problema reside en que sin el tiempo necesario
para entender y definir los requisitos adecuadamente, el
servicio que se entrega a tiempo puede que no sea el
servicio que el negocio estaba solicitando.
Los estudios realizados sobre fallos del proyecto de TI
presentan una línea común. Muchos de los proyectos
y servicios de TI insatisfactorios sugieren las siguientes
conclusiones:
■■ Una gran proporción de errores (más del 80%) se
introducen en la fase de requisitos
■■ Muy pocos fallos (menos del 10%) se introducen
en el diseño y desarrollo. Los desarrolladores están
desarrollando correctamente de acuerdo con los
requisitos, pero frecuentemente no desarrollan los
resultados correctos
■■ La mayoría del tiempo de proyecto se asigna a las
fases de desarrollo y prueba del proyecto
■■ Menos del 12% del tiempo del proyecto se asigna a
los requisitos.
Estas conclusiones son particularmente significativas ya
que el coste de la corrección de errores en los requisitos
aumenta drásticamente posteriormente durante el ciclo de
vida de desarrollo cuando se detectan.
Uno de los problemas principales con la ingeniería de
requisitos es la falta de habilidades detalladas y de un
entendimiento global del área cuando las personas lo
utilizan. Si se lleva a cabo con precisión, el trabajo puede
integrar requisitos procedentes de numerosas áreas en
muy pocas preguntas.
Otros problemas típicos con los requisitos han sido
identificados como:
■■ Falta de relevancia respecto a los objetivos del servicio
■■ Falta de claridad en la redacción
■■ Ambigüedad
■■ Duplicación entre requisitos
■■ Conflictos entre requisitos
■■ Requisitos expresados de tal forma que es difícil
evaluar si se han logrado
■■ Requisitos que asumen una solución más que
establecer qué entregará el servicio
■■ Incertidumbre entre usuarios sobre qué necesitan del
nuevo servicio
■■ Los usuarios eluden identificar los requisitos
■■ Niveles inconsistentes de detalle
■■ Una suposición de que el usuario y el personal de TI
tienen un conocimiento que realmente no poseen y
que por tanto cometen un error al asegurar que existe
un entendimiento común
■■ Crecimiento progresivo del número de requisitos – la
suma gradual de requisitos aparentemente pequeños
sin tener en cuenta un esfuerzo extra en el plan de
proyecto.
Otro problema es una incapacidad aparente de parte de
los usuarios para articular claramente lo que desean que el
servicio haga. Con mucha frecuencia se ven disuadidos de
hacerlo debido a que la naturaleza del requisito se explica
de forma directa.
 Actividades asociadas con la tecnología de Diseñ̃o del Servicio | 187

5.1.4.1  Resolución de problemas de ingeniería
de requisitos
Definición de actores
Hay algunos participantes que deben tomar parte en el
proceso de requisitos. Se pueden pensar representados
por tres amplios grupos de interesados:
■■ El negocio
■■ La comunidad de usuarios
■■ El equipo de desarrollo del servicio.
La comunidad de usuarios debe estar representada por el
experto en el dominio (o experto en la materia objeto) y
por los usuarios finales.
Conocimiento tácito
Al desarrollar un nuevo servicio, los usuarios nos pasarán
su conocimiento explicito, es decir, conocimiento de
procedimientos y datos que se encuentran en sus
mentes y que pueden articular fácilmente. Un problema
importante al detectar los requisitos es aquel procedente
del conocimiento tácito, es decir, aquellos otros aspectos
del trabajo que un usuario es incapaz de articular o
explicar.
Algunos elementos comunes que causan problemas y falta
de entendimiento son:
■■ Habilidades – la explicación de cómo llevar a cabo las
acciones utilizando sólo palabras es extremadamente
difícil.
Tabla 5.1 Ingeniería de requisitos – conocimiento tácito y explícito
Tácito
Individual Habilidades, valores, conocimiento
asumido, intuición
Corporativo Normas, back-story, cultura, comunidades
de práctica
■■ Información que se da por hecho – incluso los
usuarios de negocio experimentados o expertos
podrían fallar a la hora de mencionar información o
aclarar terminología y puede que el analista no se dé
cuenta de que se requieren preguntas posteriores.
■■ Front-story/back-story – este aspecto se asocia con
una tendencia a encuadrar una descripción de las
prácticas de trabajo actuales, o de un lugar de trabajo,
para proporcionar una visión más positiva de lo que
realmente es.
■■ Conocimiento de futuros sistemas – si el estudio se
realizara para el desarrollo de un nuevo servicio, sin
experiencia o conocimiento previo en la organización,
¿cómo saben los potenciales usuarios lo que desean?
■■ La dificultad de un extraño a la hora de asumir
un lenguaje común y las normas comunes de
comunicación. (Si no lo tuvieran, entonces el alcance
de la falta de interpretación de la situación puede
crecer considerablemente).
■■ Entendimiento intuitivo, normalmente como
consecuencia de una experiencia considerable. Con
frecuencia se piensa que los responsables de la
toma de decisiones siguen un camino lógico y lineal
de indagación mientras toman sus decisiones. En
realidad, a medida que se adquiere el conocimiento
y habilidades para la toma de decisiones, en muchas
ocasiones se abandona el camino lineal en favor de
patrones intuitivos.
Explícito
Tareas, descripciones del puesto de trabajo,
objetivos, volúmenes y frecuencias
Procedimientos, guías de estilo, procesos,
conocimiento compartido

A continuación se incluyen ejemplos de conocimiento tácito y explícito:

Tabla 5.2  Ingeniería de requisitos; ejemplos de conocimiento tácito o explícito (Maiden y Rugg, 1995)
Técnica Conocimiento explícito Conocimiento tácito Habilidades Futuros requisitos
Entrevistas √√ √ X √
Seguimiento √√ √√ √√ X
Reuniones de trabajo √√ √√ X √√
Prototipos √√ √√ √√ √√
Análisis de escenarios √√ √√ X √√
Análisis de protocolos √√ √√ √√ X
188 | Actividades asociadas con la tecnología de Diseñ̃o del Servicio
■■ Cultura organizativa – sin un entendimiento de
la cultura de una organización, el ejercicio de los
requisitos podría resultar deficiente.
Las comunidades de práctica son grupos discretos de
trabajadores, quizás asociados por tarea, departamento,
por ubicación geográfica o por algún otro factor, que
tienen sus propios conjuntos de normas y prácticas,
distintos de otros grupos dentro de la organización.
5.1.5 Requisitos de documentación
El documento con los requisitos es el núcleo del proceso
y puede tener varias formas. Normalmente el documento
incluirá un catálogo de requisitos, con cada requisito
individual documentado utilizando una plantilla estándar.
Se podría complementar este catálogo con uno o más
modelos que muestren aspectos específicos, como por
ejemplo requisitos de procesamiento o de datos.
Antes de que se introduzcan formalmente en el catálogo,
los requisitos debieran estar sujetos a un escrutinio
en profundidad. Este escrutinio podría implicar la
organización de los requisitos en grupos y comprobar que
cada requisito esté ‘bien definido’.
Una vez se considere que el documento está completo,
los representantes del negocio deben revisarlo y confirmar
que es una plasmación real de los requisitos presentes en
ese momento. Durante esta etapa los revisores examinan
los requisitos y confirman si están bien definidos y si son
claros y completos.
A medida que salgan a relucir los requisitos de diferentes
usuarios, necesitaremos documentarlos. Esto se hace
mejor en las dos fases diferentes – construcción de la
Tabla 5.3  Lista de requisitos
Requisitos Fuente
Tabla 5.4  Plantilla de requisitos
Servicio de TI Autor
ID del requisito Nombre del requisito
Fuente Propietario
Descripción de requisitos funcionales
Requisitos operativos, de gestión y de Descripción
usabilidad
Justificación
Documentos asociados
Requisitos asociados
Comentarios
Resolución
Nº de versión Histórico de cambios
lista de requisitos y posteriormente, desarrollo de un
catálogo organizado de requisitos. La lista tiende a ser un
documento informal y se puede presentar en forma de
cuatro columnas como se muestra en la Tabla 5.3.
Cada requisito de la lista debe comprobarse para ver si
está bien constituido y es SMART (específico, medible, que
pueda ser alcanzado, realista, y viable en el tiempo).
Al comprobar la totalidad o los requisitos individuales, se
puede utilizar la siguiente lista de comprobación:
■■ ¿Los requisitos son ambiguos cuando se capturan?
■■ ¿El significado está claro?
■■ ¿El requisito está alineado con el desarrollo del
servicio y con los objetivos de negocio, o esto es
irrelevante?
■■ ¿El requisito es razonable, o sería caro y requeriría
tiempo satisfacerlo?
■■ ¿Algún requisito entra en conflicto con otro, como por
ejemplo cuando sólo se pudiera implementar uno de
ellos?
■■ ¿Implican una solución en lugar de establecer un
requisito?
■■ ¿Son unidades simples o realmente son varios
requisitos agrupados en una entrada?
■■ ¿Se solapan varios requisitos o están duplicados?
Existen varios resultados posibles del ejercicio:
■■ Aceptar el requisito tal cual
■■ Volver a redactar el requisito para eliminar jergas y
ambigüedades
■■ Combinar requisitos duplicados/solapados
■■ Pedir a los usuarios que aclaren requisitos poco claros
o ambiguos.
Comentarios Nivel de detalle
Fecha
Prioridad Proceso de negocio
Fecha Petición de cambio
 Actividades asociadas con la tecnología de Diseñ̃o del Servicio | 189
5.1.5.1  El catálogo de requisitos
El Catálogo de Requisitos es el repositorio central de los
requisitos de los usuarios y todos los requisitos deben
documentarse aquí, después del análisis de la lista definida
anteriormente. El Catálogo de Requisitos debe formar
parte del Flujo de Creación de Servicios general dentro del
Porfolio de Servicios general. Cada requisito que se haya
analizado se documenta utilizando una plantilla estándar,
como por ejemplo la mostrada en la Tabla 5.4.
Las cinco entradas clave en la plantilla son las siguientes:
■■ ID del requisito – hace referencia a un ID único que
nunca cambia y que se utiliza para la trazabilidad,
por ejemplo para hacer referencia al requisito en
documentos de diseño, especificaciones de prueba
o en códigos implementados. Esto garantiza que se
hayan cumplido todos los requisitos y que todas las
funciones se basen en los requisitos.
■■ Fuente – el área de negocio o usuarios que solicitaron
el requisito o el documento en el que surgió el
requisito. El registro de la fuente de un requisito ayuda
a garantizar que se pueda responder a las preguntas o
que pueda volverse a evaluar la necesidad en el futuro
si fuera necesario.
■■ Propietario – el usuario que acepta la propiedad del
requisito individual estará de acuerdo con su correcta
redacción y documentación, y lo aprobará en las
pruebas de aceptación cuando se realicen y sean
positivas.
■■ Prioridad – el nivel de importancia y necesidad de
un requisito. Normalmente se utilizan métodos como
MoSCoW, donde se aplica la siguiente interpretación
nemotécnica:
●● Debe tener – un requisito clave sin el que el
servicio no tiene valor.
●● Debería tener – un requisito importante que debe
entregarse aunque, si no hubiera tiempo, podría
desplegarse durante una futura entrega. Debería
tratarse de un leve retraso, aunque el servicio
todavía tendría valor sin ellos.
●● Podría tener – un requisito que sería beneficioso
incluir si no costara demasiado o no se tardara
demasiado en entregar, aunque no es fundamental
para el servicio.
●● No tendrá (pero se requiere la próxima vez)
– un requisito que será necesario en el futuro
aunque no se requiere para esta entrega. En una
futura entrega del servicio, este requisito podría
actualizarse a ‘debe tener’.
Lo que se incluye a continuación debe acordarse
claramente durante esta actividad de priorización:
■■ Las prioridades de los requisitos pueden cambiar y
cambian durante la vida útil del proyecto de desarrollo
del servicio.
■■ Es necesario considerar en profundidad los requisitos
‘debería tener’ porque, si no se entregaran dentro
de la etapa de diseño inicial, podría ser imposible
implementarlos posteriormente.
■■ Invariablemente, los requisitos son más difíciles y más
caros de cumplir posteriormente en el Ciclo de Vida
del Servicio.
■■ No es cierto que sólo que los requisitos funcionales
pueden ser del tipo ‘debe tener’ ya que algunos de
los requisitos operativos y de gestión deben ser ‘debe
tener’.
■■ Descripción de los requisitos – una descripción concisa
del requisito. Un método útil para describir el requisito
utilizando la siguiente estructura:
●● Actor (o rol de usuario)
●● Frase verbal
●● Objeto (nombre o frase nominal).
■■ Si el requisito incorporara reglas de negocio o
validación de datos complejas, el uso de una tabla
de decisiones o un árbol de decisiones podrían
ser útiles para definir reglas complejas de negocio,
mientras que las reglas de validación de datos
podrían definirse en un repositorio. Si se utilizara una
técnica suplementaria para especificar o modelar el
requisito, debería haber una referencia cruzada con el
documento asociado.
■■ Proceso de negocio – una simple frase para agrupar
juntos los requisitos que den soporte a una actividad
específica, como ventas, inventario, servicio al cliente,
etc.
■■ Justificación – no todos los requisitos que se solicitan
se cumplirán. Esto podría deberse a restricciones
de tiempo y presupuesto, o podría deberse a que
el requisito se eliminó en favor de un requisito que
entraba en conflicto con el eliminado. En muchas
ocasiones el requisito no se cumple porque añade
poco valor al negocio. La justificación establece las
razones de la solicitud del requisito.
■■ Requisitos asociados – los requisitos podrían asociarse
unos con otros por múltiples razones. A veces existe
un vínculo entre la funcionalidad requerida por
diferentes requisitos, o un requisito de alto nivel
se aclara mediante una serie de requisitos más
detallados.
■■ Histórico de cambios – las entradas en esta sección
proporcionan un registro de todos los cambios
detallados que han afectado al requisito. Esto se
190 | Actividades asociadas con la tecnología de Diseñ̃o del Servicio
requiere para propósitos de trazabilidad y gestión de
la configuración.
5.1.5.2  Documentación de todos los requisitos
Un documento de requisitos eficaz debe incluir los
siguientes elementos:
■■ Un glosario de términos para definir cada término
organizativo utilizado dentro del documento de
requisitos. Esto ayudará a gestionar el problema de las
jergas locales y aclarará sinónimos y homónimos para
cualquiera que utilice el documento
■■ Un modelo del ámbito, como por ejemplo un
diagrama de contexto del sistema
■■ El Catálogo de Requisitos, idealmente integrado dentro
de un Porfolio de Servicios general
■■ Modelos de soporte, como por ejemplo modelos de
proceso de negocio, diagramas de flujo de datos o
diagramas de interacción.
Gestión de cambios en la documentación
Los cambios podrían producirse por:
■■ El ámbito del nuevo servicio se ha modificado debido
a restricciones del presupuesto
■■ El servicio debe cumplir una nueva regulación o
legislación
■■ Se han anunciado cambios en las prioridades del
negocio
■■ Los interesados han entendido mejor un requisito
después de algún análisis detallado, por ejemplo
utilizando escenarios y prototipos y modificaron el
requisito original convenientemente.
Existen varias herramientas de soporte especializadas
en el mercado para dar soporte a los procesos de
requisitos. Algunas veces se denominan CARE (Ingeniería
de Requisitos Asistida por Ordenador) o CASE (Ingeniería
de Software Asistida por Ordenador). Las funcionalidades
incluyen:
■■ Mantenimiento de referencias cruzadas entre requisitos
■■ Almacenamiento de documentación de los requisitos
■■ Gestión de cambios en la documentación de los
requisitos
■■ Gestión de versiones de la documentación de los
requisitos
■■ Elaboración de documentos formateados de
especificaciones de requisitos a partir de la base de
datos
■■ Garantía de que los documentos entregados por
cualquier proyecto de solución sean adecuados para
permitir el soporte.
5.1.6 Requisitos y externalización
El objetivo es seleccionar soluciones disponibles en
el mercado estándar siempre que sea posible para
cumplir los requisitos del servicio. Sin embargo,
independientemente de si los requisitos de TI tuvieran que
comprarse en soluciones disponibles en el mercado o se
tuvieran que desarrollar internamente o externamente,
todas las actividades hasta la producción de una
especificación de los requisitos de negocio debieran
realizarse internamente. Muchos contratos de desarrollo
del servicio de TI asumen que es posible conocer
cuáles son los requisitos al comienzo y que es posible
generar una especificación que exprese los requisitos sin
ambigüedades. No suele ser así en todos los servicios,
excepto en el caso de los más simples. El análisis de
requisitos es un proceso iterativo. Los requisitos cambiarán
durante el periodo en el que la aplicación y el servicio
se estén desarrollando. Esto requerirá la implicación del
usuario en el proceso de desarrollo, como en DSDM y en
otros métodos ‘ágiles’.
5.1.6.1  Escenarios típicos de externalización de
requisitos
Los métodos típicos para contratar el desarrollo de
sistemas de TI que se entregarán para el soporte de un
servicio de TI son los siguientes:
■■ Especificación de los requisitos de bajo nivel – el
límite entre ‘cliente’ y proveedor se encuentra entre la
especificación detallada de los requisitos y cualquier
actividad de diseño. Todos los requisitos que tienen un
impacto en el usuario debieran haberse especificado
con detalle, proporcionando al proveedor un objetivo
de implementación preciso y muy claro. Sin embargo,
el esfuerzo para realizar las especificaciones aumenta,
y el valor añadido del proveedor se limita a los
aspectos menos complejos del desarrollo.
■■ Especificación de los requisitos de alto nivel – el
límite cliente/proveedor se encuentra entre los
requisitos de alto nivel y todas las demás fases. El
contrato del proveedor cubre todo lo que hay debajo
de esa línea. El cliente es responsable de probar el
servicio entregado con respecto a los requisitos de
negocio. Puesto que es más fácil especificar requisitos
de alto nivel, se reduce el esfuerzo para desarrollar
entradas del contrato. Sin embargo, podrían generarse
problemas importantes debido al incremento de los
costes y del riesgo para el cliente y el proveedor,
junto con el aumento de errores, inestabilidad de
los requisitos y aumento de la dificultad a la hora de
conocer qué sistemas de información se desean.
 Actividades asociadas con la tecnología de Diseñ̃o del Servicio | 191
5.2  Gestión de la Información y de
los Datos
Los datos representan uno de los tipos de activos críticos
que es necesario gestionar para desarrollar, entregar y dar
soporte eficazmente a los servicios de TI. La Gestión de
la Información/Datos se refiere a cómo una organización
planifica, recopila, crea, organiza, utiliza, controla, divulga
y se deshace de sus datos/información, tanto registros
estructurados como datos sin estructurar. También
garantiza que el valor de esos datos/información se
identifique y explote, dando soporte a sus operaciones
internas y añadiendo valor a sus procesos de negocio
orientados al cliente.
En este área son comunes varios términos, incluyendo
‘Gestión de Datos’, ‘Gestión de la Información’ y ‘Gestión
de Recursos de la Información’. Para los propósitos de esta
publicación, el término ‘Gestión de Datos’ se utiliza como
representativo de los tres indicados anteriormente.
El rol de la Gestión de Datos descrito no se asocia
únicamente con la gestión de los datos sin procesar,
se asocia con la gestión de todos los metadatos
contextuales, ‘datos adicionales sobre los datos’, y que
cuando se añaden a los datos sin procesar proporcionan
‘información’ o ‘datos en contexto’.
Los datos, entendidos como base de la información de la
organización, tienen todos los atributos necesarios para
tratarlos como un activo (o recurso). Por ejemplo, son
fundamentales para ‘el logro de los objetivos de negocio
y para el éxito del trabajo diario de una organización’.
Además, ‘una organización los puede obtener y conservar,
aunque con un coste financiero’. Finalmente, se pueden
utilizar, junto con otros recursos/activos, para ‘lograr
posteriormente los objetivos de una organización’.
Los factores clave para lograr el éxito en la Gestión de
Datos son los siguientes:
■■ Todos los usuarios tienen acceso a través de diferentes
canales a la información que necesitan para realizar
sus tareas.
■■ Los activos de los datos se explotan en su totalidad, a
través de datos compartidos dentro de la organización
y con otras entidades.
■■ La calidad de los datos de la organización se mantiene
a un nivel aceptable, y la información utilizada en el
negocio es precisa, fiable y consistente.
■■ Se cumplen los requisitos legales para mantener la
privacidad, seguridad, confidencialidad e integridad de
los datos.
■■ La organización logra un alto nivel de eficiencia y
eficacia en sus actividades de tratamiento de datos e
información.
■■ Se dispone de un modelo de datos empresariales para
definir las entidades más importantes y sus relaciones.
Esto ayuda a evitar redundancias y a evitar que la
arquitectura quede desfasada, ya que ésta varía con el
paso de los años.
5.2.1 Gestión de los activos de los datos
Si los datos no se gestionaran eficazmente:
■■ Las personas mantendrían y recopilarían datos que no
necesitan
■■ La organización podría tener información histórica que
ya no se utilizará
■■ La organización podría mantener muchos datos que
son inaccesibles para los usuarios potenciales
■■ La información podría divulgarse a más personas de
las que se debería, o no llegar a aquellas personas a
las que se debería divulgar realmente la información
■■ La organización podría utilizar métodos ineficientes o
desactualizados para recopilar, analizar, almacenar y
recuperar los datos
■■ La organización podría fallar a la hora de recopilar los
datos que son necesarios, reduciendo la calidad de los
datos y su integridad, por ejemplo, entre fuentes de
datos relacionadas.
Por otra parte, si la información se deriva o no de datos de
buena calidad es una pregunta difícil de responder ya que
no se han aplicado mediciones con las que compararlos.
Por ejemplo, en muchas ocasiones una calidad deficiente
de los datos surge de comprobaciones en la entrada o de
procedimientos de actualización deficientes. Una vez que
se hayan almacenado datos imprecisos o incompletos en
el sistema de TI, cualquier informe generado utilizando
estos datos reflejará estas imprecisiones o gaps. Podría
haber una falta de consistencia entre la información
de gestión generada internamente procedente de los
sistemas operativos y aquella procedente de otros sistemas
internos utilizados localmente, provocada debido a que
los datos centrales no se han verificado.
Una forma de mejorar la calidad de los datos es utilizar
un proceso de Gestión de Datos que establezca la política
y estándares, proporcione experiencia y facilite el manejo
de los aspectos de los datos de los nuevos servicios.
Esto debe permitir la Gestión Total de los Activos de
Información/Datos para:
■■ Añadir valor a los servicios entregados a los clientes
■■ Reducir riesgos en el negocio
192 | Actividades asociadas con la tecnología de Diseñ̃o del Servicio
■■ Reducir los costes de los procesos de negocio
■■ Estimular la innovación en procesos internos de
negocio.
5.2.2  Ámbito de la Gestión de Datos
Existen cuatro áreas de gestión que se incluyen dentro del
alcance de Gestión de Información/Datos:
■■ Gestión de recursos de datos: el gobierno de
la información en la organización debe garantizar
que todos estos recursos se conozcan y que se
hayan asignado las responsabilidades de su gestión,
incluyendo la propiedad de los datos y metadatos. A
este proceso normalmente se le hace referencia como
administración de datos e incluye la responsabilidad
de:
■■ Definir las necesidades de información
●● Construir un inventario de datos y un modelo de
datos empresariales
●● Identificar la duplicación y deficiencias de los datos
●● Mantener un catálogo/índice del contenido de
información/datos
●● Medir el coste y valor de los datos de la
organización.
■■ Gestión de la tecnología de información/datos:
la gestión de las Tecnologías de la Información que
dan soporte a los sistemas de información de la
organización; esto incluye procesos como diseño
y administración de bases de datos. Este aspecto
normalmente está gestionado por especialistas dentro
de la función de TI. Vea la publicación Operación del
Servicio para más detalles.
■■ Gestión de los procesos de información: los
procesos de negocio conducirán a que los servicios
de TI requieran recursos de datos de la organización.
Los procesos de creación, recopilación, acceso,
modificación, almacenamiento, eliminación y archivo
de datos, es decir, el ciclo de vida de los datos, deben
controlarse adecuadamente, en muchas ocasiones
junto con el proceso de gestión de aplicaciones.
■■ Gestión de políticas y estándares de datos: será
necesario que la organización defina estándares y
políticas para su Gestión de Datos como un elemento
de la estrategia de TI. Las políticas gobernarán
los procedimientos y responsabilidades para la
Gestión de Datos en la organización; y las políticas,
arquitecturas y estándares técnicos que se aplicarán a
la infraestructura de TI que da soporte a los sistemas
de información de la organización.
El ámbito de las mejores prácticas del proceso Gestión
de Datos incluye la gestión de datos no estructurados
que no se encuentran en sistemas de bases de datos
convencionales, por ejemplo, utilizando formatos como
texto, imágenes y audio. También es responsable de
asegurar la calidad del proceso en todas las etapas del
ciclo de vida de los datos, desde los requisitos hasta la
retirada del servicio. El enfoque central de esta publicación
estará en su rol en las fases de requisitos, diseño y
desarrollo de los activos y en el Ciclo de Vida del Servicio.
El equipo que da soporte al proceso de Gestión de Datos
también podría proporcionar un servicio de soporte de
la información del negocio. En este caso serán capaces
de responder a la organización cuestiones sobre el
significado, formato y disponibilidad de los datos internos
ya que gestionan los metadatos. También son capaces de
entender y explicar qué datos externos podrían necesitarse
para llevar a cabo los procesos de negocio y adoptarán las
acciones necesarias para proporcionarlos.
Además, al crear o rediseñar procesos y dar soporte a los
servicios de TI, es buena práctica considerar la reutilización
de datos y metadatos a través de diferentes áreas de la
organización. La capacidad de hacer esto podría estar
apoyada por un modelo de datos corporativos, algunas
veces conocido como un modelo de información común,
para ayudar a dar soporte a la reutilización, con frecuencia
un objetivo importante para la gestión de datos.
5.2.3 Gestión de Datos y el Ciclo de Vida
del Servicio
Se recomienda adoptar un método de ciclo de vida para
entender el uso de los datos en los procesos de negocio.
Los aspectos generales incluyen:
■■ ¿Qué datos se están manteniendo actualmente y
cómo se clasificarán?
■■ ¿Qué datos será necesario recopilar y crear mediante
los procesos de negocio?
■■ ¿Cómo se almacenarán y mantendrán los datos?
■■ ¿Cómo se accederá a los datos, quién y de qué
forma?
■■ ¿Cómo se desecharán los datos y bajo qué autoridad?
■■ ¿Cómo se mantendrá la calidad de los datos
(precisión, consistencia, moneda, etc.)?
■■ ¿Cómo se logrará la accesibilidad/disponibilidad de los
datos?
5.2.4 Soporte del Ciclo de Vida del Servicio
Durante los requisitos y diseño inicial, Gestión de Datos
puede ayudar a los equipos de diseño y desarrollo en el
modelado de datos específicos del servicio y proporcionar
asesoramiento sobre el uso de varias técnicas para
modelar datos.
 Actividades asociadas con la tecnología de Diseñ̃o del Servicio | 193
Durante el diseño y desarrollo detallados (‘físico’), la
función Gestión de Datos puede proporcionar experiencia
técnica sobre sistemas de gestión de bases de datos y
sobre cómo convertir modelos ‘lógicos’ iniciales de datos
en implementaciones físicas específicas del producto.
Muchos servicios nuevos han fracasado porque no se ha
abordado la calidad deficiente de los datos durante el
desarrollo del servicio, o porque un desarrollo particular
creó sus propios datos y metadatos, sin consultarlo con
otros propietarios del servicio, o con Gestión de Datos.
5.2.5  Valoración de los datos
Los datos son un activo y tienen valor. En algunas
organizaciones este valor es más obvio que en otras.
En organizaciones que son proveedores de datos para
otras organizaciones, como por ejemplo Yell, Dun and
Bradstreet y Reuters, se pueden evaluar los datos como
una ‘salida’ en términos del precio que están cargando
a organizaciones externas para recibirlos. También es
posible pensar en el valor en términos de lo que los datos
internos podrían representar para otra organización.
Es más habitual valorar los datos en términos de lo que
es valioso para la organización propietaria. Existen varias
formas para hacer esto:
■■ Valoración de los datos por disponibilidad: un
método que se utiliza en muchas ocasiones es
considerar qué procesos de negocio serían posibles
si una parte particular de los datos no estuvieran
disponibles y cuánto le costaría al negocio esa falta de
disponibilidad de los datos.
■■ Valoración de los datos perdidos: otro método que
se utiliza frecuentemente es pensar sobre los costes de
obtención de algunos datos si éstos se destruyeran.
■■ Valoración de los datos considerando el ciclo de
vida de los datos: esto implica pensar en primer
lugar sobre cómo se crean u obtienen los datos,
cómo se ponen a disposición de las personas, y
cómo se retiran, mediante su archivo o destrucción
física. También podría ocurrir que algunos datos
se suministraran a partir de fuentes externas y a
continuación se almacenaran internamente, o que los
datos tuvieran que crearse mediante sistemas internos
de la organización. En estos dos casos, el ciclo de vida
es diferente y los procesos que tienen lugar para la
captura de datos estarán completamente separados.
En ambos casos se pueden evaluar los costes de
rehacer estas etapas. Mientras más valor tengan los
datos, mayor esfuerzo será necesario para garantizar
su integridad, disponibilidad y confidencialidad.
5.2.6  Clasificación de datos
Los datos se pueden clasificar inicialmente como
operativos, tácticos o estratégicos:
■■ Datos operativos: necesarios para el funcionamiento
continuo de una organización y se puede considerar
como el nivel inferior más específico.
■■ Datos tácticos: normalmente necesarios para la
gestión de segunda línea, o superior, y habitualmente
se asocian con datos sintetizados o datos históricos,
normalmente datos anuales o datos trimestrales.
Habitualmente, los datos que se utilizan aquí
aparecen en sistemas de información de gestión que
requieren datos sintetizados a partir de varios sistemas
operativos para abordar un requisito de contabilidad,
por ejemplo.
■■ Datos estratégicos: normalmente se asocian con
tendencias a largo plazo y con la comparación con
el mundo exterior, por lo que proporcionar los datos
necesarios para un sistema de soporte estratégico
implica proporcionar juntos datos operativos y tácticos
derivados de muchas áreas diferentes con datos
externos relevantes. Se requieren muchos más datos
de fuentes externas.
Un método alternativo consiste en utilizar una clasificación
de seguridad de datos y documentos. Esto normalmente
se adopta como una política corporativa dentro de una
organización.
Una clasificación ortogonal distingue entre datos de
toda la organización, datos de áreas funcionales y datos
específicos del servicio.
■■ Es necesario gestionar centralizadamente los datos de
toda la organización.
■■ El siguiente nivel de datos son datos de áreas
funcionales que deben compartirse a través de
toda la función del negocio. Esto implica compartir
‘instancias’ de datos, por ejemplo, registros de
clientes individuales, y también asegurar que se estén
utilizando metadatos consistentes a través de tal área
funcional, como por ejemplo, formatos estándar de
dirección.
■■ El nivel final es el específico del servicio de TI, donde
los datos y metadatos son válidos para un servicio de
TI y no es necesario compartirlos con otros servicios.
5.2.7 Establecimiento de estándares de
datos
Uno de los aspectos críticos de la administración de
datos es garantizar que se apliquen estándares para los
metadatos, por ejemplo, qué metadados se conservarán
194 | Actividades asociadas con la tecnología de Diseñ̃o del Servicio
para los diferentes ‘tipos de datos’ subyacentes. En función
del área se conservan detalles diferentes sobre datos
tabulares estructurados. La ‘Propiedad’ es un elemento
crítico de estos metadatos, y otros podrían ser alguna
clasificación de identificador único, una descripción en
términos de importancia para el negocio y un formato.
También se registra el propietario o custodio, alguien en
el departamento de TI que asume la responsabilidad de la
gestión diaria de los datos.
Otro beneficio de un proceso de Gestión de Datos
estaría en el campo de los datos de referencia. Ciertos
tipos de datos, como códigos postales y nombres de
países, podrían ser necesarios para una gran variedad de
sistemas, y es necesario que sean consistentes. Parte de la
responsabilidad de administración de datos es gestionar
datos de referencia en nombre de todo el negocio, y
asegurarse que todos los sistemas de la organización
utilicen los mismos datos de referencia o maestros de la
organización.
Deben aplicarse estándares de nomenclatura; por lo tanto,
si se requiriera un nuevo tipo de datos en un nuevo
servicio, entonces será necesario utilizar nombres que
cumplan estos estándares. Un ejemplo de estándar podría
ser ‘todo en mayúsculas, sin subrayado y sin abreviaturas’.
5.2.8  Propiedad de los datos
La administración de datos puede ayudar al
desarrollador del servicio a estar seguro de que el
negocio y el departamento de TI asumen seriamente las
responsabilidades de la propiedad de los datos. Una de
las formas más satisfactorias de hacer esto es hacer que
el negocio y el departamento de TI firmen un cuadro de
datos, es decir, un conjunto de estándares y guías de
procedimientos para lograr una meticulosa gestión de los
datos en la organización incorporándose a los estándares
definidos a nivel corporativo. Las responsabilidades más
habituales del propietario de los datos se definen aquí y
podrían incluir:
■■ Acordar una descripción del negocio y un propósito
para los datos
■■ Definir quién puede crear, modificar, leer y eliminar
ocurrencias de los datos
■■ Autorizar cambios en la forma en la que se capturan o
derivan los datos
■■ Aprobar cualquier formato, dominio y rango de valores
■■ Aprobar el nivel adecuado de seguridad, asegurándose
de la adhesión a requisitos legales y políticas internas
sobre la seguridad de los datos.
5.2.9  Migración de los datos
La migración de los datos es un aspecto donde un nuevo
servicio está sustituyendo a varios (posiblemente sólo a
uno) de los servicios existentes y es necesario incorporar
al nuevo servicio datos de buena calidad procedentes
de sistemas y servicios existentes. Existen dos tipos de
migración de datos de interés para los proyectos: uno
consiste en la migración de datos en data warehouses,
etc., para propósitos de análisis/inteligencia del negocio;
el otro tipo consiste en la migración de datos a un nuevo
servicio operativo y transaccional. En ambos casos será
beneficioso si los estándares, procedimientos y procesos
de migración de datos estuvieran determinados por la
Gestión de Datos. Puede que el equipo de Gestión de
Datos ya hubiera comprado herramientas de migración
de datos en nombre de la organización. Sin este soporte,
es muy fácil subestimar la cantidad de esfuerzo requerido,
particularmente si tuviera que aplicarse la consolidación
y limpieza de los datos entre múltiples sistemas fuente y
si se conoce que la calidad de los datos de los servicios
existentes no es buena.
5.2.10 Almacenamiento de datos
Un área donde la tecnología ha evolucionado muy
rápidamente es el área de almacenamiento de
datos. Es necesario considerar diferentes medios de
almacenamiento, por ejemplo almacenamiento óptico
y ser conscientes del tamaño y de las implicaciones de
coste asociados con ello. La razón principal para entender
los desarrollos en este área es que hacen posible muchos
tipos de áreas de gestión de datos que se consideraron
demasiado caras anteriormente. Por ejemplo, el
almacenamiento de vídeo en tiempo real que utiliza un
ancho de banda enorme, se ha considerado hasta hace
dos o tres años, algo demasiado caro. Lo mismo se puede
aplicar al escaneo de grandes números de documentos en
papel, particularmente si esos documentos no se basaran
en texto y sí en imágenes o en diagramas detallados.
El entendimiento de los desarrollos tecnológicos en
relación con el almacenamiento electrónico de datos es
crítico para entender las oportunidades con las que se
encuentra el negocio para explotar eficazmente las fuentes
de información haciendo el mejor uso de las nuevas
tecnologías.
5.2.11  Captura de datos
También es muy importante trabajar con Gestión de
Datos sobre medidas eficaces para la captura de datos.
El objetivo aquí es capturar datos de una forma precisa
y rápida. Es necesario garantizar que los procesos de
captura de datos requieran la mínima cantidad posible
 Actividades asociadas con la tecnología de Diseñ̃o del Servicio | 195
de tecleado y explicar las ventajas que proporcionan las
interfaces gráficas de usuario en términos de minimización
del número de registros tecleados necesarios, reduciendo
también la posibilidad de generar errores durante la
captura de datos. Es razonable esperar que el proceso
de Gestión de Datos disponga de estándares y pueda
proporcionar experiencia sobre métodos eficaces de
captura de datos en varios entornos, incluyendo la captura
de datos ‘no estructurados’ utilizando mecanismos como
el escaneo.
5.2.12 Recuperación y uso de datos
Una vez se hayan capturado y almacenado los datos,
el siguiente aspecto a considerar es la recuperación de
información a partir de los datos. Todas las organizaciones
necesitan servicios para facilitar el acceso a datos
estructurados a través de herramientas de consulta de
varios niveles de complejidad, y para generar sus propias
demandas de arquitecturas específicas.
Toda el área de búsqueda dentro del texto escaneado y
de otros datos no estructurados como vídeo, imágenes
y sonido, es un área importante de expansión. Técnicas
como indexación automática, y el uso de motores
de búsqueda para proporcionar un acceso eficiente a
través de palabras clave para las partes relevantes de
un documento, son tecnologías esenciales que se han
implementado ampliamente, particularmente en Internet.
Gestión de Datos y Gestión del Contenido deben tener
experiencia en el uso de datos o del contenido dentro
de sitios web, es decir, deben haber estándares y
procedimientos que sean vitales para los sitios web.
5.2.13  Integridad de los datos y aspectos
asociados
Al definir los requisitos para los servicios de TI, es muy
importante que se consideren los requisitos operativos y
de gestión asociados con los datos. En particular, deben
abordarse las siguientes áreas:
■■ Recuperación de datos perdidos o corruptos
■■ Acceso controlado a los datos
■■ Implementación de políticas sobre el archivo de
datos, incluyendo la conformidad con los periodos
regulatorios de retención
■■ Comprobaciones periódicas de la integridad de los
datos.
La integridad de los datos se asocia con el aseguramiento
de que los datos sean de alta calidad y no estén corruptos.
También evita la duplicación incontrolada de datos y
por lo tanto evita cualquier confusión sobre cuál es la
versión válida de los datos. Existen varios métodos que
podrían utilizarse para esto. Para evitar datos múltiples,
inconsistentes y actualizaciones ilegales de datos se
utilizan varios dispositivos tecnológicos, como por ejemplo
el ‘bloqueo de bases de datos’. Además, la prevención
de actualizaciones ilegales podría lograrse mediante
mecanismos de control de accesos.
5.3  Gestión de Aplicaciones
Una aplicación se define aquí como los programas de
software que realizan aquellas funciones específicas que
dan soporte directamente a la ejecución de procesos
y/o procedimientos de negocio.
Las aplicaciones, junto con los datos y componentes de
la infraestructura como el hardware, el sistema operativo
y el middleware, forman parte de los componentes
tecnológicos de un servicio de TI. La propia aplicación
es sólo un componente, a pesar de ser un componente
importante del servicio. Por lo tanto, es importante que
la aplicación entregada se corresponda con los requisitos
acordados con el negocio. Sin embargo, demasiadas
organizaciones dedican demasiado tiempo en centrarse en
los requisitos funcionales del nuevo servicio y aplicación
y no dedican suficiente tiempo al diseño de los requisitos
operativos y de gestión (requisitos no funcionales) del
servicio. Esto significa que cuando el servicio pasa a estar
operativo, cumple todos los requisitos funcionales y sin
embargo falla en su totalidad a la hora de cumplir las
expectativas del negocio y de los clientes en términos de
calidad y rendimiento y por lo tanto no se puede usar.
Son necesarios dos métodos alternativos para implementar
completamente Gestión de Aplicaciones. Un método
emplea un Ciclo de Vida de Desarrollo del Servicio (SDLC)
extendido para dar soporte al desarrollo de un servicio de
TI. SDLC es un método sistemático para la resolución de
problemas y se compone de los siguientes pasos:
■■ Estudio de viabilidad
■■ Análisis
■■ Diseño
■■ Prueba
■■ Implementación
■■ Evaluación
■■ Mantenimiento.
El otro método obtiene una visión global de todos los
servicios para asegurar la capacidad de mantenimiento
continuo y la capacidad de gestión de las aplicaciones:
■■ Todas las aplicaciones se describen de forma
consistente a través de un Porfolio de Aplicaciones
que se gestiona y mantiene para permitir el
alineamiento con necesidades dinámicas del negocio.
196 | Actividades asociadas con la tecnología de Diseñ̃o del Servicio
■■ La consistencia del método a desarrollar se fuerza a
través de un número limitado de marcos de trabajo
de la aplicación, con patrones de diseño y a través de
una filosofía de ‘reutilización’.
■■ Los componentes de software comunes,
habitualmente para cumplir requisitos operativos y de
gestión, se crean o adquieren a nivel ‘organizativo’ y
los utilizan sistemas individuales cuando se diseñan y
construyen.
5.3.1 El Porfolio de Aplicaciones
Consiste simplemente en un registro completo de todas
las aplicaciones dentro de la organización y su contenido
es dinámico.
5.3.2  Vínculo entre la Aplicación y el
Porfolio de Servicios
Algunas organizaciones mantienen un Porfolio de
Aplicaciones independiente con atributos independientes,
mientras que en otras organizaciones el Porfolio de
Aplicaciones se almacena dentro del CMS junto con
las relaciones correspondientes. Otras organizaciones
combinan el Porfolio de Aplicaciones con el Porfolio de
Servicios. Cada organización deberá decidir la estrategia
más apropiada en función de sus propias necesidades. Lo
que está claro es que debe haber relaciones y vínculos
muy estrechos entre las aplicaciones, los servicios a los
que dan soporte y los componentes de la infraestructura
utilizados.
5.3.3  Marco de Aplicaciones
El concepto de un marco de aplicaciones es muy
poderoso. El marco de aplicaciones cubre todos los
aspectos operativos y de gestión, realmente proporciona
soluciones para todos los requisitos operativos y de
gestión que rodean a una aplicación.
Tabla 5.5 Ejemplo de atributos del Porfolio de aplicaciones
Nombre de la aplicación Propietario de las operaciones de TI
Identificador de la aplicación Propietario del desarrollo de TI
Descripción de la aplicación Contactos de soporte
Proceso de negocio soportado Tecnologías de bases de datos
Servicios de TI soportados Aplicaciones dependientes
Patrocinador ejecutivo Sistemas de TI soportados
Geografías soportadas Interfaces de usuario
Criticidad del negocio Arquitectura de TI incluyendo topología de red
Vínculo con SLA Tecnologías de aplicaciones utilizadas
Propietario del negocio Número de usuarios
El concepto de estandarización se encuentra implícito en
los marcos de aplicaciones. Si una organización utilizara
y tuviera que mantener un marco de aplicaciones para
cada aplicación independiente, no se lograrán demasiados
beneficios del uso de un marco de aplicaciones.
Una organización que desea desarrollar y mantener
marcos de aplicaciones y que desea garantizar que los
marcos de aplicaciones satisfacen las necesidades de
los desarrolladores de aplicaciones, debe invertir en
ello. Es fundamental que las arquitecturas del marco de
aplicaciones no se desarrollen de forma aislada, sino que
deben estar estrechamente relacionadas e integradas
con todos los demás marcos de trabajo y actividades de
creación de arquitecturas. El Servicio, la Infraestructura, el
Entorno y las Arquitecturas de datos deben estar todos
integrados estrechamente con la Arquitectura y el Marco
de Aplicaciones.
Arquitectura, marcos de aplicaciones y
estándares
Las actividades relacionadas con la arquitectura tienen
que planificarse y gestionarse por separado a partir de
proyectos de software basados en sistemas individuales.
También es importante que las actividades relacionadas
con la arquitectura se realicen para el beneficio de más
de una aplicación. Los desarrolladores de aplicaciones
deben centrarse en una única aplicación, mientras que los
desarrolladores del marco de aplicaciones deben centrarse
en más de una aplicación y en las funcionalidades
comunes de esas aplicaciones en particular.
Una práctica común es distinguir entre varios tipos de
aplicaciones. Por ejemplo, no todas las aplicaciones
se pueden construir en una plataforma con el sistema
operativo Microsoft ® Windows, conectada a un servidor
UNIX, utilizando HTML, applets de Java, JavaBeans y
una base de datos relacional. Los diferentes tipos de
aplicaciones se pueden considerar como familias de
Coste del nuevo desarrollo
Costes operativos anuales
Costes de soporte anuales
Costes de mantenimiento anuales
Componentes externalizados
Socios de externalización
Métricas de producción
Vínculo con OLA
Métricas de soporte
 Actividades asociadas con la tecnología de Diseñ̃o del Servicio | 197
aplicaciones. Todas las aplicaciones de la misma familia se
basan en el mismo marco de aplicaciones.
Utilizando el concepto de un marco de aplicaciones,
el primer paso de la fase de diseño de la aplicación es
identificar el marco de aplicaciones apropiado. Si el marco
de aplicaciones estuviera maduro, se proporcionan un
gran número de decisiones de diseño. Si no estuviera
maduro y no se pudieran cumplir todos los requisitos
operativos y de gestión en un marco de aplicaciones
existente, la estrategia preferida debiera consistir en
recopilar y analizar los requisitos que no se puedan
abordar con la versión actual del marco de aplicaciones.
Basándose en los requisitos de las aplicaciones, se pueden
definir nuevos requisitos para el marco de aplicaciones. A
continuación, el marco de aplicaciones se puede modificar
para que pueda hacer frente a los requisitos de las
aplicaciones. De hecho, toda la familia de aplicaciones que
corresponde con el marco de aplicaciones puede utilizar
las funcionalidades modificadas o añadidas recientemente
del marco.
El desarrollo y mantenimiento de un marco de
aplicaciones es una tarea exigente y como otras
actividades de diseño, deben realizarla personas
competentes y experimentadas. Alternativamente, los
marcos de aplicaciones se pueden adquirir de terceros.
5.3.4  La necesidad de herramientas CASE y
repositorios
Un aspecto importante de ese alineamiento general
es la necesidad de alinear las aplicaciones con sus
estructuras de soporte subyacentes. Los entornos de
desarrollo de aplicaciones tradicionales tienen sus propias
herramientas de Ingeniería de Software Asistidas por
Ordenador (CASE) que ofrecen los medios para especificar
requisitos, elaborar diagramas de diseño (de acuerdo
con estándares particulares de modelado), o incluso
para generar aplicaciones completas, o esqueletos casi
completos de aplicaciones, ya casi preparados para ser
desplegados. Estos entornos también proporcionan
una ubicación centralizada para almacenar y gestionar
todos los elementos que se creen durante el desarrollo
de aplicaciones, generalmente llamada repositorio.
La funcionalidad del repositorio incluye control de
versiones y comprobación de la consistencia a través
de varios modelos. El método actual consiste en utilizar
herramientas metaCASE para modelar leguajes específicos
del dominio y para usarlos para hacer que el trabajo con
CASE esté más alineado con las necesidades del negocio.
5.3.5 Diseño de aplicaciones específicas
La fase de requisitos del ciclo de vida se abordó
anteriormente en la sección de ingeniería de requisitos.
La fase de diseño es una de las fases más importantes
dentro del ciclo de vida de la aplicación. Esto asegura
que una aplicación se conciba teniendo en cuenta la
capacidad de operación y la Gestión de Aplicaciones. Esta
fase toma las salidas de la fase de requisitos y las convierte
en la especificación que se utilizará para desarrollar la
aplicación.
El objetivo de los diseños debe ser satisfacer los requisitos
de la organización. Diseñar incluye el diseño de la propia
aplicación, el diseño de la infraestructura y del entorno
en el que opera la aplicación. Las consideraciones
estructurales son los aspectos más importantes de esta
fase, ya que pueden impactar en la estructura y en el
contenido del modelo de aplicación y operativo. Las
consideraciones estructurales para la aplicación (diseño
de la Arquitectura de la Aplicación) y las consideraciones
estructurales para el entorno (diseño de la Arquitectura de
TI), están íntimamente asociadas y es necesario alinearlas.
La Arquitectura de la Aplicación y el diseño no deben
considerarse de forma aislada sino que deben formar un
componente integrado general de arquitectura y diseño
del servicio.
Generalmente, en la fase de diseño, los mismos modelos
se producirán como se han entregado en la fase de
requisitos, pero durante el diseño podrían añadirse
muchos más detalles. Los nuevos modelos incluyen
modelos de arquitectura, donde es necesario definir la
forma en la que se hacen corresponder los diferentes
componentes funcionales con los componentes físicos
(por ejemplo, ordenadores de escritorio, servidores, bases
de datos y red). Esa correspondencia, junto con la carga
estimada del sistema, deben permitir el dimensionamiento
de la infraestructura requerida.
Otro aspecto importante del modelo de arquitectura es la
integración de la aplicación en el entorno existente. ¿Qué
partes de la infraestructura existente se utilizarán para
dar soporte a las nuevas funcionalidades requeridas? ¿Se
pueden utilizar servidores o redes existentes? ¿Con qué
impacto? ¿Las funciones requeridas están disponibles en
aplicaciones existentes que se puedan utilizar? ¿Existen
paquetes que ofrecen la funcionalidad necesaria o deben
construirse funciones partiendo de cero?
La fase de diseño tiene en cuenta todos los requisitos
y comienza a integrarlos en un diseño inicial para la
solución. Hacer esto no sólo ofrece a los desarrolladores
una base para empezar a trabajar: también es probable
que surjan cuestiones que es necesario responder en
198 | Actividades asociadas con la tecnología de Diseñ̃o del Servicio
relación con los clientes/usuarios. Si fuera posible, deben
aplicarse marcos de aplicaciones como punto de inicio.
No siempre es posible considerar con anticipación todos
los aspectos del diseño de una solución. Cuando se
desarrolla una solución, se aprenderán nuevas aspectos
sobre cómo hacer las cosas y cómo no hacerlas.
La clave es crear un diseño flexible para que un cambio no
haga que los desarrolladores vuelvan al principio de la fase
de diseño. Existen varios métodos que pueden minimizar
la posibilidad de que esto se produzca, e incluyen:
■■ Diseñar para los requisitos operativos y de gestión
■■ Gestionar las concesiones (trade-offs)
■■ Utilizar directrices de diseño independientes de la
aplicación; utilizar marcos de aplicaciones
■■ Emplear un proceso de diseño estructurado/lista de
comprobación de la capacidad de gestión.
El diseño para los requisitos operativos y de
mantenimiento implica llevar a los requisitos operativos
y de gestión a un nivel de importancia similar de los
requisitos funcionales, e incluirlos como una parte
obligatoria de la fase de diseño. Esto incluye un número
de requisitos operativos y de gestión como disponibilidad,
capacidad, capacidad de mantenimiento, fiabilidad y
seguridad. Ahora es inconcebible que en los proyectos
modernos de desarrollo de aplicaciones se omita el diseño
de la interfaz de usuario (requisitos de usabilidad) como
una actividad de diseño clave. Sin embargo, muchas
organizaciones ignoran y se olvidan de la capacidad de
gestión. Los detalles de los requisitos operativos y de
gestión necesarios se incluyen dentro del SDP y SAC en los
Apéndices A y B.
5.3.6 Gestión de las concesiones
La gestión de decisiones sobre concesiones (trade-offs) se
centra en el equilibrio de la relación entre recursos, en la
programación del proyecto y en aquellas funcionalidades
que es necesario incluir en la aplicación para obtener la
calidad debida.
Cuando los equipos de desarrollo intentan completar este
equilibrio, esto se hace en muchas ocasiones a expensas
de los requisitos operativos y de gestión. Una forma de
evitarlo es incluir requisitos operativos y de gestión en
las directrices de diseño independientes de la aplicación,
por ejemplo, en la forma de un marco de aplicaciones.
La capacidad de operación y de gestión se convierten
eficazmente en componentes estándar de todos los
procesos de diseño, por ejemplo, en forma de un marco
de aplicaciones, y se integran en las prácticas de trabajo y
en la cultura de la organización de desarrollo.
5.3.7 Salidas típicas del diseño
A continuación se incluyen ejemplos de las salidas de un
diseño de aplicaciones que forma parte del Diseño del
Servicio general:
■■ Diseño de entradas y salidas, incluyendo formularios e
informes
■■ Un diseño de interfaz de usuario utilizable (interacción
hombre-ordenador)
■■ Un modelo de datos/objetos adecuado
■■ Un flujo de proceso o modelo de flujo de trabajo
■■ Especificaciones detalladas para procesos de
actualización y de sólo lectura
■■ Mecanismos para lograr controles de auditoría,
seguridad, confidencialidad y privacidad
■■ Un diseño ‘físico’ específico de la tecnología
■■ Scripts para probar el diseño de los sistemas
■■ Interfaces y dependencias con otras aplicaciones.
Existen directrices y marcos de trabajo que se pueden
adoptar para determinar y definir salidas del diseño dentro
de Gestión de Aplicaciones, como por ejemplo Integración
de Modelos Capacidad y Madurez (CMMI).
5.3.8  Patrones de diseño
Un patrón de diseño es una solución repetible y general
para un problema que se produce habitualmente en el
diseño del software. Los patrones de diseño orientado a
objetos normalmente muestran relaciones e interacciones
entre clases u objetos, sin especificar las clases u objetos
de aplicaciones finales que están implicados. Los patrones
de diseño describen un problema y una solución para
problemas habituales encontrados durante el desarrollo de
la aplicación.
Un principio de diseño importante utilizado como la base
para un gran número de patrones de diseño encontrados
en la literatura reciente es el de la separación en asuntos
(separation of concerns). La separación en asuntos
implicará la división de las aplicaciones en componentes,
con una fuerte cohesión y mínimo acoplamiento entre
componentes. La ventaja reside en que la modificación
se puede hacer en componentes individuales con poca o
ninguna importancia en otros componentes.
En proyectos típicos de desarrollo de aplicaciones, más
del 70% del esfuerzo se dedica a funciones genéricas de
diseño, desarrollo y en satisfacer los requisitos operativos
y de gestión. Eso se debe a que es necesario que cada
aplicación individual proporcione una solución para cada
funcionalidad genérica como por ejemplo impresión,
gestión de errores y seguridad.
 Actividades asociadas con la tecnología de Diseñ̃o del Servicio | 199
Entre otros, el Grupo de Gestión de Objetos (OMG, www.
omg.com) definió un gran número de servicios que son
necesarios en cada aplicación. La Arquitectura de Gestión
de Objetos (OMA) de OMG distingue claramente entre
aspectos funcionales, operativos y de gestión de una
aplicación. Se fundamenta en el concepto de proporcionar
un entorno que ofrezca todas las clases de facilidades a
una aplicación.
En este concepto, la aplicación cubre los aspectos
funcionales y el entorno cubre todos los aspectos
operativos y de gestión. Los desarrolladores de
aplicaciones deben, por definición, centrarse en los
aspectos funcionales de una aplicación, mientras que
los demás pueden centrarse en la creación del entorno
que proporcione los servicios operativos y de gestión
necesarios. Esto significa que los desarrolladores de
aplicaciones se centran en los requisitos del negocio,
mientras que los desarrolladores de arquitecturas o los
desarrolladores del marco de aplicaciones se centran en
los requisitos para los desarrolladores de aplicaciones.
5.3.9 Desarrollo de aplicaciones individuales
Una vez se haya completado la fase de diseño, el equipo
de desarrollo de aplicaciones tomará los diseños que se
han generado y pasará a desarrollar la aplicación. Tanto la
aplicación como el entorno asociado se preparan para el
despliegue. Los componentes de la aplicación se codifican
o adquieren, integran y prueban.
Para garantizar que la aplicación se desarrolle teniendo
como núcleo la gestión, es necesario que el equipo
de desarrollo se centre en garantizar que la fase de
desarrollo continúe abordando correctamente los
aspectos operativos y de gestión del diseño (por ejemplo,
capacidad de respuesta, disponibilidad, seguridad).
La guía de la fase de desarrollo cubre los siguientes
aspectos:
■■ Convenciones consistentes de codificación
■■ Directrices de construcción independientes de la
aplicación
■■ Pruebas de capacidad de operación
■■ Lista de comprobación de gestión para la fase de
construcción
■■ Organización de los roles del equipo de construcción.
5.3.10  Convenciones consistentes de
codificación
La razón principal para utilizar un conjunto consistente de
convenciones de diseño y codificación es estandarizar la
estructura y estilo de codificación de una aplicación para
que todos puedan leer, entender y gestionar fácilmente
el proceso de desarrollo de la aplicación. Un diseño y
convenciones de codificación adecuados consiguen un
código fuente preciso, legible y sin ambigüedades que sea
consistente con los estándares organizativos de gestión
y codificación y lo más intuitivo posible. Si se añade
capacidad de operación de la aplicación a esta convención
se garantizará que todas las aplicaciones se construyan
de tal forma que se puedan gestionar completamente en
todo momento a través de sus ciclos de vida.
La propia convención de codificación puede ser una
ayuda significativa para gestionar la aplicación, ya que
la consistencia permite a las herramientas de gestión
interactuar con la aplicación de una forma conocida. Es
mejor introducir un conjunto mínimo de convenciones
que todo el mundo pueda seguir en lugar de crear un
conjunto demasiado complejo que abarque todas las
facetas pero que no se siga o utilice consistentemente en
toda la organización.
5.3.11 Generación de plantillas y de códigos
Existe un número de herramientas de desarrollo que
proporcionan una gran variedad de plantillas para crear
componentes comunes de la aplicación. En lugar de
crear todas las partes de una aplicación desde cero, los
desarrolladores pueden personalizar una plantilla existente.
También pueden reutilizar componentes personalizados en
múltiples aplicaciones creando sus propias plantillas. Otras
herramientas de desarrollo generarán grandes segmentos
de código (esqueletos) basándose en los modelos de
diseño y convenciones de codificación. El código podría
incluir vínculos en los segmentos de código que será
necesario añadir.
A este respecto, las plantillas y marcos de aplicaciones
deben considerarse activos de TI. Estos activos no
sólo guían el desarrollo de las aplicaciones, sino que
también incorporan las lecciones aprendidas o capital
intelectual procedentes de esfuerzos desarrollados en
aplicaciones previas. Mientras más componentes estándar
se diseñen dentro de la solución, con más rapidez se
podrán desarrollar las aplicaciones y con menores costes
a largo plazo (sin ignorar el hecho de que el desarrollo
de plantillas, generadores de códigos y marcos de
aplicaciones requiere inversiones significativas).
5.3.12  Instrumentación integrada de la
aplicación
La fase de desarrollo utiliza instrumentación incorporada
en la estructura de la aplicación. Los desarrolladores
necesitan una forma consistente de proporcionar
instrumentación para drivers de aplicaciones/componentes
200 | Actividades asociadas con la tecnología de Diseñ̃o del Servicio

de middleware (por ejemplo, drivers de bases de datos) y
aplicaciones, que sea eficiente y fácil de implementar. Para
evitar que los desarrolladores de aplicaciones reinventen
la rueda con cada nueva aplicación que desarrollen, la
industria informática proporciona métodos y tecnologías
para simplificar y facilitar el proceso de instrumentación.
Éstos incluyen:
■■ Medida de la Respuesta de la Aplicación (ARMS)
■■ Especificación de Gestión de Aplicaciones de IBM
(AMS)
■■ Modelo de Información Común (CIM) y Gestión
Empresarial Basada en Web (WBEM) del Grupo de
Trabajo de la Gestión Distribuida (DMTF)
■■ Instrumentación de Gestión de PCs (DMI)
■■ Microsoft Windows © Management Instrumentation
(WMI)
■■ Extensión de Gestión Java (JMX).
Cada una de estas tecnologías proporciona un modelo
descriptivo consistente y completo de la configuración,
del estado y de aspectos operativos de aplicaciones y
servicios. Éstos se proveen a través de la programación de
Interfaces de Programación de Aplicaciones (APIs) que el
desarrollador incorpora en una aplicación, normalmente a
través del uso de plantillas de programación estándar.
Es importante asegurar que todas las aplicaciones se
construyan conforme a algún nivel de conformidad para la
instrumentación de aplicaciones. Las formas de hacer esto
podrían incluir:
■■ Proporcionar acceso a datos de gestión a través de la
instrumentación API
■■ Publicar datos de gestión para otros sistemas de
gestión, nuevamente a través de la instrumentación
API
■■ Proporcionar manejo de eventos de aplicaciones
■■ Proporcionar un enlace de diagnóstico.
■■ Información al nivel de software proporcionada por
los componentes de la infraestructura de la aplicación
como por ejemplo bases de datos, servidor web o
sistemas de mensajería
■■ Información personalizada proporcionada por las
aplicaciones
■■ Información sobre el rendimiento de componentes y
del servicio.
5.3.14 Salidas principales del servicio
procedentes del desarrollo
Las salidas principales procedentes de la fase de desarrollo
son:
■■ Scripts a ejecutar antes o después del despliegue
■■ Scripts para iniciar o detener la aplicación
■■ Scripts para comprobar las configuraciones de
hardware y software de entornos operativos antes del
despliegue o instalación
■■ Especificación de métricas y eventos que se pueden
recuperar de la aplicación y que indican el estado de
rendimiento de la aplicación
■■ Scripts personalizados por el personal de Operaciones
del Servicio para gestionar la aplicación (incluyendo el
manejo de actualizaciones de la aplicación)
■■ Especificación de la información del control de
accesos para los recursos del sistema utilizados por
una aplicación
■■ Especificación de los detalles requeridos para rastrear
las transacciones principales de una aplicación
■■ Objetivos y requisitos de los SLA
■■ Requisitos operativos y documentación
■■ Requisitos de soporte
■■ Backups y recuperación de la aplicación
■■ Otros requisitos y objetivos de SM de TI.

5.3.13 Enlaces de diagnóstico
Los enlaces de diagnóstico son de gran valor durante las
pruebas y cuando se ha descubierto un error en el servicio
de producción. Los enlaces de diagnóstico proporcionan
principalmente la información necesaria para resolver
rápidamente problemas y errores de las aplicaciones y
para restablecer el servicio. También se pueden utilizar
para proporcionar medición e información sobre gestión
de las aplicaciones.
Las tres categorías principales son:
■■ Información al nivel de sistema proporcionada por el
OS y el hardware
824_007 Chapter 06.indd 201
Organización del
Diseñ̃o del Servicio 6
22/1/10 13:50:56
824_007 Chapter 06.indd 202 22/1/10 13:50:57
 6 Organización del Diseño del Servicio
Para que Diseño del Servicio tenga éxito, es fundamental
definir los roles y responsabilidades de las distintas
actividades dentro de la organización.
Al diseñar un servicio o proceso, es imperativo que se
definan claramente todos los roles. Un indicativo de
organizaciones de alto rendimiento es la capacidad de
tomar las decisiones correctas rápidamente y ejecutarlas
eficazmente. Si la decisión implicara una decisión
estratégica o una operación crítica, es importante tener
claro quién genera el input, quién decide y quién lleva
a cabo las acciones que permitirán a la compañía seguir
adelante rápidamente.
El modelo RACI será beneficioso a la hora de permitir
tomar decisiones con ritmo y confianza. RACI es un
acrónimo de los cuatro roles principales de:
■■ Responsable – la persona o personas responsables de
que se realice el trabajo
■■ Encargado – sólo una persona puede ser responsable
de cada tarea se lleve a cabo
■■ Consultado – las personas a las que se consulta y
cuyas opiniones se buscan
■■ Informado – las personas que se mantienen
informadas del proceso.
Ocasionalmente se utiliza una versión ampliada de RACI
denominada RACI-VS, con dos roles más:
■■ Verificador – la persona o grupo que comprueba si
se han cumplido los criterios de aceptación
■■ Signs off (autorizador) – la persona que aprueba la
decisión V y autoriza la transferencia del producto.
Este rol podría asumirlo la persona A.
Tabla 6.1  Ejemplo de matriz RACI
Director de Gestión Gestor de Nivel de
del Servicio Servicio
Actividad 1 AR C I
Actividad 2 A R
Actividad 3 I A
Actividad 4 I A
Actividad 5 I I
824_007 Chapter 06.indd 203
Una tercera variación del modelo RACI es RASCI, donde
S representa Soporte. Este rol proporciona recursos
adicionales para dirigir el trabajo, o juega un rol de
soporte en la implementación, por ejemplo. Esto podría
ser beneficioso para la implementación del servicio de TI.
El cuadro RACI de la Tabla 6.1 muestra la estructura y
posibilidades del modelado RACI. Incluye las actividades
en el lado izquierdo con las acciones necesarias que
deben acometerse y las decisiones que deben tomarse. En
la parte superior el cuadro se indican los roles funcionales
responsables de llevar a cabo la iniciativa o de tomar parte
de la toma de decisiones.
Si se utilizara el modelo RACI o alguna otra herramienta,
lo más importante es evitar dejar la asignación de
responsabilidades a su suerte o dejarla para decidirla en
el último minuto. Se pueden evitar conflictos y tomar
las decisiones rápidamente si los roles se asignaran con
anticipación.
Para construir un cuadro RACI se requieren los siguientes
pasos:
■■ Identificar las actividades/procesos
■■ Identificar/definir los roles funcionales
■■ Dirigir reuniones y asignar los códigos RACI
■■ Identificar cualquier gap o solape – por ejemplo, si
hubieran dos Rs o ninguna R (vea el análisis siguiente)
■■ Distribuir el cuadro e incorporar retroalimentación
■■ Garantizar que se sigan las asignaciones.
Gestor de Problemas Gestor de la Gestor de compras
Seguridad
I C
C C C
R I C
R I
A C I
22/1/10 13:50:57
 204 | Organización del Diseñ̃o del Servicio
6.1  Análisis de roles funcionales
■■ Muchas As: ¿Las tareas se han segregado
adecuadamente? ¿Alguien más debe ser responsable
de alguna de estas actividades? ¿Esto está causando
un cuello de botella en algunas áreas que retrasará la
toma de decisiones?
■■ Muchas Rs: ¿Esto es demasiado para una función?
■■ No hay espacios vacíos: ¿Es necesario implicar a este
rol en tantas tareas?
■■ Además, ¿el tipo o grado de participación se ajusta a
las cualificaciones de este rol?
6.2  Análisis de actividades
■■ Más de una A: sólo se puede justificar un rol.
■■ Ninguna A: al menos debe asignarse una A a cada
actividad.
■■ Más de una R: demasiados roles responsables
con frecuencia implica que ninguno asume la
responsabilidad. La responsabilidad puede compartirse,
pero sólo si los roles están claros.
■■ Ninguna R: al menos debe ser responsable una
persona.
■■ Muchas C: ¿Existe un requisito a consultar con tantos
roles? ¿Cuáles son los beneficios y se puede justificar
el tiempo extra?
■■ No hay Cs ni Is: ¿Los canales de comunicación están
abiertos para permitir a las personas y departamentos
hablar unos con los otros y mantenerse actualizados?
6.3  Habilidades y atributos
Los roles específicos dentro de Gestión del Servicio de
ITIL requieren habilidades, atributos y competencias de
las personas implicadas para permitirles trabajar eficaz y
eficientemente. Sin embargo, independientemente de su
rol, es importante que la persona que lleva a cabo ese rol
tenga las siguientes cualidades:
■■ Concienciación de las prioridades, objetivos e
impulsores del negocio
■■ Concienciación del rol que desempeña TI a la hora de
permitir que se cumplan los objetivos de negocio
■■ Habilidades de servicio al cliente
■■ Concienciación de lo que TI puede ofrecer al negocio,
incluyendo las habilidades más novedosas
■■ La competencia, conocimiento e información
necesarios para completar su rol
■■ La capacidad de utilizar, entender e interpretar
la mejor práctica, políticas y procedimientos para
garantizar su cumplimiento.
824_007 Chapter 06.indd 204
A continuación se incluyen ejemplos de atributos
requeridos en muchos de los roles, dependiendo de la
organización y del rol específico:
■■ Habilidades de gestión – desde la perspectiva de
gestión de una persona y desde la perspectiva del
control general del proceso
■■ Habilidades de reunión – para organizar, coordinar,
documentar y garantizar que se realicen las
actividades
■■ Comunicaciones – un elemento importante de
todos los roles es la concienciación de los procesos
aplicados para garantizar la aceptación y conformidad.
Será fundamental disponer de la capacidad para
comunicarse en todos los niveles dentro de la
organización
■■ Lenguaje articulado – tanto por escrito, para
informes, etc., y verbal
■■ Negociación – requerida para varios aspectos, como
por ejemplo compras y contratos
■■ Analítico – para analizar métricas generadas de la
actividad.
Puede encontrar más información sobre las habilidades y
competencias de estos roles dentro del Marco de Trabajo
de Habilidades para la Era de la Información (SFIA –
www.sfia.org.uk).
6.4  Roles y responsabilidades
Las siguientes secciones describen los roles y
responsabilidades de varios roles dentro de Diseño del
Servicio. En algunas organizaciones esto podría implicar a
un individuo a tiempo completo y en otras podría implicar
a varias personas, o podría ser un rol a tiempo parcial.
En organizaciones más pequeñas muchos de estos roles
podrían realizarlos una única persona. Esto dependerá
del tamaño y volatilidad de la organización. Los roles o
nombres de puestos de trabajo varían frecuentemente
entre organizaciones. Sin embargo, lo que es
importante es que los roles, responsabilidades, procesos,
dependencias e interfaces estén claramente definidos y
delimitados para cada organización individual. (Vea el
Apéndice C para disponer de una plantilla de documento
de proceso de ejemplo).
A continuación se incluyen ejemplos de las actividades
principales dentro de cada uno de los roles de Diseño del
Servicio.
6.4.1 Propietario del proceso
Un propietario del proceso es responsable de garantizar
que su proceso se esté realizando de acuerdo con el
22/1/10 13:50:57

proceso acordado, documentado y se estén cumpliendo
los objetivos de la definición del proceso. Eso incluye
tareas como:
■■ Documentar y publicitar el proceso
■■ Definir los Indicadores Clave de Rendimiento (KPIs)
para evaluar le eficacia y eficiencia del proceso
■■ Revisar KPIs y tomar las acciones requeridas después
del análisis
■■ Ayudar y ser responsable en última instancia del
diseño del proceso
■■ Mejorar la eficacia y eficiencia del proceso
■■ Revisar cualquier mejora propuesta en el proceso
■■ Proporcionar una entrada al Plan de Mejora Continua
del Servicio
■■ Abordar cualquier problema asociado con la puesta en
práctica del proceso
■■ Garantizar que todo el personal relevante tenga
la formación requerida en el proceso y que sean
conscientes de su rol en el proceso
■■ Garantizar que el proceso, roles, responsabilidades y
documentación se revisen y auditen regularmente
■■ Que interactuen con los mandos de línea y líderes
tecnológicos, garantizando que el proceso reciba los
recursos necesarios de personal. (Que los mandos
y líderes y los propietarios del proceso tengan
tareas complementarias. Es necesario que colaboren
para garantizar procesos eficientes y eficaces. Con
frecuencia es una tarea de la supervisión directa
garantizar la formación requerida del personal).
6.4.2  Gestor del Diseño del Servicio
En esta publicación ser recogen el rol y responsabilidades
clave del Gestor de Diseño del Servicio. Éste será
responsable de la coordinación general y del despliegue
de diseños de soluciones de calidad para servicios y
procesos. Las responsabilidades del rol por encima de
aquellas de la supervisión directa de todas las personas
implicadas en los roles de Diseño del Servicio incluyen:
■■ Asumir las Estrategias del Servicio generales y asegurar
que se reflejen en la práctica de Diseño del Servicio
y en los Diseños del Servicio que se generan para
cumplir los requisitos de negocio documentados
■■ Diseñar los aspectos funcionales de los servicios y de
la infraestructura, de las aplicaciones, del entorno y de
la gestión de datos
■■ Generar diseños de calidad, seguros y flexibles
para servicios nuevos o mejorados, la arquitectura
tecnológica, procesos o sistemas de medida que
cumplan todos los requisitos de TI actuales y futuros
acordados de la organización
824_007 Chapter 06.indd 205
Organización del Diseñ̃o del Servicio | 205
■■ Generar y mantener toda la documentación del
diseño, incluyendo diseños, planes, arquitecturas y
políticas
■■ Generar y mantener todos los SDP necesarios
■■ Medir la eficacia y eficiencia del proceso de Diseño del
Servicio.
6.4.3 Planificador de TI
Un Planificador de TI es responsable de la elaboración y
coordinación de planes de TI. Los objetivos principales del
rol son los siguientes:
■■ Desarrollar planes de TI que cumplan y continúen
cumpliendo los requisitos de TI del negocio.
■■ Coordinar, medir y revisar el progreso de la
implementación de todas las estrategias y planes de
TI.
■■ Generar y mantener el conjunto completo de
estándares, políticas, planes y estrategias de TI,
abarcando todos los aspectos de TI requeridos
para dar soporte a la estrategia de negocio de
una organización. La planificación de TI incluye la
participación en la creación de SLAs y la planificación
de todos los aspectos de la infraestructura, internos
y externos, públicos o privados, Internet o intranet,
necesarios para garantizar que la provisión de servicios
de TI satisfaga al negocio.
■■ Asumir la responsabilidad de todos los aspectos de la
implementación de los estándares, política y estrategia
de TI en su totalidad y para proyectos significativos o
nuevas aplicaciones estratégicas principales.
■■ Recomendar la política para el uso eficaz de TI a
través de la organización y trabajar con Diseñadores
de TI para garantizar que los planes y estrategias
generales se desarrollen junto con diseño de TI para
todas las áreas de TI.
■■ Revisar los costes de TI con respecto a los
presupuestos y a nuevos desarrollos, iniciando
propuestas de cambio en estrategias y planes de TI si
fuera apropiado, junto con Gestión Financiera.
■■ Asumir toda la responsabilidad de la gestión,
planificación y coordinación de sistemas y servicios de
TI, incluyendo la investigación, análisis, especificación,
diseño, desarrollo, prueba, mantenimiento,
actualización, transición y operación. Es fundamental
que mientras se realizan estas actividades, el negocio,
Gestión de TI y todos los procesos de Gestión del
Servicio se mantengan actualizados con el progreso
de los proyectos.
■■ Obtener y evaluar propuestas de los suministradores
de equipos, software, servicios de transmisión y otros
22/1/10 13:50:57
 206 | Organización del Diseñ̃o del Servicio
servicios, garantizando que se satisfagan todos los
requisitos del negocio y de TI.
■■ Identificar factores internos y externos que influyan,
necesidades de futuras previsiones y establecer planes
para el uso eficaz de TI dentro de la organización.
■■ Patrocinar y monitorizar la investigación, desarrollo y
planificación a largo plazo para la provisión y uso de
arquitecturas, productos y servicios de TI
■■ Revisar el rendimiento de TI con todas las áreas
e iniciar cualquier mejora en la organización para
garantizar que se continúen cumpliendo los objetivos
y niveles del servicio en todas las áreas.
■■ Asumir la responsabilidad última para priorizar y
programar la implementación de servicios nuevos o
modificados dentro de TI.
■■ Trabajar con la Dirección y con otros especialistas y
planificadores senior en la formulación de planes y a
la hora de tomar decisiones de compras aplicables a
todas las áreas de TI.
■■ Reconocer los impulsores clave del negocio y aquellas
áreas de negocio necesarias que no se vean apoyadas
adecuadamente por los servicios de TI actuales y
planificados, desarrollando planes y respuestas de TI
para los requisitos de negocio.
■■ Identificar aplicaciones, servicios y productos
adecuados, junto con sus entornos, para satisfacer
las necesidades del negocio dentro del plazo de
planificación requerido.
■■ Desarrollar planes iniciales para la implementación
de nuevos servicios de TI autorizados, aplicaciones y
soporte de infraestructura, identificando restricciones
presupuestarias, técnicas y de personal, e indicando
claramente los costes y beneficios esperados.
■■ Monitorizar los planes de TI existentes en relación con
las necesidades del negocio y la estrategia de TI para
determinar oportunidades de mejora de los procesos
de negocio a través del uso de nuevas tecnologías y
para identificar riesgos imprevistos para el logro del
beneficio previsto para el negocio.
■■ Investigar opciones importantes para proporcionar
servicios de TI eficaz y eficientemente y recomendar
nuevas soluciones innovadoras, basadas en métodos
nuevos para procesos, provisión, selección y retención,
y contratos de suministro globales.
■■ Elaborar estudios de viabilidad, modelos de negocio,
modelos de TI, casos de negocio, SoRs e ITTs para
sistemas nuevos de TI, identificando el impacto para el
negocio, la probabilidad de satisfacer las necesidades
del negocio, los beneficios anticipados para el negocio
y los riesgos y consecuencias del fallo.
824_007 Chapter 06.indd 206
■■ Supervisar y coordinar el programa de
implementaciones y cambios planificados en los
proyectos de TI, tomando las acciones oportunas para
identificar y superar problemas y resolver conflictos.
■■ Dirigir Revisiones Post Implementación (PIR),
junto con Gestión de Cambios, de aquellos
sistemas de información introducidos a través de
la implementación de los planes, para evaluar la
amplitud con la que se materializan los beneficios
esperados para el negocio.
■■ Actuar conjuntamente con los equipos y procesos de
Estrategia, Transición y Operaciones para planificar sus
necesidades inmediatas y futuras.
■■ Proporcionar consejo y guía autorizados sobre
los estándares, regulaciones, protocolos y tarifas
nacionales o internacionales relevantes.
■■ Documentar todo el trabajo utilizando estándares,
métodos y herramientas requeridos.
■■ Garantizar que todos los procesos de planificación de
TI, roles, responsabilidades y documentación se revisen
y auditen regularmente para lograr eficiencia, eficacia
y conformidad.
■■ Mantener un buen conocimiento general de todas las
capacidades del producto de TI y de los marcos de
trabajo técnicos en los que operan.
■■ Si se requiere, evaluar los cambios para determinar su
conformidad con las estrategias de diseño, incluyendo
la asistencia a reuniones del CAB si fuera pertinente.
6.4.4  Arquitecto/Diseñador de IT
Un Arquitecto/Diseñador de TI es responsable de la
coordinación y diseño general de la tecnología requerida.
En muchas ocasiones los Diseñadores y Arquitectos
de grandes organizaciones se especializan en uno de
los cinco aspectos del diseño (vea las sección 3). Sin
embargo, siempre debe adoptarse un método integrado
de diseño, por lo que es necesario que Diseñadores
y Arquitectos trabajen juntos dentro de un método y
marco de trabajo formales para garantizar que se generen
diseños consistentes y compatibles. En organizaciones
más pequeñas, normalmente se combinan algunos o
todos los roles, y esto representa un problema menor,
aunque todavía deberá utilizarse un método formal.
Siempre que se generen diseños, deberán adoptar un
método integrado que cubra todas las áreas, y todas las
áreas deberán aceptarlo y aprobarlo. Es necesario que
todos los diseñadores entiendan cómo se acoplan juntos
las arquitecturas, estrategias, diseños y planes y todos los
aspectos principales del diseño.
El Diseñador/Arquitecto debe generar un mapa detallado
del proceso que documente todos los procesos y sus
22/1/10 13:50:57

interfaces de alto nivel. Esto evita que toda la estructura
sea innecesariamente compleja, consigue que las
interfaces centrales del proceso formen parte del diseño, y
proporciona una descripción general a todo el mundo de
cómo el cliente y todos los demás interesados interactúan
con los procesos.
Para llevar a cabo el rol de Diseñador o Arquitecto, es
necesario que el personal tenga un buen conocimiento
y experiencia práctica de la planificación y filosofías de
diseño, incluyendo Gestión de Programas, Proyectos y
Servicios, métodos y principios. Los objetivos principales
del Diseñador/Arquitecto de TI son los siguientes:
■■ Generar y revisar los diseños de todos los servicios
nuevos o modificados, SLAs, OLAs y contratos.
■■ Generar un mapa del proceso de todos los procesos
y sus interfaces de alto nivel para garantizar la
integración, consistencia y continuidad en todos los
procesos.
■■ Diseñar arquitecturas tecnológicas seguras y flexibles
que cumplan todos los requisitos de TI actuales y
futuros anticipados de la organización.
■■ Garantizar que el diseño de todos los procesos, roles,
responsabilidades y documentación se revisen y
auditen regularmente para lograr eficiencia, eficacia y
conformidad.
■■ Diseñar un Porfolio de Servicios apropiado que dé
soporte a todas las actividades dentro del Ciclo de
Vida del Servicio.
■■ Diseñar sistemas y técnicas de medida para dar
soporte a la mejora continua de la provisión del
servicio y a todos los procesos de soporte.
■■ Generar y mantener actualizada toda la
documentación del diseño, arquitectura, política y
especificaciones de TI.
■■ Generar y mantener todos los aspectos de la
especificación de TI, incluyendo los diseños generales,
arquitecturas, topologías y configuraciones de la
infraestructura, entorno, aplicaciones y datos, y la
documentación del diseño para todos los sistemas
de TI. Esto debe incluir no sólo la tecnología, sino
también los sistemas de gestión, procesos, flujos de
información y servicios externos.
■■ Recomendar soluciones de TI proactivas e innovadoras
para la mejora del diseño y operación de TI siempre y
cuando sea posible.
■■ Traducir diseños lógicos a diseños físicos, teniendo
en cuenta los requisitos de negocio, entornos de
operación, procesos, requisitos de rendimiento,
sistemas y servicios existentes, y cualquier posible
aspecto relacionado con la seguridad.
824_007 Chapter 06.indd 207
Organización del Diseñ̃o del Servicio | 207
■■ Crear y mantener políticas de diseño, filosofías y
criterios de TI, cubriendo todas las áreas que incluyan
la conectividad, capacidad, interfaces, seguridad,
flexibilidad, recuperación, acceso y acceso remoto, y
garantizando que todos los nuevos servicios cumplen
sus objetivos y niveles de servicio.
■■ Trabajar con Gestión de la Capacidad y revisar los
requisitos y volúmenes de tráfico de TI, identificando
tendencias en los flujos de tráfico y en los niveles de
servicio.
■■ Proponer mejoras de diseño en la infraestructura de
TI, cambios de capacidad, acuerdos de continuidad,
backup y recuperación, y ser conscientes de los
requisitos operativos, especialmente en términos
de niveles de servicio, disponibilidad, tiempos de
respuesta, seguridad y tiempos de reparación. Todas
estas actividades se realizan en colaboración con
todos los procesos de Gestión del Servicio.
■■ Revisar los costes de TI con respecto a los
suministradores externos de servicios, nuevos
desarrollos y nuevos servicios, iniciando propuestas
de cambio del diseño de TI si pudieran lograrse
beneficios y reducciones apropiadas de costes,
consultándolo con Gestión Financiera.
■■ Proporcionar consejo y guía sobre las fases de diseño
y planificación de sistemas de TI para garantizar que
se reflejen los requisitos (particularmente en lo que
respecta a las necesidades de capacidad, recuperación,
rendimiento y seguridad) en las especificaciones
generales.
■■ Proporcionar asesoramiento y directrices para todas
las áreas de Gestión de TI y del negocio, analistas,
planificadores, diseñadores y desarrolladores en todos
los aspectos del diseño de TI y de la tecnología.
■■ Ser interfaz con diseñadores y planificadores de
suministradores externos y proveedores de servicio,
garantizando que todos los servicios de TI externos
se diseñen para cumplir sus objetivos y niveles de
servicio acordados.
■■ Desempeñar un rol importante en la selección
de cualquier infraestructura de TI o soluciones
tecnológicas nuevas.
■■ Asumir la responsabilidad técnica sobre estándares,
política y diseño de TI para todos los proyectos
significativos o áreas de aplicación importantes,
ayudando en la evaluación del impacto y en la
evaluación de nuevas e importantes opciones de
diseño de TI.
■■ Proporcionar consejo y guía técnica sobre los
estándares, regulaciones, protocolos y tarifas
nacionales o internacionales relevantes.
22/1/10 13:50:57
 208 | Organización del Diseñ̃o del Servicio
■■ Asumir toda la responsabilidad de los aspectos de
diseño de todas las etapas del ciclo de vida de los
sistemas de TI, incluyendo la investigación, análisis,
especificación, diseño, desarrollo, construcción, prueba,
mantenimiento, actualización, transición, operación y
mejora.
■■ Trabajar con sus colegas de TI siempre que sea
apropiado, generando y actualizando modelos y
documentación corporativos de diseño.
■■ Actualizar o proporcionar entradas para el análisis de
coste-beneficio, análisis de riesgo, SoRs e ITTs y planes
de desarrollo, para tener en cuenta las decisiones de
diseño.
■■ Obtener y ayudar con la evaluación y selección
de propuestas y soluciones de los suministradores
de equipos, software y de otros proveedores de
productos y servicios de TI.
■■ Construir, interpretar y monitorizar planes de prueba
para verificar la operación correcta de sistemas con
respecto a sus objetivos de diseño.
■■ Documentar todo el trabajo utilizando estándares,
métodos y herramientas requeridos.
■■ Mantener un buen conocimiento técnico de todas las
capacidades de los productos de TI y de los marcos
de trabajo técnico en los que operan.
■■ Si se requiere, evaluar los cambios para determinar su
conformidad con los principios de diseño, incluyendo
la asistencia a reuniones del CAB si fuera pertinente.
Nota: En muchas ocasiones los Diseñadores y Arquitectos
de grandes organizaciones se especializan en uno de
los cinco aspectos del diseño (vea las secciones 3 y 4
para disponer de más detalles). Sin embargo, siempre
debe adoptarse un método integrado de diseño, por lo
que es necesario que Diseñadores y Arquitectos trabajen
juntos dentro de un método y marco de trabajo formales
para garantizar que se generen diseños consistentes
y compatibles. En organizaciones más pequeñas,
normalmente se combinan algunos o todos los roles, y
esto representa un problema menor, aunque aún deberá
utilizarse un método formal. Siempre que se generen
diseños, deberán adoptar un método integrado que
cubra todas las áreas, y todas las áreas deberán aceptarlo
y aprobarlo. Es necesario que todos los Diseñadores
entiendan cómo se acoplan juntos las arquitecturas,
estrategias, diseños y planes.
6.4.5  Gestor del Catálogo de Servicios
El Gestor del Catálogo de Servicios tiene la responsabilidad
de generar y mantener el Catálogo de Servicios. Se
incluyen responsabilidades tales como:
824_007 Chapter 06.indd 208
■■ Garantizar que se registren en el Catálogo de Servicios
todos los servicios operativos y todos los servicios que
se están preparando para empezar a operar
■■ Garantizar que toda la información dentro del
Catálogo de Servicios sea precisa y esté actualizada
■■ Garantizar que toda la información del Catálogo de
Servicios sea consistente con la información incluida
en el Porfolio de Servicios
6.4.6  Garantizar que la información del
Catálogo de Servicios esté adecuadamente
protegida y respaldada.Gestor de Nivel de
Servicio
El Gestor de Nivel de Servicio tiene la responsabilidad
de garantizar que se cumplan los objetivos de Gestión
del Nivel de Servicio. Se incluyen responsabilidades tales
como:
■■ Mantenerse al tanto de las necesidades cambiantes del
negocio
■■ Garantizar que los requisitos del servicio actuales y
futuros de los clientes se identifiquen, entiendan y
documenten en documentos de SLAs y SLRs
■■ Negociar y acordar con el cliente los niveles de
servicio que se entregarán (internos o externos);
documentar formalmente estos niveles del servicio en
SLAs
■■ Negociar y acordar con los clientes del servicio OLAs
y, en algunos casos, otros SLAs y acuerdos que den
soporte a los SLAs
■■ Ayudar en la producción y mantenimiento detallado
del Porfolio de Servicios, Catálogo de Servicios y
Porfolio de Aplicaciones y con los procedimientos de
mantenimiento correspondientes
■■ Garantizar que los objetivos acordados en los
contratos de soporte estén alineados con los objetivos
de SLAs y SLRs
■■ Garantizar que se elaboren informes del servicio
para cada servicio del cliente y que se tomen en
consideración e investiguen los incumplimientos
de los objetivos de los SLAs y se llevan a cabo las
acciones oportunas para evitar su recurrencia
■■ Garantizar que se planifiquen las revisiones del
rendimiento del servicio, que se realicen regularmente
con los clientes y que se documenten con el avance
de las acciones acordadas
■■ Garantizar que se actúe sobre las iniciativas de mejora
identificadas en las revisiones del servicio y que se
proporcionen informes del progreso a los clientes
■■ Revisar regularmente el ámbito del servicio, SLAs, OLAs
y otros acuerdos, idealmente, una vez al año
22/1/10 13:50:57

■■ Garantizar que se evalúen todos los cambios con
respecto a su impacto en los niveles de servicio,
incluyendo SLAs, OLAs y contratos de soporte, e,
igualmente, la asistencia a reuniones del CAB si fuera
oportuno
■■ Identificar a todos los interesados y clientes clave
■■ Desarrollar la relación y la comunicación con los
interesados, clientes y usuarios clave
■■ Definir y aceptar las disconformidades y su registro,
gestión, escalado, y si fuera necesario, su resolución
■■ Definir el registro y comunicación de todas las
disconformidades
■■ Medir, registrar, analizar y mejorar la satisfacción del
cliente.
6.4.7  Gestor de la Disponibilidad
El Gestor de la Disponibilidad tiene la responsabilidad de
garantizar que se cumplan los objetivos de Gestión de la
Disponibilidad. Se incluyen responsabilidades tales como:
■■ Garantizar que todos los servicios existentes ofrezcan
los niveles de disponibilidad acordados con el negocio
en SLAs
■■ Garantizar que todos los nuevos servicios se diseñen
para proporcionar los niveles de disponibilidad
requeridos por el negocio, y validar que el diseño
final cumple los niveles mínimos de disponibilidad
acordados con el negocio para los servicios de TI
■■ Colaborar con la investigación y diagnóstico de
todas las incidencias y problemas que impactan
negativamente en la disponibilidad de los servicios o
de sus componentes
■■ Participar en el diseño de la infraestructura de TI,
incluyendo la especificación de los requisitos de
disponibilidad para el hardware y software
■■ Especificar los requisitos para crear nuevos sistemas
de gestión de eventos o mejorar los existentes para
la monitorización automática de la disponibilidad de
componentes de TI
■■ Especificar la fiabilidad, capacidad de mantenimiento y
capacidad de servicio para componentes suministrados
por proveedores internos y externos
■■ Asumir la responsabilidad de la monitorización de la
disponibilidad de TI real con respecto a los objetivos
de los SLAs, y proporcionar una serie de informes de
disponibilidad de TI para garantizar que se midan y
monitoricen los niveles acordados de disponibilidad,
fiabilidad y capacidad de mantenimiento de forma
continua
■■ Mejorar de forma proactiva disponibilidad del servicio
siempre que sea posible y optimizar la disponibilidad
824_007 Chapter 06.indd 209
Organización del Diseñ̃o del Servicio | 209
de la infraestructura de TI para ofrecer mejoras
rentables que proporcionen beneficios tangibles al
negocio
■■ Crear, mantener y revisar regularmente un AMIS y
un Plan de Disponibilidad innovadores, con objeto
de mejorar la disponibilidad general de los servicios
de TI y de los componentes de la infraestructura,
para garantizar que se cumplan los requisitos de
disponibilidad actuales y futuros para el negocio
■■ Garantizar que el proceso Gestión de la Disponibilidad,
sus técnicas y métodos asociados, se revisen y auditen
regularmente, y que todos ellos estén sujetos a mejora
continua y que continúen ajustados a su propósito
■■ Crear criterios de diseño de disponibilidad y
recuperación para que se apliquen al diseño de
infraestructuras nuevas o a mejoras en las mismas
■■ Trabajar con Gestión Financiera, garantizando que
se justifican los costes de los niveles requeridos de
disponibilidad de TI
■■ Mantener y completar un calendario de pruebas para
todos los mecanismos de disponibilidad
■■ Garantizar que todas las pruebas y planes de
disponibilidad se prueben después de cada cambio
importante en el negocio
■■ Ayudar a Gestión de la Continuidad del Servicio de TI
y de la Seguridad en la evaluación y gestión del riesgo
■■ Evaluar cambios con respecto a su impacto
en respecto a la disponibilidad, incluyendo la
disponibilidad general del servicio y el Plan de
Disponibilidad
■■ Asistir a las reuniones del CAB cuando sea oportuno.
6.4.8  Gestor de la Continuidad del Servicio
de TI
El Gestor de la Continuidad del Servicio de TI tiene
la responsabilidad de garantizar que se cumplan los
objetivos de Gestión de la Continuidad del Servicio de TI.
Esto incluye tareas y responsabilidades tales como:
■■ Realizar Análisis de Impacto del Negocio para todos
los servicios nuevos o existentes
■■ Implementar y mantener el proceso ITSCM conforme
a los requisitos generales del proceso Gestión de la
Continuidad del Negocio, y representar a los servicios
de TI en el proceso Gestión de la Continuidad del
Negocio
■■ Garantizar que todos los planes, riesgos y actividades
de ITSCM apoyen y se alineen con todos los planes,
riesgos y actividades de BCM, y sean capaces, bajo
cualquier circunstancia, de cumplir los objetivos
acordados y documentados
22/1/10 13:50:57
 210 | Organización del Diseñ̃o del Servicio
■■ Realizar la gestión y evaluación del riesgo para evitar
desastres, siempre que se justifique sus coste y sea
útil
■■ Desarrollar y mantener la estrategia de continuidad de
la organización
■■ Evaluar problemas potenciales de la continuidad del
negocio y arrancar el Plan de Continuidad del Servicio
si fuera necesario
■■ Gestionar el Plan de Continuidad del Servicio mientras
esté en operación, incluyendo la conmutación a una
ubicación secundaria y la restauración de la ubicación
principal
■■ Realizar revisiones post mortem de las invocaciones y
pruebas de continuidad del servicio e instar acciones
correctivas si fuera necesario
■■ Desarrollar y gestionar los planes de ITSCM para
asegurar que, en todo momento, se puedan alcanzar
los objetivos de recuperación
■■ Asegurar que todas las áreas del servicio de TI estén
preparadas y puedan responder a una invocación de
los planes de continuidad
■■ Mantener una programación integral de pruebas de
TI, incluyendo las pruebas de todos los planes de
continuidad en línea con los requisitos del negocio y
después de cualquier cambio importante del negocio
■■ Emprender revisiones de calidad de todos los
procedimientos y garantizar que éstas se incorporen al
calendario de pruebas
■■ Comunicar y mantener la concienciación sobre los
objetivos de ITSCM dentro de las áreas de negocio a
las que se da soporte y de las áreas de servicio de TI
■■ Realizar revisiones regulares de los Planes de
Continuidad con las áreas de negocio, al menos
anualmente, para garantizar que reflejen con precisión
las necesidades del negocio
■■ Negociar y gestionar contratos con proveedores de
servicios externos de recuperación
■■ Evaluar los cambios respecto a su impacto en
la Continuidad del Servicio y en los Planes de
Continuidad
■■ Asistir a las reuniones del CAB cuando sea oportuno.
6.4.9  Gestor de la Capacidad
El Gestor de la Capacidad tiene la responsabilidad de
garantizar que se cumplan los objetivos de Gestión de la
Capacidad. Esto incluye tareas como:
■■ Garantizar que haya capacidad de TI adecuada para
cumplir los niveles requeridos del servicio, y que se
aconseje correctamente a la dirección de TI en cómo
824_007 Chapter 06.indd 210
hacer corresponder la capacidad con la demanda y
para que se optimice el uso de la capacidad existente
■■ Identificar, con el Gestor de Nivel de Servicio, los
requisitos de capacidad a través de discusiones con
los usuarios del negocio
■■ Entender el uso actual de la infraestructura y de
los servicios de TI, y la capacidad máxima de cada
componente
■■ Realizar el dimensionamiento de todos los servicios y
sistemas nuevos propuestos, posiblemente utilizando
técnicas de modelado, para determinar los requisitos
de capacidad
■■ Prever los futuros requisitos de capacidad
basándose en planes de negocio, tendencias de uso,
dimensionamiento de nuevos servicios, etc.
■■ Elaboración y revisión regular del Plan de Capacidad,
en línea con el ciclo de planificación del negocio
de la organización, identificando el uso actual y los
requisitos previstos en el periodo que abarque el plan
■■ Garantizar que se establezcan los niveles apropiados
de monitorización de los recursos y del rendimiento
del sistema
■■ Análisis de los datos de uso y rendimiento, e informar
sobre el rendimiento respecto a los objetivos
contenidos en los SLAs
■■ Crear incidencias y problemas cuando se detecten
incumplimientos de la capacidad o de los umbrales
de rendimiento, y ayudar con la investigación y
diagnóstico de aquellos asociados con la capacidad
■■ Identificar e iniciar cualquier ajuste a realizar para
optimizar y mejorar la capacidad o rendimiento
■■ Identificar e implementar iniciativas para mejorar el
uso de los recursos, por ejemplo, técnicas de gestión
de la demanda
■■ Evaluar las nuevas tecnologías y su relevancia para la
organización en términos de rendimiento y coste
■■ Conocer la posible demanda de servicios de TI y
evaluarla en los niveles de rendimiento del servicio
■■ Garantizar que se evalúen todos los cambios con
respecto a su impacto en la capacidad y rendimiento
y asistir a reuniones del CAB si fuera oportuno
■■ Elaborar informes regulares de gestión que incluyan el
uso actual de recursos, tendencias y previsiones
■■ Dimensionar todos los servicios y sistemas nuevos
propuestos para determinar los recursos informáticos
y de red requeridos para establecer la utilización
del hardware, niveles de servicio de rendimiento e
implicaciones de costes
22/1/10 13:50:57

■■ Evaluar nuevas técnicas y productos de hardware y
software que podría utilizar Gestión de la Capacidad
para mejorar la eficiencia y eficacia del proceso
■■ Realizar pruebas de los nuevos servicios y sistemas
■■ Elaborar informes de rendimiento del servicio y de los
componentes con respecto a los objetivos contenidos
en SLAs
■■ Disponer de un conocimiento de la futura demanda
de servicios de TI y predecir los efectos de la demanda
en los niveles de rendimiento del servicio
■■ Determinar los niveles de rendimiento del servicio que
pueden mantenerse y están justificados en costes
■■ Recomendar ajustes de servicios y sistemas, y hacer
recomendaciones de uso y diseño de los sistemas a
gestión de TI para ayudar a asegurar el uso óptimo de
todos los recursos de hardware y software de sistema
operativo
■■ Actuar como un punto de encuentro principal para
todos los aspectos de capacidad y rendimiento.
6.4.10  Gestor de la Seguridad
El Gestor de la Seguridad es responsable de garantizar que
se cumplan los objetivos de Gestión de la Seguridad de la
Información. Esto incluye tareas y responsabilidades tales
como:
■■ Desarrollar y mantener la política de Seguridad de
la Información y un conjunto de políticas específicas
de soporte, asegurando la autorización, compromiso
y respaldo apropiados de la dirección de TI y del
negocio
■■ Comunicar y publicitar la política de Seguridad de la
Información a todas las partes correspondientes
■■ Garantizar que se aplique y cumpla la política de
Seguridad de la Información
■■ Identificar y clasificar los activos de TI y de la
información (Elementos de Configuración) y el nivel de
control y protección requerido
■■ Ayudar con el Análisis de Impacto del Negocio
■■ Llevar a cabo el Análisis de Riesgo de Seguridad
y la gestión del riesgo, junto con Gestión de la
Disponibilidad y Gestión de la Continuidad del
Negocio
■■ Diseñar controles de seguridad y desarrollar planes de
seguridad
■■ Desarrollar y documentar procedimientos para operar
y mantener controles de seguridad
■■ Monitorizar y gestionar todos los incumplimientos
de seguridad y tratar las incidencias de seguridad,
tomando todas las acciones correctivas necesarias para
evitar su repetición siempre que sea posible
824_007 Chapter 06.indd 211
Organización del Diseñ̃o del Servicio | 211
■■ Informar, analizar y reducir el impacto y nivel de
afectación de todas las incidencias de seguridad junto
con Gestión de Problemas
■■ Promover la educación y concienciación sobre la
seguridad
■■ Mantener un conjunto de controles y documentos de
seguridad, y revisar y auditar regularmente todos los
procedimientos y controles de seguridad
■■ Garantizar que se evalúen todos los cambios con
respecto a su impacto en todos los aspectos de
seguridad, incluyendo la Política Seguridad de la
Información y controles de seguridad y asistir a
reuniones del CAB si fuera oportuno
■■ Realizar pruebas de seguridad
■■ Participar en cualquier revisión de seguridad que surja
por incumplimientos de la seguridad y promover
acciones correctivas
■■ Garantizar que se mantenga la confidencialidad,
integridad y disponibilidad de los servicios en los
niveles acordados en los SLAs y que estén conformes
con todos los requisitos reglamentarios aplicables
■■ Garantizar que todo el acceso a los servicios por parte
de socios y suministradores externos esté sujeto a
acuerdos y responsabilidades contractuales
■■ Actuar como un punto de encuentro principal para
todos los aspectos de la seguridad.
6.4.11  Gestor de Suministradores
El Gestor de Suministradores tiene la responsabilidad de
garantizar que se cumplan los objetivos de Gestión de
Suministradores. Esto incluye tareas como:
■■ Proporcionar ayuda en el desarrollo y revisión de SLAs,
contratos, acuerdos o de cualquier otro documento
relacionado con proveedores externos
■■ Asegurar que se obtiene un coste adecuado a los
beneficios en todos los contratos y suministradores
de TI
■■ segurar que todos los procesos del suministrador de TI
sean consistentes y son coherente con las estrategias,
procesos y términos y condiciones estándar
corporativos del suministrador
■■ Mantener y revisar una Base de Datos de Contratos y
Proveedores (SCD)
■■ Revisión y Análisis de Riesgo rutinarios de todos los
suministradores y contratos
■■ Asegurar que cualquier contrato de soporte, acuerdo o
SLA desarrollado se alinee con los del negocio
■■ Asegurar que todos los servicios de soporte se acoten
y documenten y que los interfaces y dependencias
22/1/10 13:50:57
 212 | Organización del Diseñ̃o del Servicio

entre suministradores, servicios de soporte y procesos

de suministradores se acuerden y documenten
■■ Asegurar que todos los roles y relaciones entre
suministradores principales y subcontratados se
documenten, mantengan y estén sujetos al acuerdo
contractual
■■ Revisar los procesos de los suministradores principales
para garantizar que cualquier suministrador
subcontratado cumpla sus obligaciones contractuales
■■ Realizar revisiones de contratos y SLAs al menos
anualmente, y garantizar que todos los contratos sean
consistentes con los requisitos organizativos y con
los términos y condiciones estándar siempre que sea
posible
■■ Actualizar contratos y SLAs siempre que se requiera,
asegurando que se siga el proceso de Gestión de
Cambios
■■ Mantener un proceso para abordar disputas
contractuales, y garantizar que cualquier disputa se
aborde de manera eficaz y eficiente
■■ Mantener un proceso para abordar el final esperado,
final anticipado o transferencia de un servicio
■■ Monitorizar, comunicar y revisar regularmente el
rendimiento del suministrador con respecto a los
objetivos, identificando acciones de mejora cuando
sea apropiado y asegurando la implementación de
estas acciones
■■ Garantizar que se evalúen los cambios con respecto a
su impacto en los suministradores, servicios de soporte
y contratos, y asistir a las reuniones del CAB si fuera
oportuno
■■ Coordinar y dar soporte a todos los gestores de
contratos y de suministradores de TI garantizando
que cada suministrador/contrato tenga asignado un
propietario dentro de la organización del proveedor
de servicio.

824_007 Chapter 06.indd 212 22/1/10 13:50:57

824_008 Chapter 07.indd 213
Consideraciones sobre
la tecnología 7
22/1/10 13:51:38
824_008 Chapter 07.indd 214 22/1/10 13:51:38
 7 Consideraciones sobre la tecnología
Se reconoce de forma generalizada que el uso de
herramientas de Gestión del Servicio es fundamental
para el éxito de todas las implementaciones de los
procesos excepto para aquellas que sean muy limitadas.
Sin embargo, es importante que la herramienta que
se esté utilizando dé soporte a los procesos, y no al
revés. Como regla general, no se deben modificar los
procesos para adecuarlos a la herramienta. Sin embargo,
al utilizar herramientas para dar soporte a los procesos,
es necesario ser pragmáticos y reconocer que puede que
no haya una herramienta que dé soporte completamente
al proceso diseñado, por lo que podría ser necesario
rediseñar algunos elementos del proceso. No se deben
limitar los requisitos de funcionalidad sino considerar
la capacidad del producto para asumir el aumento del
tamaño de las bases de datos, la recuperación de errores
y el mantenimiento de la integridad de los datos. Hay
que tener en cuenta si l producto está conforme con los
estándares internacionales y si es suficientemente eficiente
para permitirle cumplir los Requisitos de Gestión del
Servicio.
En muchas ocasiones las organizaciones creen que
simplemente con la compra y desarrollo de una
herramienta se resolverán todos sus problemas, y es
fácil olvidar que todavía dependemos del proceso, de la
función, y lo más importante, de las personas. Recuerde:
‘un tonto con una herramienta sigue siendo un tonto’
7.1  Herramientas de Diseño del
Servicio
Existen muchas herramientas y técnicas que se pueden
utilizar para ayudar con el diseño de servicios y sus
componentes asociados. Estas herramientas y técnicas
permiten:
■■ Diseño del hardware
■■ Diseño del software
■■ Diseño del entorno
■■ Diseño del proceso
■■ Diseño de datos.
Las herramientas y técnicas son numerosas y diversas,
incluyendo aquellas propietarias y no propietarias, y son
útiles para:
824_008 Chapter 07.indd 215
■■ Acelerar el proceso de diseño
■■ Asegurar que se sigan los estándares y convenciones
■■ Ofrecer prototipos, modelado y funcionalidades de
simulación
■■ Permitir examinar escenarios y responder a preguntas
tipo ¿Qué ocurre si?’
■■ Permitir que se comprueben y asocien interfaces y
dependencias
■■ Validar los diseños antes de que se desarrollen e
implementen para garantizar que satisfagan y cumplan
sus requisitos previstos
El desarrollo de los Diseños del Servicio se puede
simplificar utilizando herramientas que proporcionen
vistas gráficas del servicio y de sus componentes, desde
los procesos de negocio, a través del servicio y SLA, hasta
la infraestructura, entorno, datos y aplicaciones, procesos,
OLAs, equipos, contratos y suministradores. Algunas
herramientas de Gestión de la Configuración proporcionan
tales funcionalidades, y algunas veces se hace referencia
a ellas como un elemento de las herramientas de
Gestión del Servicio de Negocio (BSM). Pueden contener
o estar vinculadas a herramientas y mecanismos de
‘auto-descubrimiento’ y permiten la representación
gráfica de las relaciones entre todos estos elementos,
proporcionando la capacidad de realizar cambios rápidos
dentro de cada componente y obtener información
detallada si fuera necesario.
Si estos tipos de herramientas también contuvieran
información financiera, y se vincularan con un ‘Árbol
de Métricas’ que proporcionara KPIs y métricas de los
diferentes aspectos del servicio, entonces el servicio se
podrá monitorizar y gestionar a través de todas las etapas
del su ciclo de vida. Compartir este conjunto único y
centralizado de datos del servicio permite a todos los
miembros de la organización del proveedor de servicio y
del negocio acceder a una vista real, única y consistente
del servicio y de su rendimiento, y proporciona una
base sólida para el desarrollo de buenas relaciones y
colaboraciones entre el proveedor de servicio y sus
clientes.
Estos tipos de herramientas no sólo facilitan los procesos
de diseño, sino que también dan soporte y ayudan en
todas las etapas del Ciclo de Vida del Servicio, incluyendo:
22/1/10 13:51:38
 216 | Consideraciones sobre la tecnología
■■ Gestión de todas las etapas del Ciclo de Vida del
Servicio
■■ Todos los aspectos del servicio y de su rendimiento
■■ Medición, comunicación y gestión de los logros del
servicio, SLA, OLA, contratos y suministradores
■■ Métricas consolidadas y árboles de métricas que
pueden consultarse desde paneles de control
de gestión hasta información detallada de los
componentes, rendimiento y análisis e identificación
de fallos
■■ Vistas consistentes y consolidadas a través de todos
los procesos, sistemas, tecnologías y grupos
■■ Relaciones e integración del negocio y de sus
procesos con servicios, sistemas y procesos de TI
■■ Un conjunto integral de funcionalidades de búsqueda
e información, lo que permite obtener información
precisa y el análisis para llevar a cabo una toma de
decisiones informada
■■ Gestión de los costes del servicio
■■ Gestión de las relaciones, interfaces e
interdependencias
■■ Gestión del Porfolio de Servicios y Catálogo de
Servicios
■■ Una Gestión de la Configuración (CMS)
■■ Un Sistema de Gestión del Conocimiento del Servicio
(SKMS).
Las siguientes actividades genéricas serán necesarias para
implementar tal metodología:
■■ Establecer el ciclo de vida genérico de los activos
de TI (Requisitos, Diseño y Desarrollo, Construcción,
Prueba, Despliegue, Operación y Optimización
y Eliminación) y definir los procesos, políticas,
actividades y tecnologías principales dentro de cada
etapa del ciclo de vida para cada tipo de activo
■■ Formalizar las relaciones entre diferentes tipos de
activos de TI, y la relación entre la adquisición y
gestión de activos de TI y otras disciplinas de TI
■■ Definir todos los roles y responsabilidades implicados
en las actividades de gestión de los activos de TI
■■ Establecer medidas que permitan comprender el Coste
(Total) de Propiedad de un servicio de TI
■■ Establecer políticas para la reutilización de los activos
de TI a través de los servicios, por ejemplo, en el
ámbito corporativo
■■ Definir una estrategia para la adquisición y gestión de
activos de TI, incluyendo la forma en la que se alinea
con otras estrategias del negocio y de TI.
Adicionalmente, para el tipo de activo de aplicaciones:
824_008 Chapter 07.indd 216
■■ Definir una estrategia para la adquisición y gestión
de activos de TI, incluyendo cómo se alinea con otras
estrategias del negocio y de TI
■■ Documentar el rol desempeñado por las aplicaciones
en la entrega de servicios de TI al negocio
■■ Garantizar que el modelo de ciclo de vida genérico
de los activos de TI se adapte al ciclo de vida de
las aplicaciones, y se ajuste a los diferentes tipos de
aplicaciones
■■ Establecer estándares para el uso de diferentes
métodos para desarrollar aplicaciones e identificar
el rol de las metodologías de desarrollo, incluyendo
aquellas basadas en la reutilización (vea la sección
Diseño y Desarrollo para disponer de más detalles)
■■ Garantizar que se apliquen procedimientos que
consideren todos los tipos de requisitos (como por
ejemplo, operatividad, rendimiento del servicio,
capacidad de mantenimiento y seguridad) en las
primeras etapas del desarrollo de aplicaciones
■■ Establecer estándares para decidir la forma óptima
de proveer las aplicaciones a la organización, como
por ejemplo el uso de proveedores de Servicios
de Aplicación, desarrollos personalizados, COTS y
personalización de paquetes.
Adicionalmente, para el tipo de activos de datos/
información:
■■ Establecer cómo los principios generales de
adquisición y gestión de activos de TI pueden ayudar
a gestionar los recursos de datos/información de una
organización.
Garantizar que los diseños de datos se aborden en función
de:
■■ La importancia de metadatos estandarizados y
reutilizables
■■ Las necesidades de calidad de los datos
■■ El valor de los datos para una organización
■■ Las necesidades de administración de los datos y
habilidades de administración de bases de datos
■■ Entender el área objeto ‘corporativa’ (o común/
cooperativa) y las vistas de datos de los servicios
individuales (‘sistema’)
■■ La necesidad de gestionar datos de tipos de datos no
tradicionales como texto, imágenes escaneadas, vídeo
y audio
■■ Concienciación sobre los problemas más importantes
de almacenamiento, seguridad y legales relacionados
con los datos
22/1/10 13:51:38

■■ Especificar cómo se puede adaptar el modelo genérico
de ciclo de vida de los activos de TI con el tipo de
activo de datos.
Adicionalmente, para la infraestructura de TI y tipo de
activo del entorno:
■■ Establecer estándares para la adquisición y gestión
de los equipos de entorno e infraestructura de TI
(incluyendo hardware, alimentación, software O/S,
software dbms, middleware y redes), y asegurar que
proporcionen una base estable aunque adaptable que
apoye la provisión al negocio de servicios de TI
■■ Establecer cómo se debe adaptar el modelo genérico
de ciclo de vida de los activos de TI al ciclo de vida
de la infraestructura de TI
■■ Establecer actividades para optimizar el uso de activos
de la infraestructura de TI a través de su reutilización
■■ Especificar la necesidad de herramientas y describir
cómo su uso e integración generales ayudan a la
gestión de una infraestructura de TI eficaz y asociada
con los servicios.
Adicionalmente, para las habilidades (personas,
competencias):
■■ Formalizar cómo las competencias de los individuos
responsables de los activos de TI y asociadas con los
servicios se pueden considerar como un activo dentro
de la organización, y cómo se gestionan como tales
■■ Especificar cómo se aplica el ciclo de vida de
los activos de TI a los activos de las personas,
particularmente en términos de competencias
medibles, como habilidades, conocimiento,
entendimiento, cualificaciones, experiencia, actitud y
comportamiento
■■ Asegurar la documentación de las competencias
aplicadas actualmente y especificar cómo éstas se
pueden reutilizar y mejorar
■■ Garantizar que los estándares de la organización
sean compatibles con los marcos de trabajo de
competencias estándares existentes para el sector de
TI, por ejemplo, cómo las habilidades y competencias
SFIA+ (Habilidades Para la Era de la Información) se
incorporan en roles y responsabilidades.
Además, para establecer interfaces y dependencias
eficaces:
■■ Definir las interfaces que tiene la gestión y adquisición
de activos de TI con el Cambio del Negocio facilitado
por TI, Gestión de Proyectos de TI y Seguridad de TI
■■ Formalizar las interfaces que tienen la adquisición y
gestión de activos de TI con funciones y procesos
fuera de TI
824_008 Chapter 07.indd 217
Consideraciones sobre la tecnología | 217
■■ Formalizar finalmente la gestión y la comunicación en
este área:
●● Identificando métricas adecuadas y los informes
sobre los activos de TI para la distribución a través
de la organización
●● Formalizar la medida y control de calidad en la
adquisición y gestión de activos de TI.
7.2  Herramientas de Gestión del
Servicio
Las herramientas permiten que los procesos de Diseño
del Servicio funcionen más eficazmente. Las herramientas
aumentan la eficiencia y eficacia, y proporcionan
una riqueza de información de gestión que conduce
a la identificación de las áreas con debilidades. Los
beneficios a largo plazo que se pueden obtener del uso
de herramientas son ahorros de costes y una mayor
productividad, que a su vez pueden conducir a un
incremento de la calidad de la provisión del servicio de TI.
El uso de herramientas permite la centralización de los
procesos clave y la automatización e integración de los
procesos principales de Gestión de Servicio. Los datos
sin procesar recopilados por las herramientas se podrán
analizar para identificar las ‘tendencias’. Con ello se podrán
implementar medidas preventivas, mejorando nuevamente
la calidad de la provisión del servicio de TI.
Algunos puntos que deben considerar las organizaciones
al evaluar las herramientas de Gestión del Servicio
incluyen:
■■ Estructura, tratamiento e integración de los datos
■■ Integración de componentes de infraestructuras
multi proveedor, y la necesidad de absorber nuevos
componentes en el futuro. Éllo determinará requisitos
particulares en las capacidades de modelado y manejo
de datos de la herramienta
■■ Conformidad con estándares internacionales
■■ Flexibilidad en la implementación, uso y distribución
de datos
■■ Usabilidad – la facilidad de uso que permite la interfaz
de usuario
■■ Soporte para monitorizar los niveles de servicio
■■ Clientes distribuidos con una base de datos
compartida centralizada (por ejemplo, servidor cliente)
■■ Requisitos de conversión para datos rastreados
previamente
■■ Backup, control y seguridad de los datos
■■ Opciones de soporte proporcionadas por el proveedor
de herramientas
22/1/10 13:51:38
 218 | Consideraciones sobre la tecnología
■■ Escalabilidad en el aumento de la capacidad (el
número de usuarios, volumen de datos, etc.).
Deben considerarse los requisitos exactos que se requieren
de la herramienta. ¿Cuáles son los requisitos obligatorios
y cuáles son los requisitos deseados? Normalmente, la
herramienta debe dar soporte a los procesos, y no al revés,
para minimizar la modificación de los procesos a los que
ajustar la herramienta. Si fuera posible, es mejor adquirir
una herramienta totalmente integrada (aunque no a costa
de la eficacia y eficiencia) para dar apoyo a muchos (si no
a todos) los procesos de Gestión del Servicio. Si esto no
fuera posible, deben tenerse en cuenta los interfaces entre
las diferentes herramientas.
Es fundamental tener una Declaración de requisitos
(SoR) para su uso durante el proceso de selección.
Esta declaración se puede utilizar como una ‘lista de
verificación’. Los requisitos de la herramienta deben
clasificarse por categorías utilizando el análisis MoSCoW:
■■ M – Debe (Must) tener esto
■■ S – Debería (Should) tener esto si fuera posible
■■ C – Podría (Could) tener esto si no afectara a nada
más
■■ W – No lo tendrá (Won't) en este momento pero
podría requerirse en el futuro.
La herramienta debe ser adecuadamente flexible para
dar soporte a sus derechos de acceso. Debe ser capaz de
determinar a quién se le permite el acceso a qué datos y
para qué propósito, por ejemplo, acceso de lectura a los
clientes.
En las primeras etapas, debe tenerse en cuenta la
plataforma en la que se espera que opere la herramienta,
es decir, en hardware o software existentes o en una
nueva compra. Podrían existir restricciones derivadas de la
estrategia de TI, por ejemplo, todos los nuevos productos
tienen que residir en servidores específicos. Esto podría
restringir los productos que podrían incluirse en el proceso
de evaluación. Asegúrese de que la compra se ajuste a los
presupuestos aprobados actuales.
Existen muchas herramientas de Gestión del Servicio.
Se puede encontrar información de ellas en Internet,
publicaciones de Gestión del Servicio, solicitando
información a organizaciones o consultores o asistiendo
a seminarios y conferencias para ver qué productos hay
disponibles en el mercado.
Durante las primeras etapas del proceso de selección, es
necesario reflexionar sobre la credibilidad del proveedor
y de la herramienta. ¿Seguirán dando soporte a la
herramienta comprada en los próximos meses o en el
plazo de un año? Hay que considerar el historial del
824_008 Chapter 07.indd 218
suministrador y de la herramienta. Llame por teléfono al
Centro de Servicio al Usuario del suministrador para ver la
facilidad de acceder al mismo, y realice algunas preguntas
de prueba para evaluar su competencia técnica. Solicite
al proveedor acordar una visita a un emplazamiento
de referencia para ver in situ la experiencia con la
herramienta, y si fuera posible, sin que esté presente
el proveedor o suministrador. Asegúrese de que la
organización tenga requisitos similares de la herramienta.
Vea la herramienta en funcionamiento y hable con los
usuarios sobre sus experiencias, iniciales y posteriores.
Evalúe las necesidades de formación de la organización y
la capacidad del suministrador a la hora de proporcionar
la formación adecuada. También será necesario evaluar la
formación continua y la actualización de la herramienta
(actualizaciones y cambios en los requisitos del usuario)
para determinar los costes de soporte y formación. En
particular, considere los costes de formación, ubicación de
la formación, tiempo requerido, cuánto tiempo se tardará
en estar en uso la herramienta después de la formación;
y durante el proyecto de implementación, asegure que
proporciona información suficiente. Piense sobre cómo
impactará la nueva herramienta en TI y en el consumidor.
Asegúrese también de que los interfaces con las demás
herramientas y con la telefonía estén funcionando
correctamente. Es aconsejable identificar si se ha estado
utilizando (o intentando utilizar) la solución planificada en
algún otro sitio y con qué resultados. Considere periodos
de operación solapada con las soluciones existentes antes
de la entrada en producción.
Al evaluar las herramientas, no debe esperarse que
la herramienta a seleccionar se ajuste al 100% a los
requisitos, y casi con toda seguridad no podrá encontrarse
ninguna que lo haga totalmente. En lugar de ello,
debe aplicarse la ‘regla 80/20’. Se considera que una
herramienta se ajusta a su propósito si cumple el 80% o
más de los requisitos operativos del negocio. Como se
analizó anteriormente, esos requisitos operativos deben
clasificarse por categorías.
Cualquier producto debe rechazarse como inadecuado si
no se cumplieran todos los requisitos obligatorios (‘debe
tener’). En algunas circunstancias, será imposible encontrar
un producto de software existente que cumpla todos los
requisitos obligatorios o alcance el 80% . En esta situación,
debe seleccionarse el producto que ofrezca el mejor
diseño funcional y reescribir los elementos inadecuados.
Si fuera posible, el proveedor debe realizar este proceso
de mejora. En algunos casos, el comprador puede asumir
parte de los costes de mejora. Algunos productos se han
diseñado para incluir puntos de codigo modificables
que proporcionan accesibilidad al código escrito en
22/1/10 13:51:38

¿Qué requisitos?
Evaluar productos
Identificar productos
Elaboración de la
lista corta
Criterios de selección
Figura 7.1  Proceso de evaluación de herramientas de Gestión del Servicio
puntos procedimentales clave, sin la necesidad de que se
modifique el paquete.
La selección del producto no termina el proceso. En
muchos casos puede considerarse sólo el principio.
A partir de ese momento la herramienta tiene que
implementarse. Una vez se haya preparado la plataforma
hardware y se haya cargado el software, será necesario
considerar la introducción de los datos. ¿Qué, desde
dónde, cómo y cuándo? La programación es importante
para la prueba, implementación y aplicación de los
procesos. Los recursos deben estar disponibles para
garantizar el éxito. En otras palabras, no programe la
implementación durante un periodo de alta ocupación
conocido, como el procesamiento de finales de año.
En la actualidad se dispone de productos de ‘software
como un servicio’ si no se requiere hardware ni software.
Estos productos ofrecen gestión y acceso, basado en
redes, de software disponible comercialmente. Estos
tipos de productos todavía requerirán planificación e
implementación, aunque esto debe simplificar el proceso
ya que no se requiere hardware dedicado.
Deben analizarse los proveedores de servicios y los
proveedores de Servicios de Aplicaciones gestionados, por
si pudieran proporcionar la misma funcionalidad.
Independientemente de la herramienta elegida, el
cumplimiento de los requisitos se puede diferenciar entre:
■■ Listo para implementar – se cumple el requisito
■■ Configuración – la herramienta se puede configurar
para cumplir el requisito en x días de esfuerzo y ello
se preservará durante las actualizaciones del producto
824_008 Chapter 07.indd 219
Consideraciones sobre la tecnología | 219
Calificación
Clasificación de
los productos
Seleccionar producto
■■ Personalización – será necesario un esfuerzo de
x días de reprogramación de la herramienta para
cumplir el requisito, y ello podría tener que repetirse
en todas las actualizaciones del producto.
Siempre se evita la personalización excesiva de cualquier
producto debido a los altos costes de la actualización
del producto. Los proveedores podrían ser reacios a dar
soporte a entregas antiguas, y los compradores podrían
ser incapaces de ofrecer las aplicaciones necesarias
para cualquier personalización diseñada a medida. La
personalización también puede liberar al proveedor
de muchas de sus obligaciones de soporte. Esto sería
desastroso si, como resultado de ello, el sistema de
Gestión del Servicio no estuviera disponible durante un
largo periodo de tiempo. También se incurriría en costes
posteriores a la hora de proporcionar formación diseñada
a medida. Sería imposible beneficiarse de cualquier
curso de formación de bajo precio programado que esté
impartiendo el suministrador de software.
El proceso de evaluación de herramientas se muestra en la
Figura 7.1.
La Figura 7.1 muestra el método estándar de identificación
de requisitos antes de identificar los productos, aunque
podría haber algún elemento solapado, en el que la
exploración de herramientas del mercado permite darse
cuenta de nuevas opciones que pueden convertirse en
requisitos. Estas etapas se orientan principalmente a la
evaluación de productos de software comercial, aunque
también podría utilizarse un método similar para evaluar
software hecho a medida. Genere una Declaración de
22/1/10 13:51:39
 220 | Consideraciones sobre la tecnología

Requisitos (SoR) clara que identifique los requisitos de

negocio junto con las funcionalidades obligatorias y
aquellas funcionalidades que sería bueno tener. Además,
identifique las políticas y estándares del emplazamiento
con los que debe estar conforme el producto. Tales
estándares podrían incluir su ejecución sobre algún
software de sistema particular o sobre hardware específico.
Recuerde las consideraciones sobre la idoneidad del
suministrador, y realice una evaluación formal de los
productos en consideración.
Si se utilizaran herramientas bien desarrolladas y
apropiadas para dar soporte a los procesos, los resultados
logrados serán mucho mejores y en muchas ocasiones se
reducirán los costes generales de la provisión del servicio.
La selección de la herramienta correcta implica prestar
atención a varios aspectos:
■■ Un 80% de ajuste a los requisitos funcionales y
técnicos
■■ Un cumplimiento de TODOS los requisitos obligatorios
■■ Se requiere una pequeña (si hubiera) personalización
del producto
■■ Cumplimiento por parte de la herramienta y del
suministrador de la mejor práctica de Gestión del
Servicio
■■ Manejo y estructura adecuados de los datos
■■ Integración con otras herramientas de Gestión del
Servicio y de Gestión Operativa
■■ Soporte de interfaces y estándares abiertos
■■ Orientada al negocio y no a la tecnología
■■ Costes de administración y mantenimiento dentro del
presupuesto
■■ Niveles aceptables de mantenimiento y políticas de la
entrega
■■ Seguridad e integridad
■■ Disponibilidad de servicios de formación y consultoría
■■ Generación de informes adecuados
■■ Escalabilidad y crecimiento.

824_008 Chapter 07.indd 220 22/1/10 13:51:39

824_009 Chapter 08.indd 221
Implementación de
Diseñ̃o del Servicio 8
22/1/10 13:52:24
824_009 Chapter 08.indd 222 22/1/10 13:52:24
 8 Implementación de Diseño del Servicio
Esta sección considera la tarea de implementar los
procesos de Diseño del Servicio y afronta aspectos como
los siguientes:
■■ ¿Dónde comenzamos?
■■ ¿Cómo mejoramos?
■■ ¿Cómo sabemos que estamos llevando a cabo el
proceso?
Es necesario que las actividades de implementación
y mejora de Diseño del Servicio se centren en las
necesidades y deseos del cliente y del negocio. Por lo
tanto, estas actividades deben dirigirse y priorizarse
mediante:
■■ Necesidades del negocio e impactos en el negocio
■■ Riesgos para los servicios y procesos.
Las actividades se verán influenciadas significativamente
por los requisitos descritos en los SLR y por los acuerdos
establecidos en los SLA.
8.1  Análisis de Impacto en el Negocio
Una fuente valiosa de información al intentar determinar
las necesidades, impactos y riesgos del negocio es el
Análisis de Impacto en el Negocio (BIA). El BIA es un
elemento fundamental del proceso general de continuidad
del negocio (vea la sección 4.7) y dictará la estrategia para
la reducción del riesgo y recuperación de desastres. Su
propósito es identificar el efecto que un desastre tendría
en el negocio. Mostrará las partes de la organización que
se verán más afectadas por una incidencia importante
y qué efecto tendrá en toda la empresa. Por lo tanto,
permite el reconocimiento de las funciones de negocio
más críticas para la supervivencia de la compañía y si esta
criticidad difiere dependiendo de la hora del día, semana,
mes y año. Adicionalmente, la experiencia ha demostrado
que los resultados del BIA pueden ser una información
extremadamente útil para otras áreas, y proporcionará un
entendimiento mucho mayor del servicio.
El BIA podría dividirse en dos áreas:
■■ Una relaciónada con la gestión del negocio, que tiene
que investigar el impacto de la pérdida (o pérdida
parcial) de un proceso o función de negocio. Esto
incluye el conocimiento de soluciones provisionales
manuales y su coste.
824_009 Chapter 08.indd 223
■■ Un segunda área incluida en Gestión del Servicio
que es esencial para impedir los efectos negativos en
el negocio de la pérdida de servicio. Este elemento
del BIA muestra el impacto para el negocio de la
interrupción del servicio. Los servicios se pueden
gestionar y verse influenciados por la Gestión del
Servicio. Otros aspectos también recogidos en ‘BIA
para el Negocio’ no pueden verse influidos por la
Gestión del Servicio.
Como parte de la fase de diseño de un servicio nuevo o
modificado, debe realizarse un BIA para ayudar a definir
la estrategia de continuidad del servicio y para permitir
un mayor entendimiento de la función e importancia del
servicio. Esto permitirá a la organización definir:
■■ Cuáles son los servicios críticos, qué constituye una
incidencia importante en estos servicios, y el impacto
e interrupción provocados en el negocio, lo que es
importante para decidir cuándo y cómo implementar
los cambios
■■ Niveles aceptables y tiempos de los niveles de parada
del servicio - nuevamente importante para considerar
las planificaciones de cambios e implementaciones
■■ Periodos críticos del servicio y del negocio – periodos
importantes a evitar
■■ El coste de la pérdida de servicio – importante para
Gestión Financiera
■■ Las posibles implicaciones en la seguridad de una
pérdida de servicio – consideraciones importantes en
la gestión del riesgo.
8.2  Requerimientos de Nivel de
Servicio
Como parte del proceso Gestión del Nivel de Servicio
(vea el Capítulo 4), se establecerán los Requerimientos
de Nivel de Servicio para todos los servicios, se evaluará
la capacidad de satisfacer estos requisitos y finalmente
se acordarán en un SLA formal. Para nuevos servicios, los
requisitos deben establecerse al comienzo del proceso
de desarrollo, no después de su finalización. Desde una
perspectiva de Diseño del Servicio, es fundamental tener
en cuenta los Requerimientos de Nivel de Servicio para
construir el servicio.
22/1/10 13:52:24
 224 | Implementación de Diseñ̃o del Servicio
8.3  Riesgos para los servicios y
procesos
Al implementar los procesos de Diseño del Servicio e
ITSM, las prácticas habituales del negocio no deben verse
afectadas negativamente. Este aspecto debe considerarse
durante la producción y selección de la solución preferida
para garantizar la mínima interrupción de los servicios
operativos. Esta evaluación del riesgo debe considerarse
con detalle en las actividades de Transición del Servicio
como parte del proceso de implementación.
8.4  Implementación de Diseño del
Servicio
Es necesario documentar y utilizar el proceso, política y
arquitectura del diseño de servicios de TI incluidos en
esta publicación para garantizar que se puedan diseñar e
implementar servicios de TI innovadores con el objetivo
de cumplir los requisitos de negocio acordados actuales y
futuros.
También será necesario implementar los procesos de
Gestión del Servicio de TI incluidos en el Capítulo 4 de
esta publicación y en otras publicaciones de esta serie
para garantizar que la entrega del servicio se corresponda
con los requisitos del servicio.
La pregunta que con frecuencia se realiza es ‘¿Qué
proceso debo implementar primero?’. La respuesta real
es todos ellos, ya que el valor real de la implementación
de todos los procesos de Gestión del Servicio es mucho
mayor que la suma de los procesos individuales. Todos los
procesos se interrelacionan y en algunos casos dependen
totalmente de los demás. Lo que se requiere en última
instancia es un conjunto único e integrado de procesos
que proporcione la gestión y control de un conjunto de
servicios de TI a través de todo su ciclo de vida.
Reconociendo que para obtener todo el beneficio de la
implementación de Gestión del Servicio de TI es necesario
abordar todos los procesos, también se reconoce que es
improbable que las organizaciones puedan hacer todo a la
vez. Por lo tanto, se recomienda abordar primero las áreas
de mayor necesidad. Es necesario realizar una evaluación
detallada para determinar las fortalezas y debilidades de la
provisión del servicio de TI. Esto debe realizarse llevando
a cabo encuestas de satisfacción del cliente, hablando
con clientes, hablando con el personal de TI y analizando
los procesos que se están aplicando. A partir de esta
evaluación, se pueden desarrollar estrategias de corto,
medio y largo plazo.
Podría ocurrir que fuera necesario implementar acciones
de mejora a corto plazo para mejorar la situación actual,
824_009 Chapter 08.indd 224
aunque estos procesos mejorados podrían tener que
descartarse o modificarse como parte de las estrategias
de medio o largo plazo. Si se implementaran éxitos a
corto plazo, es importante que no se realicen a costa
de los objetivos a largo plazo, por lo que éstos deben
considerarse en todo momento. Sin embargo, toda
organización tendrá que comenzar en algún punto, y el
punto de inicio será aquel en el que se encuentre ahora
la organización en términos de madurez de Gestión del
Servicio de TI.
Deben establecerse prioridades de implementación con
respecto a los objetivos de un SIP. Por ejemplo, si la
viabilidad de los servicios de TI fuera un aspecto crítico,
el enfoque en esos procesos debe orientarse a maximizar
la disponibilidad (por ejemplo, Gestión de Incidencias,
Gestión de Problemas, Gestión de Cambios y Gestión de la
Disponibilidad). A través del proceso de implementación,
los participantes clave deben estar implicados en el
proceso de toma de decisiones. En éstos se incluirán
receptores y proveedores del servicio. Puede producirse
la tendencia, al analizar las áreas de mayor necesidad,
de adquirir herramientas para mejorar la situación.
Las reuniones de trabajo o grupos de interés serán
beneficiosas para entender los requisitos y el proceso más
adecuado de implementación que incluirá a personas,
procesos, productos y socios.
La primera cosa que se hará es establecer un proceso y
método formales de implementación y mejora de Diseño
del Servicio, con la aplicación del gobierno apropiado.
Este proceso formal debe basarse en el proceso de seis
etapas que se ilustra en la Figura 8.1. También se puede
encontrar más información sobre este proceso en la
publicación Mejora Continua del Servicio.
Es importante que al implementar o mejorar los
procesos se utilice un método estructurado de Gestión
de Proyectos. El proceso de mejora se puede concretar
primero entendiendo la visión, mediante la determinación
de los objetivos de negocio de alto nivel. Debe
establecerse la visión y alinear el negocio y las estrategias
de TI. Segundo, debe evaluarse la situación actual para
identificar las fortalezas sobre las que se pueda construir
y las debilidades que sea necesario abordar. Por lo tanto
‘¿Dónde estamos ahora?’ representa un análisis de la
posición actual en términos del negocio, organización,
personas y proceso. Tercero, ‘¿Dónde queremos estar?’
se corresponde con un desarrollo de los principios
definidos en el establecimiento de la visión, acordando
las prioridades de mejora, y cuarto, detallando el SIP
para lograr la provisión de un servicio de mayor calidad.
A continuación, es necesario aplicar medidas y métricas
para demostrar que se han logrado los hitos y que se
22/1/10 13:52:24
 Implementación de Diseñ̃o del Servicio | 225

1. ¿Cuál es Objetivos de negocio

la visión? de alto nivel

2. ¿Dónde Evaluaciones,
estamos? benchmarks

3. ¿Dónde Objetivos
queremos estar? medibles
6. ¿Cómo
continuamos?

4. ¿Cómo Mejora de
llegamos? procesos

5. ¿Cómo
podemos saber que Medidas y
lo conseguimos? métricas

Figura 8.1  Ciclo de implementación/mejora

han cumplido los objetivos y prioridades del negocio.
Finalmente, el proceso debe asegurar que se mantenga la
mejora de la calidad.
A continuación se incluyen los elementos clave para
lograr un alineamiento de TI exitoso con los objetivos de
negocio:
■■ Visión y liderazgo a la hora de establecer y mantener
la dirección estratégica, objetivos claros, y la medición
del logro de los objetivos en términos de dirección
estratégica
■■ Aceptación de la innovación y de nuevas formas de
trabajo
■■ Entendimiento concienzudo del negocio, sus
interesados y su entorno
■■ El entendimiento del personal de TI de las necesidades
del negocio
■■ El entendimiento del negocio del potencial de TI
■■ Información y comunicación disponibles y accesibles
para todo el que lo necesite
■■ Tiempo asignado para familiarizarse con el material
■■ Rastreo continuo de tecnologías para identificar
oportunidades para el negocio.
El ciclo de implementación/mejora es útil para comprobar
el alineamiento entre el negocio y TI, como se muestra en
la Figura 8.1.
8.4.1  ¿Cuál es la visión?
El punto de inicio para todas estas actividades es la cultura
y entorno de la organización del proveedor de servicio.
Las personas y la cultura tienen que ser apropiadas y
aceptables para la mejora y el cambio. Por lo tanto, antes
de intentar alguna cosa más, es necesario revisar la cultura
del proveedor de servicio para garantizar que acepte
y facilite la implementación de las mejoras y cambios
requeridos. Es necesario completar los siguientes pasos
clave para llevar a cabo esta etapa del ciclo:
■■ Establecer una visión, alineada con la visión y
objetivos del negocio
■■ Establecer el ámbito del proyecto/programa
■■ Establecer un conjunto de objetivos de alto nivel
■■ Establecer el gobierno, patrocinio y presupuesto

824_009 Chapter 08.indd 225 22/1/10 13:52:25

 226 | Implementación de Diseñ̃o del Servicio

■■ Obtener el compromiso de la gestión senior Oportunidades (DAFO)

■■ Establecer una cultura centrada en: ●● Una metodología de evaluación y gestión del
●● La calidad riesgo
●● El enfoque en el cliente y en el negocio ■■ La revisión debe incluir:
●● Un entorno de aprendizaje ●● La cultura y madurez de la organización del
●● La mejora continua proveedor de servicio
●● El compromiso con el ‘ciclo de mejora’ ●● Los procesos aplicados y su capacidad y madurez

●● La propiedad y responsabilidad. ●● Las habilidades y competencia de las personas

●● Los servicios y tecnología
8.4.2  ¿Dónde estamos ahora? ●● Los suministradores, contratos y su capacidad

Una vez definida la visión y los objetivos de alto nivel,
es necesario que el proveedor de servicio revise la
situación actual, en términos de los procesos que se están
aplicando y de la madurez de la organización. Los pasos y
actividades que es necesario completar aquí son:
■■ Una revisión, evaluación o una auditoría más formal
de la situación actual, utilizando una técnica elegida:
●● Una revisión o auditoría interna
●● Evaluación de la madurez
●● Una evaluación externa o benchmark
●● Una auditoría de ISO/IEC 20000
●● Una auditoría con respecto a COBIT
●● Un análisis de Debilidades, Amenazas, Fortalezas y
Madurez de la organización de TI
●● La calidad del servicio y las medidas, métricas y
KPIs actuales
●● Un informe que resuma las conclusiones y
recomendaciones.
La revisión de la cultura debe incluir la evaluación en
términos de la capacidad y madurez de la cultura dentro
de la organización del proveedor de servicio de TI, como
se muestra en la Figura 8.2.
Esta evaluación debe basarse en el hecho de que cada
etapa de crecimiento representa una transformación de la
organización de TI que requerirá:
■■ Cambios en las personas (habilidades y competencias)
■■ Proceso y formas de trabajo

Cadena
de valor

Negocio

Cliente

Producto/servicio

Tecnología

Influencia en el negocio
Figura 8.2  Evaluación de la madurez cultural

824_009 Chapter 08.indd 226 22/1/10 13:52:25


Madurez del proceso
3 Definido
2 Repetible
1 Inicial
Figura 8.3  Marco de trabajo de madurez del proceso
■■ Tecnología y herramientas (para dar soporte y
facilidades a personas y procesos)
■■ Dirección (las visiones, objetivos y resultados)
■■ Actitud (los valores y creencias)
■■ El nivel apropiado y grado de interacción con el
negocio, interesados, clientes y usuarios.
La evaluación también debe incluir una revisión de la
capacidad y madurez de los procesos de Diseño del
Servicio, como se muestra en la Figura 8.3.
Esta revisión deberá incluir todos los aspectos de los
procesos y su uso, incluyendo:
■■ Visión: dirección, objetivos y planes
■■ Madurez, funcionalidad, uso, aplicación, eficacia y
eficiencia del proceso junto con la propiedad, gestión
y documentación
■■ Personas: los roles, responsabilidades, habilidades y
conocimiento de las personas
■■ Productos, incluyendo las herramientas y tecnología
utilizadas para automatizar los procesos
■■ Cultura: el enfoque, actitudes y creencias.
El marco de trabajo anterior se puede utilizar para
proporcionar consistencia a la evaluación del proceso. La
evaluación de estos dos aspectos determinará el estado
actual de la organización y su capacidad y madurez de
Gestión del Servicio. Al comenzar la implementación o
824_009 Chapter 08.indd 227
Implementación de Diseñ̃o del Servicio | 227
5 Optimizar
4 Gestionado
mejora de Diseño del Servicio, o de cualquier conjunto de
procesos, es importante construir sobre las fortalezas de
las culturas y procesos existentes e identificar y mejorar
rápidamente las debilidades. En el Apéndice H se incluye
una descripción más detallada de este marco de trabajo.
8.4.3  ¿Dónde deseamos estar?
Basándose en la evaluación del estado actual y en la
visión y objetivos de alto nivel, se podrá definir un futuro
estado deseado. Esto debe expresarse en términos de
resultados planificados, incluyendo algunos o todos los
siguientes:
■■ Mejora del alineamiento de la provisión del servicio de
TI con los requisitos de negocio
■■ Mejora de la calidad de Diseño del Servicio
■■ Mejoras en los niveles de servicio y de la calidad
■■ Aumento de la satisfacción del cliente
■■ Mejoras en el rendimiento del proceso.
8.4.4  ¿Cómo llegamos hasta allí?
Debe identificarse un conjunto de mejoras para pasar del
estado actual hasta el futuro estado acordado. Es necesario
desarrollar un plan para implementar estas mejoras,
incorporando Transición del Servicio y Operación del
Servicio, y debe incluir:
22/1/10 13:52:25
 228 | Implementación de Diseñ̃o del Servicio
■■ Las acciones de mejora
■■ La metodología que se adoptará y los métodos que se
utilizarán
■■ Actividades y plazos de tiempo
■■ Evaluación y gestión del riesgo
■■ Recursos y presupuestos
■■ Roles y responsabilidades
■■ Monitorización, medida y revisión.
8.4.5  ¿Cómo podemos decir que hemos
llegado allí?
En muchas ocasiones las organizaciones impulsan
iniciativas de mejora sin considerar o diseñar el sistema
de medición desde el principio. Sin embargo, el éxito
de la iniciativa no se puede determinar porque no
tenemos una comparativa antes, durante y después de la
implementación. Es fundamental que las mediciones se
diseñen antes de la implementación. Es necesario utilizar
un conjunto definido de métricas para garantizar que se
logre el estado futuro objetivo. Es necesario expresar este
futuro estado deseado en términos medibles, como por
ejemplo:
■■ X% de reducción de las disconformidades de Diseño
del Servicio
■■ X% de aumento de la satisfacción del cliente
■■ X% de incremento de la disponibilidad de servicios
críticos
Por lo tanto, una vez se hayan completado los planes y
acciones de mejora, deben realizarse comprobaciones y
revisiones para determinar si:
■■ ¿Hemos logrado nuestro nuevo estado deseado y los
objetivos?
■■ ¿Existe alguna lección aprendida y podríamos hacerlo
mejor la próxima vez?
■■ ¿Hemos identificado alguna otra acción de mejora?
8.4.6  ¿Cómo continuamos?
Después de la mejora, ahora necesitamos consolidarnos
y avanzar. La organización y la cultura deben reconocer
que siempre podemos estar mejor, y por lo tanto deben
establecer un entorno de mejora continua. Por lo tanto,
una vez se haya logrado el nuevo estado deseado,
debemos revisar la visión y objetivos, identificar más
acciones de mejora y repetir nuevamente el proceso de
seis etapas. Por lo tanto, en esta etapa se trata de:
■■ Desarrollar un entorno de aprendizaje
■■ Establecer un deseo de mejora a través de la
organización
824_009 Chapter 08.indd 228
■■ Reconocer y reforzar el mensaje de que la calidad y
mejora representan un trabajo de todos
■■ Mantener la continuidad de la mejora y de la calidad.
8.5  Medición de Diseño del Servicio
Es necesario medir el éxito del Diseño del Servicio y el
éxito de la mejora de los procesos que rodean al Diseño
del Servicio, analizar los datos, e informar de los mismos.
Si el diseño o proceso no cumpliera los requisitos del
negocio en su totalidad, podrían requerirse cambios en el
proceso. Ademán, también deben medirse los resultados
de dichos cambios. La medición, análisis e comunicación
continuas son requisitos obligatorios para el proceso de
Diseño del Servicio y para los procesos de ITSM.
Existen métodos de medida disponibles que permiten
el análisis de la mejora del servicio. El Cuadro de Mando
Integral es un método desarrollado por Robert Kaplan y
David Norton como un medio para medir las actividades
de una empresa en términos de su visión y estrategias.
Proporciona una visión integral del rendimiento de un
negocio. El sistema fuerza a los gestores a centrarse en
las métricas importantes de rendimiento que impulsan
el éxito. Equilibra una perspectiva financiera con las
perspectivas del cliente, proceso interno, aprendizaje y
crecimiento. Puede encontrar más información sobre el
método de Cuadro de Mando Integral en la publicación
Mejora Continua del Servicio.
Six Sigma es una metodología desarrollada por Bill Smith
en Motorola Inc. en 1986, y originalmente se diseñó para
gestionar variaciones del proceso que provocan defectos,
definidos como una desviación inaceptable del medio u
objetivo, y para gestionar sistemáticamente la variación
con el fin de eliminar dichos efectos. Six Sigma ha ido
más allá del control de defectos y en muchas ocasiones se
utiliza para medir la mejora en la ejecución del proceso.
(Six Sigma es una marca de servicio registrada y marca
comercial de Motorola Inc.)
Six Sigma (DMADV) es un sistema de mejora que se utiliza
para desarrollar nuevos procesos a niveles de calidad Six
Sigma y se define como:
■■ Definir – definir formalmente los objetivos de la
actividad de diseño para que sean consistentes con
las demandas del cliente y con la estrategia de la
organización
■■ Medir – identificar Factores Críticos de Éxito,
capacidades, capacidad del proceso y evaluación del
riesgo
22/1/10 13:52:25

■■ Analizar – desarrollar y diseñar alternativas, crear
un diseño de alto nivel y evaluar su capacidad, para
seleccionar el mejor diseño
■■ Diseñar – desarrollar un diseño detallado, optimizar el
diseño y plan para la verificación del diseño
■■ Verificar – establecer ejecuciones piloto, implementar
el proceso de producción y transferencia a los
propietarios del proceso.
El proceso Six Sigma (DMAIC) (definir, medir, analizar,
mejorar, controlar) es un sistema de mejora de
procesos existentes que se comportan¡ por debajo de la
especificación y que busca una mejora incremental.
8.5.1 Prerrequisitos para el éxito
Existen varios prerrequisitos que se requieren para el
Diseño del Servicio y para el éxito de la introducción de
procesos nuevos o revisión de los mismos. En muchas
ocasiones estos prerrequisitos para el éxito (PFS) son
elementos de un proceso que requiere otro proceso.
Por ejemplo, se requiere un Catálogo de Servicios del
Negocio y un Catálogo de Servicios Técnicos totalmente
completos y actualizados antes de que la Gestión del
Nivel de Servicio pueda diseñar el SLA y dar soporte a la
estructura acordada, y antes de que SLM pueda establecer
y acordar los SLAs. Gestión de Problemas dependerá de
un proceso de Gestión de Incidencias maduro. Los PFS
pueden ser mucho más amplios que únicamente las
interdependencias del proceso de ITSM. Por ejemplo, el
diseño de la disponibilidad y de la capacidad para un
servicio nuevo no se puede lograrse sin la información
del plan de negocio que describe la utilización del nuevo
servicio. El diseño del servicio será imposible de realizar
sin el Porfolio de Servicios y sin el Paquete de Transición
del Servicio. Existen muchos más ejemplos de estos PFS
que es necesario considerar y planificar antes de que se
puedan lograr altos niveles de madurez del proceso. La
baja madurez de un proceso implicará que no se pueden
alcanzar altos niveles de madurez en otros procesos.
8.5.2  Factores Críticos de Éxito e Indicadores
Clave de Rendimiento
Factor Crítico de Éxito (CSF) es un término para un
elemento que es necesario para que una organización o
proyecto logre su misión. Los CSF se pueden utilizar como
un medio para identificar los elementos importantes de
éxito.
Los CSF son los aspectos que tienen que ir bien en el
Diseño del Servicio y dentro de cada proceso de ITSM.
Los Indicadores Clave de Rendimiento (KPIs) son medidas
que cuantifican objetivos y permiten la medida del
824_009 Chapter 08.indd 229
Implementación de Diseñ̃o del Servicio | 229
rendimiento. Los KPI deben establecerse y medirse con
respecto al diseño de cada uno de los procesos para
garantizar que se cumplan los CSF. Juntos, los CSF y KPI,
establecen la línea de referencia y los mecanismos para
hacer un seguimiento del rendimiento.
Se recomienda que cada organización de TI se centre
en un subconjunto pequeño de CSFs y KPIs en cada
momento. Los CSF y KPIs requeridos deben establecerse al
comienzo del Plan de Mejora Continua del Servicio (CSIP).
Es importante que los CSF se acuerden durante la fase
de diseño de un servicio o de los procesos, y que se
establezcan, midan y se informe de los Indicadores
Clave de Rendimiento (KPIs) que indique la calidad
del Diseño del Servicio y de los procesos de Diseño del
Servicio. Existe un requisito para poder analizar el grado
de adecuación con el que se diseñó la infraestructura del
servicio. Es posible llegar a un buen diseño utilizando
recursos muy ineficientemente y viceversa, por lo que
necesitamos examinar el nivel la calidad y los recursos
requeridos para lograr la calidad requerida. Los KIP
relacionados con el éxito de la provisón del servicio
indican la eficacia del Diseño del Servicio, por ejemplo,
¿el servicio cumple los requisitos de negocio (definidos)
para la disponibilidad, fiabilidad, rendimiento, seguridad,
capacidad de mantenimiento, capacidad de dar servicio,
funcionalidad, etc.? Sin embargo, los KPI relacionados con
las estimaciones de recursos nos mostrarán el grado de
eficiencia del diseño.
Éstos deben definirse como parte de la planificación de
QA y de la aceptación de la entrega. Estos KPI pueden
estar apoyados por métricas similares de componentes.
Los KPI para el proceso de Diseño del Servicio incluyen:
■■ Porcentaje de especificaciones de requisitos de
Diseño del Servicio generadas a tiempo (y dentro del
presupuesto)
■■ Porcentaje de planes de Diseño del Servicio generados
a tiempo
■■ Porcentaje de paquetes de Transición del Servicio
completados a tiempo
■■ Porcentaje de planes de criterios de QA y de
aceptación generados a tiempo
■■ Precisión de Diseño del Servicio – por ejemplo, ¿se
construyó la infraestructura correcta para dar soporte
al servicio?
■■ Porcentaje de precisión de la estimación de costes de
toda la fase de Diseño del Servicio
■■ Precisión de SLAs, OLAs y contratos – ¿dan soporte
realmente al nivel requerido de servicio?
22/1/10 13:52:26
 230 | Implementación de Diseñ̃o del Servicio

Para juzgar la provisión del servicio y el rendimiento del

proceso de ITSM, deben establecerse objetivos claramente
definidos y medibles. Es necesario buscar la confirmación
de que se han alcanzafdo estos objetivos e hitos
establecidos en la etapa de Mejora Continua del Servicio
(CSI) del ciclo de vida y que se ha logrado la calidad
deseada del servicio o la mejora deseada de la calidad. Al
diseñar servicios y procesos, es muy importante que se
diseñen KPIs desde cero y que se recopilen regularmente
y en hitos importantes. Por ejemplo, al diseñar después
de la finalización de cada etapa significativa del programa,
debe realizarse una Revisión Post Implementación (PIR)
para garantizar que se hayan cumplido los objetivos. La
PIR incluirá una revisión de la documentación de respaldo
y de la concienciación general entre el personal de los
procesos refinados.
Es necesario comparar lo que se ha conseguido con las
metas originales establecidas en el proyecto. Una vez se
haya confirmado, deben definirse nuevos objetivos de
mejora. Para confirmar que se han alcanzado los hitos, es
necesario monitorizar constantemente los KPI. Estos KPI
incluyen objetivos de satisfacción del cliente, por lo que
será necesario estudiar a los clientes de forma planificada
en varias etapas para confirmar que los cambios realizados
están mejorando la percepción del cliente con respecto a
la calidad del servicio. Es posible que los servicios tengan
mayor disponibilidad, que hayan menos incidencias y
que se hayan mejorado los tiempos de respuesta, pero
al mismo tiempo no se haya mejorado la percepción del
cliente con respecto a la calidad del servicio. Obviamente,
esto es muy importante, y será necesario abordarlo
hablando con los clientes para determinar sus inquietudes.
Será necesario buscar la confirmación de que los CSI
aplicados estén abordando las necesidades principales del
cliente.
Para disponer de más información sobre las prácticas
de mejora del servicio, consulte la publicación Mejora
Continua del Servicio.

824_009 Chapter 08.indd 230 22/1/10 13:52:26

 Desafíos, Factores Críticos
de Éxito y riesgos

824_010 Chapter 09.indd 231

9
22/1/10 13:53:25
824_010 Chapter 09.indd 232 22/1/10 13:53:25
 9 Desafíos, Factores Críticos de Éxito  
y riesgos
9.1  Desafíos
En todo cometido que se emprenda existirán desafíos y
dificultades que afrontar y superar. Esto será especialmente
cierto al intentar diseñar nuevos servicios y procesos que
cumplan los requisitos de todos los interesados dentro
del negocio. La experiencia ha demostrado que lo que se
indica a continuación ayudará a superar los desafíos:
■■ Entender los requisitos y prioridades de negocio
y garantizar que éstos estén siempre presentes al
diseñar los procesos y servicios.
■■ Las comunicaciones serán de vital importancia a la
hora de definir lo que está pasando y cómo se verán
afectados los individuos, y a la hora de tener en
cuenta los requisitos y necesidades de los individuos.
Es de vital importancia comunicarse con las personas
respecto a las inquietudes que asocidada a su trabajo
diario.
■■ Implicar en el diseño al mayor número de personas
posible. El establecimiento de grupos de interés o
grupos de dirección puede ser muy eficaz a la hora de
obtener la solución correcta y obtener un apoyo más
amplio.
■■ Lograr el compromiso de la dirección y de todos los
niveles del personal.
Algunos ejemplos de desafíos que se podrían afrontar
incluyen:
■■ La necesidad de garantizar el alineamiento con las
directrices, estrategia y políticas actuales en relación
con la arquitectura. Un ejemplo de esto podría ser
que la infraestructura adquirida tuviera funcionalidades
deficientes de monitorización y control.
■■ El uso de tecnologías y aplicaciones diversas y
dispares.
■■ Documentación y cumplimiento de prácticas y
procesos acordados.
■■ Requisitos poco claros o cambiantes por parte
del negocio. Esto podría ser inevitable en algunos
casos debido a que las necesidades del negocio
probablemente cambiarán. Lo más importante es
garantizar que haya una relación muy estrecha entre
la organización del proveedor de servicios de TI y el
cliente de negocio del servicio, para que se pueda
824_010 Chapter 09.indd 233
identificar cualquier requisito de cambio lo más
rápidamente posible.
■■ Una falta de concienciación y conocimiento del
servicio y de los objetivos y requisitos de negocio.
■■ Vinculado con el punto anterior, podría ocurrir que
ciertas funcionalidades no estuvieran integradas dentro
del diseño. Una vez más, es fundamental que los
representantes de los usuarios del servicio o proceso
diseñado se impliquen durante todo el proceso para
reducir la posibilidad de que esto se produzca. En la
publicación Transición del Servicio se incluyen detalles
de las pruebas del servicio (un elemento importante
aquí).
■■ Una resistencia a la planificación, o una falta de
planificación, lo que conduce a iniciativas y compras
sin planificar.
■■ Uso ineficiente de recursos que provocan gastos e
inversiones desaprovechados.
■■ Como se mencionó previamente, es fundamental un
buen conocimiento y apreciación de los impactos y
prioridades del negocio.
■■ Las relaciones y comunicaciones deficientes o falta
de cooperación entre el proveedor de servicios de TI
y el negocio podrían hacer que el diseño no logre
satisfacer los requisitos de negocio.
■■ Resistencia a trabajar de acuerdo a la estrategia
acordada.
■■ Uso de, y, por lo tanto, restricciones de tecnología
antigua y sistemas heredados.
■■ Las herramientas requeridas son demasiado costosas
o demasiado complejas para implementarlas o
mantenerlas con las habilidades actuales del personal.
■■ Falta de motivación, monitorización y medidas.
■■ Objetivos y plazos de tiempo poco razonables
acordados previamente en los SLAs y OLAs.
■■ Compromiso excesivo de recursos disponibles con una
incapacidad asociada para proporcionar la entrega
(por ejemplo, proyectos que siempre se retrasan o que
exceden el presupuesto).
■■ Gestión de suministradores deficiente y/o rendimiento
deficiente del suministrador.
■■ Falta de enfoque en la disponibilidad del servicio.
22/1/10 13:53:25
 234 | Desafíos, Factores Críticos de Éxito y riesgos

■■ Falta de concienciación y cumplimiento de los ■■ No se da suficiente tiempo a la fase de diseño, o no

aspectos operativos de procedimientos y políticas de
seguridad.
■■ Asegurar que la operación diaria normal o el negocio
habitual se considera como parte del diseño.
■■ Restricciones de costes y presupuestarias.
■■ Determinación del ROI y la materialización del
beneficio para el negocio.
se ha proporcionado suficiente formación al personal
implicado en el diseño.
■■ l No se tiene suficiente compromiso con el desarrollo
funcional de la aplicación, lo que implica que no se
preste suficiente atención a los requisitos de Diseño
del Servicio.

9.2  Riesgos
Existen diversos riesgos asociados directamente con la fase
de Diseño del Servicio del Ciclo de Vida del Servicio. Es
necesario identificar estos riesgos para garantizar que no
se materialicen. Éstos incluyen:
■■ Si no se cumplen algunos de los PFS para Diseño del
Servicio, entonces el proceso de Diseño del Servicio y
de Gestión del Servicio no será satisfactorio.
■■ Si los niveles de madurez de un proceso son bajos,
será imposible lograr la madurez total de otros
procesos.
■■ Los requisitos de negocio no están claros para el
personal de TI.
■■ Los plazos de tiempo son tales que no se da tiempo
suficiente para lograr el Diseño del Servicio apropiado.
■■ La insuficiencia de las pruebas generan un diseño
deficiente y, en consecuencia, una implementación
deficiente.
■■ Se genera un equilibrio incorrecto entre innovación,
riesgo y coste mientras se busca una ventaja
competitiva.
■■ El ajuste entre infraestructuras, clientes y socios no
es suficiente para cumplir los requisitos generales de
negocio.
■■ No se provee una interfaz coordinada entre
planificadores de TI y planificadores del negocio.
■■ Las políticas y estrategias, especialmente la estrategia
de Gestión del Servicio, no están disponibles a partir
de la Estrategia del Servicio, o su contenido no se
entiende claramente.
■■ No hay suficientes recursos y presupuesto disponibles
para las actividades de Diseño del Servicio.
■■ El riesgo de los servicios desarrollados aisladamente
que utilizan sus ‘propios’ activos e infraestructura. Esto
puede parecer más barato, pero puede ser mucho
más costoso a largo plazo debido a los ahorros
financieros de las compras corporativas y al coste
adicional a la hora de dar soporte a una arquitectura
diferente.

824_010 Chapter 09.indd 234 22/1/10 13:53:25

 Epílogo

824_011 Epilogo.indd 235 22/1/10 13:54:12

824_011 Epilogo.indd 236 22/1/10 13:54:12
 Epílogo
El diseño del Servicio, como se describe en esta Esta publicación explica que el pragmatismo algunas
publicación, cubre el diseño de servicios de TI adecuados veces anula la solución perfecta si sabemos cuál debería
e innovadores para satisfacer los requisitos de negocio ser, aunque el nivel de esfuerzo y de coste no justifique
acordados actuales y futuros. El Diseño del Servicio dicha solución. Como siempre, esto dependerá de las
desarrolla un Paquete de Diseño del Servicio y determina necesidades y requisitos de negocio. Como siempre, es
su modelo más. En esta publicación también hemos fundamental que cualquier cosa que se haga dentro de TI
examinado los diferentes modelos de aprovisionamiento tenga un beneficio directo para el negocio en general.
disponibles y se han indicado algunos beneficios y
desventajas de cada uno.
Esta publicación también analiza los fundamentos de los
procesos de diseño y los cinco aspectos del diseño:
■■ El diseño de las soluciones de los servicios, que
incluye los requisitos funcionales, recursos y
capacidades necesarios y acordados
■■ El diseño de sistemas y herramientas de Gestión del
Servicio, especialmente el Porfolio de Servicios, para la
gestión y control de servicios a lo largo de su ciclo de
vida
■■ El diseño de las arquitecturas tecnológicas y
arquitecturas de gestión requeridas para proveer los
servicios
■■ El diseño o especificación de los procesos necesarios
para el diseño, transición, operación y mejora de los
servicios, las arquitecturas y los propios procesos
■■ El diseño de sistemas de medida, métodos y métricas
de los servicios, las arquitecturas, sus componentes y
los procesos.
La definición de Diseño del Servicio es:

‘El diseño de servicios de TI adecuados e innovadores,

incluyendo sus arquitecturas, procesos, políticas y
documentación, para satisfacer los requisitos de
negocio acordados actuales y futuros’.

La publicación ha explicado que mientras más preciso sea

el diseño, se logrará una solución mejor para su puesta
en operación. También es muy probable que mientras
mejor sea el diseño, menos tiempo de remodelación será
necesario durante las fases de transición y producción.
El ámbito de esta publicación incluye el diseño de
servicios, y el diseño de sistemas y procesos de Gestión
del Servicio. El Diseño del Servicio no está limitado a
nuevos servicios, aunque incluye el cambio necesario para
aumentar o mantener el valor para los clientes sobre el
ciclo de vida de los servicios.

824_011 Epilogo.indd 237 22/1/10 13:54:12

824_011 Epilogo.indd 238 22/1/10 13:54:13
 Apéndice A:
El Paquete de Diseñ̃o
del Servicio

824_012 Apend A.indd 239 22/1/10 13:54:42

824_012 Apend A.indd 240 22/1/10 13:54:42
 | 241

Apéndice A: El Paquete de Diseño del Servicio

Durante la etapa de diseño debe generarse un ‘Paquete

de Diseño del Servicio’ o SDP para cada nuevo servicio,
cambio importante o retirada de un servicio o cambios en
el propio ‘Paquete de Diseño del Servicio’. Este paquete
pasa de Diseño del Servicio a Transición del Servicio y
detalla los aspectos del servicio y de sus requisitos a través
de las etapas posteriores de su ciclo de vida. El SDP debe
contener:

Tabla A.1  Contenido del Paquete de Diseño del Servicio

Categoría Subcategoría Descripción de lo que se incluye en el SDP
Requisitos Requisitos de negocio Los requisitos de negocio iniciales acordados y documentados
Aplicabilidad del servicio Define cómo y dónde se usaría el servicio. Podría hacer referencia a los
usuarios del negocio, cliente y usuarios de servicios internos
Contactos del Servicio Los contactos del negocio, contactos del cliente e interesados en el
servicio
Disen~o del Servicio Requisitos funcionales del servicio La funcionalidad modificada del servicio nuevo o modificado, incluyendo
sus resultados y entregables planificados en una Declaración de requisitos
(SoR) acordada formalmente
Requerimientos de Nivel de Servicio El SLR, SLA nuevo o revisado, incluyendo objetivos del servicio y de
calidad
Requisitos de gestión operativos y del Requisitos de gestión para gestionar el servicio nuevo o modificado y sus
servicio componentes, incluyendo los servicios y acuerdos de soporte, control,
operación, monitorización, medida e comunicación
Disen~o del Servicio y topología ■■ El disen~o, transición y posterior implementación y operación de la
solución del servicio y de sus componentes de soporte, incluyendo:
■■ La definición del servicio y modelo, para transición y operación
■■ Los componentes e infraestructura del servicio (incluyendo H/W,
S/W, redes, entornos, datos, aplicaciones, tecnología, herramientas,
documentación), incluyendo números de versión y relaciones,
preferiblemente dentro del CMS
■■ Toda la documentación del usuario, negocio, servicio, componente,
transición, soporte y operativa
■■ Procesos, procedimientos, medidas, métricas e informes
■■ Productos, servicios, acuerdos y suministradores de soporte
Evaluación de la Evaluación de la predisposición Plan e informe de ‘Evaluación de la Predisposición Organizativa’,
predisposición organizativa incluyendo: beneficio para el negocio, evaluación financiera, evaluación
organizativa técnica, evaluación de recursos y evaluación organizativa, junto con
detalles de todas las nuevas habilidades, competencias, capacidades
requeridas de la organización del proveedor de servicio, sus
suministradores, servicios de soporte y contratos

824_012 Apend A.indd 241 22/1/10 13:54:42

 242 | Apéndice A: El Paquete de Diseñ̃o del Servicio

Categoría Subcategoría Descripción de lo que se incluye en el SDP

Plan del Ciclo de Vida Programa del Servicio
del Servicio
Plan de Transición del Servicio
Un programa o plan general que cubre todas las etapas del ciclo de
vida del servicio, incluyendo las escalas de tiempo y las fases, para la
transición, operación y posterior mejora del nuevo servicio, incluyendo:
■■ Gestión, coordinación e integración con cualquier otro proyecto, o
actividades, servicios o procesos nuevos o modificados
■■ Gestión de riesgos o problemas
■■ Ámbito, objetivos y componentes del servicio
■■ Habilidades, competencias, roles y responsabilidades
■■ Procesos requeridos
■■ Interfaces y dependencias con otros servicios
■■ Gestión de equipos, recursos, herramientas, tecnología, presupuestos
e instalaciones
■■ Gestión de suministradores y contratos
■■ Informes del progreso, revisiones y revisión del programa y de los
planes
■■ Planes de comunicación y planes de formación
■■ Escalas de tiempo, entregables, metas y objetivos de calidad para
cada etapa
Estrategia general de transición, objetivos, política, evaluación del riesgo
y planes, incluyendo:
■■ Política, planes y requisitos de construcción, incluyendo planes
de construcción del servicio y componentes, especificaciones,
control y entornos, tecnología, herramientas, procesos, métodos y
mecanismos, incluyendo plataformas
■■ Política, planes y requisitos de las pruebas, incluyendo entornos de
pruebas, tecnología, herramientas, procesos, métodos y mecanismos
■■ Las pruebas deben incluir:
■■ Pruebas funcionales
■■ Pruebas de componentes incluyendo a todos los suministradores,
contratos y productos y servicios de soporte suministrados
externamente
■■ Aceptación del usuario y pruebas de usabilidad
■■ Pruebas de integración y compatibilidad con el sistema
■■ Pruebas de rendimiento y capacidad del servicio y de los
componentes
■■ Pruebas de capacidad de recuperación y continuidad
■■ Categorización de fallos, alarmas y eventos, procesamiento y
prueba
■■ Pruebas de seguridad e integridad del servicio y componentes
■■ Pruebas de logística, entrega y distribución
■■ Pruebas de gestión, incluyendo el control, monitorización,
medida y comunicación, junto con backup, recuperación y toda
la programación y procesamiento por lotes

824_012 Apend A.indd 242 22/1/10 13:54:42

 Apéndice A: El Paquete de Diseñ̃o del Servicio | 243

Categoría Subcategoría Descripción de lo que se incluye en el SDP

Plan de Aceptación Operativa del
Servicio
Criterios de Aceptación del Servicio
■■ Política de despliegue, política de la entrega, planes y requisitos,
incluyendo logística, despliegue, lanzamiento, presentación,
entornos de despliegue, cambio cultural, cambio organizativo,
tecnología, herramientas, procesos, metodología, métodos y
mecanismos, incluyendo todas las plataformas, conocimiento,
transferencia y desarrollo de habilidades y competencias, transición
de suministrador y contrato, migración de datos y conversión
Estrategia operativa general, objetivos, política, evaluación del riesgo y
planes, incluyendo:
■■ Gestión y planificación de la interfaz y de la dependencia
■■ Eventos, informes, aspectos del servicio, incluyendo todos los
cambios, entregas, incidencias resueltas, problemas y errores
conocidos, incluidos dentro del servicio y cualquier error, problema o
disconformidad dentro del nuevo servicio
■■ Aceptación final del servicio
Desarrollo y uso de Criterios de Aceptación del Servicio (SAC) para
su progresión a lo largo de cada etapa del Ciclo de Vida del Servicio,
incluyendo:
■■ Todos los entornos
■■ Periodos y criterios de garantía y piloto

824_012 Apend A.indd 243 22/1/10 13:54:42

824_012 Apend A.indd 244 22/1/10 13:54:43
 Apéndice B:
Criterios de Aceptación
del Servicio (ejemplo)

824_013 Apend B.indd 245 22/1/10 13:55:07

824_013 Apend B.indd 246 22/1/10 13:55:07
 | 247

Apéndice B: Criterios de Aceptación del

Servicio (ejemplo
Los Criterios de Aceptación del Servicio (SAC) representan
un conjunto de criterios que sirven para garantizar que
el servicio cumpla su funcionalidad y calidad esperadas y
que el proveedor de servicio esté preparado para entregar
el nuevo servicio una vez haya sido desplegado.

Tabla B.1  Criterio de Aceptación del Servicio

Criterios Responsabilidad
¿Se han acordado la fecha de ‘lanzamiento’ y el período de garantía con todas las partes interesadas, Cambios, Nivel de servicio
junto con los criterios de aceptación finales?
¿Se han acordado y documentado el proyecto de despliegue y la programación y se han hecho Cambios, Incidencias
públicos a todo el personal afectado?
¿Se ha revisado, repasado y acordado el SLA/SLR con todas las partes interesadas? Nivel de servicio
¿Se ha introducido/actualizado el servicio en el Catálogo de Servicios/Porfolio de Servicios dentro del Nivel de servicio, Configuración
CMS y se han establecido las relaciones apropiadas para todos los componentes de soporte?
¿Se han identificado a todos los clientes e interesados y se han registrado en el CMS? Nivel de servicio, Relaciones con
el Negocio
¿Se han evaluado todos los riesgos operativos asociados con la operación del nuevo servicio y se han Continuidad del Negocio,
completado las acciones de mitigación en caso necesario? Disponibilidad
¿Se han probado satisfactoriamente las medidas de contingencia y de recuperación de errores y se han Continuidad del Negocio,
an~adido al plan de prueba general de capacidad de recuperación? Disponibilidad
¿Se pueden monitorizar, medir, informar, revisar todos los objetivos del SLA/SLR incluyendo la Nivel de servicio, Disponibilidad
disponibilidad y rendimiento?
¿Se han identificado/aprobado a todos los usuarios y sus cuentas correspondientes creadas para ellos? Gestión de Cuentas
¿Se pueden medir todas las características de carga de trabajo y objetivos de capacidad y rendimiento, Capacidad
y se han incorporado en los Planes de Capacidad?
¿Se han acordado, probado, documentado y aceptado todos los procesos operativos, programaciones Operaciones, Continuidad del
y procedimientos (por ejemplo, documentación del emplazamiento, backups, mantenimiento, archivo, Negocio
retención)?
¿Se han acordado, probado, documentado y aceptado todos los trabajos por lotes y requisitos de Operaciones
impresión?
¿Se han completado satisfactoriamente todos los planes de prueba? Gestor de Pruebas
¿Se han completado satisfactoriamente todas comprobaciones y pruebas de seguridad? Conformidad con la Seguridad
¿Se han aplicado procedimientos y herramientas apropiadas de monitorización y medida para Gestión de Sistemas
monitorizar el nuevo servicio, junto con turnos de soporte fuera del horario normal?
¿Se han identificado y aprobado todos los costes y cargas de trabajo operativos continuos? Operaciones, Finanzas de TI
¿Se entienden todos los costes operativos del servicio y de los componentes y se han incorporado en Finanzas de TI
procesos financieros y en el modelo de costes?
¿Se han revisado y repasado las categorías y procesos de incidencias y problemas para el nuevo Informes de Incidencias,
servicio, junto con cualquier error o deficiencia conocidos? Problemas
¿Se han identificado a todos los nuevos suministradores y se han establecido adecuadamente sus Gestión de Contratos y
contratos asociados? Suministradores

824_013 Apend B.indd 247 22/1/10 13:55:07

 248 | Apéndice B: Criterios de Aceptación del Servicio (ejemplo)

Criterios Responsabilidad
¿Se han revisado y repasado todos los acuerdos de soporte – SLAs, SLRs, OLAs y contratos acordados, Gestor de Proyecto
y todos los equipos han aceptado la documentación correspondiente (incluyendo suministradores,
equipos de soporte, Gestión de Suministradores, equipos de desarrollo y soporte de aplicaciones)?
¿Incidencias, Problemas y todos los equipos de soporte de TI han proporcionado y aceptado la Incidencias, Problemas
documentación de soporte técnico?
¿Se han autorizado y actualizado todas las RFCS y Registros de Entrega? Cambios
¿Se han introducido en el CMS todos los detalles del servicio, SLA, SLR, OLA y contratos, junto con Gestión del Proyecto, Equipos
todas las aplicaciones y detalles de los componentes de la infraestructura? de Soporte, Configuración
¿Se han comprado las licencias de SW apropiadas o se han reasignado las licencias utilizadas? Configuración
¿Se ha almacenado algún nuevo componente de HW en la DL con los detalles registrados en el CMS? Configuración
¿Se han registrado todos los nuevos componentes de SW en la DL y se han registrado sus detalles en el Configuración
CMS?
¿Se han acordado todos los planes de mantenimiento y actualización, junto con políticas, frecuencias y Entrega y Despliegue
mecanismos de la entrega?
¿Se ha formado a todos los usuarios, y se ha aceptado la documentación de los usuarios y se ha Gestor de Proyecto
suministrado a todos ellos?
¿Se han documentado, acordado y apoyado todas las relaciones, interfaces y dependencias con otros Gestor de Proyecto
sistemas y servicios externos o internos?
¿Los gestores de negocio correspondientes han firmado la aceptación del nuevo servicio? Gestor de Proyecto

824_013 Apend B.indd 248 22/1/10 13:55:07

 Apéndice C:
Plantillas de documentación
del proceso (ejemplo)

824_014 Apend C.indd 249 22/1/10 13:55:32

824_014 Apend C.indd 250 22/1/10 13:55:32
 | 251

Apéndice C: Plantillas de documentación del

proceso (ejemplo)
C1  Marco de trabajo del proceso ■■ Entregables e informes generados por el proceso:
●● Frecuencia
Al diseñar un proceso nuevo o revisado para alguno de los
●● Contenido
procesos de Gestión del Servicio, se recomienda generar
una especificación o marco de trabajo del proceso. La ●● Distribución
especificación debe mantenerse a un nivel bastante alto, ■■ Glosario, acrónimos y referencias.
aunque es necesario detallar el ámbito e interfaces del
proceso. También serán necesarias instrucciones de trabajo
y procedimientos detallados para garantizar la consistencia
del proceso y su aplicación. Los contenidos típicos de un
Marco de Trabajo o Especificación del Proceso son:
■■ Nombre del proceso, descripción y administración
(administración de la documentación: versión, control
del cambio, autor, etc.)
■■ Declaraciones de visión y misión
■■ Objetivos
■■ Ámbito y términos de referencia
■■ Descripción general del proceso:
●● Descripción general
●● Entradas
●● Procedimientos
●● Actividades
●● Salidas
●● Disparadores
●● Herramientas y otros entregables
●● Comunicación
■■ Roles y responsabilidades:
●● Responsabilidades operativas
●● Propietario del proceso
●● Miembros del proceso
●● Usuarios del proceso
●● Otros roles
■■ Documentación y referencias asociadas
■■ Interfaces y dependencias con:
●● Otros proceso de SM
●● Otros procesos de TI
●● Procesos de negocio
■■ Medidas y métricas del proceso: revisiones,
evaluaciones y auditorías

824_014 Apend C.indd 251 22/1/10 13:55:32

824_014 Apend C.indd 252 22/1/10 13:55:32
 Apéndice D:
Documentos de
diseñ̃o y planificación
y sus contenidos

824_015 Apend D.indd 253 22/1/10 13:55:55

824_015 Apend D.indd 254 22/1/10 13:55:55

Apéndice D: Documentos de diseño y
planificación y sus contenidos
Este apéndice contiene detalles sugeridos de los tipos de
documentos de diseño, planes y estándares que debería
generar y mantener TI, y también describe los contenidos
mínimos de las arquitecturas y planes de TI. Sin embargo,
debe hacerse hincapié nuevamente en que todos estos
documentos deben revisarse y repasarse frecuente y
regularmente, y deben utilizarse activamente en los
procesos y procedimientos diarios de TI.
También deben mantenerse alineados con todos los
documentos similares que están en uso dentro del
negocio y de toda la organización.
D1  Documentos y estándares de
diseño y arquitectura
Los documentos de diseño y estándares desarrollados y
mantenidos por TI deben incluir:
■■ Estándares, políticas, procesos y procedimientos de
diseño y planificación
■■ Arquitecturas de aplicaciones, métodos de diseño y
estándares
■■ Requisitos de negocio, evaluación del impacto para el
negocio y métodos y estándares de caso de negocio y
priorización
■■ Estándares de requisitos funcionales
■■ Estándares y métodos SoR e ITT para su evaluación
■■ Arquitecturas tecnológicas, políticas y estándares de
diseño de TI que cubran todas las áreas tecnológicas,
incluyendo mainframe, servidor, ordenadores de
sobremesa, ordenadores portátiles, dispositivos móviles
y portátiles, sistemas de telefonía, almacenamiento,
backup, redes y direcciones de red
■■ Sistemas operativos, software de sistemas, utilidades
y arquitecturas de firmware, políticas y estándares de
diseño
■■ Arquitecturas de datos, información y bases de datos,
políticas y estándares de diseño, incluyendo flujos
de información, Gestión del Conocimiento, acceso
y seguridad de la información, Gestión de Datos,
almacenamiento de datos, data warehousing, análisis
de datos y minería de datos
■■ Sistemas, plataformas, herramientas y agentes de
gestión y sus arquitecturas, políticas y estándares de
diseño, incluyendo funcionalidad, dominios, interfaces,
824_015 Apend D.indd 255
| 255
protocolos de gestión, manejo y categorización de
eventos y alarmas, automatización y escalado
■■ Estructuras, diseños y estándares de cableado
■■ Estándares, métodos y políticas de desarrollo
■■ Métodos, políticas y estándares de prueba
■■ Estándares y métodos de traspaso, aceptación y firma
■■ Estándares y políticas de socios, suministradores y
contratos
■■ Políticas y estándares de comunicaciones
■■ Estándares y políticas de documentos y bibliotecas de
documentos
■■ Arquitecturas de Internet e intranet, estándares
y políticas de diseño, incluyendo e-commerce y
e-business
■■ Arquitecturas de correo electrónico y groupware,
estándares y políticas de diseño
■■ Requisitos del entorno, políticas y estándares de
diseño
■■ Políticas y estándares de diseño de la seguridad de TI,
incluyendo firewalls, comprobación de virus, niveles,
métodos y políticas de acceso del servicio y sistema,
acceso remoto, gestión de cuentas y contraseñas de
usuario
■■ Estándares y políticas de compras
■■ Estándares y políticas de programación, métodos y
planificación de proyectos y políticas y estándares de
revisión
■■ Estándares y políticas de calidad
■■ Estándares e interfaces de usuario.
D2  Planes de TI
TI debe generar y mantener un determinado número de
planes para coordinar y gestionar el desarrollo y calidad
generales de los servicios de TI. Éstos incluyen:
■■ Planes de negocio de TI: los planes de negocio para
el desarrollo de servicios de TI
■■ Planes estratégicos: planes para el logro de la visión,
misión y objetivos de TI a largo plazo
■■ Planes tácticos: planes para el logro de la visión,
misión y objetivos de ICT a corto y medio plazo
■■ Planes funcionales: planes para el logro de la visión,
misión y objetivos de funciones clave de TI
22/1/10 13:55:55
 256 | Apéndice D: Documentos de diseñ̃o y planificación y sus contenidos

■■ Planes operativos: planes para el desarrollo y mejora

de procesos, procedimientos y métodos operativos
■■ Programas y planes de proyecto:
●● Programas de TI y de negocio
●● Proyectos de TI
■■ Programas y planes de procesos:
●● Objetivos y metas
●● Mejora del proceso
●● Roles y responsabilidades
■■ Planes de transición:
●● Planes y programaciones de construcción
●● Calendario de pruebas y entrega
●● Entornos de desarrollo y prueba
●● Programaciones de transición
■■ Planes de Gestión del Servicio:
●● Planes de Calidad del Servicio
●● Planes y Programas de Mejora del Servicio
●● Presupuestos y Planes Financieros
●● Planes de Continuidad de los Servicios de TI y
Recuperación y Planes de Continuidad del Negocio
●● Plan de Capacidad
●● Plan de Disponibilidad
●● Planes de Soporte del Servicio
●● Planes y programaciones de la entrega
●● Planes de Gestión de la Configuración
●● Planes de Gestión de Cambios y Planificación de
Cambios
●● Planes del Centro de Servicio al Usuario, Gestión
de Incidencias y Gestión de Problemas
●● Planes de Suministradores y Contratos.

Todos los planes de TI deben desarrollarse, mantenerse

y revisarse en línea con el negocio y con toda la
organización. Esto debe lograrse utilizando el proceso
de evaluación de impactos de un sistema adecuado de
Gestión de Cambios. Las organizaciones deben tener en
cuenta los requisitos legales para los sistemas y examinar
estándares y regulaciones internacionales y nacionales y su
necesidad para el gobierno corporativo.

824_015 Apend D.indd 256 22/1/10 13:55:55

 Apéndice E:
Arquitecturas y
estándares del entorno

824_016 Apend E.indd 257 22/1/10 16:48:57

824_016 Apend E.indd 258 22/1/10 16:48:57
 | 259

Apéndice E: Arquitecturas y estándares del

entorno
Este apéndice contiene detalles de arquitecturas y
estándares del entorno. Todas las organizaciones deben
generar una política del entorno para la ubicación de
equipos, con los mínimos estándares acordados para
concentraciones particulares de equipos. Adicionalmente,
deben acordarse estándares mínimos para la protección
de edificios que tengan en su interior equipos y
estructuras de protección de salas de equipos. Las
siguientes tablas incluyen los aspectos principales que es
necesario considerar, con características de ejemplo.

Tabla E.1  Edificio/emplazamiento

Acceso Perímetros de seguridad, entradas seguras, seguimiento de auditoría
Protección de edificios y Vallado de seguridad, videocámaras, detectores de movimiento e intrusos, alarmas de ventanas y
emplazamientos puertas, protectores de iluminación, buen entorno de trabajo (estándar)
Entrada Control de múltiples puntos de entrada
Entorno externo Minimizar riesgos externos
Servicios Si fuera posible y justificable, rutas y suministradores alternativos para todos los servicios esenciales,
incluyendo servicios de red

Tabla E.2  Sala de equipos principal

Acceso Entrada controlada segura, candado de combinación, tarjeta de acceso, videocámara (si el negocio fuera
crítico y sin vigilancia)
Ubicación Primera planta allí donde sea posible, sin peligros provocados por agua, gas, productos químicos o
incendios en las proximidades, por encima, por debajo y en los aledan~os
Visibilidad Sin sen~alización y sin ventanas externas
Estructura de protección Estructura de protección externa: impermeable, hermética, insonorizada, resistente al fuego (de 0,5 a 4
horas dependiendo de la criticidad)
Entrega de los equipos Provisión adecuada para la entrega y posicionamiento de equipos delicados grandes
Suelo interior Sellado
Sala de planta separada Sistema de Alimentación Ininterrumpida (UPS). Alimentación eléctrica y conmutación, equipos de
circulación de aire, salas y unidades dobles si el negocio fuera crítico
Externo Generador para centros de datos principales y para sistemas críticos para el negocio

824_016 Apend E.indd 259 22/1/10 16:48:57

 260 | Apéndice E: Arquitecturas y estándares del entorno

Tabla E.3  Centros de datos principales

Acceso Entrada controlada segura, candado de combinación, tarjeta de acceso, videocámara (si el negocio fuera
crítico y sin vigilancia)
Temperatura Control estricto, 22° (± 3°). Provisión hasta 550W/m2. 6° de variación en la sala y un máximo de 6° por
hora
Control de humedad Control estricto: 50% (± 10%)
Calidad del aire Presión positiva, baja polución gaseosa con admisión filtrada (por ejemplo, dióxido de sulfuro ≤ 0,14
ppm), niveles de polvo para partículas > 1 micra, menos de 5 x 106 partículas/m3. Apagado automático
después de la detección de humos y de incendio
Alimentación Unidad de Distribución de Alimentación (PDU), con alimentación trifásica hasta cajas no conmutadas,
una por componente de los equipos, con disyuntores del tipo adecuado para cada suministro.
Alternativamente, se pueden utilizar cintas de distribución de alimentación aprobadas. Cargas trifásicas
balanceadas. UPS (en línea o línea interactiva con Gestión de Protocolo Simple de Administración de
Red (SNMP)) para garantizar que la tensión suministrada se encuentre entre ± 5% de la tensión nominal
con condiciones con mínimo impulso, caídas de tensión, y sobre/subtensiones
Falsos suelos Antiestáticos, baldosas de suelo de fácil manejo de 600 x 600 mm sobre pedestales, con pedestales
alternativos atornillados en el suelo sólido. Mínimo de 600 mm de holgura hasta el suelo sólido. Cargas
de suelo de hasta 5kN/m2 con un mínimo recomendado de 3 m entre el falso suelo y el techo
Paredes interiores Desde el falso suelo hasta el techo, resistente al fuego, pero con flujo de aire por encima y por debajo
del nivel del suelo
Detección/prevención de Alarma multinivel HSSD o VESDA con liberación automática de extintores FM200 (o sustitución de halón
incendios alternativo) con detección de ‘doble golpe”
Detectores del entorno Para humo, temperatura, alimentación, humedad, agua e intrusos con capacidad de alarma
automatizada. Paneles locales de alarma con paneles de repetidores, y capacidad de alarma remota
Iluminación Niveles normales de iluminación del techo con iluminación de emergencia después de un fallo de
alimentación
Seguridad de la alimentación Debe proporcionarse una masa clara en la PDU y para todos los equipos. Con botones de apagado
remoto marcados claramente en cada salida. Las conexiones con alimentación sucia deben marcarse
claramente
Extintores Suficientes extintores eléctricos con procedimientos y sen~alización adecuados
Vibración Las vibraciones deben ser mínimas en todo el área
Interferencia electromagnética Deben reducirse al mínimo las interferencias (intensidad del campo ambiente de 1,5V/m)
Instalaciones Todos los equipos deben suministrarse e instalarse con suministradores e instaladores cualificados con
los estándares de seguridad, salud y eléctricos adecuados
Conexiones de red El espacio para los equipos debe cablearse con la capacidad adecuada para un crecimiento razonable.
Todos los cables deben posicionarse y asegurarse en las bandejas de cables apropiadas
Recuperación de desastres Deben desarrollarse planes de recuperación totalmente probados para todos los centros de datos
principales incluyendo el uso de equipos y emplazamientos de sustitución

824_016 Apend E.indd 260 22/1/10 16:48:57

 Apéndice E: Arquitecturas y estándares del entorno | 261

Tabla E.4  Centros de datos regionales y centros de equipos principales

Acceso Entrada controlada segura, candado de combinación, tarjeta de acceso, videocámara (si el negocio fuera
crítico y sin vigilancia)
Temperatura Control de temperatura, 22° (± 5°), preferible
Control de humedad Control estricto: 50% (± 10%), preferible
Calidad del aire Presión positiva, baja polución gaseosa con admisión filtrada (por ejemplo, dióxido de sulfuro ≤ 0,14
ppm), niveles de polvo para partículas > 1 micra, menos de 5 x 106 partículas/m3. Apagado automático
después de la detección de humos y de incendio
Alimentación PDU con alimentación trifásica hasta cajas no conmutadas, una por componente de los equipos, con
disyuntores del tipo adecuado para cada suministro. Alternativamente, se pueden utilizar cintas de
distribución de alimentación aprobadas. Cargas trifásicas balanceadas. UPS de sala para garantizar que
la tensión suministrada se encuentre entre ± 5% de la tensión nominal con condiciones de mínimo
impulso, caídas de tensión, y sobre/subtensiones
Falsos suelos Antiestáticos, baldosas de suelo de fácil manejo de 600 x 600 mm sobre pedestales, con pedestales
alternativos atornillados en el suelo sólido. Mínimo de 600 mm de holgura hasta el suelo sólido. Cargas
de suelo de hasta 5kN/m2 con un mínimo recomendado de 3 m entre el falso suelo y el techo
Paredes interiores Desde el falso suelo hasta el techo, resistente al fuego, pero con flujo de aire por encima y por debajo
del nivel del suelo
Detección/prevención de Detección de incendios general pero sin supresión, aunque podría incluirse alarma multinivel HSSD o
incendios VESDA con liberación automática de extintores FM200 (o sustitución de halón alternativo) con detección
de ‘doble golpe” si existieran sistemas críticos para el negocio
Detectores del entorno Para humo, temperatura, alimentación, humedad, agua e intrusos con capacidad de alarma automatizada
Iluminación Niveles normales de iluminación del techo con iluminación de emergencia después de un fallo de
alimentación
Seguridad de la alimentación Debe proporcionarse una masa clara en la PDU y para todos los equipos. Con botones de apagado
remoto marcados claramente en cada salida. Las conexiones de salida con alimentación sucia deben
marcarse claramente
Extintores Suficientes extintores eléctricos con procedimientos y sen~alización adecuados
Vibración Las vibraciones deben ser mínimas en todo el área
Interferencia electromagnética Deben reducirse al mínimo las interferencias (intensidad del campo ambiente de 1,5V/m)
Instalaciones Todos los equipos deben suministrarse e instalarse con suministradores e instaladores cualificados con
los estándares de seguridad, salud y eléctricos adecuados
Conexiones de red El espacio para los equipos debe cablearse con la capacidad adecuada para un crecimiento razonable.
Todos los cables deben posicionarse y asegurarse en las bandejas de cables apropiadas
Recuperación de desastres Deben desarrollarse planes de recuperación totalmente probados para todos los centros de datos
regionales incluyendo el uso de equipos y emplazamientos de sustitución si fuera apropiado

824_016 Apend E.indd 261 22/1/10 16:48:57

 262 | Apéndice E: Arquitecturas y estándares del entorno
Tabla E.5  Salas de servidores y equipos de red
Acceso
Temperatura
Control de humedad
Calidad del aire
Alimentación
Falsos suelos
Paredes interiores
Detección/prevención de
incendios
Detectores del entorno
Iluminación
Seguridad de la alimentación
Extintores
Vibración
Interferencia electromagnética
Instalaciones
Conexiones de red
Recuperación de desastres
Tabla E.6  Entornos de oficina
Acceso
Iluminación, temperatura,
humedad y calidad del aire
Alimentación
Falsos suelos
Detección/prevención de
incendios y extintores
Conexiones de red
Recuperación de desastres
824_016 Apend E.indd 262
Entrada controlada segura con candado de combinación, tarjeta de acceso, cerradura y llave. En algunos
casos los equipos podrían ubicarse en oficinas abiertas o en racks o armarios cerrados
Entorno normal de oficina, pero si los equipos estuvieran en salas cerradas deberá proporcionarse
ventilación adecuada
Entorno normal de oficina
Entorno normal de oficina
Fuente de alimentación limpia con alimentación suministrada por UPS a todo el rack
Se recomienda un mínimo de 3 m entre el suelo y el techo con todos los cables fijados en conexiones
de cables de múltiples compartimientos
Siempre que sea posible todas las paredes deben ser resistentes al fuego
Sistemas habituales de detección de humo/fuego para las oficinas, a menos que la concentración de
equipos sea importante
Para humo, alimentación, intrusos con capacidad de alarma sonora
Niveles normales de iluminación del techo con iluminación de emergencia después de fallo de
alimentación
Debe proporcionarse una masa clara para todos los equipos. Con botones de apagado marcados
claramente
Suficientes extintores eléctricos con procedimientos y sen~alización adecuados
Las vibraciones deben ser mínimas en todo el área
Deben reducirse al mínimo las interferencias (intensidad del campo ambiente de 1,5V/m)
Todos los equipos deben suministrarse e instalarse con suministradores e instaladores cualificados con
los estándares de seguridad, salud y eléctricos adecuados
El espacio para los equipos debe cablearse con la capacidad adecuada para un crecimiento razonable.
Todos los cables deben posicionarse y asegurarse en las bandejas de cables apropiadas
Deben desarrollarse planes de recuperación totalmente probados si fuera apropiado
Todas las oficinas deben tener el acceso seguro apropiado dependiendo del negocio, de la información
y de los equipos contenidos en ellas
Un entorno de oficina limpio, confortable y ordenado normal, conforme a los requisitos del entorno y
seguridad y salud de la organización
Fuente de alimentación limpia para todos los equipos informáticos, con funcionalidades UPS si fuera
necesario
Preferibles si fuera posible, pero todos los cables deben estar contenidos dentro de los
compartimientos apropiados
Sistemas de detección de humo/fuego normales y sistemas de alerta para intrusos, a menos que la
concentración de equipos sea importante. Suficientes extintores contra incendios del tipo apropiado,
con procedimientos y sen~alización adecuados
El espacio para oficinas debe cablearse preferiblemente con la capacidad adecuada para un crecimiento
razonable. Todos los cables deben posicionarse y asegurarse en las bandejas de cables apropiadas.
Todos los equipos de red deben asegurarse en armarios o gabinetes
Deben desarrollarse planes de recuperación totalmente probados si fuera apropiado
22/1/10 16:48:57
 Apéndice F:
SLA y OLA de ejemplo

824_017 Apend F.indd 263 22/1/10 13:57:17

824_017 Apend F.indd 264 22/1/10 13:57:17
 | 265

Apéndice F: SLA y OLA de ejemplo

Este apéndice contiene ejemplos de SLAs y OLAs y de sus normalmente al Centro de Servicio al Usuario, y cuáles son
contenidos. No se recomienda que todos los SLA y OLA los periodos de notificación que se requieren).
contengan necesariamente todas las secciones incluidas
Se puede incluir un calendario del servicio o hacer
dentro de los siguientes documentos de ejemplo. Estas
referencia a uno.
áreas se consideran sugerencias al preparar plantillas
de documentos, ya que sólo se incorporarán en los Detalles de franjas horarias preacordadas de adecuación
documentos reales si fueran apropiadas y pertinentes. y mantenimiento, si éstas impactaran en el horario de los
Por lo tanto, lo que se incluye a continuación sólo debe servicios, junto con detalles sobre cómo deben negociarse
considerarse como directrices y listas de comprobación. y acordarse otras interrupciones del servicio, por quienes y
cuáles son los periodos de notificación, etc.
ACUERDO DE NIVEL DE SERVICIO (SLA – Ejemplo)
Procedimientos para solicitar cambios permanentes en el
Este acuerdo se formaliza entre....................................................y
horario del servicio.
....................................................................................................................
El acuerdo recoge la provisión y soporte de los servicios
Disponibilidad del servicio:
ABC que... (breve descripción del servicio). Los niveles objetivo de disponibilidad que el proveedor
de servicios de TI deberá proporcionar dentro de horario
Este acuerdo estará vigente durante 12 meses a partir de acordado del servicio. Deben establecerse objetivos de
(fecha) hasta (fecha). El acuerdo se revisará anualmente. disponibilidad dentro del horario acordado del servicio
Podrían registrarse cambios menores en el formulario expresados como porcentajes (por ejemplo, 99,5%),
al final del acuerdo. Ambas partes deben firmarlos y además de periodos, métodos y cálculos de medida. Esta
gestionarlos a través del proceso Gestión de Cambios. cifra puede expresarse para todo el servicio, servicios
Firmantes: de apoyo, componentes críticos o para todos ellos. Sin
embargo, es difícil asociar tales cifras de disponibilidad en
Nombre..................................Puesto...........................Fecha...............
porcentaje con la calidad del servicio, o con las actividades
Nombre..................................Puesto...........................Fecha............... del negocio del cliente. Por lo tanto, en muchas ocasiones
es mejor intentar medir la falta de disponibilidad del
Descripción del servicio: servicio en términos de incapacidad del cliente para
El Servicio ABC consiste en... (una descripción más realizar sus actividades de negocio. Por ejemplo, ‘las
detallada para incluir funciones de negocio clave, ventas se ven inmediatamente afectadas por un fallo de
entregables y toda la información relevante para describir TI a la hora de proporcionar un servicio de soporte POS
el servicio y su escala, impacto y prioridad para el adecuado’. Este fuerte vínculo entre el servicio de TI y los
negocio). procesos de negocio del cliente es un signo de madurez
en los procesos de SLM y de Gestión de la Disponibilidad.
Ámbito del acuerdo: También deben documentarse los detalles acordados de
¿Qué se recoge dentro del acuerdo y qué se excluye? cómo y cuando se medirá y se comunicará y durante qué
periodo acordado se hará.
Horario del servicio:
Una descripción del horario en el que los clientes pueden Fiabilidad:
esperar que esté disponible el servicio (por ejemplo 7 × El máximo número de interrupciones del servicio que se
24 × 365, 08:00 a 18:00 – Lunes a Viernes). pueden tolerar dentro de un periodo acordado (podría
definirse como el número de interrupciones, por ejemplo,
Condiciones especiales para las excepciones (por ejemplo,
cuatro al año, o como un Tiempo Medio Entre Fallos
fines de semana, días festivos) y procedimientos para
(MTBF) o Tiempo Medio Entre Incidencias de los Sistemas
solicitar ampliaciones del servicio (a quién contactar,
(MTBSI)).

824_017 Apend F.indd 265 22/1/10 13:57:17

 266 | Apéndice F: SLA y OLA de ejemplo
Definición de lo que constituye una ‘interrupción’ y cómo
éstas se monitorizarán y registrarán.
Soporte al cliente:
Deberán documentarse los detalles de cómo ponerse
en contacto con el Centro de Servicio al Usuario, el
horario en el que estará disponible, el horario en el que
el soporte estará disponible y qué hacer fuera del horario
para obtener asistencia (por ejemplo, soporte telefónico,
asistencia externa, etc.). El SLA también podría incluir
la referencia a la Autoayuda por Internet/Intranet y/o al
registro de Incidencias. Deben incluirse métricas y medidas
como por ejemplo objetivos de respuestas por llamadas
telefónicas (número de tonos, llamadas perdidas, etc.).
Objetivos para tiempos de respuesta de Incidencias (el
tiempo que transcurrirá antes de que alguien comience
a ayudar al cliente, lo que podría incluir tiempos de
desplazamiento, etc.).
Una definición de lo que es necesario ‘responder’ – ¿Es
una llamada telefónica devuelta al cliente o una visita al
emplazamiento? – según sea oportuno.
Acuerdos para solicitar ampliaciones de soporte,
incluyendo los periodos requeridos de notificación (por
ejemplo, la solicitud debe realizarse al Centro de Servicio
al Usuario a las 12 del mediodía para una ampliación
por la noche, a las 12 del mediodía del jueves para una
ampliación el fin de semana)
Nota: Tanto los tiempos de respuesta como los de
resolución de incidencias se basarán en códigos de
prioridad/impacto de las incidencias. Aquí también deben
incluirse detalles de la clasificación de Incidencias.
Nota: En algunos casos, podría ser apropiado hacer
referencia a contactos y contratos con terceros y a
OLAs, aunque esto no debe ser una forma de desviar la
responsabilidad.
Puntos de contacto y escalado:
Detalles de los contactos dentro de cada una de las partes
implicadas en el acuerdo y los procesos de escalado
y puntos de contacto. Esto también debe incluir la
definición de una disconformidad y el procedimiento para
gestionar disconformidades.
Rendimiento del servicio:
Detalles de la capacidad de respuesta esperada del
servicio de TI (por ejemplo, tiempos de respuesta objetivo
de la estación de trabajo para tiempos de respuesta
medios o máximos de la estación de trabajo, algunas
veces expresados como un porcentaje, por ejemplo 95%
824_017 Apend F.indd 266
en el periodo de dos segundos), detalles del rendimiento
esperado del servicio con respecto a los objetivos en
los que se basa, y cualquier umbral que invalidaría los
objetivos.
Esto debe incluir la indicación de los volúmenes de
tráfico probables, a través de la actividad, restricciones y
dependencias (por ejemplo, el número de transacciones
que se procesarán, número de usuarios concurrentes, y la
cantidad de datos que se transmitirán en la red). Esto es
importante para que se puedan identificar los problemas
de rendimiento que hayan sido provocados por unas
prestaciones excesivas, que superan de los términos del
acuerdo.
Tiempos de procesamiento de lotes:
Si fuera apropiado, detalles de cualquier tiempo de
procesamiento de lotes, tiempos de finalización y
entregables clave, incluyendo tiempos para la entrega de
las entradas y el tiempo y lugar de la entrega del resultado
si fuera oportuno.
Funcionalidad (si fuera apropiado):
Detalles de la funcionalidad mínima que se proporcionará
y el número de errores de tipos particulares que se
pueden tolerar antes de que se incumpla el SLA. Deben
incluirse niveles de severidad y el periodo de información.
Gestión de Cambios:
Breve mención y referencia a los procedimientos de
Gestión de Cambios de la organización que deben
seguirse, como medio de reforzar el cumplimiento.
Además, deben incluirse objetivos para aprobar, manejar e
implementar RFCs, normalmente basados en la categoría o
urgencia/prioridad del cambio, y los detalles de cualquier
cambio conocido que impactará en el acuerdo, si hubiera.
Continuidad del Servicio:
Breve mención y referencia a los Planes de Continuidad
del Servicio de la organización, junto con los detalles
sobre cómo podría verse afectado el SLA o referencia a un
SLA de Continuidad independiente, que contenga detalles
de cualquier reducción o modificación de los objetivos del
servicio si se produjera una situación de desastre. Detalles
de cualquier responsabilidad específica de ambas partes
(por ejemplo, backup de datos, almacenamiento off-site).
Además, detalles de la invocación de planes y cobertura
de cualquier problema de seguridad, particularmente
cualquier responsabilidad del cliente (por ejemplo,
coordinación de actividades de negocio, documentación
del negocio, backup de PCs independientes y cambios de
contraseña).
22/1/10 13:57:17

Seguridad:
Breve mención y referencia a la política de Seguridad de
la organización (que cubre problemas como controles
de contraseñas, violaciones de seguridad, software
sin autorización, virus, etc.). Detalles de cualquier
responsabilidad específica por ambas partes (por ejemplo,
Protección Anti Virus, Firewalls).
Impresión:
Detalles de cualquier condición especial asociada con
la impresión o con las impresoras (por ejemplo, detalles
de distribución de la impresión, notificación de grandes
operaciones centralizadas de impresión, o manejo de
cualquier artículo de escritorio especial de alto valor).
Responsabilidades:
Detalles de las responsabilidades de las distintas partes
implicadas dentro del servicio y sus responsabilidades
acordadas, incluyendo al proveedor de servicio, cliente y
usuarios.
Imputación de costes (si fuera aplicable):
Deben incluirse los detalles de cualquier fórmula utilizada
para la imputación de costes, periodos de imputación
de costes, o referencia a documentos de la política de
imputación de costes, junto con procedimientos de
facturación y condiciones de pago, etc. Esto también
debe incluir detalles de cualquier penalización financiera
o bonificación que se pagará si los objetivos del
servicio no cumplieran las expectativas. Cuáles serán
las penalizaciones/bonificaciones y cómo se calcularán,
acordarán y recopilarán/pagarán (más apropiado para
situaciones de terceros). Si el SLA incluyera una relación
de externalización, los costes deberán detallarse en un
Apéndice ya que normalmente se recogen mediante
provisiones comerciales confidenciales.
Debe tenerse en cuenta que las cláusulas de penalización
pueden generar sus propias dificultades. Pueden generar
una barrera con los socios si se invocaran injustamente
basandose en un tecnicismo y también pueden hacer
que el personal del proveedor de servicio sea reacio a
admitir errores por temor a las penalizaciones que se
están imponiendo. Esto puede representar, a menos que
se utilice adecuadamente, una barrera para desarrollar
relaciones eficaces y para resolver problemas.
Informes y revisiones del servicio:
El contenido, frecuencia, plazos y distribución de los
informes del servicio, y la frecuencia de las reuniones
de revisión del servicio acordadas. Además, los detalles
824_017 Apend F.indd 267
Apéndice F: SLA y OLA de ejemplo | 267
de cómo y cuándo se revisarán los SLA y los objetivos
asociados del servicio, incluyendo quién estará implicado y
con qué capacidad.
Glosario:
Explicación de cualquier abreviatura o terminología
utilizada para mejorar el entendimiento del cliente.
Hoja de modificaciones:
Para incluir un registro de cualquier modificación
acordada, con detalles de modificaciones, fechas y
firmantes. También debe incluir el historico completo del
cambio del documento y de sus revisiones.
Debe tenerse en cuenta que los contenidos del SLA
incluidos anteriormente son sólo ejemplos. No deben
considerarse como exhaustivos u obligatorios, aunque
proporcionan un buen punto de inicio.
ACUERDO DE NIVEL DE OPERATIVO (OLA – Ejemplo)
Este acuerdo se formaliza entre....................................................y
....................................................................................................................
El acuerdo recoge la provisión del servicio de soporte y
proporciona... (breve descripción del servicio).
Este acuerdo estará vigente durante 12 meses a partir de
(fecha) hasta (fecha).
El acuerdo se revisará anualmente. Podrían registrarse
cambios menores en formato al final del acuerdo siempre
que se estén acordados por ambas partes y gestionados a
través del proceso Gestión de Cambios.
Firmantes:
Nombre..................................Puesto...........................Fecha...............
Nombre..................................Puesto...........................Fecha...............
Detalles de modificaciones previas:
Descripción del servicio de soporte:
Explicación integral y detalles del servicio de soporte que
se está proporcionando.
Ámbito del acuerdo:
¿Qué se recoge dentro del acuerdo y qué se excluye?
Horario del Servicio:
Una descripción del horario en el que se suministra el
servicio de soporte.
22/1/10 13:57:17
 268 | Apéndice F: SLA y OLA de ejemplo

Objetivos del servicio: Gestión de la Continuidad del Servicio:

Los objetivos para la provisión del servicio de soporte y los
procesos de información y revisión y frecuencia.
Puntos de contacto y escalado:
Detalles de los contactos dentro de cada una de las partes
implicadas en el acuerdo y los procesos de escalado y
puntos de contacto.
Responsabilidad para garantizar que todos los
componentes dentro del dominio de soporte tengan
planes de recuperación actualizados y probados que
den soporte a requisitos de negocio acordados y
documentados. Esto podría incluir la asistencia en la
evaluación técnica del riesgo y de su gestión y mitigación
posteriores.

Responsabilidades y tiempos de respuesta del Gestión de Capacidad:

Centro de Servicio al Usuario y ante incidencias: Responsabilidad para dar soporte a las necesidades del
proceso Gestión de Capacidad en del ámbito acordado de
Las responsabilidades y objetivos acordados para el
su dominio técnico.
progreso y resolución de Incidencias y de soporte del
Centro de Servicio al Usuario.
Gestión del Nivel de Servicio:
Responsabilidades y tiempos de respuesta ante Asistencia con la definición y acuerdo de objetivos
problemas: apropiados dentro de SLAs, SLRs y OLAs, concernientes a
componentes en del ámbito de su dominio técnico.
Las responsabilidades y objetivos acordados para el
progreso y resolución de Problemas.
Gestión de Suministradores:
Gestión de Cambios: Asistencia con la gestión de contratos y suministradores,
principalmente en del ámbito de su dominio técnico.
Las responsabilidades y objetivos acordados para el
progreso e implementación de cambios.
Provisión de información:
Gestión de la Entrega: La provisión y mantenimiento de información precisa,
incluyendo datos financieros para todos los componentes
Las responsabilidades y objetivos acordados para el
en del ámbito acordado de su dominio técnico.
progreso e implementación de entregas.
Glosario:
Gestión de la Configuración:
Explicación de cualquier abreviatura o terminología
Las responsabilidades para la propiedad, provisión y
utilizada para mejorar el entendimiento de los términos
mantenimiento de información precisa de Gestión de la
contenidos dentro del acuerdo.
Configuración.
Hoja de modificaciones:
Gestión de la Seguridad de la Información:
Para incluir un registro de cualquier modificación
Las responsabilidades y objetivos acordados para el
acordada, con detalles de modificaciones, fechas y
soporte de las Políticas de Seguridad y el proceso de
firmantes. También debe incluir detalles de una historia
Gestión de la Seguridad de la Información.
del cambio completa del documento y de sus revisiones.

Gestión de la Disponibilidad:
Responsabilidad para garantizar que todos los
componentes dentro del dominio de soporte se gestionen
y se les dé apoyo para cumplir y continuar cumpliendo
los objetivos de disponibilidad del servicio y de sus
componentes.

824_017 Apend F.indd 268 22/1/10 13:57:17

 Apéndice G:
Ejemplo de Catálogo
de Servicios

824_018 Apend G.indd 269 22/1/10 13:57:45

824_018 Apend G.indd 270 22/1/10 13:57:45
 | 271

Apéndice G: Ejemplo de Catálogo de Servicios

El Catálogo de Servicios es un documento clave que

contiene información valiosa sobre el conjunto completo
de servicios ofrecidos. Debe almacenarse preferiblemente
como un conjunto de CIs del ‘servicio’ dentro de un
CMS, mantenido bajo Gestión de Cambios. Debido a
que es un conjunto valioso de información, debe estar
disponible para todos los que se encuentren dentro
de la organización. Todos los nuevos servicios deben
introducirse inmediatamente en el Catálogo de Servicios
una vez se hayan documentado y acordado su definición
inicial de los requisitos. Además de la información
siguiente, el Catálogo de Servicios debe registrar el estado
de todos los servicios, a través de las etapas de su ciclo de
vida definido.

Tabla G1  Ejemplo de Catálogo de Servicios

Nombre del Descripción Tipo de Servicios de Propietarios Unidades de Gestores del Impacto en Prioridad del SLA Horario del
Servicio del Servicio servicio soporte del negocio negocio Servicio el Negocio Negocio servicio
Servicio 1
Servicio 2
Servicio 3
Servicio 4

824_018 Apend G.indd 271 22/1/10 13:57:45

824_018 Apend G.indd 272 22/1/10 13:57:45
 Apéndice H:
El marco de trabajo de
madurez del proceso
Gestión del Servicio

824_019 Apend H.indd 273 22/1/10 13:58:04

824_019 Apend H.indd 274 22/1/10 13:58:04
 | 275

Apéndice H: El marco de trabajo de madurez

del proceso Gestión del Servicio
El marco de trabajo de madurez del proceso (PMF) se
puede utilizar como un marco de trabajo para evaluar
individualmente la madurez de cada uno de los procesos
de Gestión del Servicio, o para medir la madurez de
la totalidad del proceso de Gestión del Servicio. Éste
es un método que se ha utilizado ampliamente en la
industria de TI durante varios años, con muchos modelos
propietarios de varias organizaciones. Este PMF particular
se ha desarrollado para proporcionar un método de
mejor práctica común para la revisión y evaluación de la
madurez del proceso de Gestión del Servicio. Este marco
de trabajo, que se muestra en la Figura H.1, puede ser
utilizado por las organizaciones para revisar internamente
sus propios procesos de Gestión del Servicio y por
revisores, asesores o auditores de organizaciones externas.
El uso del PMF en la evaluación de los procesos de
Gestión del Servicio radica en una apreciación del Modelo
de Crecimiento Organizativo de TI. La madurez de los
procesos de Gestión del Servicio depende en gran medida
de la etapa de crecimiento de toda la organización de TI.
Es difícil, si no imposible, desarrollar la madurez de los
procesos de Gestión del Servicio más allá de la madurez y
capacidad de toda la organización de TI. La madurez de la
organización de TI no depende únicamente de la madurez
de los procesos de Gestión del Servicio. Cada nivel
requiere un cambio de una combinación de elementos
para que sea completamente eficaz. Por lo tanto, una
revisión de los procesos requerirá una evaluación a
completar con respecto a las cinco áreas de:
■■ Visión y dirección
■■ Proceso
■■ Personas
■■ Tecnología
■■ Cultura.
Éstas se describen dentro del PMF para evaluar la madurez
del proceso. Las características principales de cada nivel
del PFM son las siguientes.

5 Optimizar

4 Gestionado

3 Definido
En términos de:
- visión y dirección
2 Repetible - personas
- procesos
- tecnología
1 Inicial - cultura

Figura H.1 Marco de trabajo de madurez del proceso

824_019 Apend H.indd 275 22/1/10 13:58:05

 276 | Apéndice H: El marco de trabajo de madurez del proceso Gestión del Servicio

Inicial (Nivel 1)
El proceso se ha identificado aunque hay muy poca o
ninguna actividad de gestión del proceso y no se le ha
dado ninguna importancia, recursos o atención dentro
de la organización. Este nivel también se puede describir
como ‘ad hoc’ u ocasionalmente incluso ‘caótico’.

Tabla H.1  PMF Nivel 1: inicial

Visión y dirección Mínimos fondos y recursos con poca actividad
Resultados temporales no retenidos
Informes y revisiones esporádicos
Proceso Procesos y procedimientos definidos en términos generales, utilizados relativamente cuando se
producen problemas
Procesos totalmente reactivos
Actividades irregulares y sin planificar
Personas Roles y responsabilidades definidos en términos generales
Tecnología Procesos manuales o herramientas poco específicas y discretas (huecos/islas)
Cultura Herramienta y tecnología basadas y orientadas a un fuerte enfoque en la actividad

Repetible (Nivel 2)
El proceso se ha identificado y se le han asignado
recursos o enfoque de poca importancia dentro de la
operación. Generalmente, las actividades relacionadas
con el proceso están descoordinadas, son irregulares, sin
dirección y están orientadas a la eficacia del proceso.

Tabla H.2  PMF Nivel 2: repetible

Visión y dirección No hay metas u objetivos formales claros
Fondos y recursos disponibles
Actividades, informes y revisiones irregulares y sin planificar
Proceso Procesos y procedimientos definidos
Procesos ampliamente reactivos
Actividades irregulares y sin planificar
Personas Roles y responsabilidades no interrelacionados
Tecnología Muchas herramientas discretas con falta de control
Datos almacenados en ubicaciones independientes
Cultura Basada en y orientada al producto y servicio

824_019 Apend H.indd 276 22/1/10 13:58:05

 Apéndice H: El marco de trabajo de madurez del proceso Gestión del Servicio | 277

Definido (Nivel 3)
El proceso se ha identificado y documentado aunque
no hay acuerdo, aceptación o identificación formal de
su rol dentro de toda la operación de TI. Sin embargo,
el proceso tiene un dueño del proceso, objetivos y
metas formales con recursos asignados, y se centra
en la eficiencia y eficacia del proceso. Los informes
y resultados se almacenan para futuras referencias.
revisados

Tabla H.3  PMF Nivel 3: definido

Visión y dirección Metas u objetivos formales documentados y acordados
Planes formalmente publicados, monitorizados y revisados
Bien financiados y con los recursos apropiados
Revisiones e informes regulares y planificados
Proceso Procesos y procedimientos claramente definidos y bien publicitados
Actividades regulares y planificadas
Documentación adecuada
Proceso proactivo ocasionalmente
Personas Roles y responsabilidades claramente definidos y acordados
Objetivos y metas formales
Planes formalizados de formación sobre el proceso
Tecnología Recopilación continua de datos con alarma y monitorización de umbrales
Datos consolidados, retenidos y utilizados para la planificación, previsión e identificación de tendencias
Cultura Orientado al Servicio y al Cliente con un método formalizado

Gestionado (Nivel 4)
Ahora el proceso se ha identificado y aceptado
completamente en todo TI. Está centrado en el servicio
y tiene objetivos y metas que se basan en objetivos
y metas del negocio. El proceso está completamente
definido y gestionado y es proactivo, con interfaces y
dependencias documentadas y establecidas con otros
procesos de TI.

Tabla H.4  PMF Nivel 4: gestionado

Visión y dirección Dirección clara con metas y objetivos de negocio formales y con medición del progreso
Informes eficaces de gestión utilizados activamente
Planes de proceso integrados y vinculados con los planes de TI y del negocio
Mejoras regulares planificadas y revisadas
Proceso Procesos, procedimientos y estándares bien definidos, incluidos en todas las descripciones del puesto
de trabajo del personal de TI
Interfaces y dependencias del proceso definidas claramente
Procesos integrados de Gestión del Servicio y de desarrollo de sistemas
Proceso principalmente proactivo
Personas Equipo de trabajo inter e intra proceso
Responsabilidades claramente definidas en todas las descripciones de los puestos de trabajo de TI
Tecnología Monitorización, medida, generación de informes y alerta de umbrales continuos para un conjunto
centralizado de herramientas, bases de datos y procesos integrados
Cultura Negocio enfocado con un entendimiento de los aspectos más importantes

824_019 Apend H.indd 277 22/1/10 13:58:05

 278 | Apéndice H: El marco de trabajo de madurez del proceso Gestión del Servicio

Optimización (Nivel 5) Este marco de trabajo de madurez se alinea con el

Ahora el proceso se ha identificado completamente Software Engineering Institute Capability Maturity
y tiene metas y objetivos estratégicos alineados con Model® Integration (SEI CMMI) y con sus diversos
la estrategia general del negocio y con las metas de modelos de madurez incluyendo el CMMI-SVC en
TI. Éstos se han ‘institucionalizado’ como parte de la desarrollo, que se centra en la entrega de servicios.
actividad diaria para todos aquellos implicados con el
proceso. Se establece un proceso continuo y compacto
de mejora como parte del proceso, que ahora está
desarrollando una capacidad preventiva.
Tabla H.5  PMF Nivel 5: optimización
Visión y dirección Planes estratégicos integrados vinculados con planes de negocio, metas y objetivos generales del
negocio
Monitorización, medida, informes de alertas y revisiones continuos vinculados con un proceso continuo
de mejora
Revisiones y auditorías regulares con respecto a la eficacia, eficiencia y conformidad
Proceso Procesos y procedimientos bien definidos como parte de la cultura corporativa
Proceso proactivo y preventivo
Personas Objetivos y metas formales alineados con el negocio y monitorizados activamente como parte de la
actividad diaria
Roles y responsabilidades como parte de una cultura general corporativa
Tecnología Arquitectura de herramientas globales y bien documentadas, con total integración en todas las áreas de
personas, procesos y tecnología
Cultura Una actitud de mejora continua, junto con un enfoque de negocio estratégico. Un entendimiento del
valor de TI para el negocio y su rol dentro de la cadena de valor del negocio

824_019 Apend H.indd 278 22/1/10 13:58:05

 Apéndice I: Ejemplo de
contenidos de una Declaración
de Requisitos (SoR) y/o
Convocatoria de Licitación (ITT)

824_020 Apend I.indd 279 22/1/10 13:59:25

824_020 Apend I.indd 280 22/1/10 13:59:25
 | 281

Apéndice I: Ejemplo de contenidos de

una Declaración de Requisitos (SoR) y/o
Convocatoria de Licitación (ITT)
A continuación se incluye el ejemplo de un conjunto ■■ Detalles del crecimiento posible y planificado
mínimo de contenidos que deben incluirse en una ITT o ■■ Procedimientos para manejar los cambios
SOR: ■■ Detalles de los contenidos y estructura de las
■■ Una descripción de los servicios, productos y/o responsabilidades requeridas.
componentes requeridos
■■ Todas las especificaciones, detalles y requisitos
técnicos relevantes
■■ Un SLR si fuera aplicable
■■ Requisitos de disponibilidad, fiabilidad, capacidad de
mantenimiento y capacidad de servicio
■■ Detalles de la propiedad del hardware, software,
edificios, instalaciones, etc.
■■ Detalles de los criterios de rendimiento que deberán
cumplir los equipos y suministradores
■■ Detalles de todos los estándares que es necesario
cumplir (internos, externos, nacionales e
internacionales)
■■ Requisitos legales y regulatorios (de la industria,
nacionales, de la UE e internacionales)
■■ Detalles de criterios de calidad
■■ Plazos de tiempo, detalles y requisitos, términos y
condiciones contractuales
■■ Todas las consideraciones comerciales: costes,
cargos, bonificaciones, pagos y programaciones de
penalizaciones
■■ Interfaces y contactos requeridos
■■ Métodos de gestión de proyectos que se utilizarán
■■ Procedimientos y criterios de información,
monitorización y revisión que se utilizarán durante y
después de la implementación
■■ Requisitos y condiciones del suministrador
■■ Requisitos del subcontratista
■■ Detalles de cualquier término y condición relevante
■■ Descripción de los requisitos de respuesta del
suministrador:
●● Formato
●● Criterios
●● Condiciones
●● Escalas de tiempo
●● Varianzas e incumplimientos
●● Responsabilidades y requisitos del cliente

824_020 Apend I.indd 281 22/1/10 13:59:25

824_020 Apend I.indd 282 22/1/10 13:59:25
 Apéndice J:
Los contenidos típicos de
un Plan de Capacidad

824_021 Apend J.indd 283 22/1/10 13:59:55

824_021 Apend J.indd 284 22/1/10 13:59:55

Apéndice J: Los contenidos típicos de un Plan
de Capacidad
Los contenidos típicos de un Plan de Capacidad son los
siguientes.
1  Introducción
Esta sección explica brevemente el trasfondo del Plan de
Capacidad, cómo se genera y qué contiene. Por ejemplo:
■■ Los servicios, tecnología y recursos actuales
■■ Los niveles de capacidad actuales de la organización
■■ Problemas que se están experimentando y
concibiendo debido a una sobrecapacidad o falta de
capacidad
■■ El grado en el que se están logrando los niveles de
servicio
■■ Qué ha cambiado desde el último problema del plan.
2  Resumen ejecutivo
La mayor parte del Plan de Capacidad contiene, por
necesidad, detalles técnicos que no son de interés para
todos los lectores del plan. El resumen ejecutivo debe
resaltar los aspectos, opciones, recomendaciones y costes
principales. Podría ser necesario generar un documento
independiente de resumen ejecutivo que contenga los
puntos principales de cada una de las secciones del plan
principal.
4  Escenarios de negocio
Es necesario poner el plan en el contexto del entorno de
negocio actual y concebido. Por ejemplo, una aerolínea
británica planificó trasladar a un gran número de
miembros de su personal al edificio de su sede principal.
Se hizo una previsión de 1,7 personas por terminal de
escritorio. Se alertó de ello a Gestión de la Capacidad y
ésta fue capaz de calcular el tráfico de red adicional que
se podría generar.
Es importante mencionar explícitamente todas las
previsiones conocidas de negocio para que los lectores
puedan determinar lo que está dentro y fuera del ámbito
del plan. Debe incluir el crecimiento anticipado en los
servicios existentes, los servicios nuevos potenciales y los
servicios existentes que se prevé clausurar.
824_021 Apend J.indd 285
| 285
4  Ámbito y términos de referencia
del plan
Idealmente, el Plan de Capacidad debe abarcar todos los
recursos de TI. Esta sección debe nombrar explícitamente
aquellos elementos de la infraestructura de TI que se
incluyen y aquellos que se excluyen, si hubiera.
5  Métodos utilizados
El Plan de Capacidad utiliza información recopilada por los
subprocesos. Por lo tanto, esta subsección debe contener
detalles de cómo y cuándo se obtuvo esta información,
por ejemplo, previsiones del negocio obtenidas de planes
de negocio, previsiones de la carga de trabajo obtenidas
de los clientes, previsiones de nivel de servicio obtenidas
por el uso de herramientas de modelado.
6  Suposiciones hechas
Es importante resaltar con anticipación en el plan
cualquier suposición hecha, particularmente aquellas
concernientes a las directrices de negocio para la
Capacidad de TI. Si fueran los principios básicos sobre
los que se construyen más cálculos detallados, entonces
es fundamental que todos los implicados entiendan este
hecho.
7  Resumen del servicio
La sección del resumen del servicio debe incluir:
■■ Provisión actual y reciente del servicio: para cada
servicio que se entregue, proporcione un perfil del
servicio. Esto debe incluir ratios de rendimiento y
la utilización de recursos resultante – por ejemplo,
de memoria, espacio de almacenamiento, tasas de
transferencia, uso del procesador y uso de red. Aquí
deben presentarse tendencias a corto, medio y largo
plazo.
■■ Previsiones del servicio: los planes de negocio
deben proporcionar a Gestión de Capacidad detalles
de los nuevos servicios planificados y del crecimiento
o reducción del uso de servicios existentes. Esta
subsección debe informar sobre nuevos servicios y
sobre la retirada de sistemas heredados.
22/1/10 13:59:55
 286 | Apéndice J: Los contenidos típicos de un Plan de Capacidad

8  Resumen de recursos también deben incluirse las implicaciones si el plan y sus

recomendaciones no se implementaran.
La sección del resumen de recursos debe incluir:
Las recomendaciones deben cuantificarse en términos de:
■■ Uso actual y reciente de recursos: esta subsección
se concentra en el uso de recursos resultante de los ■■ Los beneficios esperados para el negocio
servicios. Informa, nuevamente, sobre las tendencias ■■ Impacto potencial a la hora de llevar a cabo las
a corto, medio y largo plazo del uso de recursos, recomendaciones
desglosado por plataforma de hardware. Esta ■■ Riesgos implicados
información ha sido recopilada y analizada por los ■■ Recursos requeridos
subprocesos de Gestión de la Capacidad del Servicio y ■■ Coste, para la configuración y continuidad.
por Gestión de la Capacidad del Componente y debe
estar disponible.
■■ Previsiones de recursos: esta subsección prevé el uso
probable de recursos que resulta de las previsiones
del servicio. Aquí debe abordarse cada escenario de
negocio mencionado anteriormente. Por ejemplo, un
negocio de venta al por mayor de alfombras en el
Norte de Inglaterra podía predecir con precisión cuál
sería el uso medio y el pico de uso del procesador
antes de decidir absorber a un negocio rival. Se
probó que no se requeriría una actualización. Esto se
reflejó en el modelo de costes, lo que condujo a una
absorción satisfactoria.

9  Opciones de mejora del servicio

En función de los resultados de la sección anterior, esta
sección describe las posibles opciones de mejora de la
eficacia y eficiencia de la Provisión del Servicio. Podría
contener opciones para combinar diferentes servicios en
un único procesador, actualizar la red para beneficiarse
de las ventajas tecnológicas, ajustar el uso de recursos o
del rendimiento del servicio, rescribir sistemas heredados,
comprar nuevo hardware o software, etc.

10  Previsión de costes

Aquí deben documentarse los costes asociados con estas
opciones. Además, debe incluirse el coste actual y previsto
del suministro de los servicios de TI. En la práctica, Gestión
de la Capacidad obtiene mucha de esta información
procedente del proceso Gestión Financiera y del Plan
Financiero de TI.

11  Recomendaciones
La sección final del plan debe contener un resumen
de las recomendaciones realizadas en el plan anterior
y de su estado, por ejemplo, rechazado, planificado,
implementado, y de cualquier varianza del plan. Aquí
debe hacerse cualquier nueva recomendación, es decir,
cuál de las opciones mencionadas en el plan se prefiere, y

824_021 Apend J.indd 286 22/1/10 13:59:55

 Apéndice K:
Los contenidos típicos de
un plan de recuperación

824_022 Apend K.indd 287 22/1/10 14:00:44

824_022 Apend K.indd 288 22/1/10 14:00:44
 | 289

Apéndice K: Los contenidos típicos de un plan

de recuperación
Los contenidos típicos de un plan de recuperación de
ITSCM son los siguientes.

PLAN GENÉRICO DE RECUPERACIÓN

1  CONTROL DE DOCUMENTOS
Este documento debe mantenerse para garantizar que
los sistemas, Infraestructura e instalaciones incluidos,
den soporte convenientemente a los requisitos de
recuperación del negocio.

1.1  Distribución del documento

Copia Emitido por Fecha Puesto
1.
2.
3.
4.

1.2  Revisión del documento

Este documento se revisará cada X meses.
Revisión actual: fecha
Próxima revisión: fecha

Fecha de la revisión Nº de versión Resumen de Cambios

1.3  Aprobación del documento

Este documento debe estar aprobado por el siguiente
personal:

Nombre Cargo Firma

824_022 Apend K.indd 289 22/1/10 14:00:44

 290 | Apéndice K: Los contenidos típicos de un plan de recuperación
2  INFORMACIÓN DE SOPORTE
2.1  Introducción
Este documento detalla las instrucciones y procedimientos
que es necesario seguir para recuperar o continuar
la operación de sistemas, Infraestructura, servicios o
instalaciones para mantener la Continuidad de los
Servicios hasta el nivel definido o acordado con el
negocio.
2.2  Estrategia de recuperación
Los sistemas, Infraestructura, servicios o instalaciones
se recuperarán en sistemas, Infraestructura, servicios o
instalaciones alternativos.
Se requerirán aproximadamente X horas para recuperar
los sistemas, Infraestructura, servicios o instalaciones. El
sistema se recuperará hasta el último punto conocido de
estabilidad/integridad de los datos, que es punto en el día/
duración.
El tiempo requerido de recuperación para este sistema,
Infraestructura, servicio e instalación es:
El tiempo de recuperación y procedimientos para este
sistema, Infraestructura, servicio o instalación:
2.3  Invocación
El siguiente personal está autorizado para invocar este
plan:
1 esto, las acciones deben estar en un formato de lista de
2
2.4 Interfaces y dependencias con otros
planes
Detalles de referencias e interrelaciones con todos los
demás planes de continuidad y recuperación y cómo se
activan las interfaces.
Sistema Referencia de documento
824_022 Apend K.indd 290
2.5  Guía general
Debe hacerse referencia a todas las solicitudes de
información de los medios o de otros recursos en el
Procedimiento de la compañía.
Al notificar al personal un desastre potencial o real, siga
los procedimientos operativos de escalado definidos, y
en particular:
■■ Mantenga la calma y evite conversaciones largas
■■ Avíseles de la necesidad de hacer referencia a
solicitudes de información al punto de escalado
■■ Avíseles de las expectativas y acciones (evite
darles detalles de la incidencia a menos que sea
absolutamente necesario)
■■ Si la llamada fuera respondida por otra persona:
●● Pregunte si el contacto está disponible en algún
otro lugar
●● Si no pudiera ponerse en contacto con ellos, deje
un mensaje para que se pongan en contacto con
usted en un número determinado
●● No proporcione detalles de la incidencia
●● Documente siempre los detalles, respuestas y
acciones en el tiempo de llamada.
Todas las actividades y contacto/escalado deben
registrarse claramente y con precisión. Para facilitar
comprobación y debería haber espacio para registrar la
fecha y hora en las que se inició y completó la actividad, y
quién la llevó a cabo.
2.6  Dependencias
Deben documentarse las dependencias del Sistema,
Infraestructura, servicio, instalación o interfaz (en orden
de prioridad) para que se puedan identificar y activar los
planes y procedimientos asociados que será necesario
invocar junto con este plan de recuperación. La persona
responsable de la invocación debe garantizar que las
Contacto
22/1/10 14:00:44
 Apéndice K: Los contenidos típicos de un plan de recuperación | 291

actividades de recuperación se coordinen con estos otros

planes.

Nombre Organización/Rol Cargo Detalles de Contacto

2.7  Listas de contactos

Listas de todos los nombres de contacto, organizaciones
y detalles y mecanismos de contacto:

Nombre Cargo Detalles de Contacto

2.8  Equipo de recuperación 2.9 Lista de comprobación del equipo de

El siguiente personal/funciones son responsables de recuperación
activar estos procedimientos o de asegurar que se activen, Para facilitar la realización de actividades clave de forma
registrando cualquier problema encontrado. El contacto oportuna, debe utilizarse una lista de comprobación
se realizará a través de los procedimientos normales de similar a la siguiente.
escalado.
Tarea Cumplimiento del objetivo Cumplimiento real
Confirmar invocación
Iniciar el árbol de llamadas y los
procedimientos de escalado
Promover y hacer de interfaz con cualquier
otro plan de recuperación necesario (por
ejemplo, BCP, Gestión de Crisis, Plan de
Respuesta de Emergencia)
Disposición de los medios de backup
y documentación que se enviarán a los
emplazamientos de recuperación
Establecer equipos de recuperación
Iniciar acciones de recuperación
Confirmar informes de progreso
Informar al equipo de recuperación de los
requisitos de información

824_022 Apend K.indd 291 22/1/10 14:00:44

 292 | Apéndice K: Los contenidos típicos de un plan de recuperación

Tarea Cumplimiento del objetivo Cumplimiento real

Confirmar los requisitos de comunicación
con todos los equipos de recuperación
Avisar a los clientes y a la dirección de la
finalización estimada de la recuperación

3  PROCEDIMIENTO DE RECUPERACIÓN
Introduzca aquí las instrucciones/procedimientos de
recuperación o las referencias a todos los procedimientos
de recuperación.
El contenido/formato debe estar en línea con los
estándares de la compañía para los procedimientos. Si no
hubiera ninguno, el Responsable o el Jefe de Equipo del
área responsable debe emitir una guía para el sistema,
Infraestructura, servicios o instalación. La única directriz
es que un profesional experimentado debe ser capaz
de ejecutar las instrucciones sin depender en exceso del
conocimiento local.
Si fuera necesario, deben hacerse referencias a
documentación de soporte (y a su ubicación), diagramas y
otras fuentes de información. Esto debe incluir el número
de referencia de documento (si existiera). El autor del
plan es responsable de garantizar que esta información
se mantenga con este plan. Si sólo hubiera una cantidad
limitada de información de soporte, podría ser más fácil
incluirla dentro del plan, siempre que este plan siguiera
siendo fácil de leer/seguir y que no se transformara en
algo demasiado engorroso.

824_022 Apend K.indd 292 22/1/10 14:00:44

 Información adicional

824_023 Additonal Info.indd 293 22/1/10 14:01:14

824_023 Additonal Info.indd 294 22/1/10 14:01:14
 Información adicional
Referencias
1. Estrategia del Servicio
2. Transición del Servicio
3. Operación del Servicio
4. Mejora Continua del Servicio
5. Peter Drucker
6. COBIT – ISACA
7. CMMI – CMU
8. eSCM-Service Portfolio – CMU
9. PRINCE2 – OGC
10. ISO 9000
11. ISO/IEC 20000
12. ISO 27001
13. Enterprise Architecture – Gartner
14. Plan Do Check Act – W Edwards Deming
15. Balanced Scorecard – Kaplan/Norton
16. Service Oriented Architecture – OASIS
17. Management of Risk – OGC
18. Recommended Practice for Software Requirements
Specification (IEEE 830)
19. The Software Engineering Body of Knowledge
(SWEBOK)
20. Object Management Architecture – OMG
21. Common Information Model (CIM) – DMTF
22. Web-Based Enterprise Management (WEBM) – DMTF
23. Application Management Specification – IBM
24. Windows Management Instrumentation – Microsoft
25. Desktop Management Instrumentation – Windows
26. Six Sigma – Motorola Inc
27. Dynamics of Software Development – Jim McCarthy
28. Requirements engineering; examples of tacit and
explicit knowledge (Maiden & Rugg, 1995)
29. Business Analysis – Deborah Paul y Donald Yeates
30. Principles of Data Management – Keith Gordon
31. Practical Data Migration – John Morris

824_023 Additonal Info.indd 295 22/1/10 14:01:14

824_023 Additonal Info.indd 296 22/1/10 14:01:14
 Glosario

824_024 Glossary.indd 297 22/1/10 14:01:37

824_024 Glossary.indd 298 22/1/10 14:01:37
 Lista de acrónimos

ACD Distribución Automática de Llamadas

AM Gestión de la Disponibilidad
AMIS Sistema de Información de Gestión de la Disponibilidad
ASP Proveedor de Servicios de Aplicaciones
BCM Gestión de la Capacidad del Negocio
BCM Gestión de la Continuidad del Negocio
BCP Plan de la Continuidad del Negocio
BIA Análisis de Impacto en el Negocio
BRM Gestor de las Relaciones con el Negocio
BSI British Standards Institution
BSM Gestión del Servicio de Negocio
CAB Comité de Cambios
CAB/EC Comité de Cambios / Comité de Emergencia
CAPEX Gasto de Capital
CCM Gestión de la Capacidad del Componente
CFIA Análisis de Impacto de Fallos de Componentes
CI Elemento de Configuración
CMDB Base de Datos de Gestión de la Configuración
CMIS Sistema de Información de Gestión de la Capacidad
CMM Modelo de Madurez de la Capacidad
CMMI Modelo de Integración de Madurez de la Capacidad
CMS Sistema de Gestión de la Configuración
COTS Producto Software Empaquetado
CSF Factores Críticos de Éxito
CSI Mejora Continua del Servicio
CSIP Plan de Mejora Continua del Servicio
CSP Paquete de Servicio Esencial
CTI Integración de Telefonía e Informática
DIKW Datos-a-Información-a-Conocimiento-a-Sabiduría
ELS Soporte Post-Implantación
eSCM–CL Modelo de Madurez del eSourcing para Organizaciones Cliente
eSCM–SP Modelo de Madurez del eSourcing para Proveedores de Servicio
FMEA Modos de Fallo y Análisis de Efectos
FTA Análisis del Árbol de Fallos
IRR Tasa Interna de Retorno
ISG Consejo de Dirección de TI
ISM Gestión de la Seguridad de la Información
ISMS Sistema de Gestión de la Seguridad de la Información
ISO Organización Internacional de Normalización

824_024 Glossary.indd 299 22/1/10 14:01:37

 300 | Glosario

ISP Proveedor de servicios de Internet

TI Tecnologías de la Información
ITSCM Gestión de la Continuidad del Servicio de TI
ITSM Gestión de los Servicios de TI
itSMF Foro para la Gestión de los Servicios de TI
IVR Respuesta Interactiva de Voz
KEDB Base de Datos de Errores Conocidos
KPI Indicador Clave de Rendimiento
LOS Línea de Servicio
M_o_R Gestión del Riesgo
MTBF Tiempo Medio entre Fallos
MTBSI Tiempo Medio entre Incidencias de Servicio
MTRS Tiempo Medio de Restauración del Servicio
MTTR Tiempo Medio de Reparación
NPV Valor Neto Actual
OGC Office of Government Commerce
OLA Acuerdo de Nivel Operativo
OPEX Gasto Operativo
OPSI Oficina de Información del Sector Público
PBA Patrones de Actividad de Negocio
PIR Evaluación Post Implementación
PFS Prerrequisitos para el Éxito
PSO Parada de Servicio Planificada
QA Aseguramiento de la Calidad
QMS Sistema de Gestión de la Calidad
RCA Análisis de la Causa Raíz
RFC Solicitud de Cambio
ROI Retorno de la Inversión
RPO Punto Objetivo de Recuperación
RTO Objetivo de Tiempo de Recuperación
SoC Separación en asuntos
SAC Criterios de Aceptación del Servicio
SACM Gestión de la Configuración y de los Activos del Servicio
SCD Base de Datos de Suministradores y de Contratos
SCM Gestión de la Capacidad del Servicio
SDP Paquete para el Diseño del Servicio
SFA Análisis de fallos del servicio
SIP Programa de Mejora de Servicio
SKMS Sistema de Gestión del Conocimiento del Servicio
SLA Acuerdo de Nivel de Servicio
SLM Gestión del Nivel de Servicio
SLP Paquete del nivel de servicio
SLR Requerimientos de Nivel de Servicio

824_024 Glossary.indd 300 22/1/10 14:01:37

 Glosario | 301

SMO Objetivo de la Gestión de Servicios

SOP Procedimientos de Operación Estándar
SOR Declaración de Requisitos
SPI Interlocutor con el Proveedor de Servicios
SPM Gestión de la Cartera de Servicios
SPO Optimización de la Provisión del Servicio
SPOF Punto Único de Fallo
TO Observación Técnica
TOR Términos de Referencia
TCO Coste Total de Propiedad
TCU Coste Total de Utilización
TQM Gestión de Calidad Total
UC Contrato de Soporte
UP Perfil de Usuario
VBF Función Vital del Negocio
VOI Valor de la Inversión
WIP Trabajo en Curso

824_024 Glossary.indd 301 22/1/10 14:01:37

 Lista de definiciones
Los nombres de la publicación incluidos entre paréntesis amplio. Los términos con varios nombres de publicaciones se
después del nombre de un término, identifican el lugar amplían en múltiples publicaciones.
donde un lector podrá encontrar más información sobre
Donde la definición de un término incluya otro término,
ese término. Esto se debe a que esa publicación utiliza
aquellos términos asociados se resaltarán con un segundo
principalmente ese término o porque allí se podrá encontrar
color. Esto se ha considerado así para indicar a los lectores
información útil adicional sobre el mismo. Generalmente,
definiciones adicionales que forman parte del término
puede que los términos sin un nombre de publicación
original del que están interesados. La forma ‘Vea también
asociado sean utilizados por varias publicaciones, o es posible
Término X, Término Y’ se utiliza al final de una definición si
que estén definidos con mayor detalle que en el glosario,
no se utilizara un término asociado importante con el texto
es decir, sólo indicamos a los lectores algún lugar en el que
de la propia definición.
puedan ampliar su conocimiento o ver un contexto más

Aceptación Acuerdo formal que indica que un Servicio de TI, Proceso, Plan, u
otro Entregable se ha completado, es preciso, fiable y cumple los
requisitos especificados. Normalmente la Aceptación está precedida
por una Evaluación o Prueba y se requiere antes de proceder con la
siguiente etapa de un Proyecto o Proceso. Vea también Criterios de
Aceptación del Servicio.
Actividad Un conjunto de acciones disen~adas para alcanzar un resultado
específico. Normalmente, las Actividades se definen como parte de
Procesos o Planes, y se documentan en Procedimientos.
Activo (Estrategia del Servicio) Cualquier Recurso o Capacidad. Los
Activos de un Proveedor de Servicio incluyen todo aquello que
se pueda atribuir a la entrega del Servicio. Los Activos pueden ser
de los siguientes tipos: De Gestión, Organizativos, de Proceso, de
Conocimiento, Personas, Información, Aplicaciones, Infraestructura, y
de Capital.
Activo del Servicio Cualquier Capacidad o Recurso de un Proveedor de Servicio. Vea
también Activo.
Acuerdo Documento que describe el entendimiento formal entre dos o más
partes. Un Acuerdo no tiene fuerza legal, a menos que forme parte
de un Contrato. Vea también Acuerdo de Nivel de Servicio, Acuerdo
de Nivel Operativo.
Acuerdo de Nivel de Servicio (SLA) (Disen~o del Servicio) (Mejora Continua del Servicio) Consiste en el
Acuerdo entre un Proveedor de Servicios de TI y un Cliente. El SLA
describe el Servicio de TI, documenta los Objetivos de Nivel de
Servicio y especifica las responsabilidades del Proveedor de Servicios
de TI y del Cliente. Un único SLA puede cubrir varios Servicios de TI
o varios Clientes. Vea también Acuerdo de Nivel Operativo.
Acuerdo Recíproco (Disen~o del Servicio) Una Opción de Recuperación. Un acuerdo
entre dos Organizaciones para compartir recursos en una
emergencia. Por ejemplo, espacio de una Sala Informática o uso de
un mainframe.

824_024 Glossary.indd 302 22/1/10 14:01:37

 Glosario | 303

Acuerdos de Nivel Operativo (OLA) (Disen~o del Servicio) (Mejora Continua del Servicio) Consiste en el
Acuerdo entre un Proveedor de Servicios de TI y otra parte de la
misma Organización. Un OLA apoya la entrega de Servicios de TI
del Proveedor de Servicios de TI a los Clientes. El OLA define los
bienes y Servicios que se suministrarán y las responsabilidades de
ambas partes. Por ejemplo, podrá haber un OLA:
■■ Entre el Proveedor de Servicios de TI y un departamento de
compras para obtener hardware en los plazos acordados
■■ Entre el Centro de Servicio al Usuario y un Grupo de Soporte
para la Resolución de Incidencias en los plazos acordados.
Vea también Acuerdo de Nivel de Servicio.
Ajustado al Propósito Un término informal usado para describir un Proceso, Elemento de
Configuración, Servicio de TI, etc., que es capaz de cumplir sus
Objetivos o Niveles de Servicio. Estar Ajustado al Propósito requiere
un disen~o, implementación, control y mantenimiento adecuados.
Ajuste La Actividad responsable de la Planificación de Cambios para que
el uso de los Recursos sea más eficiente. El Ajuste forma parte
de la Gestión del Rendimiento, que incluye Monitorización del
Rendimiento y la implementación de los cambios requeridos.
Alerta (Operación del Servicio) Advertencia de que se ha superado un
umbral, de que algo ha cambiado, o de que se produjo un Fallo.
De forma regular, las Alertas se crean y gestionan con herramientas
de Gestión de Sistemas y están administradas por el Proceso de
Gestión de Eventos.
Alta Disponibilidad (Disen~o del Servicio) Una metodología o disen~o que minimiza u
oculta a los Usuarios de un Servicio de TI los efectos del Fallo de
un Elemento de Configuración. Las soluciones de Alta disponibilidad
se disen~an para alcanzar los niveles acordados de disponibilidad y
para hacer uso de técnicas como la Tolerancia a Fallos, Resistencia
y Recuperación rápida, para reducir el número de Incidencias y el
Impacto de las mismas.
Ámbito El límite o grado en el que se aplica un Proceso, Procedimiento,
Certificación, Contrato, etc. Por ejemplo, el Ámbito de la
Gestión de Cambios puede incluir todos los Servicios de TI
reales y Elementos de Configuración asociados, el Ámbito de un
Certificado ISO/IEC 20000 puede incluir todos los Servicios de TI
implementados desde un centro de datos en cuestión.
Amenaza Cualquier cosa que pueda aprovechar un Vulnerabilidad. Cualquier
causa potencial de una Incidencia puede ser considerada una
Amenaza. Por ejemplo, un fuego es una Amenaza que puede
aprovechar la Vulnerabilidad de moquetas inflamables. Este
término se utiliza comúnmente en la Gestión de la Seguridad de
la Información y en la Gestión de la Continuidad del Servicio de
TI, pero también se aplica a otras áreas tales como Gestión de la
Disponibilidad y Problemas.
Análisis Coste-Beneficio Una Actividad que analiza y compara los costes y los beneficios
involucrados en uno o más cursos de acción alternativos. Vea
también Caso de Negocio, Retorno de la Inversión.
Análisis DAFO (Mejora Continua del Servicio) Una técnica que revisa y analiza
los puntos fuertes y débiles internos de una Organización, y
las oportunidades externas y amenazas que afronta. DAFO es el
acrónimo de Debilidades, Amenazas, Fortalezas y Oportunidades.

824_024 Glossary.indd 303 22/1/10 14:01:37

 304 | Glosario
Análisis de Fallos del Servicio (SFA)
Análisis de Impacto de Fallos de Componentes (CFIA)
Análisis de Impacto en el Negocio (BIA)
Análisis de tendencias
Análisis del Árbol de Fallos (FTA)
Aplicación
Aprovisionamiento de Servicios Externo
Aprovisionamiento de Servicios Interno
Arquitectura
Asociación
824_024 Glossary.indd 304
(Disen~o del Servicio) Una Actividad que identifica las causas
subyacentes de una o más interrupciones del Servicio de TI.
SFA identifica oportunidades y herramientas de mejora tanto
de Procesos del Proveedor de Servicios de TI como de la
Infraestructura de TI. SFA es más una Actividad de tipo proyecto
limitada en tiempo que un proceso continuo de análisis.
(Disen~o del Servicio) Técnica utilizada para ayudar a identificar el
impacto que produce un fallo de CI sobre los Servicios de TI. Se
elabora a partir de una matriz que contiene los Servicios de TI en
un extremo y los CI en el otro. Esto permite la identificación de
los CI críticos (que podrían provocar el fallo de múltiples Servicios
de TI) y de los Servicios de TI poco robustos (que tienen múltiples
Puntos Únicos de Fallo).
(Estrategia del Servicio) BIA es la Actividad de la Gestión de la
Continuidad del Negocio que identifica las Funciones Vitales del
Negocio y sus dependencias. Estas dependencias pueden incluir
Proveedores, personas, otros Procesos de Negocio, Servicios de
TI, etc. BIA define los requisitos de recuperación para los Servicios
de TI. Dichos requisitos incluyen Objetivos de Tiempos de
Recuperación, Objetivos del Punto de Recuperación y los Objetivos
de Nivel de Servicio mínimos para cada Servicio de TI.
(Mejora Continua del Servicio) El análisis de datos para identificar
patrones en el tiempo. Análisis de Tendencias se utiliza en Gestión
de Problemas para identificar Fallos comunes o Elementos de
Configuración frágiles, y en Gestión de Capacidad como una
herramienta de modelización para predecir el comportamiento
futuro. También se usa como una herramienta de gestión para
identificar deficiencias en los Procesos de Gestión de los Servicios
de TI.
(Disen~o del Servicio) (Mejora Continua del Servicio) Una técnica
que puede usarse para determinar la cadena de Eventos que lleva a
un Problema. El Análisis del Árbol de Fallos representa la cadena de
Eventos utilizando notación Booleana en un diagrama.
Programa que provee Funciones requeridas por un Servicio de TI.
Cada Aplicación podría ser parte de más de un Servicio de TI. Una
Aplicación se puede ejecutar en uno o más Servidores o Clientes.
Vea también Gestión de Aplicaciones, Porfolio de Aplicaciones.
Vea Externalizar.
(Estrategia del Servicio) Uso de un Proveedor Interno de Servicios
para la gestión de Servicios de TI.
(Disen~o del Servicio) La estructura de un Sistema o un Servicio de
TI, incluyendo las Relaciones de sus Componentes y del entorno
en el que se encuentran. La Arquitectura también incluye los
Estándares y las Directrices que dirigen el disen~o y evolución del
Sistema.
Es una relación entre dos Organizaciones que supone una estrecha
colaboración entre ambas, orientada a la consecución de objetivos
comunes para el beneficio mutuo. Un Proveedor de Servicios de TI
debería tener una relación de Sociedad con el Negocio, así como
con aquellos Terceros que sean críticos para proveer los Servicios
de TI. Vea también Red de Valor.
22/1/10 14:01:37
 Glosario | 305

Atributo (Transición del Servicio) Una parte de información de un Elemento

de Configuración. Ejemplos: nombre, ubicación, Número de la
versión, y Coste. Los Atributos de un CI se registran en la Base
de Datos de Gestión de la Configuración (CMDB). Vea también
Relación.
Auditoría Inspección y verificación formal para verificar si un Estándar o
un conjunto de Directrices se está siguiendo, que sus Registros
son precisos, o que las metas de Eficiencia y Eficacia se están
cumpliendo. Una Auditoría la puede realizar tanto un grupo interno
como externo. Vea también Certificación, Evaluación.
Backup (Disen~o del Servicio) (Operación del Servicio) Copiar datos para
protegerlos de la pérdida de Integridad o Disponibilidad de los
datos originales.
Base de Conocimiento (Transición del Servicio) Base de datos lógica que contiene los
datos empleados por el Sistema de Gestión del Conocimiento del
Servicio.
Base de Datos de Contratos y Proveedores (SCD) (Disen~o del Servicio) Una base de datos o Documento estructurado
que se usa para gestionar Contratos del Suministrador en su Ciclo
de Vida. El SCD contiene Atributos clave para todos los Contratos
con Suministradores, y debería formar parte del Sistema de Gestión
del Conocimiento del Servicio.
Benchmark (Mejora Continua del Servicio) El estado registrado de algo en un
punto específico de tiempo. Un Benchmark se puede crear para
una Configuración, Proceso, o cualquier otro conjunto de datos.
Por ejemplo, se puede usar un benchmark en:
■■ Mejora Continua del Servicio, para establecer el estado actual
para gestionar las mejoras
■■ Gestión de Capacidad, para documentar características de
Rendimiento durante las operaciones normales.
Vea también Benchmarking, Línea de Referencia.
Benchmarking (Mejora Continua del Servicio) Comparar un Benchmark con
una Línea de Referencia o con una Mejor Práctica. El término
Benchmarking también se usa para referirse a la creación de una
serie de Benchmarks en el tiempo, y comparar los resultados para
medir el progreso o la mejora.
Cadena de Suministro (Estrategia del Servicio) Actividades en la Cadena de Valor
acometidas por Suministradores. Una Cadena de Suministro
implica típicamente múltiples Suministradores, cada uno de ellos
aportando valor al producto o Servicio. Vea también Red de Valor.
Cadena de Valor (Estrategia del Servicio) Una secuencia de Procesos que crea un
producto o Servicio que proporciona valor a un Cliente. Cada paso
de la secuencia se apoya en los pasos anteriores y contribuye al
conjunto del producto o Servicio. Vea también Red de Valor.
Cambios (Transición del Servicio) Adición, modificación o eliminación de
algo que podría afectar a los Servicios de TI. El Alcance debería
incluir todos los Servicios de TI, Elementos de Configuración,
Procesos, Documentación, etc.
Capacidad (Disen~o del Servicio) Rendimiento máximo que se puede
obtener de un Elemento de Configuración o Servicio de TI en el
cumplimiento de los Objetivos de Nivel de Servicio acordados.
Para algunos tipos de CI, la Capacidad puede ser el taman~o o el
volumen, por ejemplo, de una unidad de disco.

824_024 Glossary.indd 305 22/1/10 14:01:37

 306 | Glosario
Capacidad de Mantenimiento
Capacidad de Recuperación
Capacidad de Respuesta
Capacidad de Servicio
Carga de Trabajo
Caso de Negocio
Caso de Uso
Catálogo de servicios
Categoría
Causa Raíz
824_024 Glossary.indd 306
(Disen~o del Servicio) Medida de cómo de rápida y Eficazmente
se puede restaurar un Elemento de Configuración o Servicio de TI
hasta alcanzar su funcionamiento normal después de un Fallo. La
Capacidad de Mantenimiento se mide y se informa frecuentemente
como MTRS. El término
Capacidad de Mantenimiento se emplea también en el contexto de
Desarrollo de Software o Desarrollo de Servicios de TI refiriéndose
a la capacidad de ser Cambiado o Reparado fácilmente.
(Disen~o del Servicio) La capacidad de resistencia de un Elemento
de Configuración o Servicio de TI ante Fallos o de Recuperarse
rápidamente tras un Fallo. Por ejemplo, un cable reforzado resistirá
fallos cuando esté bajo estrés. Vea también Tolerancia a Fallos.
Medida del tiempo consumido para responder a algo. Podría ser un
Tiempo de Respuesta o una Transacción, o la velocidad a la que
un Proveedor de Servicios de TI responde a una Incidencia o a una
Solicitud de Cambio, etc.
(Disen~o del Servicio) (Mejora Continua del Servicio) Capacidad de
un Proveedor Externo para cumplir los términos de su Contrato.
Este Contrato incluye los niveles acordados de Fiabilidad,
Capacidad de Mantenimiento y Disponibilidad de un Elemento de
Configuración.
Los Recursos requeridos para entregar una parte identificable de
un Servicio de TI. Las Cargas de Trabajo pueden Categorizarse por
Usuarios, grupos de Usuarios, o Funciones dentro de un Servicio
de TI. Se usa para ayudar en el análisis y gestión de la Capacidad,
Rendimiento y Uso de Elementos de Configuración y Servicios de
TI. El término Carga de Trabajo se usa a veces como sinónimo de
Rendimiento.
(Estrategia del Servicio) Justificación para el gasto de un elemento
relevante. Incluye información de Costes, beneficios, opciones,
situaciones, Riesgos, y posibles problemas. Vea también Análisis
Coste-Beneficio.
(Disen~o del Servicio) Una técnica usada para definir la funcionalidad
requerida, Objetivos y para el Disen~o de Pruebas. Los Casos de
Uso definen escenarios realistas que describen las interacciones
entre Usuarios y un Servicio de TI u otro Sistema.
(Disen~o del Servicio) Una base de datos o un Documento
estructurado con información sobre todos los Servicios de TI
reales, incluyendo aquellos disponibles para el Despliegue. El
Catálogo de Servicios es la única parte publicada del Portfolio de
Servicios para Clientes, y se utiliza para apoyar la venta y entrega
de los Servicios de TI. El Catálogo de Servicios incluye puntos de
contacto, solicitud y Procesos de petición.
Grupo nominal de cosas que tienen algo en común. Las Categorías
se usan para agrupar distintos contenidos. Por ejemplo, los Tipos
de Coste se usan para agrupar clases similares de Costes. Las
Categorías de Incidencias se usan para agrupar tipos similares de
Incidencias, Los Tipos de CI, se usan para agrupar distintas clases
de Elementos de Configuración.
(Operación del Servicio) La causa original o subyacente de una
Incidencia o Problema.
22/1/10 14:01:37
 Glosario | 307

Centro de Llamadas (Operación del Servicio) Organización o Unidad de Negocio que

maneja gran cantidad de llamadas telefónicas entrantes y salientes.
Vea también Centro de Servicio al Usuario.
Centro de Servicio al Usuario (Operación del Servicio) Punto Único de Contacto entre el
Proveedor de Servicio y los Usuarios. Un Centro de Servicio al
Usuario típico gestiona Incidencias, Peticiones de Servicio, y
también maneja la comunicación con los Usuarios.
Cerrado (Operación del Servicio) Estado final en el Ciclo de Vida de una
Incidencia, Problema, Cambio, etc. Cuando el Estado es Cerrado,
no se requiere ninguna acción adicional.
Certificación Emisión de un certificado que acredita la Conformidad con un
Estándar. La Certificación incluye una Auditoría formal realizada por
un organismo independiente y Acreditado. El término Certificación
también se usa para denotar la concesión de un certificado que
acredita que una persona ha logrado una cualificación determinada.
CI de componente (Transición del Servicio) Un Elemento de Configuración que forma
parte de una Agrupación. Por ejemplo, una CPU o CI de memoria
puede formar parte de un CI Servidor.
Ciclo de Vida Las diversas etapas en la vida de un Servicio de TI, Elemento de
Configuración, Incidencia, Problema, Cambio, etc. El Ciclo de Vida
define las Categorías de cada Estado y las transiciones de Estado
permitidas. Por ejemplo:
■■ El Ciclo de Vida de una Aplicación incluye Requisitos, Dise n~ar,
Construir, Desplegar, Operar, Optimizar
■■ El Ciclo de Vida Expandido de la Incidencia incluye Detectar,
Responder, Diagnosticar, Reparar, Recuperar, Restaurar.
■■ El Ciclo de Vida de un Servidor puede incluir: Pedido, Recibido,
En Prueba, Real, Eliminado, etc.
Ciclo de Vida de la Gestión del Servicio Aproximación a la Gestión de los Servicios de TI que pone énfasis
en la importancia de la coordinación y el Control a través de las
diferentes Funciones, Procesos y Sistemas necesarios para gestionar
el Ciclo de Vida total de los Servicios de TI. La aproximación
del Ciclo de Vida de la Gestión del Servicio incluye la Estrategia,
Disen~o, Transición, Operación y Mejora Continua de los Servicios
de TI.
Ciclo de Vida Expandido de la Incidencia (Gestión de la Disponibilidad) Etapas detalladas en el Ciclo de
Vida de una Incidencia. Las etapas son Detección, Diagnóstico,
Reparación, Recuperación y Restauración. El Ciclo de Vida
Expandido de la Incidencia se usa para ayudar a la comprensión
de las diferentes contribuciones al Impacto de Incidencias y para
Planificar cómo controlarlas y reducirlas.
Cierre (Operación del Servicio) Acción de cambiar el Estado de una
Incidencia, Problema, Cambio, etc., a Cerrado.
Clasificación Acción de asignar una Categoría a algo. La Clasificación se usa con
el objeto de asegurar la calidad de la información y una gestión
consistente. Típicamente se Clasifican CIs, Incidentes, Problemas,
Cambios etc.

824_024 Glossary.indd 307 22/1/10 14:01:38

 308 | Glosario

Cliente Término genérico que describe un Cliente, Negocio o Cliente de

Negocio. Por ejemplo, Gestor de Clientes podría utilizarse como
sinónimo de Gestor de Cuentas. El término cliente también se
usa para definir:
■■ Un ordenador que un Usuario utiliza directamente, por
ejemplo, un PC, un portátil, o estación de trabajo
■■ La parte de una Aplicación Cliente-Servidor con el que el
Usuario se conecta directamente. Por ejemplo, un Cliente de
correo electrónico.
Cliente Alguien que compra bienes o Servicios. El Cliente de un Proveedor
de Servicios de TI es la persona o grupo que define y acuerda
los Objetivos de Nivel de Servicio. El término Cliente –customer-
también se utiliza informalmente para Usuario, por ejemplo: "Esta
es una Organización enfocada al Usuario".
Cliente de Negocio (Estrategia del Servicio) El receptor de un producto o Servicio del
Negocio. Por ejemplo, si el Negocio es un fabricante de coches,
entonces el Cliente de Negocio es quien compra un coche.
COBIT (Mejora Continua del Servicio) Control Objectives for Information
and related Technology (COBIT) proporciona las directrices y
Mejores Prácticas para la gestión de los Procesos de TI. COBIT está
publicado por el IT Governance Institute. Vea www.isaca.org para
disponer de más información.
Cobro Diferencial Técnica utilizada para dar soporte a Gestión de la Demanda
cobrando diferentes cantidades para la misma Función del Servicio
de TI en momentos diferentes.
Comité de Cambios (CAB) (Transición del Servicio) Personal que asesora al Gestor de Cambios
en la Evaluación, priorización y planificación de los Cambios. Este
comité está formado por representantes de todas las áreas del
Proveedor de Servicios de TI, del Negocio y Proveedores Externos.
Componente Término genérico usado para definir una parte de algo más
complejo. Por ejemplo, un Sistema informático puede ser un
Componente de un Servicio de TI, una Aplicación puede ser un
Componente de una Unidad de Entrega. Los Componentes que
necesitan ser gestionados son los Elementos de Configuración.
Concurrencia Una medida del número de Usuarios dedicados a la misma
Operación al mismo tiempo.
Confidencialidad (Disen~o del Servicio) Principio de seguridad que requiere que sólo
personal autorizado pueda acceder a los datos.
Configuración (Transición del Servicio) Término genérico usado para describir
un grupo de Elementos de Configuración que actúan o funcionan
juntos para proveer un Servicio de TI, o un subconjunto
representativo de un Servicio de TI. El término Configuración
también se usa para describir los parámetros y ajustes realizados en
uno o más CI.
Conformidad Garantía del cumplimiento de un Estándar o conjunto de
Directrices, o que se emplean unas prácticas de seguimiento
adecuadas y consistentes.
Consejo de Dirección de TI (ISG) Un grupo formal que es responsable de asegurar que las Estrategias
y Planes del Negocio y el Proveedor de Servicios de TI se
alineen estrechamente. Un Consejo de Dirección de TI incluye a
representantes senior del Negocio y del Proveedor de servicios de
TI

824_024 Glossary.indd 308 22/1/10 14:01:38


Construir
Contabilidad de Costes
Contramedida
Contrato
Contrato de Soporte (UC)
Control
Control de Configuración
Control de Procesos
Coste
Coste Indirecto
Coste Operativo
Coste Total de Propiedad (TCO)
Costes de Actividad
824_024 Glossary.indd 309
Glosario | 309
(Transición del Servicio) La Actividad de montaje de un número de
Elementos de Configuración para crear parte de un Servicio de TI.
El termino Construir también se utiliza para hacer referencia a una
Versión que se autoriza para su distribución. Por ejemplo, Creación
de un Servidor o Creación de un ordenador portátil. Vea también
Línea de Referencia.
(Estrategia del Servicio) El Proceso responsable de identificar
los Costes de la entrega de Servicios de TI, comparándolos con
los costes presupuestados, y registrando las diferencias con el
Presupuesto.
Puede usarse para referirse a algún tipo de Control. El término
Contramedida es muy usado cuando se refiere a medidas que
incrementan la Capacidad de recuperación, Tolerancia a fallos o
Fiabilidad de un Servicio de TI.
Un Acuerdo legalmente obligatorio entre dos o más partes.
(Disen~o del Servicio) Un Contrato entre un Proveedor de Servicios
de TI y un Suministrador Externo. El Suministrador Externo
proporciona bienes o Servicios que soportan la entrega de un
Servicio de TI a Clientes. El Contrato de Soporte define objetivos
y responsabilidades que se requieren para alcanzar los Objetivos de
Nivel de Servicio en un SLA.
Un medio de gestión de Riesgo que asegura que se alcance el
Objetivo de Negocio, o que asegura que se sigue un Proceso. Por
poner ejemplos, los Controles incluyen Políticas, Procedimientos,
Roles, RAID, door-locks, etc. Por otra parte, algunas veces control
se denomina Contramedida o medida de seguridad. Control
también es un medio de gestionar el uso o comportamiento de un
Elemento de Configuración, Sistema o Servicio de TI.
(Transición del Servicio) La Actividad responsable de asegurar
que la adición, modificación o eliminación de un CI se gestionen
adecuadamente, por ejemplo enviando una Solicitud de Cambio o
Petición de Servicio.
Es la Actividad de planificación y regulación de un Proceso, con el
Objetivo de garantizar un desarrollo Eficiente, Eficaz y coherente
del Proceso.
La cantidad de dinero gastada en una Actividad específica, Servicio
de TI, o Unidad de Negocio. Los Costes consisten de un coste
real (dinero), coste por noción, tal como el tiempo de la gente y
Depreciación.
(Estrategia del Servicio) El Coste de proveer un Servicio de TI que
no se puede asignar completamente a un Cliente específico. Por
ejemplo, el Coste de proveer Servidores compartidos o licencias
de software. También conocido como Gasto General.
Coste que resulta de la ejecución de Servicios de TI. Con
frecuencia pagos por reparaciones. Por ejemplo, costes de
personal, electricidad y mantenimiento del hardware (también
conocido como ‘gastos corrientes’ o ‘gastos de explotación’).
(Estrategia del Servicio) Una metodología empleada para ayudar a
la toma de decisiones de inversión. TCO establece el Coste total
de propiedad de un Elemento de Configuración a lo largo de su
Ciclo de Vida, no sólo el Coste inicial o precio de compra.
Vea Coste Operativo.
22/1/10 14:01:38
 310 | Glosario

Criterios de Aceptación del Servicio (SAC) (Transición del Servicio) Un conjunto de criterios que se utilizan
para asegurar que un Servicio de TI cumpla su funcionalidad y
Requisitos de Calidad y que el Proveedor de Servicio de TI esté
preparado para Operar el nuevo Servicio de TI cuando haya sido
Desplegado. Vea también Aceptación.
Cuadro de Mando Integral (Mejora Continua del Servicio) Una herramienta de gestión
desarrollada por los Drs. Robert Kaplan (Harvard Business School)
y David Norton. Un Cuadro de Mando Integral permite dividir la
Estrategia en Indicadores Clave de Rendimiento. El Rendimiento
frente a los KPI se usa para demostrar lo bien que se ha alcanzado
la Estrategia. El Cuadro de Mando Integral tiene 4 áreas, cada
una tiene un número pequen~o de KPIs. Las mismas 4 áreas se
consideran en diferentes niveles de detalle en la Organización.
Cultura Un conjunto de valores que un grupo de personas comparte,
incluyendo expectativas acerca de cómo la gente debería
comportarse, sus creencias, ideas y prácticas. Vea también Visión.
Cultura de servicios Cultura orientada al Cliente. Los Objetivos principales de una
Cultura de Servicios es la satisfacción del Cliente y la ayuda al
Cliente a conseguir sus Objetivos de Negocio.
Cumplimiento Realizar Actividades para cumplir una necesidad o Requisito. Por
ejemplo, proporcionar un nuevo Servicio de TI, o cumplir una
Petición de Servicio.
Declaración de Requisitos (SOR) (Disen~o del Servicio) Un Documento que contiene todos los
Requisitos para una compra de producto, o de un Servicio de TI
nuevo o modificado. Vea también Términos de Referencia.
Dependencia La dependencia directa o indirecta de un Proceso o Actividad
sobre otro.
Derechos (Operación del Servicio) Los permisos concedidos a un Usuario
o Rol. Por ejemplo, el Derecho a modificar una información en
concreto, o a autorizar un Cambio.
Desarrollo (Disen~o del Servicio) Proceso responsable de crear o modificar un
Servicio de TI o Aplicación. También usado para referirse al Rol o
grupo encargado del trabajo de Desarrollo.
Descripción del Puesto de Trabajo Documento que define los Roles, responsabilidades, aptitudes
y conocimiento requeridos por una persona en particular. Una
Descripción del Puesto de Trabajo puede incluir múltiples Roles,
por ejemplo, los Roles de Gestor de la Configuración y Gestor de
Cambios pueden ser desempen~ados por una sola persona.
Despliegue (Transición del Servicio) La Actividad responsable del movimiento
de hardware, software, documentación, Procesos, etc, nuevos o
modificados, en un Entorno de Producción. Despliegue es parte
del Proceso de Gestión de Versiones y Despliegues.
Detección (Operación del Servicio) Etapa en el Ciclo de Vida de la Incidencia.
La detección de resultados en las Incidencias llevan a conocer
al Proveedor de Servicios. La detección puede ser automática, o
puede ser resultado de una Incidencia registrada por un Usuario.
Diagnóstico (Operación del Servicio) Una etapa en el Ciclo de vida de
Incidencias y Problemas. El propósito de Diagnóstico es identificar
una Solución Provisional para una Incidencia o la Causa Raíz de un
Problema.

824_024 Glossary.indd 310 22/1/10 14:01:38

 Glosario | 311

Dimensionamiento de la Aplicación (Disen~o del Servicio) Actividad responsable de entender los

Requisitos de Recursos necesarios para apoyar una nueva
Aplicación, o un Cambio importante de una Aplicación existente. El
Dimensionado de la Aplicación ayuda a asegurar que los Servicios
de TI cumplen con los Objetivos de Nivel de Servicio acordados
para la Capacidad y el Rendimiento.
Directriz Un Documento que describe las Mejores Prácticas que
recomiendan lo que se debe hacer. Normalmente no se obliga a la
conformidad con una directriz. Vea también Estándar.
Disen~o (Disen~o del Servicio) Actividad o Proceso que identifica Requisitos
y que a continuación define una solución que es capaz de alcanzar
dichos Requisitos. Vea también Disen~o del Servicio.
Disen~o del Servicio (Disen~o del Servicio) Una fase en el Ciclo de Vida de un Servicio
de TI. Disen~o del Servicio incluye varios Procesos y Funciones y
es el título de una de las publicaciones esenciales de ITIL. Vea
también Disen~o.
Disponibilidad (Disen~o del Servicio) Capacidad de un Elemento de Configuración
o de un Servicio de TI para realizar las Funciones acordadas
cuando se requiere. La Disponibilidad la determinan la Fiabilidad,
Capacidad de Mantenimiento, Capacidad de Servicio, Rendimiento,
y Seguridad. Normalmente la Disponibilidad se calcula en
porcentajes. Éste cálculo se basa normalmente en el Tiempo
de Servicio Acordado y en el Tiempo de Caída. Calcular la
Disponibilidad usando métricas de las salidas del Negocio respecto
del Servicio de TI se considera como una Mejor Práctica.
Disponibilidad Continua (Disen~o del Servicio) Método o disen~o para lograr el 100% de
Disponibilidad. Un Servicio de TI Disponible Continuamente no
tiene Paradas planificadas o sin planificar.
Distribución Automática de Llamada (ACD) (Operación del Servicio) El uso de las Tecnologías de la
Información para redirigir una llamada telefónica entrante hacia la
persona más adecuada en el menor tiempo posible. Algunas veces
se le llama Distribución Automatizada de Llamada.
Documento Información en forma legible. Un Documento puede estar en
papel o en formato electrónico. Por ejemplo, el establecimiento
de Política, Acuerdo de Nivel de Servicio, Registro de la Incidencia,
plano del diagrama de una sala de ordenadores. Vea también
Registro.
Economías de Escala (Estrategia del Servicio) La reducción en Coste promedio que será
posible incrementando la utilización de un Servicio de TI o un
Activo.
Eficacia (Mejora Continua del Servicio) Una medida de si se han alcanzado
los Objetivos de un Proceso, Servicio o Actividad. Una actividad o
Proceso Eficaz es cuando se alcanzan sus Objetivos acordados. Vea
también KPI.
Eficiencia (Mejora Continua del Servicio) Una medida de si se ha utilizado
la cantidad correcta de recursos para la provisión de un Proceso,
Servicio o Actividad. Un Proceso Eficaz alcanza sus Objetivos
con el mínimo de tiempo, dinero, personas u otros recursos. Vea
también KPI.

824_024 Glossary.indd 311 22/1/10 14:01:38

 312 | Glosario

Elemento de Configuración (CI) (Transición del Servicio) Cualquier Componente que necesite
ser gestionado con el objeto de proveer un Servicio de TI.
La información sobre cada CI se almacena en un Registro de
Configuración dentro del Sistema de Gestión de la Configuración
y se mantiene durante todo su Ciclo de Vida mediante Gestión
de la Configuración. Los CI están bajo el control de Gestión de
Cambios. Típicamente, los CI pueden ser Servicios de TI, hardware,
software, edificios, personal, y documentación formal como por
ejemplo documentación sobre Procesos y SLAs.
Empaquetado Vea también Producto Software Empaquetado.
Entorno (Transición del Servicio) Un subconjunto de la Infraestructura de TI
que se utiliza para un propósito particular. Por ejemplo: Entorno
de Producción, Entorno de Pruebas, Entorno de Construcción. Para
múltiples Entornos existirá la posibilidad de compartir Elementos
de Configuración, por ejemplo, Pruebas y Entornos de Producción
pueden usar diferentes particiones en un único ordenador
mainframe. También utilizado como un término de entorno físico
para definir instalaciones, aire acondicionado, sistema eléctrico, etc.
Entorno también se usa como término genérico para definir
condiciones externas que influyen o afectan en algo.
Entorno de Desarrollo (Disen~o del Servicio) Entorno usado para crear o modificar
Servicios de TI o Aplicaciones. Los Entornos de Desarrollo
normalmente no están sometidos al mismo grado de control que
el Entorno de Pruebas y Entornos de Producción. Vea también
Desarrollo.
Entorno de producción (Transición del Servicio) Entorno controlado que contiene
Elementos de Configuración Reales empleados para proveer
Servicios de TI a los Clientes.
Entrega (Transición del Servicio) Colección de hardware, software,
documentación, Procesos, u otros Componentes requeridos para
implementar uno o más Cambios aprobados en los Servicios
de TI. Los contenidos de cada Versión se gestionan, prueban, e
implementan como una única entidad.
Entregable Algo que se debe proporcionar para cumplir un compromiso en
un Acuerdo de Nivel de Servicio o en un Contrato. Entregable
también se usa en forma más informal para una salida planificada
de cualquier Proceso.
Error (Operación del Servicio) Un defecto o mal funcionamiento que
causa Fallos en uno o más Elementos de Configuración o Servicios
de TI. También se considerará un Error, aquel error cometido por
una persona o un Proceso defectuoso que impacta en un CI o en
un Servicio de TI.
Error Conocido (Operación del Servicio) Problema que tiene una Causa Raíz
documentada y una Solución Provisional . Los Errores Conocidos
se crean y gestionan a través de su Ciclo de Vida mediante Gestión
de Problemas. Desarrollo o Suministradores también podrían
identificar Errores Conocidos.
Escalabilidad Capacidad de un Servicio de TI, Proceso, Elemento de
Configuración, etc., a la hora de realizar su Función acordada
cuando la Carga de Trabajo o el Ámbito cambian.

824_024 Glossary.indd 312 22/1/10 14:01:38

 Glosario | 313

Escalado (Operación del Servicio ) Una Actividad que obtiene Recursos

adicionales cuando son necesarios para alcanzar las metas de
Nivel de Servicio o las expectativas del Cliente. Escalado puede
ser necesario dentro de cualquier Proceso de Gestión de los
Servicios de TI, pero normalmente se asocia más con Gestión de
Incidencias, Gestión de Problemas y Gestión de quejas de Clientes.
Hay dos tipos de Escalado: Funcional y Jerárquico.
Especificación Definición formal de Requisitos. Una Especificación puede usarse
para definir Requisitos Técnicos u Operativos, y puede ser interna
o externa. Muchos Estándares públicos consisten en un Código de
Práctica y una Especificación. La Especificación define el Estándar
frente al que una Organización puede ser Auditada.
Establecimiento de Precios (Estrategia del Servicio) Actividad que establece la cantidad que
debe ser Cobrada a los Clientes.
Estado Nombre de un campo requerido en muchos tipos de Registros.
Muestra la situación actual de un Elemento de Configuración,
Incidencia o Problema, etc., en su Ciclo de Vida.
Estándar Un Requisito obligatorio. Por ejemplo ISO/IEC 20000 (Estándar
internacional), una configuración de seguridad interna estándar para
Unix, o un estándar gubernamental acerca de cómo mantener los
Registros financieros. El término Estándar también se emplea para
definir un Código de Prácticas o Especificación publicada por una
Organización de Estándares como ISO o BSI. Vea también Directriz.
Estimación Uso de la experiencia para proporcionar un valor aproximado para
una Métrica o Coste. La Estimación también se usa en Gestión de
la Capacidad y de la Disponibilidad como método de Modelización
más económico y menos preciso.
Estrategia (Estrategia del Servicio) Plan Estratégico disen~ado para alcanzar
determinados Objetivos.
Estrategia del Servicio (Estrategia del Servicio) Título de uno de los libros Esenciales de
ITIL. La Estrategia del Servicio establece una Estrategia conjunta
para los Servicios de TI y para la Gestión de los Servicios de TI.
Estratégico (Estrategia del Servicio) El más elevado de los tres niveles de
Planificación y entrega (Estratégico, Táctico y Operativo). Las
Actividades Estratégicas incluyen el establecimiento de Objetivos y
la Planificación a largo plazo para alcanzar la Visión global.
Evaluación Inspección y análisis para verificar si se está siguiendo un Estándar
o un conjunto de Directrices, que sus Registros son precisos, o
que las metas de Eficiencia y Eficacia se están cumpliendo. Vea
también Auditoría.
Evaluación (Transición del Servicio) Proceso responsable de evaluar un
Servicio de TI nuevo o modificado para asegurar que los Riesgos
se han gestionado y para ayudar a determinar si se debe proceder
con el Cambio. La evaluación también se usa para comparar el
Resultado real con el pretendido, o comparar una alternativa con
otra.
Evaluación del Riesgo Los pasos iniciales de la Gestión del Riesgo. Analizar el valor de
los Activos del negocio, identificando Amenazas para esos Activos,
y evaluando la Vulnerabilidad de cada Activo con respecto a esas
Amenazas. La Evaluación del Riesgo puede ser cuantitativa (basada
en datos numéricos) o cualitativa.

824_024 Glossary.indd 313 22/1/10 14:01:38

 314 | Glosario

Evaluación Post Implementación (PIR) Se trata de la Revisión que se realiza tras la implementación de
un Cambio o de un Proyecto. Una PIR determina si el Cambio o
Proyecto se completó con éxito, e identifica nuevas oportunidades
de mejora.
Evento (Operación del Servicio) Un cambio de estado significativo para
la gestión de un Elemento de Configuración o un Servicio de T
I. El término Evento también se usa
como Alerta o notificación creada por un Servicio de TI, Elemento
de Configuración o herramienta de Monitorización. Los Eventos
requieren normalmente que el personal de Operaciones de TI tome
acciones, y a menudo conllevan el registro de Incidencias.
Externalización (Estrategia del Servicio) Uso de un Proveedor Externo de Servicios
para la gestión de Servicios de TI.
Factor Crítico de Éxito (CSF) Algo que debe existir si un Proceso, Proyecto, Plan, o Servicio
de TI desea ser exitoso. Los KPI se utilizan para medir el alcance
de cada CSF. Por ejemplo: un CSF de "proteger Servicios de TI
cuando se hacen Cambios" podría ser medible por KPIs tales como
"porcentaje de reducción de Cambios no exitosos", o "porcentaje
de reducción de Cambios que causen Incidencias", etc.
Fallo (Operación del Servicio) Pérdida de la habilidad de Operar de
acuerdo con las Especificaciones, o de proporcionar el resultado
requerido. El término Fallo puede usarse cuando nos referimos a
Servicios de TI, Procesos, Actividades, Elementos de Configuración,
etc. Un Fallo a menudo provoca una Incidencia.
Fallo Vea Error.
Fiabilidad (Disen~o del Servicio) (Mejora Continua del Servicio) Medida de
cuánto tiempo un Elemento de Configuración o Servicio de TI
puede ejecutar de forma ininterrumpida su Función acordada.
Generalmente medida como MTBF o MTBSI. El término Fiabilidad
también puede utilizarse para definir la probabilidad de que
un Proceso, Función, etc., responda de la forma esperada. Vea
también Disponibilidad.
Función Un equipo o grupo de personas y las herramientas
que usan para llevar a cabo uno o más Procesos o
Actividades. Por ejemplo, el Centro de Servicio al Usuario.
El término Función también tiene otros dos significados:
■■ El propósito de un Elemento de Configuración, Persona,
Equipo, Proceso o Servicio de TI. Por ejemplo, una Función del
Servicio de Correo Electrónico puede ser almacenar y reenviar
correos, una Función de un Proceso de Negocio puede ser
enviar bienes a Clientes.
■■ Realizar su propósito correctamente. “El ordenador funciona”.
Función Vital de Negocio (VBF) (Disen~o del Servicio) Una Función de un Proceso de Negocio que
es critica para el éxito del Negocio. Las Funciones Vitales del
Negocio son consideraciones importantes para la Gestión de la
Continuidad del Negocio, Gestión de la Continuidad del Servicio
de TI y Gestión de la Disponibilidad.
Garantía (Estrategia del Servicio) Una promesa o garantía que un producto
o Servicio cumplirá los Requisitos acordados. Vea también Garantía
del Servicio.

824_024 Glossary.indd 314 22/1/10 14:01:38

 Glosario | 315

Garantía del Servicio (Estrategia del Servicio) Seguridad de que un Servicio de TI

cumplirá los Requerimientos acordados. Puede ser un Acuerdo
formal como un SLA o Contrato, o un mensaje de marketing o
imagen de marca. El valor de Negocio de un Servicio de TI se crea
por la combinación de la Funcionalidad del Servicio (lo que el
Servicio hace) y la Garantía del Servicio (cómo de bien lo hace).
Vea también Garantía.
Gasto General Vea Coste Indirecto.
Gestión de Activos (Transición del Servicio) Proceso responsable de dar seguimiento e
informar del valor y la propiedad de los Activos financieros en todo
el Ciclo de Vida. La Gestión de Activos forma parte de los Activos
del Servicio y del Proceso de Gestión de la Configuración.
Gestión de Aplicaciones (Disen~o del Servicio) (Operación del Servicio) Función responsable
de gestionar las Aplicaciones en su Ciclo de Vida.
Gestión de Cambios (Transición del Servicio) Proceso responsable del control del
Ciclo de Vida de los Cambios. El objetivo principal de Gestión de
Cambios es permitir la ejecución de los Cambios a realizar, con la
mínima interferencia en los Servicios de TI.
Gestión de Capacidad del Negocio (BCM) (Disen~o del Servicio) En el contexto de ITSM, la Gestión de
Capacidad del Negocio es la Actividad responsable de conocer
los futuros Requisitos de Negocio para usarlos en el Plan de
Capacidad. Vea también Gestión de la Capacidad del Servicio.
Gestión de Continuidad de los Servicios de Tecnologías de la (Disen~o del Servicio) Proceso responsable de gestionar los Riesgos
Información (ITSCM) que podrían impactar seriamente a los Servicios de TI. ITSCM
asegura que el Proveedor de Servicios de TI pueda proporcionar
siempre los Niveles de Servicio mínimos acordados, reduciendo el
Riesgo a un nivel aceptable y Planificando la Recuperación de los
Servicios de TI. ITSCM debería disen~arse de tal manera que soporte
la Gestión de la Continuidad del Negocio.
Gestión de Crisis (Gestión de la Continuidad del Servicio de TI) Gestión de Crisis
es el Proceso responsable de gestionar las implicaciones más
amplias de Continuidad del Negocio. Un equipo de Gestión de
Crisis es responsable de problemas Estratégicos como mantener
las relaciones con los medios y la confianza de los accionistas, y
decide cuándo invocar los Planes de Continuidad del Negocio.
Gestión de Entregas y Despliegues (Transición del Servicio) Proceso responsable de ambos, Gestión
de la Versión y Despliegue.
Gestión de Eventos (Operación del Servicio) Proceso responsable de la gestión de
Eventos a lo largo de su Ciclo de Vida. La Gestión de Eventos es
una de las principales Actividades de Operaciones de TI.
Gestión de Incidencias (Operación del Servicio) Proceso responsable de la gestión del
Ciclo de Vida de todas las Incidencias. El objetivo principal de la
Gestión de Incidencias es recuperar lo antes posible el Servicio de
TI para los Usuarios.
Gestión de la Capacidad (Disen~o del Servicio) Proceso responsable de asegurar que la
Capacidad de los Servicios de TI y la Infraestructura de TI es capaz
de proveer los Objetivos de Nivel de Servicio en los tiempos y
Rentabilidad acordados. La Gestión de Capacidad tiene en cuenta
todos los Recursos requeridos para proveer el Servicio de TI, y la
planificación de los Requisitos de Negocio a corto, medio y largo
plazo.

824_024 Glossary.indd 315 22/1/10 14:01:39

 316 | Glosario
Gestión de la Capacidad del Componente
Gestión de la Capacidad del Servicio (SCM)
Gestión de la Configuración
Gestión de la Continuidad del Negocio (BCM)
Gestión de la Continuidad del Servicio
Gestión de la Demanda
Gestión de la Disponibilidad
Gestión de la Seguridad
Gestión de la Seguridad de la Información (ISM)
824_024 Glossary.indd 316
(Disen~o del Servicio) (Mejora Continua del Servicio) Proceso
responsable de la comprensión de la Capacidad, Utilización, y
Rendimiento de los Elementos de Configuración. Se recopilan
datos, se archivan y se analizan para su uso en el Plan de
Capacidad. Vea también Gestión de la Capacidad del Servicio.
(Disen~o del Servicio) (Mejora Continua del Servicio) La Actividad
responsable de comprender el Rendimiento y la Capacidad de los
Servicios de TI. Los Recursos usados por cada Servicio de TI y
el patrón de uso con el paso del tiempo se recogen, registran y
analizan para ser utilizados en el Plan de Capacidad. Vea también
Gestión de la Capacidad del Negocio y Gestión de la Capacidad
del Componente.
(Transición del Servicio) Proceso responsable de mantener
información sobre los Elementos de Configuración requeridos para
la provisión de un Servicio de TI, incluyendo las Relaciones entre
ellos. Esta información se gestiona durante todo el Ciclo de Vida
del CI. La Gestión de la Configuración forma parte de un Activo
del Servicio global y del Proceso de Gestión de la Configuración.
(Disen~o del Servicio) Es el proceso de negocio responsable de
gestionar los Riesgos que puede tener un alto impacto en el
Negocio. BCM protege los intereses de los principales interesados,
la reputación, la marca y las actividades que aportan valor al
Negocio. El Proceso de BCM incluye reducir el Riesgo a un nivel
aceptable y planificar el restablecimiento de los Procesos de
Negocio ante una situación. BCM establece los Objetivos, el
Ámbito y los Requisitos para una Gestión de la Continuidad del
Servicio de TI.
Vea Gestión de la Continuidad del Servicio de TI.
Actividades que entienden e influyen en la demanda del Cliente
de Servicios y en la provisión de Capacidad para cumplir con esas
demandas. Una Gestión de la Demanda de nivel Estratégico puede
incluir un análisis de Modelos de Actividad de Negocio y Perfiles
de Usuarios. Un nivel Táctico puede incluir el uso de Cobros
Diferenciales para alentar a los Usuarios a utilizar los Servicios de TI
en horas de baja actividad. Vea también Gestión de la Capacidad.
(Disen~o del Servicio) Proceso responsable de definir, analizar,
Planificar, medir y mejorar todos los aspectos relativos
a la Disponibilidad de los Servicios de TI. La Gestión de
la Disponibilidad tiene la responsabilidad de que toda la
Infraestructura de TI, Procesos, Herramientas, Roles, etc., estén
de acuerdo con los Objetivos de Nivel de Servicio para la
Disponibilidad.
Vea Gestión de la Seguridad de la Información.
(Disen~o del Servicio) Proceso que asegura la Confidencialidad,
Integridad y Disponibilidad de los Activos de una Organización,
información, datos y Servicios de TI. La Gestión de la Seguridad
de la Información normalmente forma parte de la Gestión de la
Seguridad de la Organización, la cual tiene un ámbito más amplio
que el del Proveedor de Servicios de TI e incluye accesos a
edificios, llamadas de teléfonos, etc., para toda la Organización.
22/1/10 14:01:39

Gestión de la Versión
Gestión de las Instalaciones
Gestión de las Relaciones con el Negocio
Gestión de los Servicios de TI (ITSM)
Gestión de Peticiones
Gestión de Problemas
Gestión de Sistemas
Gestión de Suministradores
Gestión del Conocimiento
824_024 Glossary.indd 317
Glosario | 317
(Transición del Servicio) Proceso responsable de la Planificación,
Programación y Control del movimiento de Versiones a Probar y
de Entornos de Producción. El Objetivo principal de la Gestión
de la Versión es asegurarse de que la integridad del Entorno
de Producción esté protegida y que se implementen los
Componentes correctos. La Gestión de la Versión es parte del
Proceso de Gestión de Versiones y Despliegues.
(Operación del Servicio) Función responsable de la gestión del
Entorno físico donde se ubique la Infraestructura de TI. Gestión
de las Instalaciones incluye todos los aspectos de la gestión del
Entorno físico, por ejemplo, alimentación o refrigeración, Gestión
de Accesos de los edificios, y Monitorización del entorno.
(Estrategia del Servicio) El Proceso o Función responsable del
mantenimiento de la Relación con el Negocio. Normalmente
incluye:
■■ Gestionar las Relaciones personales con los directivos del
Negocio
■■ Proporcionar información a la Gestión de la Cartera de
Servicios
■■ Asegurarse de que el Proveedor de Servicios de TI está
satisfaciendo las necesidades de Negocio de los Clientes
Este Proceso está fuertemente relacionado con la Gestión del Nivel
de Servicio.
Implantación y gestión de Servicios de TI de Calidad que cumplan
con las necesidades del Negocio. Los Proveedores de Servicios
de TI llevan a cabo la Gestión de los Servicios de TI a través de la
adecuada combinación de personas, Procesos y Tecnologías de la
Información. Vea también Gestión del Servicio.
(Operación del Servicio) Proceso responsable de la gestión del
Ciclo de Vida de todas las Peticiones de Servicio.
(Operación del Servicio) Proceso responsable de la gestión del
Ciclo de Vida de todos los Problemas. El principal Objetivo de la
Gestión de Problemas es la prevención de Incidencias, al igual que
la reducción del Impacto de aquellas Incidencias que no haya sido
posible prevenir.
La parte de Gestión de los Servicios de TI que se centra en la
gestión de la Infraestructura de TI en lugar del Proceso.
(Disen~o del Servicio) Proceso responsable de asegurar que
todos los Contratos y Proveedores soportan las necesidades del
Negocio, y que todos los Proveedores cumplen sus compromisos
contractuales.
(Transición del Servicio) Proceso responsable de recoger, analizar,
almacenar y compartir conocimiento e información dentro
de una Organización. El propósito principal de la Gestión del
Conocimiento es mejorar la Eficiencia reduciendo la necesidad de
redescubrir el conocimiento. Vea también Sistema de Gestión del
Conocimiento del Servicio.
22/1/10 14:01:39
 318 | Glosario

Gestión del Nivel de Servicio (SLM) (Disen~o del Servicio) (Mejora Continua del Servicio) Proceso
responsable de negociar y asegurar el cumplimiento de los
Acuerdos de Nivel de Servicio. SLM es responsable de asegurar que
todos los Procesos de Gestión de los Servicios de TI, Acuerdos
de Nivel Operativo y Contratos de Soporte son adecuados con
respecto a los Objetivos de Nivel de Servicio. SLM monitoriza e
informa de los Niveles de Servicio y mantiene revisiones periódicas
con el Cliente.
Gestión del Porfolio de Servicios (SPM) (Estrategia del Servicio) Proceso responsable de gestionar el
Porfolio de Servicios. La Gestión de la Cartera de Servicios
considera los Servicios en términos del valor para el Negocio que
proporcionan.
Gestión del Rendimiento (Mejora Continua del Servicio) Es el Proceso responsable de las
Actividades del día a día dentro de la Gestión de la Capacidad.
Incluye la monitorización, detección de umbrales, análisis de
Rendimiento y Ajuste, así como la implementación de Cambios
relacionados con el Rendimiento o la Capacidad.
Gestión del riesgo El Proceso responsable de identificar, evaluar y controlar Riesgos.
Vea también Evaluación del Riesgo.
Gestión del Riesgo (MoR) La metodología OGC para la gestión de Riesgos. MoR incluye
todas las Actividades necesarias para identificar y Controlar
toda exposición al Riesgo que pueda tener un impacto en la
consecución de los Objetivos de Negocio de la Organización. Vea
www.m-o-r.org para disponer de más detalles.
Gestión del Servicio La Gestión del Servicio es un conjunto de capacidades
organizativas especializadas empleadas para proporcionar valor a
los Clientes en forma de Servicios.
Gestión del Servicio de Negocio (BSM) (Estrategia del Servicio) (Disen~o del Servicio) Metodología de
gestión de Servicios de TI que tiene en cuenta los Procesos de
Negocio soportados y el Valor para el negocio proporcionado.
Este término también hace referencia a la gestión de Servicios de
Negocio entregados a Clientes del Negocio.
Gestión Financiera (Estrategia del Servicio) La Función y Procesos responsables de
gestionar los requisitos de Presupuesto, Contabilidad e Imputación
de Costes de un Proveedor de Servicios de TI.
Gestión Técnica (Operación del Servicio) La Función responsable de proporcionar
capacidades técnicas en el soporte de los Servicios de TI y en
la gestión de la Infraestructura de TI. La Gestión Técnica define
los roles de los Grupos de Soporte, así como las herramientas,
Procesos y Procedimientos requeridos.
Gestor del Servicio Gestor que es responsable de gestionar el Ciclo de Vida de uno
o más Servicios de TI de principio a fin. El término Gestor del
Servicio también se emplea para referirse a un gestor dentro del
Proveedor de Servicios de TI. Comúnmente empleado para referirse
al Gestor de Relaciones con el Negocio, Gestor de Procesos o
Gestor de Cuentas o un gestor con responsabilidad en el conjunto
de Servicios de TI.
Gobierno Asegurar que se implementan las Políticas y Estrategias, y que se
siguen correctamente los Procesos requeridos. El Gobierno incluye
definir los Roles y Responsabilidades, medir y generar informes, y
tomar acciones para resolver cualquier problema identificado.

824_024 Glossary.indd 318 22/1/10 14:01:39


Grupo de Soporte
Habilidad
Historia del Cambio
Horario Acordado de Servicio
Horario de Soporte
Horario del servicio
Identificación de Configuración
Impacto
Impulsor
Imputación de Costes
Incidencia
Incidencia Grave
824_024 Glossary.indd 319
Glosario | 319
(Operación del Servicio) Un grupo de personas con capacidades
técnicas. Los Grupos de Soporte proporcionan el Soporte Técnico
necesario para todos los Procesos de Gestión de los Servicios de
TI. Vea también Gestión Técnica.
(Estrategia del Servicio) Capacidad de una Organización, persona,
Proceso, Aplicación, Elemento de Configuración o Servicio de TI
para el desarrollo de una Actividad. Las Habilidades son Activos
intangibles de una Organización. Vea también Recurso.
(Transición del Servicio) Información sobre todos los cambios
realizados en un Elemento de Configuración durante su vida útil.
La Historia del Cambio consta de todos los Registros de Cambio
que afectan al CI.
(Disen~o del Servicio) Un sinónimo para las horas de Servicio,
utilizado normalmente en cálculos formales de Disponibilidad. Vea
también Tiempo de Caída.
(Disen~o del Servicio) (Operación del Servicio) Los plazos u horas
en los que se ofrece soporte a los Usuarios. Normalmente son las
horas en las que el Centro de Servicio al Usuario está disponible.
El Horario de Soporte debería definirse en un Acuerdo de Nivel
de Servicio y puede no coincidir con el Horario del Servicio. Por
ejemplo, el Horario del Servicio puede ser 24 horas al día, pero el
Horario de Soporte puede ser de 07:00 a 19:00.
(Disen~o del Servicio) (Mejora Continua del Servicio) Un periodo
de tiempo acordado cuando debería estar Disponible un Servicio
de TI en particular. Por ejemplo, ‘Lunes-Viernes de 08:00 a 17:00
excepto días festivos’. El Horario del Servicio debe definirse en un
Acuerdo de Nivel de Servicio.
(Transición del Servicio) Actividad responsable de recopilar
información sobre Elementos de Configuración y sus Relaciones,
y cargar esta información en la CMDB. Identificación de
Configuración también es responsable de etiquetar los propios
CIs, para que se puedan encontrar los Registros de Configuración
correspondientes.
(Operación del Servicio) (Transición del Servicio) Una medida del
efecto de una Incidencia, Problema o Cambio en los Procesos
de Negocio. Normalmente el Impacto se basa en cómo se verán
afectados los Niveles de Servicio. El Impacto y la Urgencia se
emplean para asignar la Prioridad.
Algo que influye en la Estrategia, Objetivos o Requisitos. Por
ejemplo, una nueva legislación o las acciones de competidores.
(Estrategia del Servicio) Requerir el pago por la provisión de
Servicios de TI. La Imputación de Costes para Servicios de TI es
opcional, y muchas Organizaciones optan por tratar a su Proveedor
de Servicios de TI como un Centro de Coste.
(Operación del Servicio) Interrupción no planificada de un Servicio
de TI o reducción en la Calidad de un Servicio de TI. También
lo es el Fallo de un Elemento de Configuración que todavía no
ha impactado en el Servicio. Por ejemplo, el Fallo de uno de los
discos de un “mirror”.
(Operación del Servicio) La Categoría mayor de Impacto para
una Incidencia. Una Incidencia Grave genera una interrupción
significativa del Negocio.
22/1/10 14:01:39
 320 | Glosario
Indicador Clave de Rendimiento (KPI)
Información de Gestión
Informe de Excepciones
Informes del servicio
Infraestructura de TI
Instalación Portátil
Instrucción de Trabajo
Integridad
Interesado
Internalización
ISO 9000
824_024 Glossary.indd 320
(Disen~o del Servicio) Métrica empleada para ayudar a gestionar
un Proceso, Servicio de TI o Actividad. Muchas Métricas pueden
medirse pero sólo las más importantes se definen como KPIs y
son empleadas para gestionar de forma activa e informar sobre los
Procesos, los Servicios de TI o las Actividades. Los KPI deberían
seleccionarse de tal forma que aseguren el control de la Eficiencia,
la Eficacia, y la Rentabilidad. Vea también Factor Crítico de Éxito.
Información empleada para apoyar la toma de decisiones de
los gestores. La Información de Gestión a menudo se genera
automáticamente a través de las herramientas que soportan los
diversos Procesos de Gestión de Servicios de TI. La Información
de Gestión suele incluir los valores de los KPI como por ejemplo
"Porcentaje de Cambios precedidos por Incidencias", o "tasa de
resolución en primera instancia".
Un documento que contiene detalles de uno o más KPIs u otros
objetivos importantes que hayan superado los Umbrales definidos.
Por ejemplo, objetivos de los SLA fallidos o a punto de ello, y
Métricas de Rendimiento que indiquen un problema potencial de
Capacidad.
(Mejora Continua del Servicio) Proceso responsable de la
generación y entrega de los informes de cumplimiento y
tendencias de Niveles de Servicio. Los Informes del Servicio deben
acordar con los Clientes el formato, contenido y frecuencia de los
informes.
Todo el hardware, software, redes, instalaciones etc. requeridas
para Desarrollar, Probar, proveer, Monitorizar, Controlar o soportar
los Servicios de TI. El término Infraestructura de TI incluye todas
las Tecnologías de la Información pero no las personas, Procesos y
documentación asociados.
(Disen~o del Servicio) Edificio prefabricado, o un vehículo grande,
provisto por un suministrador externo y que se desplaza hasta
una ubicación cuando lo requiera un Plan de Continuidad de los
Servicios de TI. Vea también Opción de Recuperación.
Un Documento que contiene instrucciones detalladas que
especifican exactamente qué pasos seguir para acometer una
Actividad. Una Instrucción de Trabajo contiene muchos más
detalles que un Procedimiento y sólo se crea cuando se necesitan
instrucciones muy detalladas.
(Disen~o del Servicio) Un principio de seguridad que certifica
que sólo personal y Actividades autorizados puedan modificar
Elementos de Configuración. La Integridad considera todas las
posibles causas de modificación, incluyendo Fallos de software y
hardware, Eventos medioambientales e intervención humana.
Conjunto de personas que tienen interés en una Organización,
Proyecto, Servicio de TI, etc. Los Interesados pueden interesarse en
las Actividades, Objetivos, Recursos o Entregables. Los Interesados
pueden incluir Clientes, Asociaciones, empleados, accionistas,
propietarios, etc. Vea también RACI.
Vea Aprovisionamiento de Servicios Interno.
Término genérico que se refiere a un conjunto de Estándares y
Directrices para los Sistemas de Gestión de la Calidad. Vea www.
iso.org para disponer de más información. Vea también ISO.
22/1/10 14:01:39
 Glosario | 321

ISO 9001 Un Estándar internacional para los Sistemas de Gestión de la

Calidad. Vea también ISO 9000, Estándar.
ISO/IEC 20000 Especificación ISO y Código de Práctica para la Gestión de los
Servicios de TI. ISO/IEC 20000 está alineado con las Mejores
Prácticas ITIL.
ISO/IEC 27001 (Disen~o del Servicio) (Mejora Continua del Servicio) Especificación
ISO para la Gestión de la Seguridad de la Información. El Código
de Práctica correspondiente es ISO/IEC 17799. Vea también
Estándar.
ITIL Conjunto de Mejores Prácticas para la Gestión de los Servicios
de TI. ITIL es propiedad de la OGC y consiste en una serie de
publicaciones que aconsejan sobre la provisión de Servicios de TI
de Calidad, y sobre los Procesos y las instalaciones necesarias para
soportarlos. Vea www.itil.co.uk para disponer de más información.
La calidad Característica de un producto, Servicio o Proceso para proporcionar
su propio valor. Por ejemplo, un Componente hardware puede
ser considerado de alta Calidad si rinde según lo esperado y
proporciona la Fiabilidad requerida. La Calidad de un Proceso
requiere la capacidad para medir su Eficacia y Eficiencia, o incluso
para mejorarlas si fuese necesario. Vea también Sistema de Gestión
de la Calidad.
Línea de Referencia (Mejora Continua del Servicio) Una Referencia que se usa como
punto de referencia. Por ejemplo:
■■ Una Línea de Referencia de ITSM se puede usar como punto
de partida para medir el resultado de un Plan de Mejora del
Servicio
■■ Una Línea de Referencia de Rendimiento se puede usar para
medir cambios en el Rendimiento de un Servicio de TI en un
periodo de tiempo
■■ Una Línea de Referencia de la Gestión de la Configuración
puede servir para restablecer la Infraestructura de TI en una
Configuración conocida en caso de fallo de un Cambio o de
un Entregable.
Línea de Referencia de Configuración (Transición del Servicio) Una Línea de Referencia de una
Configuración que ha sido acordada formalmente y se gestiona
a través del proceso de Gestión de Cambios. Una Línea de
Referencia de una Configuración sirve de base para futuras
Construcciones, Entregas y Cambios.
Línea de Servicio (LOS) (Estrategia del Servicio) Servicio Esencial o Servicio de Soporte
que posee múltiples Paquetes del Nivel de Servicio. Una Línea de
Servicio es gestionada por un Gestor de Producto y cada Paquete
del Nivel de Servicio se designa para soportar un segmento de
mercado en particular.
Llamada (Operación del Servicio) Llamada telefónica de un Usuario al
Centro de Servicio al Usuario. Una Llamada puede derivar en el
registro de una Incidencia o una Petición de Servicio.
Madurez (Mejora Continua del Servicio) Medida de la Fiabilidad, Eficiencia y
Eficacia de un Proceso, Función, Organización, etc. Los Procesos
y Funciones más maduros están íntimamente alineados con los
Objetivos de Negocio y con la Estrategia, y están soportados por
un marco de trabajo para la mejora continua.

824_024 Glossary.indd 321 22/1/10 14:01:39

 322 | Glosario

Mejor Práctica Actividades o Procesos que más de una Organización han usado
con éxito. ITIL es un ejemplo de Mejor Práctica.
Mejora Continua del Servicio (CSI) (Mejora Continua del Servicio) Una etapa en el Ciclo de Vida de un
Servicio de TI y el título de una de las publicaciones esenciales de
ITIL. La Mejora Continua del Servicio es responsable de la gestión
de mejoras en los Procesos de Gestión de los Servicios de TI y de
los Servicios de TI. El Rendimiento de los Proveedores de Servicios
de TI se mide continuamente y las mejoras se realizan en los
Procesos, Servicios de TI e Infraestructura de TI para incrementar su
Eficiencia y Eficacia, y Rentabilidad. Vea también Planificar–Hacer–
Verificar–Actuar.
Métrica (Mejora Continua del Servicio) Algo que se mide y de lo que
se informa para ayudar a gestionar un Proceso, Servicio de TI o
Actividad. Vea también KPI.
Middleware (Disen~o del Servicio) Software que conecta uno o más
Componentes o Aplicaciones software. El Middleware
generalmente se adquiere de un Suministrador, en lugar de
desarrollarlo dentro del Proveedor de Servicios de TI. Vea también
Empaquetado.
Modelado Técnica que se emplea para predecir el comportamiento futuro de
un Sistema, Proceso, Servicio de TI, Elemento de Configuración,
etc. El Modelado suele emplearse en Gestión Financiera, Gestión
de Capacidad y Gestión de la Disponibilidad.
Modelado analítico (Estrategia del Servicio) (Disen~o del Servicio) (Mejora Continua
del Servicio) Técnica que usa Modelos matemáticos para predecir
el comportamiento de un Elemento de Configuración o Servicio
de TI. Los Modelos Analíticos suelen emplearse habitualmente
en Gestión de la Capacidad y Gestión de la Disponibilidad. Vea
también Modelado.
Modelo Representación de un Sistema, Proceso, Servicio de TI, Elemento
de Configuración, etc., que se emplea para ayudar a entender o
predecir comportamientos futuros.
Modelo de Madurez del eSourcing para Proveedores de Servicio (Estrategia del Servicio) Un marco de trabajo para ayudar a los
(eSCM-SP) Proveedores de Servicios de TI a desarrollar sus Capacidades
de Gestión de los Servicios de TI desde una perspectiva de
Aprovisionamiento del Servicio. eSCM-SP fue desarrollado por la
Carnegie Mellon University, EE.UU.
Monitorización (Operación del Servicio) Observación repetida de un Elemento de
Configuración, Servicio de TI o Proceso para detectar Eventos y
asegurarse de que se conoce el estado actual.
Monitorización Pasiva (Operación del Servicio) Monitorización de un Elemento de
Configuración o un Servicio de TI o un Proceso que radica en una
Alerta o notificación para descubrir el estado actual.
Negocio (Estrategia del Servicio) El total de una entidad u Organización
compuesta por un número de Unidades de Negocio. En el
contexto de ITSM, en el Negocio se incluye tanto el sector público
como el privado, y organizaciones sin fines de lucro. Un Proveedor
de Servicios de TI provee Servicios de TI a un Cliente que es parte
del Negocio. El Proveedor de Servicios de TI puede ser parte del
mismo Negocio que el Cliente (Proveedor Interno de Servicios) o
parte de otro Negocio (Proveedor Externo de Servicios).

824_024 Glossary.indd 322 22/1/10 14:01:39

 Glosario | 323

Nivel de servicio Resultados medidos e informados frente a uno o más Objetivos de

Nivel de Servicio. El término Nivel de Servicio se emplea a veces
para referirse a un Objetivo de Nivel de Servicio.
Objetivo El propósito o la intención definidos de un Proceso, una Actividad
o una Organización en su totalidad. Los Objetivos se expresan
generalmente como metas medibles. El término Objetivo se usa
también de manera informal para Requisito. Vea también Salida.
Objetivo de Negocio (Estrategia del Servicio) El Objetivo de un Proceso de Negocio, o
del Negocio como un todo. Los Objetivos de Negocio apoyan la
Visión de Negocio, proporcionan guías para la Estrategia de TI, y
normalmente reciben apoyo de los Servicios de TI.
Objetivos de Nivel de Servicio (Disen~o del Servicio) (Mejora Continua del Servicio) Compromiso
que está documentado en un SLA. Los Objetivos de Nivel de
Servicio se basan en los Requisitos de Nivel de Servicio y son
necesarios para asegurar que el Disen~o del Servicio de TI se Ajuste
al Propósito del mismo. Los Objetivos de Nivel de Servicio deben
ser SMART y normalmente se basan en KPIs.
Office of Government Commerce (OGC) OGC consiguió la marca ITIL (derechos de autor y marca
registrada). OGC es un departamento del Gobierno del Reino
Unido que da soporte a la realización de la agenda de compras
del gobierno gracias a su trabajo en alianzas de contratación y a
sus elevados niveles de aptitudes y habilidades de compra con
distintos departamentos. También proporciona soporte a proyectos
complejos para el sector público.
Off-shore (Estrategia del Servicio) Provisión de Servicios desde una
localización externa al país del Cliente y, frecuentemente, en
diferente continente. Puede tratarse de la provisión de un Servicio
de TI, o de Funciones de soporte como por ejemplo un Centro de
Servicio al Usuario. Vea también On-shore.
On-shore (Estrategia del Servicio) Provisión de Servicios desde el propio país
del Cliente. Vea también Off-shore.
Opción de Recuperación (Disen~o del Servicio) Estrategia para responder a una interrupción
del Servicio. Las Estrategias usadas habitualmente son No
Hacer Nada, Solución Provisional Manual, Acuerdo Recíproco,
Recuperación Gradual, Recuperación Intermedia, Recuperación
Rápida, Recuperación Inmediata. Las Opciones de Recuperación
podrían hacer uso de facilidades dedicadas, o Facilidades de
Suministradores Externos compartidas por múltiples Negocios.
Operación (Operación del Servicio) Gestión del día a día de un Servicio de
TI, un Sistema, u otro Elemento de Configuración. El término
Operación se usa también para referirse a una Actividad o
Transacción predefinida. Por ejemplo, la carga de una cinta
magnética, la recogida de importes en un punto de venta, o la
lectura de datos desde una unidad de disco.
Operación Continua (Disen~o del Servicio) Método o disen~o para eliminar la Parada
planificada de un Servicio de TI. Tenga en cuenta que los
Elementos de Configuración pueden estar parados incluso si el
Servicio de TI está Disponible.
Operación del Servicio (Operación del Servicio) Una fase en el Ciclo de Vida de un
Servicio de TI. La Operación del Servicio incluye varios Procesos y
Funciones y es uno de los títulos esenciales en las publicaciones
de ITIL. Vea también Operación.

824_024 Glossary.indd 323 22/1/10 14:01:40

 324 | Glosario

Operaciones de Negocio (Estrategia del Servicio) La ejecución del día a día, la

monitorización y la gestión de los Procesos de Negocio.
Operaciones de TI (Operación del Servicio) Actividades desempen~adas por Control de
Operaciones de TI, incluyendo Gestión de Consolas, Planificación
de Tareas, Backup y Restauración, y Gestión de Salida e Impresión.
Operaciones de TI se utiliza también como sinónimo de Operación
del Servicio.
Operar Obtener un rendimiento esperado. Se dice que un Proceso o un
Elemento de Configuración Opera, cuando está proporcionando el
resultado requerido. Operar también puede referirse a la realización
de una o más Operaciones. Por ejemplo, Operar un PC consiste
en la realización de las Operaciones diarias que necesita para su
rendimiento correcto.
Operativo El nivel inferior de los 3 niveles de la Planificación y Entrega
(Estratégico, Táctico, Operativo). Las Actividades Operativas
incluyen la Planificación o entrega del día a día de un Proceso de
Negocio o de un Proceso de Gestión de los Servicios de TI. El
término Operativo puede usarse como sinónimo del término Real.
Optimizar Revisar, Planificar y solicitar Cambios para obtener la máxima
Eficiencia y Eficacia de un Proceso, Elemento de Configuración,
Aplicación, etc.
Organización Una compan~ía, entidad legal u otra institución. Como ejemplos de
Organizaciones que no se consideran empresas se pueden incluir
la Organización Internacional para la Normalización o itSMF. El
término Organización se utiliza algunas veces para hacer referencia
a una entidad que tiene Personas, Recursos y Presupuestos. Por
ejemplo, una Unidad de Negocio o Proyecto.
Organización Internacional para la Normalización (ISO) La Organización Internacional para la Normalización (ISO) es
el mayor desarrollador de Estándares del mundo. ISO es una
organización no gubernamental que constituye una red de
Institutos de Estandarización nacionales de 156 países. Vea www.
iso.org para disponer de más información sobre ISO.
Panel de Control (Operación del Servicio) Representación gráfica de Resultados
generales de Servicios de TI y Disponibilidad. El Panel de Control
podría actualizarse en tiempo real y también puede incluirse en
informes de gestión y en páginas web. Los Paneles de Control
puede utilizarse para ayudar en la Gestión del Nivel de Servicio,
Gestión de Eventos o Diagnóstico de Incidencias.
Paquete de Nivel de Servicio (SLP) (Estrategia del Servicio) Nivel definido de Utilidad y Garantía
para un determinado Paquete de Servicio. Cada SLP se disen~a
para cumplir con las necesidades de un determinado Patrón de
Actividad de Negocio. Vea también Línea de Servicio.
Paquete para el Disen~o del Servicio (Disen~o del Servicio) Documentos que definen todos los aspectos
de un Servicio de TI y sus Requisitos a través de cada etapa de su
Ciclo de Vida. Se produce un Paquete para el Disen~o del Servicio
para cada nuevo Servicio de TI, Cambio importante o Retirada de
Servicio de TI.
Parada Planificada (Disen~o del Servicio) Tiempo acordado cuando un Servicio de TI
no esté disponible. Parada Planificada se utiliza normalmente para
mantenimiento, actualizaciones y prueba. Vea también Ventana
para el Cambio, Tiempo de Caída.

824_024 Glossary.indd 324 22/1/10 14:01:40

 Glosario | 325

Patrones de Actividad de Negocio (PBA) (Estrategia del Servicio) Es un perfil de Carga de Trabajo de una o
más Actividades de Negocio. Los Patrones de Actividad de Negocio
se utilizan para ayudar al Proveedor de Servicios de TI a entender
y planificar en función de los diferentes niveles de Actividad de
Negocio.
Perspectiva de control (Estrategia del Servicio) Un acercamiento a la gestión de Servicios
de TI, Procesos, Funciones, Activos, etc. Pueden haber varias
Perspectivas de Control diferentes para un mismo Servicio de
TI, Procesos, etc., permitiendo a diferentes individuos o equipos
centrarse en lo que es importante y relevante para su Rol
específico. Como ejemplos de Perspectivas de Control se pueden
incluir gestión Reactiva y Proactiva dentro de Operaciones de
TI, o una visión de Ciclo de vida para un equipo de Proyecto de
Aplicaciones.
Perspectiva del Negocio (Mejora Continua del Servicio) El entendimiento del punto de vista
del Negocio por parte del Proveedor de Servicio y de los Servicios
de TI, y un entendimiento del Negocio desde el punto de vista del
Proveedor de Servicio.
Petición de Cambio Vea Solicitud de Cambio.
Petición de Cambio (RFC) (Transición del Servicio) Propuesta formal para que se realice un
Cambio. Una RFC incluye detalles del Cambio propuesto, y puede
registrarse en papel o electrónicamente. El término RFC se suele
confundir con Registro de Cambio, o con el Cambio en sí.
Petición de Servicio (Operación del Servicio) Petición que hace un Usuario solicitando
información, asesoramiento, un Cambio Estándar o Acceso a
un Servicio de TI. Por ejemplo, la inicialización de una clave, o
proporcionar a un nuevo Usuario Servicios de TI estándares. Las
Peticiones de Servicio se gestionan normalmente mediante un
Centro de Servicio al Usuario, y no requieren que se realice una
RFC. Vea también Gestión de Peticiones.
Piloto (Transición del Servicio) Despliegue limitado de un Servicio de TI,
una Versión o un Proceso en el Entorno de Producción. Un piloto
se usa para reducir el Riesgo y para obtener retroalimentación del
Usuario y la Aceptación. Vea también Prueba, Evaluación.
Plan Propuesta detallada que describe las Actividades y Recursos
necesarios para la consecución de un Objetivo. Por ejemplo, el
Plan para implementar un nuevo Proceso o Servicio de TI. ISO/IEC
20000 requiere un Plan como parte de la gestión de cada Proceso
de Gestión de los Servicios de TI.
Plan de Capacidad (Disen~o del Servicio) Plan de Capacidad que se utiliza para
gestionar los Recursos requeridos para entregar Servicios de TI. El
Plan contiene escenarios para diferentes predicciones de demanda
de Negocio, y las opciones valoradas para proveer los Objetivos de
Nivel de Servicio.
Plan de Continuidad de los Servicios de TI (Disen~o del Servicio) Plan que define los pasos requeridos para
Recuperar uno o más Servicios de TI. El Plan también identificará
los disparadores para la Invocación, personas a involucrar,
comunicaciones, etc. El Plan de Continuidad de los Servicios de TI
deberá formar parte de un Plan de Continuidad del Negocio.

824_024 Glossary.indd 325 22/1/10 14:01:40

 326 | Glosario
Plan de Continuidad del Negocio (BCP)
Plan de Disponibilidad
Planificación
Planificación de Cambios
Planificación de la Capacidad
Planificación de Trabajos
Planificar-Hacer-Verificar-Actuar
PMBOK
Política
Política de Seguridad
Política de Seguridad de la Información
824_024 Glossary.indd 326
(Disen~o del Servicio) Un plan que define los pasos requeridos para
Restaurar Procesos de Negocio después de una interrupción. El Plan
también identificará los disparadores para la Invocación, personas
a involucrar, comunicaciones, etc. El Plan de Continuidad de los
Servicios de TI deberá formar parte significativa de los Planes de
Continuidad del Negocio.
(Disen~o del Servicio) Plan para asegurar que se puedan proveer de
forma rentable los Requisitos de Disponibilidad actuales y futuros
para Servicios de TI.
Una Actividad responsable de la creación de uno o más Planes. Por
ejemplo, Planificación de la Capacidad.
(Transición del Servicio) Documento que enumera todos los
Cambios aprobados y su fecha prevista de implementación. Una
Planificación de Cambios también se conoce como Lista de
Cambios Planificados, incluso puede contener información sobre
Cambios que ya se han implementado.
(Disen~o del Servicio) Actividad del proceso de Gestión de
Capacidad responsable de la creación de un Plan de Capacidad.
(Operación del Servicio) Planificación y gestión de la ejecución de
las tareas del software que se requieren como parte de un Servicio
de TI. La Planificación de Trabajos se realiza mediante Gestión
de Operaciones de TI, y con frecuencia se automatiza usando
herramientas de software que realizan tareas por lotes u online en
momentos específicos del día, semana, mes o an~o.
(Mejora Continua del Servicio) Ciclo de gestión de Procesos en
cuatro etapas, y atribuido a Edward Deming. Plan-Do-Check-Act es
también conocido como el Ciclo de Deming.
PLAN (planificar): Disen~ar o revisar Procesos que soportan Servicios
de TI.
DO (hacer): Implementación del Plan y gestión de los Procesos.
CHECK (verificar): Medición de los Procesos y los Servicios de
TI, comparación con los Objetivos marcados y generación de
informes.
ACT (actuar): Planificación e implementación de Cambios para la
mejora de los Procesos.
Estándar de Gestión de Proyectos mantenido y publicado por el
Project Management Institute. PMBOK son las siglas de Project
Management Body of Knowledge (Cuerpo de Conocimiento de
Gestión de Proyectos). Vea www.pmi.org para disponer de más
información. Vea también PRINCE2.
Documento formal que contiene las intenciones y expectativas
de gestión. Las Políticas se utilizan para dirigir las decisiones, y
asegurar un desarrollo e implementación coherente y apropiado de
los Procesos, Estándares, Roles, Actividades, Infraestructura de TI,
etc.
Vea Política de Seguridad de la Información.
(Disen~o del Servicio) La Política que gobierna un método de la
Organización para Gestión de la Seguridad de la Información.
22/1/10 14:01:40
 Glosario | 327

Porfolio de Aplicaciones (Disen~o del Servicio) Una base de datos o Documento estructurado
que se usa para gestionar Aplicaciones en su Ciclo de Vida. El
Porfolio de Aplicaciones contiene Atributos que son clave para
todas las Aplicaciones. Algunas veces el Porfolio de Aplicaciones
se implementa como parte del Porfolio de Servicios, o como parte
del Sistema de Gestión de la Configuración.
Porfolio de Servicios (Estrategia del Servicio) Conjunto de todos los Servicios que son
gestionados por un Proveedor de Servicios. El Porfolio de Servicios
se emplea para gestionar el Ciclo de Vida completo de todos los
Servicios, e incluye tres Categorías: Flujo de Creación de Servicios
(propuestos o en Desarrollo); Catálogo de Servicios (Reales o
disponibles para su Despliegue); y Servicios Retirados. Vea también
Gestión de la Cartera de Servicios.
Práctica Se trata de un método de trabajo o forma en la que debería
realizarse el trabajo. Las Prácticas pueden incluir Actividades,
Procesos, Funciones, Estándares y Directrices. Vea también Mejor
Práctica.
Prerrequisitos para el Éxito (PFS) Una actividad que debe completarse, o una condición que se debe
cumplir, para permitir la implementación exitosa de un Plan o
Proceso. Un PFS es frecuentemente una salida de un Proceso que
es una entrada requerida para otro Proceso.
Presupuestar La Actividad para predecir y controlar el gasto de dinero.
Es un ciclo de negociaciones periódicas para establecer
futuros Presupuestos (normalmente en periodos anuales) y la
monitorización y ajuste diario del Presupuesto actual.
Presupuesto Lista de todo el dinero que una Organización o una Unidad de
Negocio ha planificado recibir y pagar en un periodo de tiempo
específico. Vea también Presupuestar, Planificación.
PRINCE2 Metodología de Gestión de Proyectos estándar del gobierno del
Reino Unido. Vea www.ogc.gov.uk/prince2 para disponer de más
información. Vea también PMBOK.
Prioridad (Transición del Servicio) (Operación del Servicio) Categoría
empleada para identificar la importancia relativa de una Incidencia,
Problema o Cambio. La Prioridad se basa en el Impacto y la
Urgencia, y se utiliza para identificar los plazos requeridos para la
realización de las diferentes acciones. Por ejemplo, el SLA podría
indicar que las Incidencias de Prioridad 2 deben resolverse en
menos de 12 horas.
Problema (Operación del Servicio) Causa de una o más Incidencias. En el
momento en el que se crea el Registro de Problemas, no es
frecuente conocer su causa, por lo que es necesario realizar su
investigación mediante el Proceso de Gestión de Problemas.
Procedimiento Documento que contiene los pasos que se deben seguir para la
realización de una determinada Actividad. Los Procedimientos se
definen como partes de Procesos. Vea también Instrucción de
Trabajo.

824_024 Glossary.indd 327 22/1/10 14:01:40

 328 | Glosario

Proceso Conjunto estructurado de Actividades disen~ado para la consecución

Proceso de Negocio
Procesos de Relación
Producto Software Empaquetado (COTS)
Proforma
Programa
Programa de Mejora de Servicio (SIP)
Propietario del Proceso
Propietario del Servicio
Proveedor de Servicio
Proveedor de Servicios de Aplicaciones (ASP)
Proveedor de Servicios de TI
Proveedor Externo de Servicios
de un Objetivo determinado. Los Procesos requieren una o más
entradas y producen una serie de salidas, ambas previamente
definidas. Un Proceso suele incorporar la definición de los Roles
que intervienen, las responsabilidades, herramientas y Controles
de gestión necesarios para obtener las salidas de forma eficaz.
El Proceso podrá definir las Políticas, Estándares, Directrices,
Actividades, y las Instrucciones de Trabajo que sean necesarias.
Un Proceso que pertenece y que lo lleva a cabo el Negocio. Un
Proceso de Negocio contribuye a la entrega de un producto o
Servicio para un Cliente de Negocio. Por ejemplo, un revendedor
podría tener un Proceso de compra que ayudara a entregar
Servicios a sus Clientes de Negocio. Muchos de los Procesos de
Negocio están basados en Servicios de TI.
El grupo de Proceso ISO/IEC 20000 que incluye Gestor de las
Relaciones con el Negocio y Gestión de Suministradores.
(Disen~o del Servicio) Software de aplicación o Middleware que se
puede comprar de un Suministrador externo.
Una plantilla, o Documento de ejemplo que contiene datos de
muestra que serán sustituidos por los valores reales cuando estén
disponibles.
Conjunto de Proyectos y Actividades planificadas y gestionadas
como una unidad para la obtención de unos Objetivos y Salidas
comunes.
(Mejora Continua del Servicio) Un Plan formal para implementar
mejoras en un Proceso o Servicio de TI.
Es el Rol responsable de asegurar que un Proceso Coincide con su
Propósito. Las responsabilidades del Propietario del Proceso cubren
el patrocinio, Disen~o, Gestión de Cambios y mejora continua
del Proceso y sus Métricas. Este Rol se asigna comúnmente a la
persona que desempen~a también el Rol de Gestor del Proceso,
aunque en grandes Organizaciones, ambos Roles pueden estar
separados.
(Mejora Continua del Servicio) Rol responsable de la entrega de un
determinado Servicio de TI.
(Estrategia del Servicio) Organización que presta Servicios a uno
o más Clientes Internos o Externos. El término de Proveedor de
Servicio se usa a menudo como forma abreviada de Proveedor de
Servicios de TI.
(Disen~o del Servicio) Un proveedor de Servicio Externo que
proporciona Servicios de TI utilizando Aplicaciones que se ejecutan
en las instalaciones del proveedor de Servicio. Los usuarios
acceden a las Aplicaciones a través de conexiones de red hasta el
proveedor de Servicio.
(Estrategia del Servicio) Proveedor de Servicio que proporciona
Servicios de TI a Clientes Internos o Externos.
(Estrategia del Servicio) Un Proveedor de Servicios de TI que
forma parte de una Organización diferente a la de su Cliente.
Un Proveedor de Servicios de TI puede tener Clientes Internos o
Externos.

824_024 Glossary.indd 328 22/1/10 14:01:40


Proveedor Interno de Servicio
Proyecto
Prueba
Punto Único de Fallo (SPOF)
RACI
Real
Recuperación
Recuperación Gradual
Recuperación Inmediata
Recuperación Inmediata
Recuperación Intermedia
824_024 Glossary.indd 329
Glosario | 329
(Estrategia del Servicio) Proveedor de Servicios de TI que forma
parte de la misma Organización que su Cliente. Un Proveedor de
Servicios de TI puede tener Clientes Internos o Externos.
Se trata de una Organización temporal, compuesta por personal
y por los Activos requeridos para la obtención de los Objetivos
y Salidas necesarios. Cada Proyecto tiene un Ciclo de Vida que
típicamente incluye inicio, Planificación, ejecución, Cierre, etc.
Los Proyectos se gestionan habitualmente mediante metodologías
formales, como puede ser PRINCE2.
(Transición del Servicio) Una Actividad que verifica que un
Elemento de Configuración, Servicio de TI, Proceso, etc. cumple
con sus Especificaciones o Requisitos acordados. Vea también
Aceptación.
(Disen~o del Servicio) Cualquier Elemento de Configuración que
puede provocar una Incidencia cuando falla y para el que no
se ha implementado una Contramedida. Un SPOF puede ser
tanto una persona, un paso en un Proceso o Actividad como un
Componente de la Infraestructura de TI. Vea también Fallo.
(Disen~o del Servicio) (Mejora Continua del Servicio) Un Modelo
usado como ayuda para definir roles y responsabilidades. RACI
significa Encargado, Responsable, Consultados e Informados.
(Transición del Servicio) Hace referencia a un Servicio de TI o
Elemento de Configuración que se está usando para entregar un
Servicio a un Cliente.
(Disen~o del Servicio) (Operación del Servicio) Recuperar un
Elemento de Configuración o un Servicio de TI hasta el estado de
funcionamiento. Recuperar un Servicio de TI incluye normalmente
la recuperación de datos para llegar un estado consistente.
Después de la recuperación podrían ser necesarios otros pasos
antes de que los Servicios de TI puedan estar disponibles para los
Usuarios (Restauración).
(Disen~o del Servicio) Una Opción de Recuperación que es también
conocida como Recuperación Gradual. Se realiza la provisión para
la Recuperación del Servicio de TI en un período superior a 72
horas. La Recuperación Gradual normalmente usa una Instalación
Portátil o Fija que cuenta con soporte ambiental y cableado de
red, pero no Sistemas informáticos. El hardware y software se
instalan dentro del Plan de Continuidad de los Servicios de TI.
Vea también Recuperación Rápida.
(Disen~o del Servicio) Una Opción de Recuperación que es
también conocida como Recuperación Inmediata. Se realiza la
provisión para Recuperar el Servicio de TI sin pérdida de Servicio.
La Recuperación Inmediata normalmente usa tecnologías de
Duplicación, Equilibrio de Carga y Ubicación Dividida.
(Disen~o del Servicio) Una Opción de Recuperación que es también
conocida como Recuperación Intermedia. Se realiza la provisión
para la Recuperación del Servicio de TI en un período de tiempo
entre 24 y 72 horas. Recuperación Intermedia utiliza típicamente
una Facilidad Fija o Portátil compartida que tiene Sistemas de
Ordenador y Componentes de Red. El hardware y software
necesitarán configurarse, y los datos necesitarán almacenarse,
como parte del Plan de Continuidad de los Servicios de TI.
22/1/10 14:01:40
 330 | Glosario

Recuperación Intermedia (Warm Standby) Vea Recuperación intermedia.

Recuperación Rápida (Disen~o del Servicio) Una Opción de Recuperación que es también
conocida como Recuperación Inmediata. Se realiza la provisión
para la Recuperación del Servicio de TI en un corto período de
tiempo: típicamente menos de 24 horas. La Recuperación Rápida
normalmente usa una Instalación Fija dedicada con Sistemas
informáticos y software configurado y dispuesto a ejecutar los
Servicios de TI. La Recuperación Rápida puede llevar hasta 24 horas
si hay necesidad de Restaurar datos de Backups.
Recurso (Estrategia del Servicio) Término genérico que incluye
Infraestructura de TI, personal, dinero o cualquier otra cosa que
pueda ayudar a entregar un Servicio de TI. A los Recursos se les
considera como el Activo de una Organización. Vea también
Habilidad, Activo del Servicio.
Red de Valor (Estrategia del Servicio) Un complejo conjunto de relaciones entre
dos o más grupos u organizaciones. El valor es generado a través
del intercambio de conocimiento, información, bienes o Servicios.
Vea también Cadena de valor, Asociación.
Redundancia Vea Tolerancia a Fallos.
El término Redundante también tiene un significado de obsoleto, o
de que ya no es necesario.
Registro Un Documento que contiene el resultado u otro tipo de salida
desde un Proceso o Actividad. Los registros son la evidencia de
que una Actividad tuvo lugar, y podría estar en papel o en formato
electrónico. Por ejemplo, un informe de Auditoría, un Registro de
la Incidencia, o los minutos de una reunión.
Registro de la Incidencia (Operación del Servicio) Registro que contiene los detalles de una
Incidencia. Cada Registro de la Incidencia documenta el Ciclo de
Vida de una sola Incidencia.
Registro de la Versión (Transición del Servicio) Registro en la CMDB que define el
contenido de una Versión. Un Registro de la Versión tiene Relación
con todos los Elementos de Configuración que se ven afectados
por la Versión.
Relación Conexión o interacción entre dos personas o cosas. En la Gestión
de las Relaciones con el Negocio es la interacción entre el
Proveedor de Servicios de TI y el Negocio. En la Gestión de la
Configuración es el enlace entre dos Elementos de Configuración
que identifican una dependencia o conexión entre ellos. Por
ejemplo, las Aplicaciones se pueden vincular con los Servidores
sobre los que se ejecutan. Los Servicios de TI pueden tener
muchos enlaces a todos los CI que los forman.
Rendimiento (Disen~o del Servicio) Una medida del número de Transacciones u
otras Operaciones realizadas en un tiempo fijo. Por ejemplo 5000
correos electrónicos enviados por hora, o 200 E/S de disco por
segundo.
Rendimiento Medida de la respuesta obtenida por un Sistema, persona, equipo,
Proceso, o Servicio de TI.
Rentabilidad Una medida del equilibrio entre la Eficacia y el Coste de un
Servicio, Proceso o actividad. Un Proceso Rentable es aquel
proceso que alcanza su Objetivo al mínimo Coste. Vea también
KPI, Retorno de la Inversión, Valor Obtenido por el Dinero.

824_024 Glossary.indd 330 22/1/10 14:01:40

 Glosario | 331

Reparación (Operación del Servicio) La sustitución o corrección de un

Elemento de Configuración fallido.
Requisito (Disen~o del Servicio) Una declaración formal de lo que se necesita.
Por ejemplo: un Requisito de Nivel de Servicio, un Requisito
de Proyecto, o los Entregables requeridos para un Proceso. Vea
también Declaración de Requisitos.
Requisito de Nivel de Servicio (SLR) (Disen~o del Servicio) (Mejora Continua del Servicio) Requisito del
Cliente para un aspecto de un Servicio de TI. Los SLR se basan en
Objetivos de Negocio y se usan para negociar los Objetivos de
Nivel de Servicio acordados.
Resolución (Operación del Servicio) Acción tomada para reparar la Causa Raíz
de una Incidencia o Problema o para implementar una Alternativa.
En ISO/IEC 20000, el Proceso de Resolución es el grupo de
Procesos que incluye la Gestión de Problemas e Incidencias.
Restauración (Operación del Servicio) Acción para restaurar un Servicio de TI
para los Usuarios tras Reparar y Recuperarse de una Incidencia. Este
es el Objetivo Principal de la Gestión de Incidencias.
Restauración del Servicio Vea Restaurar.
Retirar (Transición del Servicio) Eliminación permanente de un Servicio de
TI u otro Elemento de Configuración del Entorno de Producción.
La Retirada es una etapa en el Ciclo de Vida de muchos Elementos
de Configuración.
Retorno a la Normalidad (Disen~o del Servicio) La fase de un Plan de Continuidad de los
Servicios de TI durante la cual se reanudan completamente
las operaciones normales. Por ejemplo, si un centro de datos
alternativo ha estado en uso, esta fase devolverá al centro de datos
principal de nuevo a la operación y restaurará la capacidad para
invocar de nuevo Planes de Continuidad de los Servicios de TI.
Retorno de la Inversión (ROI) (Estrategia del Servicio) (Mejora Continua de Servicio) Medida del
beneficio esperado de una inversión. En su significado más sencillo
es el beneficio neto de una inversión dividida por el valor de los
Activos invertidos.
Retroceder Vea Corrección.
Revisión La evaluación de un Cambio, Problema, Proceso, Proyecto, etc. Las
Revisiones habitualmente se llevan a cabo en puntos predefinidos
en el Ciclo de Vida, y especialmente tras el Cierre. El propósito de
una Revisión es asegurarse de que se han suministrado todos los
Entregables, e identificar oportunidades de mejora. Vea también
Evaluación Post Implementación.
Riesgo Un posible Evento que podría causar dan~o o pérdida, o afectar
a la capacidad de alcanzar Objetivos. Un Riesgo se mide por la
probabilidad de una Amenaza, la Vulnerabilidad del Activo a esa
Amenaza, y por el Impacto que tendría en caso de producirse.
Rol Conjunto de responsabilidades, Actividades y autorizaciones
concedidas a una persona o equipo. Un Rol se define en un
Proceso. Una persona o equipo puede tener múltiples Roles,
por ejemplo, una misma persona y de manera individual puede
llevar a cabo los Roles de Gestor de la Configuración y Gestor de
Cambios.

824_024 Glossary.indd 331 22/1/10 14:01:41

 332 | Glosario
Salida
Seguridad
Separación en Asuntos (SoC)
Servicio
Servicio de Infraestructura
Servicio de Negocio
Servicio de Soporte
Servicio de TI
Servicio Técnico
Servicios Gestionados
Servidor
Simulación
824_024 Glossary.indd 332
Es el resultado de la realización de una Actividad, el seguimiento
de un Proceso, la entrega de un Servicio de TI, etc. El término
Salida se emplea para referirse a los resultados esperados, al igual
que a los resultados reales. Vea también Objetivo.
Vea Gestión de la Seguridad de la Información.
(Estrategia del Servicio) Aproximación al Disen~o de una solución
o Servicio de TI que divide el problema en partes que pueden ser
resueltas de forma independiente. Esta aproximación separa “lo
que” se tiene que hacer de “como“ se tiene que hacer.
Un medio de entregar valor a los Clientes facilitando Resultados
que los Clientes quieren lograr sin la propiedad de Costes y
Riesgos específicos.
Un Servicio de TI que el Negocio no usa directamente, pero que el
Proveedor de Servicio de TI necesita para poder proporcionar otros
Servicios de TI. Por ejemplo Servicios de Directorio, servicios de
nombrado o servicios de comunicación.
Servicio de TI que sustenta directamente un Proceso de Negocio,
en contraposición a un Servicio de Infraestructura que el Proveedor
de Servicios de TI usa internamente y que normalmente no tiene
visibilidad hacía el Negocio.
El término Servicio de Negocio también se usa para definir un
Servicio que se provee a Clientes de Negocio a través de Unidades
de Negocio. Por ejemplo, la provisión de servicios financieros a
Clientes de un banco, o la provisión de bienes a Clientes en una
tienda de venta al por menor. La provisión exitosa de Servicios de
Negocio a menudo depende de uno o más Servicios de TI.
(Estrategia del Servicio) Un Servicio que posibilita o mejora un
Servicio Esencial. Por ejemplo, un Servicio de Directorio o un
Servicio de Backup.
Servicio que un Proveedor de Servicios de TI proporciona a
uno o más Clientes. Un Servicio de TI se basa en el uso de las
Tecnologías de la Información y soporta los Procesos de Negocio
del Cliente. Un Servicio de TI se compone de una combinación
de personas, Procesos y tecnología y debería estar definido en un
Acuerdo de Nivel de Servicio.
Vea Servicio de Infraestructura.
(Estrategia del Servicio) Perspectiva sobre los Servicios de TI que
enfatiza el hecho de que son gestionados. El término Servicios
Gestionados se emplea también como sinónimo de Servicios de TI
Externalizados.
(Operación del Servicio) PC que está conectado a la red y que
provee Funciones de software que usan otros PC.
(Disen~o del Servicio) (Mejora Continua del Servicio) Técnica que
crea un Modelo detallado para predecir el comportamiento de
un Elemento de Configuración o Servicio de TI. Los Modelos
de Simulación pueden ser muy precisos pero suelen ser caros y
tardan en crearse. Un Modelo de Simulación se crea a menudo
empleando los Elementos de Configuración reales que se quieren
modelizar, con Transacciones o Cargas de Trabajo artificiales. Se
usan en Gestión de la Capacidad cuando se necesitan resultados
precisos. A veces se denominan Benchmark de Rendimiento.
22/1/10 14:01:41

Sistema
Sistema de Gestión
Sistema de Gestión de Calidad (QMS)
Sistema de Gestión de la Configuración (CMS)
Sistema de Gestión de Seguridad de la Información (ISMS)
Sistema de Gestión del Conocimiento del Servicio (SKMS)
Sistema de Información de Gestión de la Capacidad (CMIS)
Sistema de Información de Gestión de la Disponibilidad (AMIS)
SMART
824_024 Glossary.indd 333
Glosario | 333
Número de cosas relacionadas que trabajan juntas para conseguir
un Objetivo común. Por ejemplo:
■■ Un Sistema Informático completo, incluyendo hardware,
software y Aplicaciones
■■ Un sistema de Gestión, incluyendo múltiples Procesos que
se planifican y gestionan juntos. Por ejemplo, un Sistema de
Gestión de la Calidad
■■ Un Sistema de Gestión de Bases de Datos o un Sistema
Operativo que incluye muchos módulos de software que se
disen~an para realizar un conjunto de Funciones relacionadas.
Marco de trabajo de Políticas, Procesos y Funciones que asegura
que una Organización puede alcanzar sus Objetivos.
(Mejora Continua del Servicio) Conjunto de Procesos responsables
de asegurar que el trabajo será realizado por una Organización con
la Calidad necesaria para satisfacer las necesidades de los Objetivos
de Negocio o Niveles de Servicio. Vea también ISO 9000.
(Transición del Servicio) Conjunto de herramientas y bases de
datos usadas para gestionar los datos de Configuración de un
Proveedor de Servicios de TI. El CMS también incluye información
sobre Incidencias, Problemas, Errores Conocidos, Cambios y
Versiones; y puede contener datos sobre empleados, Proveedores,
ubicaciones, Unidades de Negocio, Clientes y Usuarios. El CMS
consta de herramientas para recopilar, almacenar, gestionar,
actualizar, y mostrar datos sobre todos los Elementos de
Configuración y sus Relaciones. El CMS se mantiene a través de
Gestión de la Configuración y lo usan todos los Procesos de
Gestión de los Servicios de TI. Vea también Sistema de Gestión del
Conocimiento del Servicio.
(Disen~o del Servicio) Marco de Políticas, Procesos, Estándares,
Directrices y herramientas que aseguran que una Organización
puede alcanzar sus objetivos en la Gestión de la Seguridad de la
Información.
(Transición del Servicio) Conjunto de herramientas y bases
de datos que se emplean para gestionar el conocimiento y la
información. El SKMS incluye tanto el Sistema de Gestión de la
Configuración como otras herramientas y bases de datos. El SKMS
almacena, gestiona, actualiza y presenta toda la información que
un Proveedor de Servicios de TI necesita para gestionar todo el
Ciclo de Vida de los Servicios de TI.
(Disen~o del Servicio) Repositorio virtual que contiene todos los
datos de la Gestión de Capacidad que normalmente se almacenan
en múltiples ubicaciones físicas. Vea también Sistema de Gestión
del Conocimiento del Servicio.
(Disen~o del Servicio) Repositorio virtual que contiene todos los
datos de la Gestión de la Disponibilidad que normalmente se
almacenan en múltiples ubicaciones físicas. Vea también Sistema
de Gestión del Conocimiento del Servicio.
(Disen~o del Servicio) (Mejora Continua del Servicio) Acrónimo
para ayudar a recordar que los objetivos en los Acuerdos de Nivel
de Servicio y Planes de Proyecto deben ser Específicos (Specific),
Medibles (Measurable), Alcanzables (Achievable), Relevantes
(Relevant) y viables en Tiempo (Timely).
22/1/10 14:01:41
 334 | Glosario
Solución Provisional
Solución Provisional Manual
Soporte técnico
Standby
Suministrador
Suministrador Externo
Táctico
Tecnologías de la Información (TI)
Tercera Línea de Soporte
Términos de Referencia (TOR)
824_024 Glossary.indd 334
(Operación del Servicio) Reducción o eliminación del Impacto de
una Incidencia o Problema para el que todavía no está disponible
una Resolución completa. Por ejemplo, reinicio de un Elemento
de Configuración fallido. Las Soluciones Provisionales para
Problemas se documentan en los Registros de Errores Conocidos.
Las Soluciones Provisionales para Incidencias que no tienen
asociados Registros de Problemas se documentan en el Registro de
Incidencias.
Una Solución Provisional que requiere intervención manual.
Solución Provisional Manual también se usa como el nombre de
una Opción de Recuperación en la que el Proceso de Negocio
Opera sin el uso de Servicios de TI. Esta es una medida temporal
que normalmente se combina con otra Opción de Recuperación.
Vea Gestión Técnica.
(Disen~o del Servicio) Empleado para referirse a Recursos que no
son necesarios para entregar los Servicios de TI reales, pero que
están disponibles para soportar los Planes de Continuidad de
Servicio de TI. Por ejemplo un Centro de datos de Reserva puede
mantenerse para dar soporte a acuerdos de Sobreavisos Calientes,
Medios o Fríos.
(Estrategia del Servicio) (Disen~o del Servicio) Tercero responsable
de suministrar bienes o Servicios que son necesarios para
proporcionar Servicios de TI. Ejemplos de suministradores incluyen
los vendedores de hardware y software, proveedores de redes y
telecomunicaciones y Organizaciones de Outsourcing. Vea también
Contrato de Soporte, Cadena de Suministro.
Una persona, grupo, o Negocio que no es parte del Acuerdo de
Nivel de Servicio para un Servicio de TI, pero que es necesaria para
asegurar el éxito de la entrega de ese Servicio de TI. Por ejemplo,
un Proveedor de software, una empresa de mantenimiento de
hardware, o el departamento de instalaciones. Los requisitos para
los Terceros están normalmente especificados en Contratos de
Soporte o Acuerdos de Nivel Operativo.
El nivel medio de los 3 niveles de la Planificación y Entrega
(Estratégico, Táctico, Operativo). Las Actividades Tácticas incluyen
los Planes a medio plazo requeridos para alcanzar Objetivos
específicos, típicamente a lo largo de un periodo de semanas o
meses.
Uso de la tecnología para el almacenamiento, comunicación o
procesado de información. La tecnología incluye típicamente
ordenadores, telecomunicaciones, Aplicaciones y otro software. La
información puede incluir datos de Negocio, voz, imágenes, video,
etc. Las Tecnologías de la Información (TI) se utilizan a menudo
para apoyar los Procesos de Negocio a través de Servicios de TI.
(Operación del Servicio) El tercer nivel en una jerarquía de los
Grupos de Soporte implicados en la resolución de Incidencias y en
la investigación de Problemas. Cada nivel contiene más habilidades
especialistas, o tienen más tiempo u otros recursos.
(Disen~o del Servicio) Un Documento que especifica los Requisitos,
Ámbito, Entregables, Recursos y programación para un Proyecto o
Actividad.
22/1/10 14:01:41
 Glosario | 335

Tiempo de Caída (Disen~o del Servicio) (Operación del Servicio) El tiempo en el

que un Elemento de Configuración o un Servicio de TI no
está Disponible durante un Tiempo Acordado de Servicio. La
Disponibilidad de un Servicio de TI normalmente se calcula a partir
del Tiempo Acordado de Servicio y del Tiempo de Caída.
Tiempo de Respuesta Una medida del tiempo para completar una Operación o
Transacción. Usado en la Gestión de Capacidad como medida
del Rendimiento de la Infraestructura de TI, y en la Gestión
de Incidencias como una medida del tiempo consumido para
contestar una llamada, o iniciar el Diagnóstico.
Tiempo Medio de Reparación (MTTR) Tiempo medio dedicado a reparar un Elemento de Configuración
o Servicio de TI tras un Fallo. MTTR se mide desde que el CI o
Servicio de TI falla hasta que es reparado. MTTR no incluye el
tiempo necesario para Recuperar o Restaurar. MTTR se emplea
algunas veces de forma incorrecta para querer decir Tiempo Medio
de Restauración del Servicio.
Tiempo Medio de Restauración del Servicio (MTRS) Tiempo medio dedicado a restaurar un Elemento de Configuración
o Servicio de TI tras un Fallo. MTTS se mide desde que el CI o
Servicio de TI falla hasta que está completamente Restaurado
y dando su funcionalidad normal. Vea también Mantenibilidad,
Tiempo Medio de Reparación.
Tiempo Medio Entre Fallos (MTBF) (Disen~o del Servicio) Métrica para medir e informar de la Fiabilidad.
MTBF es el tiempo medio que un Elemento de Configuración
o Servicio de TI puede realizar su Función concertada sin
interrupción.. Se mide desde que el CI o Servicio de TI empieza a
funcionar, hasta que falla la siguiente vez.
Tiempo Medio entre Incidencias de Servicio (MTBSI) (Disen~o del Servicio) Métrica que sirve para medir e informar de
la Fiabilidad. MTBSI es el tiempo medio desde cuando falla un
Sistema o Servicio de TI, hasta el siguiente fallo. MTBSI es igual a
MTBF + MTRS.
Tolerancia a Fallos (Disen~o del Servicio) Habilidad de un Servicio de TI ó Elemento
de Configuración para continuar con su Operación correcta tras el
Fallo de un Componente. Vea también Capacidad de Recuperación,
Contramedida.
Tormenta de ideas (Operación del Servicio) Una técnica que ayuda a un equipo
a generar ideas. Las ideas no se revisan durante la sesión de
Tormenta de ideas, pero sí en una etapa posterior. Gestión de
Problemas utiliza normalmente Tormenta de ideas para identificar
causas posibles.
Transacción Una Función discreta realizada por un Servicio de TI. Por ejemplo,
transferir dinero de una cuenta bancaria a otra. Un transacción
simple puede involucrar numerosas adiciones, borrados y
modificaciones de datos. Ya se completen todas con éxito o
ninguna se lleve a cabo.
Transición (Transición del Servicio) Un cambio de estado, correspondiente
al movimiento de un Servicio de TI u otro Elemento de
Configuración de un estado de su Ciclo de Vida a otro.
Transición del Servicio (Transición del Servicio) Una fase en el Ciclo de Vida de un
Servicio de TI. Transición del Servicio incluye varios Procesos y
Funciones y es el título de una de las publicaciones esenciales de
ITIL. Vea también Transición.

824_024 Glossary.indd 335 22/1/10 14:01:41

 336 | Glosario

Turno (Operación del Servicio) Un grupo o equipo de personas que

realizan un Rol específico durante un periodo de tiempo fijado.
Por ejemplo, podrían haber cuatro turnos del personal de Control
de Operaciones de TI para dar soporte a un Servicio de TI que se
usa las 24 horas al día.
Umbral El valor de una Métrica que debe provocar la generación de una
Alerta, o que se tome una acción de gestión. Por ejemplo, “una
incidencia de prioridad 1 no resuelta en 4 horas”, “más de 5 errores
leves de disco en una hora”, o “más de 10 cambios fallidos en un
mes”.
Unidad de Negocio (Estrategia del Servicio) Segmento del Negocio que tiene sus
propios Planes, Métricas, ingresos y Costes. Cada Unidad de
Negocio posee Activos y los usa para crear valor para sus Clientes
en forma de bienes y Servicios.
Urgencia (Transición del Servicio) (Disen~o del Servicio) Una medida del
tiempo en el que una Incidencia, Problema o Cambio tendrá un
Impacto significativo para el Negocio. Por ejemplo, una Incidencia
de alto Impacto puede tener una Urgencia baja si el Impacto no
afectara al Negocio hasta el final del an~o fiscal. El Impacto y la
Urgencia se emplean para asignar la Prioridad.
Usabilidad (Disen~o del Servicio) La facilidad mediante la cual una Aplicación,
producto o Servicio de TI puede usarse. Los Requisitos de
Usabilidad se incluyen a menudo en una Declaración de
Requerimientos.
Usuario Una persona que usa el Servicio de TI diariamente. Los usuarios
son distintos a los Clientes, dado que algunos Clientes no usan el
Servicio de TI directamente.
Utilidad (Estrategia del Servicio) Funcionalidad ofrecida por un Producto
o Servicio para satisfacer una necesidad específica. La utilidad a
menudo se resume en “lo que hace”.
Validación (Transición del Servicio) Una Actividad que asegura que un
Servicio de TI, Proceso, Plan u otro Entregable nuevo o cambiado
satisface las necesidades del Negocio. La Validación asegura que
se satisfacen los Requisitos de Negocio incluso aunque éstos se
combinen desde su disen~o original. Vea también Verificación,
Aceptación.
Valor Obtenido por el Dinero Una medida informal de la Rentabilidad. Valor Obtenido por el
Dinero se basa a menudo en la comparación con el Coste de las
alternativas. Vea también Análisis Coste-Beneficio.
Varianza La diferencia entre un valor previsto y el valor real medido. Se
usa comúnmente en Gestión Financiera, Gestión de Capacidad y
Gestión del Nivel de Servicio, pero puede aplicarse en cualquier
área donde se empleen Planes.
Ventana para el Cambio (Transición del Servicio) Un tiempo regular, acordado, en el
que se pueden implementar los Cambios o Entregas con un
mínimo impacto en los Servicios. Las Ventanas para el Cambio
normalmente se documentan en SLAs.
Verificación (Transición del Servicio) Una Actividad que asegura que un Servicio
de TI, Proceso, Plan u otro Entregable nuevo o modificado, sea
completo, preciso, Fiable y esté de acuerdo con su especificación
de disen~o. Vea también Validación, Aceptación.

824_024 Glossary.indd 336 22/1/10 14:01:41

 Glosario | 337

Versión (Transición del Servicio) Una Versión se usa para identificar una
Línea de Referencia específica o un Elemento de Configuración.
Las Versiones emplean normalmente una convención de
identificación que posibilita identificar la secuencia o fecha de
cada Línea de Referencia. Por ejemplo Aplicación de Nóminas
Versión 3 contiene funcionalidades actualizadas de la Versión 2.
Visión Una descripción de lo que la Organización intenta ser en el futuro.
El Equipo Directivo creará una Visión y se usará para influir en la
Cultura y en la Planificación Estratégica.
Vulnerabilidad Una debilidad que puede ser aprovechada por una Amenaza.
Por ejemplo, un puerto abierto en el cortafuegos, una clave de
acceso que no se cambia, o una alfombra inflamable. También se
considera una Vulnerabilidad un Control perdido.

824_024 Glossary.indd 337 22/1/10 14:01:41

824_024 Glossary.indd 338 22/1/10 14:01:41
6403 SD SPAN COV v0_3.indd 2 21/1/10 13:02:23
 Los servicios bien diseñados desempeñan un rol esencial para
conseguir una estrategia del servicio acertada. Un diseño eficaz
contribuye a la entrega de servicios de calidad que cumplan o
superen las expectativas del cliente.

Este libro muestra cómo crear activos del servicio de TI valiosos

para su organización, aunque dentro de las limitaciones del
negocio, como son el tiempo y el dinero. Proporciona un marco
de trabajo para el diseño del servicio que tiene en cuenta los
Diseño del Servicio
requisitos del cliente, presentes y futuros, manteniendo con
firmeza la visión del negocio.

La organización itSMF International, a través de su Subcomité

Ejecutivo de Publicaciones Internacionales (IPESC), integrado por
miembros de todos los capítulos de itSMF en todo el mundo, ha
concedido la aprobación formal de itSMF International a este libro.

Diseño del Servicio

ISBN 978-0-11-331226-9

9 780113 312269
www.tso.co.uk

6403 SD SPAN COV v0_3.indd 1 21/1/10 13:02:12